RFC 7223 - YANG 接口类型定义
RFC 7223 - 面向接口管理的YANG数据模型
摘要
本文件定义了网络接口管理的数据模型。预计接口类型特定的数据模型将扩展本文档中定义的通用接口数据模型。数据模型包括配置数据和状态数据（用于收集统计数据的状态信息和计数器）。
1. 介绍
本文件定义了用于管理网络接口的YANG[RFC6020]数据模型。预计接口类型特定的数据模型将扩展本文档中定义的通用接口数据模型。
网络接口是许多互联网协议管理的核心。因此，为如何识别、配置和监测接口建立一个共同的数据模型是很重要的。
数据模型包括配置数据和状态数据（用于收集统计数据的状态信息和计数器）。
1.1. 术语
本文件中使用了以下术语：
o 系统控制接口：如果系统独立于显式配置创建和删除接口，则称该接口为系统控制接口。例如，接口表示在添加或删除硬件（如线路卡或热插拔无线接口）时出现和消失的物理硬件。如果启用了特定功能，系统控制的接口也可能出现（例如，如果启用了IP协议栈，则可能出现环回接口）。
o 用户控制接口：如果通过向运行配置数据存储添加显式接口配置来控制接口的创建，并且通过从运行配置数据存储中删除显式接口配置来控制接口的删除，则称接口为用户控制。例如，在系统控制的以太网接口上配置VLAN接口。
[RFC6241]中定义了以下术语，此处未重新定义：
o client客户
o configuration data配置数据
o server服务器
o state data状态数据
[RFC6020]中定义了以下术语，此处未重新定义：
o augment加强
o data model数据模型
o data node数据节点
o presence container存在容器
2. 目标
本节介绍了第5节中介绍的模型的一些设计目标。
o 我们认识到，现有实现必须将本备忘录中定义的接口数据模型映射到其专有的本机数据模型。为了促进这种映射，数据模型应该简单。
o 数据模型应该适合新的实现按原样使用，而不需要映射到不同的本机模型。
o 对接口的引用应尽可能简单，最好使用单个leafref。
o 简单网络管理协议（SNMP）用于标识接口的ifIndex[RFC2863]映射必须清晰。
o 该模型必须支持接口分层：（1）简单分层，其中一个接口分层在另一个接口之上；（2）更复杂的场景，其中一个接口由N个其他接口聚合而成，或者N个接口在另一个接口上多路复用。
o 数据模型应支持接口配置的预配置，即，应能够配置物理接口硬件不在设备上的接口。建议支持动态添加和删除物理接口的设备也支持预配置。
o 数据模型应支持物理接口和逻辑接口。
o 数据模型应包括只读计数器，以便收集发送和接收的八位字节和数据包、有错误的接收数据包以及由于错误而无法发送的数据包的统计信息。
3. 接口数据模型
本文件定义了模块”ietf接口”，其结构如下：
+--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
3.1. 接口列表
本文档中提供的接口数据模型使用接口的平面列表。列表中的每个接口都由其名称标识。此外，每个接口都有一个强制的”类型”叶。
“iana if type”模块[RFC7224]在iana维护的”ifType定义”注册表中定义接口类型的标识。
有一个已配置接口列表（”/interfaces/interface”），还有一个单独的所有接口操作状态列表（”/interfaces state/interface”）。
预计特定于接口类型的数据模型会增加接口列表，并可能使用”类型”叶来使增加有条件。
作为这种接口类型特定增强的一个例子，请看这个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 {
...
}
}
}
对于系统控制接口，”名称”是接口的设备特定名称。”config false”列表”/接口状态/接口”包含设备上的所有现有接口。
如果设备支持任意命名的用户控制接口，则网络配置协议（NETCONF）服务器会播发”任意名称”功能。如果设备未公布此功能，则用户控制接口的名称必须与设备的命名方案匹配。客户如何了解此类设备的命名方案超出了本文档的范围。示例见附录E.1和E.2。
当系统创建系统控制的接口时，系统尝试在”/interfaces/interface”中应用与新接口同名的接口配置。如果未找到此类接口配置，或者如果配置的类型与实际接口类型不匹配，则系统将在不应用显式配置的情况下创建接口。
创建用户控制的界面时，配置将确定界面的名称。
根据操作系统和可连接或移除网络接口的物理连接点，实现可能不可能在插入/移除周期以及预期初始插入时为系统控制接口提供可预测和一致的名称。因此，为此类接口提供配置的能力取决于实现，不能在所有情况下都假定。
3.2. 接口引用
接口由其名称标识，该名称在服务器中是唯一的。此属性在”interface ref”和”interface state ref”typedefs中捕获，当其他模块需要分别引用配置接口或操作使用的接口时，应使用这些属性。
3.3. 界面分层
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.
对于如何将接口配置为在其他接口之上分层，没有通用机制。预期特定于接口类型的模型通过使用”interface ref”类型引用较低的层来定义自己的接口分层数据节点。
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.
虽然接口分层是在接口类型特定的模型中配置的，但两个通用状态数据叶列表”较高层if”和”较低层if”表示接口分层层次结构的只读视图。
4. 与IF-MIB的关系
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”列表中的每个条目通常映射到一个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”条目的”name”映射到ifName。IF-MIB允许两个不同的IFENTRY具有相同的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.
在某些实现中，”接口”的配置”描述”传统上映射到IFALIA。本文档允许这种映射，但是实现者应该知道这些对象在值空间和持久性方面的差异。有关详细信息，请参见第5节叶”说明”的模块定义。
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还定义了可写对象IFPROMISCUUSMODE。由于SNMP代理通常不会将此对象实现为配置对象，因此不会将其映射到”ietf接口”模块。
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接口”模块。预计特定于接口类型的模块通过扩展”ietf接口”模型提供特定于接口类型的MTU LEAF。
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位的。添加64位版本是为了支持数据速率大于20000000位/秒的高速接口。今天的实现通常支持这种高速接口，因此在这个数据模型中只提供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接口”模块。
The following tables list the YANG data nodes with corresponding objects in the IF-MIB.
下表列出了IF-MIB中具有相应对象的数据节点。
+--------------------------------------+----------------------------+
| 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 State数据节点和相关的IF-MIB对象
+-----------------------------------------+---------------+
| YANG data node in /interfaces/interface | IF-MIB object |
+-----------------------------------------+---------------+
| description | ifAlias |
+-----------------------------------------+---------------+
YANG Config Data Nodes and Related IF-MIB Objects
配置数据节点和相关的IF-MIB对象
5. Interfaces YANG Module
5. 杨氏模块接口
This YANG module imports typedefs from [RFC6991].
此模块从[RFC6991]导入typedefs。
<CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"
module ietf-interfaces {
模块ietf接口{
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.
description”此模块包含用于管理网络接口的定义集合。
Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2014 IETF信托基金和被确定为代码作者的人员。版权所有。
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节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(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.”;
该模块的此版本是RFC 7223的一部分；有关完整的法律通知，请参见RFC本身。”；
revision 2014-05-08 {
description
"Initial revision.";
reference
"RFC 7223: A YANG Data Model for Interface Management";
}
6. IANA Considerations
6. IANA考虑
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].
本文件在”阳模块名称”注册表[RFC6020]中注册阳模块。
name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if
reference: RFC 7223
7. Security Considerations
7. 安全考虑
本文档基于 RFC 7223 标准，提供了面向接口管理的 YANG 数据模型的详细说明。