[要約] RFC 7223は、インターフェース管理のためのYANGデータモデルを提供するものであり、ネットワークデバイスのインターフェースの設定と監視を効率化することを目的としています。
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 7223 Tail-f Systems
Category: Standards Track May 2014
ISSN: 2070-1721
A YANG Data Model for Interface Management
インターフェース管理のためのYANGデータモデル
Abstract
概要
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).
このドキュメントは、ネットワークインターフェースの管理のためのYANGデータモデルを定義します。インターフェイスタイプ固有のデータモデルは、このドキュメントで定義されている一般的なインターフェイスデータモデルを補強することが期待されています。データモデルには、構成データと状態データ（統計情報を収集するためのステータス情報とカウンター）が含まれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7223.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7223で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Tree Diagrams ..............................................4
2. Objectives ......................................................4
3. Interfaces Data Model ...........................................5
3.1. The Interface Lists ........................................6
3.2. Interface References .......................................7
3.3. Interface Layering .........................................7
4. Relationship to the IF-MIB ......................................8
5. Interfaces YANG Module .........................................11
6. IANA Considerations ............................................26
7. Security Considerations ........................................26
8. Acknowledgments ................................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................28
Appendix A. Example: Ethernet Interface Module ....................29
Appendix B. Example: Ethernet Bonding Interface Module ............30
Appendix C. Example: VLAN Interface Module ........................31
Appendix D. Example: NETCONF <get> Reply ..........................32
Appendix E. Examples: Interface Naming Schemes ....................35
E.1. Router with Restricted Interface Names .....................35
E.2. Router with Arbitrary Interface Names ......................36
E.3. Ethernet Switch with Restricted Interface Names ............37
E.4. Generic Host with Restricted Interface Names ...............38
E.5. Generic Host with Arbitrary Interface Names ................39
This document defines a YANG [RFC6020] data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.
このドキュメントは、ネットワークインターフェースの管理のためのYANG [RFC6020]データモデルを定義します。インターフェイスタイプ固有のデータモデルは、このドキュメントで定義されている一般的なインターフェイスデータモデルを補強することが期待されています。
Network interfaces are central to the management of many Internet protocols. Thus, it is important to establish a common data model for how interfaces are identified, configured, and monitored.
ネットワークインターフェイスは、多くのインターネットプロトコルの管理の中核です。したがって、インターフェイスの識別、構成、および監視方法に関する共通のデータモデルを確立することが重要です。
The data model includes configuration data and state data (status information and counters for the collection of statistics).
データモデルには、構成データと状態データ（統計情報を収集するためのステータス情報とカウンター）が含まれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、BCP 14 [RFC2119]で説明されているように解釈されます。
The following terms are used within this document:
このドキュメントでは、次の用語が使用されています。
o system-controlled interface: An interface is said to be system-controlled if the system creates and deletes the interface independently of what has been explicitly configured. Examples are interfaces representing physical hardware that appear and disappear when hardware (e.g., a line card or hot-pluggable wireless interface) is added or removed. System-controlled interfaces may also appear if a certain functionality is enabled (e.g., a loopback interface might appear if the IP protocol stack is enabled).
o システム制御インターフェース：明示的に構成されたものとは無関係にシステムがインターフェースを作成および削除する場合、インターフェースはシステム制御であると言います。例としては、ハードウェア（ラインカードやホットプラグ可能なワイヤレスインターフェイスなど）が追加または削除されると表示および非表示になる物理ハードウェアを表すインターフェイスがあります。システム制御のインターフェースは、特定の機能が有効になっている場合にも表示されることがあります（たとえば、IPプロトコルスタックが有効になっている場合、ループバックインターフェースが表示されることがあります）。
o user-controlled interface: An interface is said to be user-controlled if the creation of the interface is controlled by adding explicit interface configuration to the running configuration datastore and the removal of the interface is controlled by removing explicit interface configuration from the running configuration datastore. Examples are VLAN interfaces configured on a system-controlled Ethernet interface.
o ユーザー制御インターフェース：明示的なインターフェース構成を実行構成データストアに追加することによってインターフェースの作成を制御し、実行構成データストアから明示的なインターフェース構成を削除することによってインターフェースの削除を制御する場合、インターフェースはユーザー制御であると言われます。例は、システム制御のイーサネットインターフェイスに設定されたVLANインターフェイスです。
The following terms are defined in [RFC6241] and are not redefined here:
以下の用語は[RFC6241]で定義されており、ここでは再定義されません。
o client
o クライアント
o configuration data
o 設定データ
o server
o サーバ
o state data
o 状態データ
The following terms are defined in [RFC6020] and are not redefined here:
以下の用語は[RFC6020]で定義されており、ここでは再定義されません。
o augment
o 増強
o data model
o データ・モデル
o data node
o だた ので
o presence container
o プレゼンスコンテナ
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows:
このドキュメントでは、データモデルの簡略化されたグラフィカル表現を使用しています。これらの図の記号の意味は次のとおりです。
o Brackets "[" and "]" enclose list keys.
o 大括弧 "["と "]"はリストキーを囲みます。
o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only).
o データノード名の前の略語：「rw」は構成（読み取り/書き込み）を意味し、「ro」は状態データ（読み取り専用）を意味します。
o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
o データノード名の後の記号： "？"オプションのノード「！」を意味しますプレゼンスコンテナを意味し、「*」はリストとリーフリストを意味します。
o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
o 括弧は選択ノードとケースノードを囲み、ケースノードもコロン（ "："）でマークされます。
o Ellipsis ("...") stands for contents of subtrees that are not shown.
o 省略記号（ "..."）は、表示されていないサブツリーのコンテンツを表します。
This section describes some of the design objectives for the model presented in Section 5.
このセクションでは、セクション5で示したモデルの設計目標のいくつかについて説明します。
o It is recognized that existing implementations will have to map the interface data model defined in this memo to their proprietary native data model. To facilitate such mappings, the data model should be simple.
o 既存の実装では、このメモで定義されたインターフェースデータモデルを独自のネイティブデータモデルにマップする必要があることが認識されています。このようなマッピングを容易にするために、データモデルは単純である必要があります。
o The data model should be suitable for new implementations to use as is, without requiring a mapping to a different native model.
o データモデルは、別のネイティブモデルへのマッピングを必要とせずに、新しい実装をそのまま使用するのに適している必要があります。
o References to interfaces should be as simple as possible, preferably by using a single leafref.
o インターフェースへの参照は、できれば単一のleafrefを使用することにより、可能な限りシンプルにする必要があります。
o The mapping to ifIndex [RFC2863] used by the Simple Network Management Protocol (SNMP) to identify interfaces must be clear.
o インターフェイスを識別するために簡易ネットワーク管理プロトコル（SNMP）が使用するifIndex [RFC2863]へのマッピングは明確でなければなりません。
o The model must support interface layering: both (1) simple layering, where one interface is layered on top of exactly one other interface, and (2) more complex scenarios, where one interface results from the aggregation of N other interfaces or when N interfaces are multiplexed over one other interface.
o モデルは、インターフェイスの階層化をサポートする必要があります。（1）1つのインターフェイスが他の1つのインターフェイスの上に階層化される単純な階層化と、（2）1つのインターフェイスが他のN個のインターフェイスの集約から発生する、またはN個のインターフェイスがある場合のより複雑なシナリオ他の1つのインターフェースで多重化されます。
o The data model should support the pre-provisioning of interface configuration, i.e., it should be possible to configure an interface whose physical interface hardware is not present on the device. It is recommended that devices that support dynamic addition and removal of physical interfaces also support pre-provisioning.
o データモデルは、インターフェース構成の事前プロビジョニングをサポートする必要があります。つまり、物理インターフェースハードウェアがデバイスに存在しないインターフェースを構成できるようにする必要があります。物理インターフェイスの動的な追加と削除をサポートするデバイスは、事前プロビジョニングもサポートすることをお勧めします。
o The data model should support physical interfaces as well as logical interfaces.
o データモデルは、物理インターフェイスと論理インターフェイスをサポートする必要があります。
o The data model should include read-only counters in order to gather statistics for sent and received octets and packets, received packets with errors, and packets that could not be sent due to errors.
o データモデルには、送受信オクテットとパケット、エラーのある受信パケット、およびエラーが原因で送信できなかったパケットの統計を収集するために、読み取り専用カウンターを含める必要があります。
This document defines the YANG module "ietf-interfaces", which has the following structure:
このドキュメントでは、次の構造を持つYANGモジュール「ietf-interfaces」を定義しています。
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw description? string
| +--rw type identityref
| +--rw enabled? boolean
| +--rw link-up-down-trap-enable? enumeration
+--ro interfaces-state
+--ro interface* [name]
+--ro name string
+--ro type identityref
+--ro admin-status enumeration
+--ro oper-status enumeration
+--ro last-change? yang:date-and-time
+--ro if-index int32
+--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-state-ref
+--ro lower-layer-if* interface-state-ref
+--ro speed? yang:gauge64
+--ro statistics
+--ro discontinuity-time yang:date-and-time
+--ro in-octets? yang:counter64
+--ro in-unicast-pkts? yang:counter64
+--ro in-broadcast-pkts? yang:counter64
+--ro in-multicast-pkts? yang:counter64
+--ro in-discards? yang:counter32
+--ro in-errors? yang:counter32
+--ro in-unknown-protos? yang:counter32
+--ro out-octets? yang:counter64
+--ro out-unicast-pkts? yang:counter64
+--ro out-broadcast-pkts? yang:counter64
+--ro out-multicast-pkts? yang:counter64
+--ro out-discards? yang:counter32
+--ro out-errors? yang:counter32
The data model for interfaces presented in this document uses a flat list of interfaces. Each interface in the list is identified by its name. Furthermore, each interface has a mandatory "type" leaf.
このドキュメントに記載されているインターフェイスのデータモデルでは、インターフェイスのフラットリストを使用しています。リスト内の各インターフェースは、その名前で識別されます。さらに、各インターフェースには必須の「タイプ」リーフがあります。
The "iana-if-type" module [RFC7224] defines YANG identities for the interface types in the IANA-maintained "ifType definitions" registry.
「iana-if-type」モジュール[RFC7224]は、IANAが管理する「ifType定義」レジストリでインターフェースタイプのYANG IDを定義します。
There is one list of configured interfaces ("/interfaces/interface"), and a separate list for the operational state of all interfaces ("/interfaces-state/interface").
構成済みインターフェースのリスト（「/ interfaces / interface」）と、すべてのインターフェースの動作状態の別個のリスト（「/ interfaces-state / interface」）があります。
It is expected that interface-type-specific data models augment the interface lists and possibly use the "type" leaf to make the augmentation conditional.
インターフェイスタイプ固有のデータモデルがインターフェイスリストを拡張し、「タイプ」リーフを使用して拡張を条件付きにすることが期待されます。
As an example of such an interface-type-specific augmentation, consider this YANG snippet. For a more complete example, see Appendix A.
このようなインターフェースタイプ固有の拡張の例として、このYANGスニペットを考えてみましょう。より完全な例については、付録Aを参照してください。
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
...
}
}
}
For system-controlled interfaces, the "name" is the device-specific name of the interface. The 'config false' list "/interfaces-state/interface" contains all existing interfaces on the device.
システム制御のインターフェースの場合、「名前」はインターフェースのデバイス固有の名前です。 「config false」リスト「/ interfaces-state / interface」には、デバイス上のすべての既存のインターフェースが含まれています。
If the device supports arbitrarily named user-controlled interfaces, the Network Configuration Protocol (NETCONF) server advertises the "arbitrary-names" feature. If the device does not advertise this feature, the names of user-controlled interfaces MUST match the device's naming scheme. How a client can learn the naming scheme of such devices is outside the scope of this document. See Appendices E.1 and E.2 for examples.
デバイスが任意の名前のユーザー制御インターフェースをサポートしている場合、ネットワーク構成プロトコル（NETCONF）サーバーは「任意の名前」機能を通知します。デバイスがこの機能をアドバタイズしない場合、ユーザー制御のインターフェースの名前はデバイスの命名方式と一致する必要があります。クライアントがこのようなデバイスの命名方式を学習する方法は、このドキュメントの範囲外です。例については、付録E.1およびE.2を参照してください。
When a system-controlled interface is created by the system, the system tries to apply the interface configuration in "/interfaces/ interface" with the same name as the new interface. If no such interface configuration is found, or if the configured type does not match the real interface type, the system creates the interface without applying explicit configuration.
システム制御のインターフェースがシステムによって作成されると、システムは「/ interfaces /インターフェース」内のインターフェース構成を新しいインターフェースと同じ名前で適用しようとします。そのようなインターフェイス設定が見つからない場合、または設定されたタイプが実際のインターフェイスタイプと一致しない場合、システムは明示的な設定を適用せずにインターフェイスを作成します。
When a user-controlled interface is created, the configuration determines the name of the interface.
ユーザー制御のインターフェースが作成されると、構成によってインターフェースの名前が決まります。
Depending on the operating system and the physical attachment point to which a network interface may be attached or removed, it may be impossible for an implementation to provide predictable and consistent names for system-controlled interfaces across insertion/ removal cycles as well as in anticipation of initial insertion. The ability to provide configurations for such interfaces is therefore dependent on the implementation and cannot be assumed in all cases.
オペレーティングシステムと、ネットワークインターフェイスが接続または削除される可能性のある物理的な接続ポイントによっては、実装がシステム制御のインターフェイスに予測可能な一貫性のある名前を挿入/削除サイクル全体で提供することや、最初の挿入。したがって、そのようなインターフェースの構成を提供する機能は実装に依存し、すべてのケースで想定できるわけではありません。
An interface is identified by its name, which is unique within the server. This property is captured in the "interface-ref" and "interface-state-ref" typedefs, which other YANG modules SHOULD use when they need to reference a configured interface or operationally used interface, respectively.
インターフェイスは、サーバー内で一意の名前で識別されます。このプロパティは、「interface-ref」および「interface-state-ref」typedefでキャプチャされます。他のYANGモジュールは、構成されたインターフェースまたは操作上使用されるインターフェースをそれぞれ参照する必要がある場合に使用する必要があります。
There is no generic mechanism for how an interface is configured to be layered on top of some other interface. It is expected that interface-type-specific models define their own data nodes for interface layering by using "interface-ref" types to reference lower layers.
インターフェイスを他のインターフェイスの上に重ねるように設定するための一般的なメカニズムはありません。インターフェースタイプ固有のモデルは、「インターフェース参照」タイプを使用して下位レイヤーを参照することにより、インターフェースレイヤー用に独自のデータノードを定義することが期待されます。
Below is an example of a model with such nodes. For a more complete example, see Appendix B.
以下は、そのようなノードを持つモデルの例です。より完全な例については、付録Bを参照してください。
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
leaf-list slave-if {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'ianaift:ethernetCsmacd'" {
description
"The type of a slave interface must be
'ethernetCsmacd'.";
}
}
// other bonding config params, failover times, etc.
}
While the interface layering is configured in interface-type-specific models, two generic state data leaf-lists, "higher-layer-if" and "lower-layer-if", represent a read-only view of the interface layering hierarchy.
インターフェイスレイヤーはインターフェイスタイプ固有のモデルで構成されますが、2つの一般的な状態データのリーフリスト「higher-layer-if」と「lower-layer-if」は、インターフェイスレイヤー階層の読み取り専用ビューを表します。
If the device implements the IF-MIB [RFC2863], each entry in the "/ interfaces-state/interface" list is typically mapped to one ifEntry. The "if-index" leaf MUST contain the value of the corresponding ifEntry's ifIndex.
デバイスがIF-MIB [RFC2863]を実装している場合、「/ interfaces-state / interface」リストの各エントリは通常、1つのifEntryにマッピングされます。 「if-index」リーフには、対応するifEntryのifIndexの値が含まれている必要があります。
In most cases, the "name" of an "/interfaces-state/interface" entry is mapped to ifName. The IF-MIB allows two different ifEntries to have the same ifName. Devices that support this feature and also support the data model defined in this document cannot have a 1-1 mapping between the "name" leaf and ifName.
ほとんどの場合、「/ interfaces-state / interface」エントリの「名前」はifNameにマッピングされます。 IF-MIBでは、2つの異なるifEntriesが同じifNameを持つことができます。この機能をサポートし、このドキュメントで定義されているデータモデルもサポートするデバイスは、「name」リーフとifNameを1-1でマッピングできません。
The configured "description" of an "interface" has traditionally been mapped to ifAlias in some implementations. This document allows this mapping, but implementers should be aware of the differences in the value space and persistence for these objects. See the YANG module definition of the leaf "description" in Section 5 for details.
「インターフェース」の構成された「説明」は、一部の実装では伝統的にifAliasにマップされていました。このドキュメントではこのマッピングを許可していますが、実装者はこれらのオブジェクトの値空間と永続性の違いに注意する必要があります。詳細については、セクション5のリーフ「説明」のYANGモジュール定義を参照してください。
The IF-MIB also defines the writable object ifPromiscuousMode. Since this object typically is not implemented as a configuration object by SNMP agents, it is not mapped to the "ietf-interfaces" module.
IF-MIBは、書き込み可能なオブジェクトifPromiscuousModeも定義します。このオブジェクトは通常、SNMPエージェントによって構成オブジェクトとして実装されていないため、「ietf-interfaces」モジュールにマップされません。
The ifMtu object from the IF-MIB is not mapped to the "ietf-interfaces" module. It is expected that interface-type-specific YANG modules provide interface-type-specific MTU leafs by augmenting the "ietf-interfaces" model.
IF-MIBのifMtuオブジェクトは、「ietf-interfaces」モジュールにマップされていません。インターフェースタイプ固有のYANGモジュールは、「ietf-interfaces」モデルを拡張することにより、インターフェースタイプ固有のMTUリーフを提供することが期待されています。
There are a number of counters in the IF-MIB that exist in two versions: one with 32 bits and one with 64 bits. The 64-bit versions were added to support high-speed interfaces with a data rate greater than 20,000,000 bits/second. Today's implementations generally support such high-speed interfaces, and hence only 64-bit counters are provided in this data model. Note that NETCONF and SNMP may differ in the time granularity in which they provide access to the counters. For example, it is common that SNMP implementations cache counter values for some time.
IF-MIBには、32ビットと64ビットの2つのバージョンに存在する多数のカウンターがあります。 64ビットバージョンは、20,000,000ビット/秒を超えるデータレートの高速インターフェイスをサポートするために追加されました。今日の実装は一般にそのような高速インターフェースをサポートしているため、このデータモデルでは64ビットカウンターのみが提供されます。 NETCONFとSNMPは、カウンターへのアクセスを提供する時間の粒度が異なる場合があることに注意してください。たとえば、SNMP実装では、しばらくの間カウンタ値をキャッシュするのが一般的です。
The objects ifDescr and ifConnectorPresent from the IF-MIB are not mapped to the "ietf-interfaces" module.
IF-MIBのオブジェクトifDescrおよびifConnectorPresentは、「ietf-interfaces」モジュールにマップされません。
The following tables list the YANG data nodes with corresponding objects in the IF-MIB.
次の表に、IF-MIB内の対応するオブジェクトを含むYANGデータノードを示します。
+--------------------------------------+----------------------------+
| YANG data node in /interfaces- | IF-MIB object |
| state/interface | |
+--------------------------------------+----------------------------+
| name | ifName |
| type | ifType |
| admin-status | ifAdminStatus |
| oper-status | ifOperStatus |
| last-change | ifLastChange |
| if-index | ifIndex |
| link-up-down-trap-enable | ifLinkUpDownTrapEnable |
| phys-address | ifPhysAddress |
| higher-layer-if and lower-layer-if | ifStackTable |
| speed | ifSpeed and ifHighSpeed |
| discontinuity-time | ifCounterDiscontinuityTime |
| in-octets | ifHCInOctets |
| in-unicast-pkts | ifHCInUcastPkts |
| in-broadcast-pkts | ifHCInBroadcastPkts |
| in-multicast-pkts | ifHCInMulticastPkts |
| in-discards | ifInDiscards |
| in-errors | ifInErrors |
| in-unknown-protos | ifInUnknownProtos |
| out-octets | ifHCOutOctets |
| out-unicast-pkts | ifHCOutUcastPkts |
| out-broadcast-pkts | ifHCOutBroadcastPkts |
| out-multicast-pkts | ifHCOutMulticastPkts |
| out-discards | ifOutDiscards |
| out-errors | ifOutErrors |
+--------------------------------------+----------------------------+
YANG State Data Nodes and Related IF-MIB Objects
YANG状態データノードおよび関連するIF-MIBオブジェクト
+-----------------------------------------+---------------+
| YANG data node in /interfaces/interface | IF-MIB object |
+-----------------------------------------+---------------+
| description | ifAlias |
+-----------------------------------------+---------------+
YANG Config Data Nodes and Related IF-MIB Objects
YANG構成データノードと関連するIF-MIBオブジェクト
This YANG module imports typedefs from [RFC6991].
このYANGモジュールは、[RFC6991]からtypedefをインポートします。
<CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"
module ietf-interfaces {
module ietf-interfaces {
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
import ietf-yang-types {
prefix yang;
}
organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
組織「IETF NETMOD（NETCONFデータモデリング言語）ワーキンググループ」;
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>";
description "This module contains a collection of YANG definitions for managing network interfaces.
説明「このモジュールには、ネットワークインターフェースを管理するためのYANG定義のコレクションが含まれています。
Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2014 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETFドキュメントに関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 7223; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 7223の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2014-05-08 {
description
"Initial revision.";
reference
"RFC 7223: A YANG Data Model for Interface Management";
}
/*
* Typedefs
*/
typedef interface-ref {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
description
"This type is used by data models that need to reference
configured interfaces.";
}
typedef interface-state-ref {
type leafref {
path "/if:interfaces-state/if:interface/if:name";
}
description
"This type is used by data models that need to reference
the operationally present interfaces.";
}
/*
* Identities
*/
identity interface-type {
description
"Base identity from which specific interface types are
derived.";
}
/*
* Features
*/
feature arbitrary-names {
description
"This feature indicates that the device allows user-controlled
interfaces to be named arbitrarily.";
}
feature pre-provisioning {
description
"This feature indicates that the device supports
pre-provisioning of interface configuration, i.e., it is
possible to configure an interface whose physical interface
hardware is not present on the device.";
}
feature if-mib {
description
"This feature indicates that the device implements
the IF-MIB.";
reference
"RFC 2863: The Interfaces Group MIB";
}
/*
* Configuration data nodes
*/
container interfaces {
description
"Interface configuration parameters.";
list interface {
key "name";
description "The list of configured interfaces on the device.
説明 "デバイス上に構成されたインターフェースのリスト。
The operational state of an interface is available in the
/interfaces-state/interface list. If the configuration of a
system-controlled interface cannot be used by the system
(e.g., the interface hardware present does not match the
interface type), then the configuration is not applied to
the system-controlled interface shown in the
/interfaces-state/interface list. If the configuration
of a user-controlled interface cannot be used by the system,
the configured interface is not instantiated in the
/interfaces-state/interface list.";
leaf name {
type string;
description
"The name of the interface.
A device MAY restrict the allowed values for this leaf, possibly depending on the type of the interface.
デバイスは、おそらくインターフェースのタイプに応じて、このリーフに許可される値を制限してもよい（MAY）。
For system-controlled interfaces, this leaf is the device-specific name of the interface. The 'config false' list /interfaces-state/interface contains the currently existing interfaces on the device.
システム制御のインターフェースの場合、このリーフはインターフェースのデバイス固有の名前です。 「config false」リスト/ interfaces-state / interfaceには、デバイスに現在存在するインターフェースが含まれています。
If a client tries to create configuration for a system-controlled interface that is not present in the /interfaces-state/interface list, the server MAY reject the request if the implementation does not support pre-provisioning of interfaces or if the name refers to an interface that can never exist in the system. A NETCONF server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case.
/ interfaces-state / interfaceリストにないシステム制御のインターフェースの構成をクライアントが作成しようとした場合、実装がインターフェースの事前プロビジョニングをサポートしていない場合、または名前が参照している場合、サーバーはリクエストを拒否できます（MAY）。システムに存在できないインターフェース。この場合、NETCONFサーバーはrpc-errorでエラータグ 'invalid-value'を返信する必要があります。
If the device supports pre-provisioning of interface configuration, the 'pre-provisioning' feature is advertised.
デバイスがインターフェイス構成の事前プロビジョニングをサポートしている場合、「事前プロビジョニング」機能がアドバタイズされます。
If the device allows arbitrarily named user-controlled interfaces, the 'arbitrary-names' feature is advertised.
デバイスが任意の名前のユーザー制御インターフェイスを許可している場合、「任意の名前」機能がアドバタイズされます。
When a configured user-controlled interface is created by
the system, it is instantiated with the same name in the
/interface-state/interface list.";
}
leaf description {
type string;
description
"A textual description of the interface.
A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document.
サーバー実装は、このリーフをifAlias MIBオブジェクトにマップしてもよい（MAY）。そのような実装では、このリーフとifAliasの間で許可されるサイズと文字の違いを処理するために、何らかのメカニズムを使用する必要があります。このようなメカニズムの定義は、このドキュメントの範囲外です。
Since ifAlias is defined to be stored in non-volatile storage, the MIB implementation MUST map ifAlias to the value of 'description' in the persistently stored datastore.
ifAliasは不揮発性ストレージに格納されるように定義されているため、MIB実装はifAliasを永続的に格納されたデータストアの「説明」の値にマップする必要があります。
Specifically, if the device supports ':startup', when ifAlias is read the device MUST return the value of 'description' in the 'startup' datastore, and when it is written, it MUST be written to the 'running' and 'startup' datastores. Note that it is up to the implementation to decide whether to modify this single leaf in 'startup' or perform an implicit copy-config from 'running' to 'startup'.
具体的には、デバイスが「：startup」をサポートしている場合、ifAliasが読み取られると、デバイスは「startup」データストアに「description」の値を返す必要があり、書き込まれると、「running」と「startup」に書き込まれる必要があります'データストア。 「startup」でこの単一のリーフを変更するか、「running」から「startup」に暗黙的なcopy-configを実行するかは、実装次第であることに注意してください。
If the device does not support ':startup', ifAlias MUST
be mapped to the 'description' leaf in the 'running'
datastore.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"The type of the interface.
When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface.
インターフェースエントリが作成されると、サーバーはタイプリーフを有効な値で初期化できます。たとえば、インターフェースの名前からタイプを導出できる場合などです。
If a client tries to set the type of an interface to a
value that can never be used by the system, e.g., if the
type is not supported or if the type does not match the
name of the interface, the server MUST reject the request.
A NETCONF server MUST reply with an rpc-error with the
error-tag 'invalid-value' in this case.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf enabled {
type boolean;
default "true";
description
"This leaf contains the configured, desired state of the
interface.
Systems that implement the IF-MIB use the value of this leaf in the 'running' datastore to set IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry has been initialized, as described in RFC 2863.
IF-MIBを実装するシステムは、RFC 2863で説明されているように、ifEntryが初期化された後、「実行中」のデータストアのこのリーフの値を使用してIF-MIB.ifAdminStatusを「アップ」または「ダウン」に設定します。
Changes in this leaf in the 'running' datastore are
reflected in ifAdminStatus, but if ifAdminStatus is
changed over SNMP, this leaf is not affected.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
}
enum disabled {
value 2;
}
}
description
"Controls whether linkUp/linkDown SNMP notifications
should be generated for this interface.
If this node is not configured, the value 'enabled' is
operationally used by the server for interfaces that do
not operate on top of any other interface (i.e., there are
no 'lower-layer-if' entries), and 'disabled' otherwise.";
reference
"RFC 2863: The Interfaces Group MIB -
ifLinkUpDownTrapEnable";
}
}
}
/*
* Operational state data nodes
*/
container interfaces-state {
config false;
description
"Data nodes for the operational state of interfaces.";
list interface {
key "name";
description "The list of interfaces on the device.
説明 "デバイス上のインターフェースのリスト。
System-controlled interfaces created by the system are always present in this list, whether they are configured or not.";
システムによって作成されたシステム制御インターフェースは、構成されているかどうかにかかわらず、常にこのリストに表示されます。 ";
leaf name {
type string;
description
"The name of the interface.
A server implementation MAY map this leaf to the ifName
MIB object. Such an implementation needs to use some
mechanism to handle the differences in size and characters
allowed between this leaf and ifName. The definition of
such a mechanism is outside the scope of this document.";
reference
"RFC 2863: The Interfaces Group MIB - ifName";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"The type of the interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf admin-status {
if-feature if-mib;
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"Not ready to pass packets and not in some test mode.";
}
enum testing {
value 3;
description
"In some test mode.";
}
}
mandatory true;
description
"The desired state of the interface.
This leaf has the same read semantics as ifAdminStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf oper-status {
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"The interface does not pass any packets.";
}
enum testing {
value 3;
description
"In some test mode. No operational packets can
be passed.";
}
enum unknown {
value 4;
description
"Status cannot be determined for some reason.";
}
enum dormant {
value 5;
description
"Waiting for some external event.";
}
enum not-present {
value 6;
description
"Some component (typically hardware) is missing.";
}
enum lower-layer-down {
value 7;
description
"Down due to state of lower-layer interface(s).";
}
}
mandatory true;
description
"The current operational state of the interface.
This leaf has the same semantics as ifOperStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifOperStatus";
}
leaf last-change {
type yang:date-and-time;
description
"The time the interface entered its current operational
state. If the current state was entered prior to the
last re-initialization of the local network management
subsystem, then this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifLastChange";
}
leaf if-index {
if-feature if-mib;
type int32 {
range "1..2147483647";
}
mandatory true;
description
"The ifIndex value for the ifEntry represented by this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
leaf phys-address {
type yang:phys-address;
description
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a Media Access Control (MAC) address. The
interface's media-specific modules must define the bit
and byte ordering and the format of the value of this
object. For interfaces that do not have such an address
(e.g., a serial line), this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifPhysAddress";
}
leaf-list higher-layer-if {
type interface-state-ref;
description
"A list of references to interfaces layered on top of this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf-list lower-layer-if {
type interface-state-ref;
description
"A list of references to interfaces layered underneath this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf speed {
type yang:gauge64;
units "bits/second";
description
"An estimate of the interface's current bandwidth in bits
per second. For interfaces that do not vary in
bandwidth or for those where no accurate estimation can
be made, this node should contain the nominal bandwidth.
For interfaces that have no concept of bandwidth, this
node is not present.";
reference
"RFC 2863: The Interfaces Group MIB -
ifSpeed, ifHighSpeed";
}
container statistics {
description
"A collection of interface-related statistics objects.";
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
leaf in-octets {
type yang:counter64;
description
"The total number of octets received on the interface,
including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInOctets";
}
leaf in-unicast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were not addressed to a
multicast or broadcast address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
}
leaf in-broadcast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a broadcast
address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInBroadcastPkts";
}
leaf in-multicast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a multicast
address at this sub-layer. For a MAC-layer protocol,
this includes both Group and Functional addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInMulticastPkts";
}
leaf in-discards {
type yang:counter32;
description
"The number of inbound packets that were chosen to be
discarded even though no errors had been detected to
prevent their being deliverable to a higher-layer
protocol. One possible reason for discarding such a
packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'.";
このカウンターの値に不連続性が発生するのは、管理システムの再初期化時、および「不連続性時間」の値で示される他の場合です。
reference
"RFC 2863: The Interfaces Group MIB - ifInDiscards";
}
leaf in-errors {
type yang:counter32;
description
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from being
deliverable to a higher-layer protocol. For character-
oriented or fixed-length interfaces, the number of
inbound transmission units that contained errors
preventing them from being deliverable to a higher-layer
protocol.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInErrors";
}
leaf in-unknown-protos {
type yang:counter32;
description
"For packet-oriented interfaces, the number of packets
received via the interface that were discarded because
of an unknown or unsupported protocol. For
character-oriented or fixed-length interfaces that
support protocol multiplexing, the number of
transmission units received via the interface that were
discarded because of an unknown or unsupported protocol.
For any interface that does not support protocol
multiplexing, this counter is not present.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
}
leaf out-octets {
type yang:counter64;
description
"The total number of octets transmitted out of the
interface, including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
}
leaf out-unicast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted, and that were not addressed
to a multicast or broadcast address at this sub-layer,
including those that were discarded or not sent.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
}
leaf out-broadcast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted, and that were addressed to a
broadcast address at this sub-layer, including those
that were discarded or not sent.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutBroadcastPkts";
}
leaf out-multicast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted, and that were addressed to a
multicast address at this sub-layer, including those
that were discarded or not sent. For a MAC-layer
protocol, this includes both Group and Functional
addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutMulticastPkts";
}
leaf out-discards {
type yang:counter32;
description
"The number of outbound packets that were chosen to be
discarded even though no errors had been detected to
prevent their being transmitted. One possible reason
for discarding such a packet could be to free up buffer
space.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutDiscards";
}
leaf out-errors {
type yang:counter32;
description
"For packet-oriented interfaces, the number of outbound
packets that could not be transmitted because of errors.
For character-oriented or fixed-length interfaces, the
number of outbound transmission units that could not be
transmitted because of errors.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutErrors";
}
}
}
}
}
<CODE ENDS>
<コード終了>
This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made.
このドキュメントは、「IETF XMLレジストリ」[RFC3688]にURIを登録します。 RFC 3688のフォーマットに従って、次の登録が行われました。
URI: urn:ietf:params:xml:ns:yang:ietf-interfaces
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if
reference: RFC 7223
The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.
このメモで定義されているYANGモジュールは、NETCONFプロトコル[RFC6241]を介してアクセスされるように設計されています。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはSSH [RFC6242]です。 NETCONFアクセスコントロールモデル[RFC6536]は、特定のNETCONFユーザーのアクセスを、利用可能なすべてのNETCONFプロトコル操作およびコンテンツの事前構成済みサブセットに制限する手段を提供します。
There are a number of data nodes defined in the YANG module which are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., <edit-config>) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
YANGモジュールには、書き込み/作成/削除が可能なデータノードがいくつか定義されています（つまり、config true、デフォルトです）。これらのデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。適切に保護されていないこれらのデータノードへの書き込み操作（<edit-config>など）は、ネットワーク操作に悪影響を及ぼす可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
/interfaces/interface: This list specifies the configured interfaces on a device. Unauthorized access to this list could cause the device to ignore packets it should receive and process.
/ interfaces / interface：このリストは、デバイスに構成されたインターフェースを指定します。このリストへの不正アクセスは、デバイスが受信して処理する必要のあるパケットを無視する原因になる可能性があります。
/interfaces/interface/enabled: This leaf controls whether an interface is enabled or not. Unauthorized access to this leaf could cause the device to ignore packets it should receive and process.
/ interfaces / interface / enabled：このリーフは、インターフェースを有効にするかどうかを制御します。このリーフへの不正アクセスは、デバイスが受信して処理する必要があるパケットを無視する原因となる可能性があります。
The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav Lhotka, and Juergen Schoenwaelder for their helpful comments.
著者は、有益なコメントを提供してくれたAlexander Clemm、Per Hedeland、Ladislav Lhotka、およびJuergen Schoenwaelderに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M。、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、2010年10月。
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013.
[RFC6991] Schoenwaelder、J。、「Common YANG Data Types」、RFC 6991、2013年7月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011.
[RFC6242] Wasserman、M。、「Secure Shell（SSH）上のNETCONFプロトコルの使用」、RFC 6242、2011年6月。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、2012年3月。
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, May 2014.
[RFC7224] Bjorklund、M。、「IANA Interface Type YANG Module」、RFC 7224、2014年5月。
Appendix A. Example: Ethernet Interface Module
付録A.例：イーサネットインターフェイスモジュール
This section gives a simple example of how an Ethernet interface module could be defined. It demonstrates how media-specific configuration parameters can be conditionally augmented to the generic interface list. It also shows how operational state parameters can be conditionally augmented to the operational interface list. The example is not intended as a complete module for Ethernet configuration.
このセクションでは、イーサネットインターフェイスモジュールを定義する簡単な例を示します。メディア固有の構成パラメーターを条件付きで汎用インターフェースリストに追加する方法を示します。また、操作状態パラメーターを条件付きで操作インターフェースリストに追加する方法も示します。この例は、イーサネット構成用の完全なモジュールを意図したものではありません。
module ex-ethernet {
namespace "http://example.com/ethernet";
prefix "eth";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
// configuration parameters for Ethernet interfaces
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
choice transmission-params {
case auto {
leaf auto-negotiate {
type empty;
}
}
case manual {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
leaf speed {
type enumeration {
enum "10Mb";
enum "100Mb";
enum "1Gb";
enum "10Gb";
}
}
}
}
// other Ethernet-specific params...
}
}
// operational state parameters for Ethernet interfaces
augment "/if:interfaces-state/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
// other Ethernet-specific params...
}
}
}
Appendix B. Example: Ethernet Bonding Interface Module
付録B.例：イーサネットボンディングインターフェイスモジュール
This section gives an example of how interface layering can be defined. An Ethernet bonding interface that bonds several Ethernet interfaces into one logical interface is defined.
このセクションでは、インターフェイスの階層化を定義する方法の例を示します。複数のイーサネットインターフェイスを1つの論理インターフェイスに結合するイーサネットボンディングインターフェイスが定義されています。
module ex-ethernet-bonding {
namespace "http://example.com/ethernet-bonding";
prefix "bond";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
leaf-list slave-if {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'ianaift:ethernetCsmacd'" {
description
"The type of a slave interface must be 'ethernetCsmacd'.";
}
}
leaf bonding-mode {
type enumeration {
enum round-robin;
enum active-backup;
enum broadcast;
}
}
// other bonding config params, failover times, etc.
}
}
Appendix C. Example: VLAN Interface Module
付録C.例：VLANインターフェイスモジュール
This section gives an example of how a VLAN interface module can be defined.
このセクションでは、VLANインターフェイスモジュールを定義する方法の例を示します。
module ex-vlan {
namespace "http://example.com/vlan";
prefix "vlan";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag'";
leaf vlan-tagging {
type boolean;
default false;
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan'";
leaf base-interface {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/vlan:vlan-tagging = 'true'" {
description
"The base interface must have VLAN tagging enabled.";
}
}
leaf vlan-id {
type uint16 {
range "1..4094";
}
must "../base-interface" {
description
"If a vlan-id is defined, a base-interface must
be specified.";
}
}
}
}
Appendix D. Example: NETCONF <get> Reply
This section gives an example of a reply to the NETCONF <get> request for a device that implements the example data models above.
このセクションでは、上記のサンプルデータモデルを実装するデバイスに対するNETCONF <get>リクエストへの応答の例を示します。
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:vlan="http://example.com/vlan">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<vlan:vlan-tagging>true</vlan:vlan-tagging>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<enabled>true</enabled>
<vlan:base-interface>eth1</vlan:base-interface>
<vlan:vlan-id>10</vlan:vlan-id>
</interface>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<enabled>true</enabled>
</interface>
</interfaces>
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>2</if-index>
<phys-address>00:01:02:03:04:05</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>7</if-index>
<phys-address>00:01:02:03:04:06</phys-address>
<higher-layer-if>eth1.10</higher-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>9</if-index>
<lower-layer-if>eth1</lower-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<!-- This interface is not configured -->
<interface>
<name>eth2</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>8</if-index>
<phys-address>00:01:02:03:04:07</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
</interfaces-state>
</data>
</rpc-reply>
Appendix E. Examples: Interface Naming Schemes
付録E.例：インターフェース命名スキーム
This section gives examples of some implementation strategies.
このセクションでは、いくつかの実装戦略の例を示します。
The examples make use of the example data model "ex-vlan" (see Appendix C) to show how user-controlled interfaces can be configured.
例では、データモデルの例「ex-vlan」（付録Cを参照）を使用して、ユーザー制御のインターフェイスを構成する方法を示します。
In this example, a router has support for 4 line cards, each with 8 ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has Fast Ethernet or Gigabit Ethernet ports.
この例では、ルーターは4つのラインカードをサポートしており、それぞれに8つのポートがあります。カードのスロットには、物理的に0〜3の番号が付けられており、各カードのポートには0〜7の番号が付けられています。各カードには、ファストイーサネットポートまたはギガビットイーサネットポートがあります。
The device-specific names for these physical interfaces are "fastethernet-N/M" or "gigabitethernet-N/M".
これらの物理インターフェイスのデバイス固有の名前は、「fastethernet-N / M」または「gigabitethernet-N / M」です。
The name of a VLAN interface is restricted to the form "<physical-interface-name>.<subinterface-number>".
VLANインターフェースの名前は、「<物理インターフェース名>。<サブインターフェース番号>」の形式に制限されています。
It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the value for "type" based on the interface name.
オペレーターはこの命名方式を知っていると想定されます。実装は、インターフェイス名に基づいて「タイプ」の値を自動初期化します。
The NETCONF server does not advertise the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージ内の「任意の名前」機能を通知しません。
An operator can configure a physical interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信することにより、物理インターフェースを構成できます。
<interface nc:operation="create">
<name>fastethernet-1/0</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
サーバーはこのリクエストを処理するときに、リーフの「タイプ」を「ianaift：ethernetCsmacd」に設定します。したがって、クライアントが上記の<edit-config>の直後に<get-config>を実行すると、次のようになります。
<interface>
<name>fastethernet-1/0</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
The client can configure a VLAN interface by sending an <edit-config> containing:
クライアントは、以下を含む<edit-config>を送信することにより、VLANインターフェイスを構成できます。
<interface nc:operation="create">
<name>fastethernet-1/0.10005</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>fastethernet-1/0</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If the client tries to change the type of the physical interface with an <edit-config> containing:
クライアントが以下を含む<edit-config>を使用して物理インターフェースのタイプを変更しようとした場合：
<interface nc:operation="merge">
<name>fastethernet-1/0</name>
<type>ianaift:tunnel</type>
</interface>
then the server will reply with an "invalid-value" error, since the new type does not match the name.
新しいタイプは名前と一致しないため、サーバーは「無効な値」エラーで応答します。
In this example, a router has support for 4 line cards, each with 8 ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has Fast Ethernet or Gigabit Ethernet ports.
この例では、ルーターは4つのラインカードをサポートしており、それぞれに8つのポートがあります。カードのスロットには、物理的に0〜3の番号が付けられており、各カードのポートには0〜7の番号が付けられています。各カードには、ファストイーサネットポートまたはギガビットイーサネットポートがあります。
The device-specific names for these physical interfaces are "fastethernet-N/M" or "gigabitethernet-N/M".
これらの物理インターフェイスのデバイス固有の名前は、「fastethernet-N / M」または「gigabitethernet-N / M」です。
The implementation does not restrict the user-controlled interface names. This allows an operator to more easily apply the interface configuration to a different interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries.
この実装は、ユーザー制御のインターフェース名を制限しません。これにより、オペレーターはインターフェース構成を別のインターフェースに簡単に適用できます。ただし、追加レベルの間接指定により、他のプロトコルにあるインターフェース名を構成エントリーにマップするのが少し複雑になります。
The NETCONF server advertises the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージで「任意の名前」機能を通知します。
Physical interfaces are configured as in Appendix E.1.
物理インターフェイスは、付録E.1のように構成されています。
An operator can configure a VLAN interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信して、VLANインターフェースを構成できます。
<interface nc:operation="create">
<name>acme-interface</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>fastethernet-1/0</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If necessary, the operator can move the configuration named "acme-interface" over to a different physical interface with an <edit-config> containing:
必要に応じて、オペレーターは、「acme-interface」という名前の構成を、以下を含む<edit-config>を使用して別の物理インターフェースに移動できます。
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>fastethernet-1/1</vlan:base-interface>
</interface>
In this example, an Ethernet switch has a number of ports, each identified by a simple port number.
この例では、イーサネットスイッチには多数のポートがあり、それぞれが単純なポート番号で識別されます。
The device-specific names for the physical interfaces are numbers that match the physical port number.
物理インターフェイスのデバイス固有の名前は、物理ポート番号と一致する番号です。
An operator can configure a physical interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信することにより、物理インターフェースを構成できます。
<interface nc:operation="create">
<name>6</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
サーバーはこのリクエストを処理するときに、リーフの「タイプ」を「ianaift：ethernetCsmacd」に設定します。したがって、クライアントが上記の<edit-config>の直後に<get-config>を実行すると、次のようになります。
<interface>
<name>6</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
In this example, a generic host has interfaces named by the kernel. The system identifies the physical interface by the name assigned by the operating system to the interface.
この例では、汎用ホストには、カーネルによって名前が付けられたインターフェースがあります。システムは、オペレーティングシステムによってインターフェイスに割り当てられた名前で物理インターフェイスを識別します。
The name of a VLAN interface is restricted to the form "<physical-interface-name>:<vlan-number>".
VLANインターフェイスの名前は、「<physical-interface-name>：<vlan-number>」の形式に制限されています。
The NETCONF server does not advertise the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージ内の「任意の名前」機能を通知しません。
An operator can configure an interface by sending an <edit-config> containing:
An operator can configure an interface by sending an <edit-config> containing:
<interface nc:operation="create">
<name>eth8</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
サーバーはこのリクエストを処理するときに、リーフの「タイプ」を「ianaift：ethernetCsmacd」に設定します。したがって、クライアントが上記の<edit-config>の直後に<get-config>を実行すると、次のようになります。
<interface>
<name>eth8</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
The client can configure a VLAN interface by sending an <edit-config> containing:
The client can configure a VLAN interface by sending an <edit-config> containing:
<interface nc:operation="create">
<name>eth8:5</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
In this example, a generic host has interfaces named by the kernel. The system identifies the physical interface by the name assigned by the operating system to the interface.
この例では、汎用ホストには、カーネルによって名前が付けられたインターフェースがあります。システムは、オペレーティングシステムによってインターフェイスに割り当てられた名前で物理インターフェイスを識別します。
The implementation does not restrict the user-controlled interface names. This allows an operator to more easily apply the interface configuration to a different interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries.
この実装は、ユーザー制御のインターフェース名を制限しません。これにより、オペレーターはインターフェース構成を別のインターフェースに簡単に適用できます。ただし、追加レベルの間接指定により、他のプロトコルにあるインターフェース名を構成エントリーにマップするのが少し複雑になります。
The NETCONF server advertises the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージで「任意の名前」機能を通知します。
Physical interfaces are configured as in Appendix E.4.
物理インターフェイスは、付録E.4のように構成されます。
An operator can configure a VLAN interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信して、VLANインターフェースを構成できます。
<interface nc:operation="create">
<name>acme-interface</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If necessary, the operator can move the configuration named "acme-interface" over to a different physical interface with an <edit-config> containing:
必要に応じて、オペレーターは、「acme-interface」という名前の構成を、以下を含む<edit-config>を使用して別の物理インターフェースに移動できます。
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>eth3</vlan:base-interface>
</interface>
Author's Address
著者のアドレス
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
EMail: mbj@tail-f.com