Internet Engineering Task Force (IETF) B. Linowski
Request for Comments: 6095 TCS/Nokia Siemens Networks
Category: Experimental M. Ersue
ISSN: 2070-1721 Nokia Siemens Networks
S. Kuryla
360 Treasury Systems
March 2011
Extending YANG with Language Abstractions
Abstract
抽象
YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.
YANG - ネットワーク構成プロトコル（NETCONF）データモデリング言語 - NETCONFを介して管理特定のネットワーク要素のコンフィギュレーションおよび実行時ステータスを表すデータ要素のツリーのモデリングをサポートしています。このメモは、モデルの拡張性と再利用性を向上する目的で補助的なモデリング機能と言語の抽象化でYANGを高めることを示唆しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6095.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6095で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Modeling Improvements with Language Abstractions . . . . . 5
1.4. Design Approach . . . . . . . . . . . . . . . . . . . . . 6
1.5. Modeling Resource Models with YANG . . . . . . . . . . . . 6
1.5.1. Example of a Physical Network Resource Model . . . . . 6
1.5.2. Modeling Entity MIB Entries as Physical Resources . . 12
2. Complex Types . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. complex-type Extension Statement . . . . . . . . . . . . . 15
2.3. instance Extension Statement . . . . . . . . . . . . . . . 17
2.4. instance-list Extension Statement . . . . . . . . . . . . 18
2.5. extends Extension Statement . . . . . . . . . . . . . . . 19
2.6. abstract Extension Statement . . . . . . . . . . . . . . . 19
2.7. XML Encoding Rules . . . . . . . . . . . . . . . . . . . . 20
2.8. Type Encoding Rules . . . . . . . . . . . . . . . . . . . 20
2.9. Extension and Feature Definition Module . . . . . . . . . 21
2.10. Example Model for Complex Types . . . . . . . . . . . . . 24
2.11. NETCONF Payload Example . . . . . . . . . . . . . . . . . 25
2.12. Update Rules for Modules Using Complex Types . . . . . . . 26
2.13. Using Complex Types . . . . . . . . . . . . . . . . . . . 26
2.13.1. Overriding Complex Type Data Nodes . . . . . . . . . . 26
2.13.2. Augmenting Complex Types . . . . . . . . . . . . . . . 27
2.13.3. Controlling the Use of Complex Types . . . . . . . . . 28
3. Typed Instance Identifier . . . . . . . . . . . . . . . . . . 29
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2. instance-type Extension Statement . . . . . . . . . . . . 29
3.3. Typed Instance Identifier Example . . . . . . . . . . . . 30
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. YANG Modules for Physical Network Resource Model
and Hardware Entities Model . . . . . . . . . . . . . 34
Appendix B. Example YANG Module for the IPFIX/PSAMP Model . . . . 40
B.1. Modeling Improvements for the IPFIX/PSAMP Model with
Complex Types and Typed Instance Identifiers . . . . . . . 40
B.2. IPFIX/PSAMP Model with Complex Types and Typed
Instance Identifiers . . . . . . . . . . . . . . . . . . . 41
YANG -- the NETCONF Data Modeling Language [RFC6020] -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This document defines extensions for the modeling language YANG as new language statements, which introduce language abstractions to improve the model extensibility and reuse. The document reports from modeling experience in the telecommunication industry and gives model examples from an actual network management system to highlight the value of proposed language extensions, especially class inheritance and recursiveness. The language extensions defined in this document have been implemented with two open source tools. These tools have been used to validate the model examples through the document. If this experimental specification results in successful usage, it is possible that the language extensions defined herein could be updated to incorporate implementation and deployment experience, then pursued on the Standards Track, possibly as part of a future version of YANG.
YANG - NETCONFデータモデリング言語[RFC6020]は - NETCONFを介して管理され、特定のネットワーク構成要素の構成及びランタイム状態を表すデータ要素のツリーのモデリングをサポートします。この文書では、モデルの拡張性と再利用性を向上するために、言語の抽象化を導入し、新しい言語文としてモデリング言語YANG用の拡張機能を定義します。文書の通信業界におけるモデリングの経験からの報告と提案した言語拡張の値を強調するために、実際のネットワーク管理システム、特にクラス継承と再帰からモデルの例を示します。この文書で定義された言語拡張は、二つのオープンソースツールを用いて実装されています。これらのツールは、文書を通じてモデルの例を検証するために使用されています。成功した使用法では、この実験の仕様の結果ならば、それは、本明細書に定義された言語拡張が実装と展開の経験を組み込むように更新される可能性があり、その後、おそらくYANGの将来のバージョンの一環として、標準化過程に追求しました。
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"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL BCP 14、[RFC2119]に記載されているように「この文書に解釈されるべきです。
Following are non-exhaustive motivation examples highlighting usage scenarios for language abstractions.
以下は、言語の抽象化のための使用シナリオを強調非網羅的な動機の例です。
o Many systems today have a Management Information Base (MIB) that in effect is organized as a tree build of recursively nested container nodes. For example, the physical resources in the ENTITY-MIB conceptually form a containment tree. The index entPhysicalContainedIn points to the containing entity in a flat list. The ability to represent nested, recursive data structures of arbitrary depth would enable the representation of the primary containment hierarchy of physical entities as a node tree in the server MIB and in the NETCONF payload.
O多くのシステム今日は、実際には再帰的にネストされたコンテナノードのツリーのビルドとして組織されていることを管理情報ベース（MIB）を持っています。例えば、ENTITY-MIB内の物理リソースは、概念的に包含ツリーを形成します。フラットリストに含むエンティティへのインデックスentPhysicalContainedInポイント。任意の深さのネストされ、再帰的なデータ構造を表現する能力は、サーバMIBおよびNETCONFペイロードのノードツリーのような物理的実体の一次包含階層の表現を可能にします。
o A manager scanning the network in order to update the state of an inventory management system might be only interested in data structures that represent a specific type of hardware. Such a manager would then look for entities that are of this specific type, including those that are an extension or specialization of this type. To support this use case, it is helpful to bear the corresponding type information within the data structures, which describe the network element hardware.
O在庫管理システムの状態を更新するためにネットワークをスキャンマネージャは、ハードウェアの特定のタイプを表すデータ構造にのみ興味があるかもしれません。このような管理者は、このタイプの拡張または専門であるものを含め、この特定のタイプであるエンティティを探します。このユースケースをサポートするためには、ネットワーク要素のハードウェアを記述するデータ構造内の対応する型情報を負担することが有用です。
o A system that is managing network elements is concerned, e.g., with managed objects of type "plug-in modules" that have a name, a version, and an activation state. In this context, it is useful to define the "plug-in module" as a concept that is supposed to be further detailed and extended by additional concrete model elements. In order to realize such a system, it is worthwhile to model abstract entities, which enable reuse and ease concrete refinements of that abstract entity in a second step.
O管理ネットワーク要素であるシステムは、名前、バージョン、および活性化状態を有するタイプの管理対象オブジェクト「プラグインモジュール」と、例えば、懸念しています。この文脈では、さらに詳細かつ追加の具体的モデル要素によって拡張されることになっている概念として「プラグインモジュール」を定義することが有用です。このようなシステムを実現するためには、再利用を可能にする抽象エンティティをモデル化し、第二段階でその抽象エンティティの具体的な改良を容易にするために価値があります。
o As particular network elements have specific types of components that need to be managed (OS images, plug-in modules, equipment, etc.), it should be possible to define concrete types, which describe the managed object precisely. By using type-safe extensions of basic concepts, a system in the manager role can safely and explicitly determine that e.g., the "equipment" is actually of type "network card".
特定のネットワーク要素を管理するために必要なコンポーネントの特定のタイプ（OSイメージ、プラグインモジュール、装置、等）を有するOなど、正確に管理オブジェクトを記述する具体的なタイプを定義することが可能であるべきです。基本的な概念のタイプセーフな拡張機能を使用することで、管理者の役割でシステムが安全かつ明示的に、例えば、「機器」は、実際にタイプの「ネットワークカード」であると判断することができます。
o Currently, different SDOs are working on the harmonization of their management information models. Often, a model mapping or transformation between systems becomes necessary. The harmonization of the models is done e.g., by mapping of the two models on the object level or integrating an object hierarchy into an existing information model. On the one hand, extending YANG with language abstractions can simplify the adoption of IETF resource models by other SDOs and facilitate the alignment with other SDOs' resource models (e.g., TM Forum SID [SID_V8]). On the other hand, the proposed YANG extensions can enable the utilization of the YANG modeling language in other SDOs, which usually model complex management systems in a top-down manner and use high-level language features frequently.
O現在、異なるのSDOは、その管理情報モデルの調和に取り組んでいます。しばしば、システム間のモデルのマッピングまたは変換が必要となります。モデルの調和は、既存の情報モデルにオブジェクトのレベルまたはオブジェクト階層を統合上の2つのモデルのマッピングによって、例えば行われます。一方、言語の抽象化とYANGを拡張すると、他のSDOによってIETFリソース・モデルの採用を簡素化し、他のSDOリソース・モデル（例えば、TMフォーラムSID [SID_V8]）との位置合わせを容易にすることができます。一方、提案YANG拡張子は通常、トップダウン的に複雑な管理システムをモデル化する他のSDOでYANGモデリング言語の利用を可能にし、高レベルの言語を使用することができ、頻繁ます。
This memo specifies additional modeling features for the YANG language in the area of structured model abstractions, typed references, as well as recursive data structures, and it discusses how these new features can improve the modeling capabilities of YANG.
このメモは、構造化されたモデルの抽象化の領域でYANG言語の追加のモデリング機能を指定する参照を入力しただけでなく、再帰的なデータ構造、そして、それはこれらの新機能は、YANGのモデリング機能を改善する方法について説明します。
Section 1.5.1 contains a physical resource model that deals with some of the modeling challenges illustrated above. Section 1.5.2 gives an example that uses the base classes defined in the physical resource model and derives a model for physical entities defined in the Entity MIB.
セクション1.5.1は、上に示したモデリング課題のいくつかを扱う物理リソースモデルが含まれています。セクション1.5.2は、物理リソースモデルで定義されたベースクラスを使用し、エンティティMIBで定義された物理的なエンティティのためのモデルを導出例を示します。
As an enhancement to YANG 1.0, complex types and typed instance identifiers provide different technical improvements on the modeling level:
YANG 1.0への拡張として、複合型および型指定されたインスタンス識別子は、モデリングレベルの異なる技術的な改善を提供します。
o In case the model of a system that should be managed with NETCONF makes use of inheritance, complex types enable an almost one-to-one mapping between the classes in the original model and the YANG module.
O場合NETCONFで管理しなければならないシステムのモデルは、継承を利用して、複合型は、元のモデルにおけるクラス間のほぼ1対1のマッピングとYANGモジュールを有効にします。
o Typed instance identifiers allow representing associations between the concepts in a type-safe way to prevent type errors caused by referring to data nodes of incompatible types. This avoids referring to a particular location in the MIB. Referring to a particular location in the MIB is not mandated by the domain model.
O型付きインスタンス識別子は、互換性のないタイプのデータノードを参照することによって引き起こされるタイプのエラーを防ぐために、型安全な方法で概念間の関連を示す可能にします。これは、MIB内の特定の場所を参照回避します。 MIB内の特定の場所を参照すると、ドメイン・モデルによって規定されていません。
o Complex types allow defining complete, self-contained type definitions. It is not necessary to explicitly add a key statement to lists, which use a grouping that defines the data nodes.
O複合型は、完全な、自己完結型の定義を定義することができます。明示的にデータノードを定義してグループ化を使用してリストにキーステートメントを追加する必要はありません。
o Complex types simplify concept refinement by extending a base complex type and make it superfluous to represent concept refinements with workarounds such as huge choice-statements with complex branches.
O複合型は、基本複合型を拡張することによって概念の洗練を簡素化し、それが余計な複雑な支店を持つ巨大な選択肢-文などの回避策をコンセプト改良を表すために作ります。
o Abstract complex types ensure correct usage of abstract concepts by enforcing the refinement of a common set of properties before instantiation.
O抽象複合型は、インスタンス化する前に、プロパティの共通セットの改善を実施することにより、抽象的な概念の正しい使用方法を確認してください。
o Complex types allow defining recursive structures. This enables representing complex structures of arbitrary depth by nesting instances of basic complex types that may contain themselves.
O複合型は、再帰的な構造を定義することができます。これは、自分自身を含むことができ、基本的な複合型のインスタンスをネストすることで、任意の深さの複雑な構造を表すことができます。
o Complex types avoid introducing metadata types (e.g., type code enumerations) and metadata leafs (e.g., leafs containing a type code) to indicate which concrete type of object is actually represented by a generic container in the MIB. This also avoids explicitly ruling out illegal use of subtype-specific properties in generic containers.
O複合タイプは、オブジェクトの具体的なタイプは、実際にMIBにおける汎用コンテナで表されるかを示すためにメタデータの種類（例えば、タイプコード列挙）とメタデータリーフ（タイプコードを含む、例えば、葉）を導入避けます。また、これは明示的に、一般的なコンテナ内のサブタイプ特異的性質の不正使用を排除避けることができます。
o Complex type instances include the type information in the NETCONF payload. This allows determining the actual type of an instance during the NETCONF payload parsing and avoids the use in the model of additional leafs, which provide the type information as content.
O複合型のインスタンスは、NETCONFペイロードタイプ情報を含みます。これは、NETCONFペイロード解析中インスタンスの実際のタイプを決定することを可能とコンテンツなど型情報を提供する追加の葉のモデルにおける使用を回避します。
o Complex types may be declared explicitly as optional features, which is not possible when the actual type of an entity represented by a generic container is indicated with a type code enumeration.
O複合タイプは、ジェネリックコンテナによって表されるエンティティの実際のタイプがタイプコード列挙で示されている場合に可能ではないオプション機能として明示的に宣言することができます。
Appendix B, "Example YANG Module for the IPFIX/PSAMP Model", lists technical improvements for modeling with complex types and typed instance identifiers and exemplifies the usage of the proposed YANG extensions based on the IP Flow Information Export (IPFIX) / Packet Sampling (PSAMP) configuration model in [IPFIXCONF].
「IPFIX / PSAMPモデルの例YANGモジュール」の付録B、複合型とモデリングのための技術的な改善を示していますし、インスタンス識別子を入力し、IPフロー情報のエクスポート（IPFIX）/パケットサンプリング（に基づいて提案YANGエクステンションの使用を例示しています【IPFIXCONF]でPSAMP）構成モデル。
The proposed additional features for YANG in this memo are designed to reuse existing YANG statements whenever possible. Additional semantics is expressed by an extension that is supposed to be used as a substatement of an existing statement.
このメモでYANGための提案の追加機能は、可能な限り既存のYANG文を再利用するために設計されています。追加のセマンティクスは、既存のステートメントのサブステートメントとして使用することを想定している拡張子で表現されます。
The proposed features don't change the semantics of models that is valid with respect to the YANG specification [RFC6020].
提案された機能は、YANG仕様[RFC6020]に対する有効なモデルのセマンティクスを変更しないでください。
The diagram below depicts a portion of an information model for manageable network resources used in an actual network management system.
以下の図は、実際のネットワーク管理システムで使用される管理ネットワークリソースのための情報モデルの一部を示します。
Note: The referenced model (UDM, Unified Data Model) is based on key resource modeling concepts from [SID_V8] and is compliant with selected parts of SID Resource Abstract Business Entities domain [UDM].
注：参照モデル（UDM、統一データモデルは）[SID_V8]からキーリソースモデリングの概念に基づいており、SIDリソース抽象ビジネスエンティティドメインの選択した部分[UDM]に準拠しています。
The class diagram in Figure 1 and the corresponding YANG module excerpt focus on basic resource ("Resource" and the distinction between logical and physical resources) and hardware abstractions ("Hardware", "Equipment", and "EquipmentHolder"). Class attributes were omitted to achieve decent readability.
図1のクラス図と基本リソース（「リソース」と論理および物理リソースの区別）およびハードウェア抽象化（「ハードウェア」、「機器」、および「機器ホルダー」）に対応するYANGモジュール抜粋フォーカス。クラス属性は、まともな読みやすさを実現するために省略しました。
+--------+
|Resource|
+--------+
/\ /\
-- --
| |
| +---------------+
| |LogicalResource|
| +---------------+
|
| +--------+
| |Physical| +-----------+
'-|Resource|<|-+-|PhysicalLink|
+---- ---+ | +------------+
| |0..* physicalLink
| | equipment
| | Holder
| | 0..*
| | +-------+
| |0..* hardware | |
| +--------+ +---------------+ +---------+ |
'-|Hardware|<|-+-|ManagedHardware|<|-+-|Equipment|<>--+
+--------+ | +---------------+ | | Holder |0..1
<> | | +---------+
0..1| | | <>
| | | |0..* equipment
| | | | Holder
| | | |
| | | |0..* equipment
| | | |
| | | | equipment
| | | | 0..*
| | | | +-------+
| | | | | |
| | | +---------+ |
| | '-|Equipment|<>--+
| | +---------+0..1
| | compositeEquipment
| |
| | +-----------------+
| '-|PhysicalConnector|----+0..* source
'----------+-----------------+ | Physical
physicalConnector 0..* | | Connector
| |
+-----------+
0..* targetPhysicalConnector
Figure 1: Physical Network Resource Model
図1：物理ネットワークのリソース・モデル
Since this model is an abstraction of network-element-specific MIB topologies, modeling it with YANG creates some challenges. Some of these challenges and how they can be addressed with complex types are explained below:
このモデルは、ネットワーク要素固有のMIBトポロジーの抽象化であるので、YANGでそれをモデル化することはいくつかの課題を作成します。これらの課題のいくつかと、それらが複合型で対処する方法を以下に説明されています。
o Modeling of abstract concepts: Classes like "Resource" represent concepts that primarily serve as a base class for derived classes. With complex types, such an abstract concept could be represented by an abstract complex type (see "complex-type extension statement" and "abstract extension statement").
抽象的な概念のモデル化○：「リソース」のようなクラスは、主に、派生クラスの基本クラスとして機能概念を表します。複合型では、そのような抽象的な概念は抽象複合型（「複合型の拡張声明」と「抽象拡張文」を参照）で表すことができます。
o Class Inheritance: Information models for complex management domains often use class inheritance to create specialized classes like "PhysicalConnector" from a more generic base class (here, "Hardware"), which itself might inherit from another base class ("PhysicalResource"), etc. Complex types allow creating enhanced versions of an existing (abstract or concrete) base type via an extension (see "extends extension statement").
Oクラスの継承：複雑な管理ドメインのための情報モデルは、多くの場合、それ自体が別の基底クラス（「PhysicalResource」）から継承するかもしれない、より汎用的な基底クラス（ここでは、「ハードウェア」）から「PhysicalConnector」のような専用のクラスを作成するために、クラスの継承を使用し、などの複合型（「拡張文を拡張する」を参照）の拡張を経て、既存の（抽象的またはコンクリート）基本型の強化バージョンを作成できます。
o Recursive containment: In order to specify containment hierarchies, models frequently contain different aggregation associations, in which the target (contained element) is either the containing class itself or a base class of the containing class. In the model above, the recursive containment of "EquipmentHolder" is an example of such a relationship (see the description for the "complex-type EquipmentHolder" in the example model "udmcore" below).
再帰的封じ込め（O）封じ込め階層を指定するために、モデルは、しばしば標的（含まれる要素）を含むクラス自体又は含むクラスのベースクラスのいずれかである、異なる集合の関連付けを含みます。上記のモデルでは、「機器ホルダー」の再帰的封じ込めは、このような関係の一例（以下の実施例モデル「udmcore」の「複合型機器ホルダー」の説明を参照します）。
o Complex types support such a containment by using a complex type (or one of its ancestor types) as the type of an instance or instance list that is part of its definition (see "instance(-list) extension statement").
O複合型（「インスタンス（-list）拡張文」を参照）、その定義の一部であるインスタンスまたはインスタンスリストの種類として複合型（またはその祖先の種類のいずれか）を使用してそのような封じ込めをサポートします。
o Reference relationships: A key requirement on large models for network domains with many related managed objects is the ability to define inter-class associations that represent essential relationships between instances of such a class. For example, the relationship between "PhysicalLink" and "Hardware" tells which physical link is connecting which hardware resources. It is important to notice that this kind of relationship does not mandate any particular location of the two connected hardware instances in any MIB module. Such containment-agnostic relationships can be represented by a typed instance identifier that embodies one direction of such an association (see Section 3, "Typed Instance Identifier").
O参考関係：多くの関連管理対象オブジェクトとのネットワークドメインのための大規模モデルの重要な要件は、そのようなクラスのインスタンス間の本質的な関係を表すクラス間の関連付けを定義する機能です。例えば、「PhysicalLink」と「ハードウェア」の間の関係は、ハードウェア・リソースを接続しているどの物理リンクを伝えます。このような関係は、任意のMIBモジュールに接続された2つのハードウェアインスタンスの任意の特定の場所を強制しないことに注意することが重要です。そのような包含に依存しない関係は、このような関連の一方向を具体型付けされたインスタンス識別子によって表すことができる（セクション3を参照し、「型付きインスタンス識別子」）。
The YANG module excerpt below shows how the challenges listed above can be addressed by the Complex Types extension (module import prefix "ct:"). The complete YANG module for the physical resource model in Figure 1 can be found in Appendix A, "YANG Modules for Physical Network Resource Model and Hardware Entities Model".
以下YANGモジュールの抜粋は、上記の課題は、複合型の拡張（モジュールのインポート接頭辞「CT：」）によって対処することができる方法を示しています。図1の物理リソース・モデルの完全なYANGモジュールは、付録A、「物理ネットワークリソース・モデルとハードウェアエンティティモデルのYANGモジュール」に記載されています。
Note: The YANG extensions proposed in this document have been implemented as the open source tools "Pyang Extension for Complex Types" [Pyang-ct], [Pyang], and "Libsmi Extension for Complex Types" [Libsmi]. All model examples in the document have been validated with the tools Pyang-ct and Libsmi.
注：この文書で提案されているYANG拡張は、オープンソースツール「複合型のためPyang拡張子」[Pyang-CT]、[Pyang]、および「複合型のためLibsmi拡張」[Libsmi]として実装されています。ドキュメント内のすべてのモデルの例は、ツールPyang-CTとLibsmiで検証されています。
<CODE BEGINS>
<CODEが開始されます>
module udmcore {
モジュールudmcore {
namespace "http://example.com/udmcore";
prefix "udm";
import ietf-complex-types {prefix "ct"; }
輸入IETF-複合タイプ{接頭辞「CT」。 }
// Basic complex types...
//基本的な複合型...
ct:complex-type PhysicalResource {
ct:extends Resource;
ct:abstract true;
// ...
leaf serialNumber {
type string;
description "'Manufacturer-allocated part number' as
defined in SID, e.g., the part number of a fiber link
cable.";
}
}
ct:complex-type Hardware {
ct:extends PhysicalResource;
ct:abstract true;
// ...
leaf-list physicalLink {
type instance-identifier {ct:instance-type PhysicalLink;}
}
ct:instance-list containedHardware {
ct:instance-type Hardware;
}
ct:instance-list physicalConnector {
ct:instance-type PhysicalConnector;
} }
｝ ｝
ct:complex-type PhysicalLink { ct:extends PhysicalResource; // ... leaf-list hardware { type instance-identifier {ct:instance-type Hardware;} } }
CT：複合型PhysicalLink {CT：PhysicalResourceを拡張します。 // ...リーフリストハードウェア{タイプインスタンス識別子{CT：インスタンス型ハードウェア;}}}
ct:complex-type ManagedHardware {
ct:extends Hardware;
ct:abstract true;
// ...
}
ct:complex-type PhysicalConnector { ct:extends Hardware; leaf location {type string;} // ... leaf-list sourcePhysicalConnector { type instance-identifier {ct:instance-type PhysicalConnector;} } leaf-list targetPhysicalConnector { type instance-identifier {ct:instance-type PhysicalConnector;} } }
CT：複合型PhysicalConnector {CTは：ハードウェアを拡張します。リーフ位置{string型;} // ...リーフリストsourcePhysicalConnector {タイプインスタンス識別子{CT：インスタンス型PhysicalConnector;}}リーフリストtargetPhysicalConnector {タイプインスタンス識別子{CT：インスタンス型PhysicalConnector;}} }
ct:complex-type Equipment {
ct:extends ManagedHardware;
// ...
ct:instance-list equipment {
ct:instance-type Equipment;
}
}
ct:complex-type EquipmentHolder {
ct:extends ManagedHardware;
description "In the SID V8 definition, this is a class based on
the M.3100 specification. A base class that represents physical
objects that are both manageable as well as able to host,
hold, or contain other physical objects. Examples of physical objects that can be represented by instances of this object
class are Racks, Chassis, Cards, and Slots.
A piece of equipment with the primary purpose of containing
other equipment.";
leaf vendorName {type string;}
// ...
ct:instance-list equipment {
ct:instance-type Equipment;
}
ct:instance-list equipmentHolder {
ct:instance-type EquipmentHolder;
}
}
// ...
}
<CODE ENDS>
<CODEはENDS>
The physical resource module described above can now be used to model physical entities as defined in the Entity MIB [RFC4133]. For each physical entity class listed in the "PhysicalClass" enumeration, a complex type is defined. Each of these complex types extends the most specific complex type already available in the physical resource module. For example, the type "HWModule" extends the complex type "Equipment" as a hardware module. Physical entity properties that should be included in a physical entity complex type are combined in a grouping, which is then used in each complex type definition of an entity.
上記物理的リソース・モジュールは、現在エンティティMIB [RFC4133]で定義されるように物理的なエンティティをモデル化するために使用することができます。 「PhysicalClass」列挙にリストされた各物理エンティティ・クラスのために、複合型が定義されています。これらの複雑なタイプのそれぞれは、物理的なリソースモジュールですでに利用可能な最も具体的な複合型を拡張します。例えば、タイプ「HWModuleは、」ハードウェアモジュールとして複合型「機器」を延びています。物理的なエンティティの複合型に含まれるべきである物理的なエンティティのプロパティは、次に、エンティティの各複合型定義で使用されるグループに組み合わされます。
This approach has following benefits:
このアプローチは、次の利点があります。
o The definition of the complex types for hardware entities becomes compact as many of the features can be reused from the basic complex type definition.
機能の多くは、基本的な複合型定義から再利用できるよう、Oハードウェアエンティティのための複合型の定義がコンパクトになります。
o Physical entities are modeled in a consistent manner as predefined concepts are extended.
事前定義された概念が拡張されるようにO物理エンティティは、一貫した方法でモデル化されます。
o Entity-MIB-specific attributes as well as vendor-specific attributes can be added without having to define separate extension data nodes.
OエンティティMIB固有属性、ならびにベンダー固有の属性は、個別の拡張データ・ノードを定義することなく追加することができます。
Module udmcore : Module hardware-entities
:
equipment :
Holder :
0..* :
+-------+ :
| | :
+---------------+ +---------+ | :
|ManagedHardware|<|-+-|Equipment|<>--+ :
+---------------+ | | Holder |0..1 : +-------+
| | |<|---------+--|Chassis|
| +---------+ : | +-------+
| <> : |
| |0..* equipment : | +---------+
| | Holder : '--|Container|
| | : +---------+
| |0..* equipment :
| | :
| | equipment :
| | 0..* :
| | +-------+ :
| | | | :
| +---------+ | :
'-|Equipment|<>--+ : +--------+
| |<|---------+--|HWModule|
+---------+ : | +--------+
compositeEquipment : |
: | +---------+
: |--|Backplane|
: +---------+
Figure 2: Hardware Entities Model
図2：ハードウェアエンティティモデル
Below is an excerpt of the corresponding YANG module using complex types to model hardware entities. The complete YANG module for the Hardware Entities model in Figure 2 can be found in Appendix A, "YANG Modules for Physical Network Resource Model and Hardware Entities Model".
以下のハードウェアエンティティをモデル化するために、複雑な型を使用して、対応するYANGモジュールの抜粋です。図2のハードウェアエンティティモデルのための完全なYANGモジュールは、付録A、「物理ネットワークリソース・モデルとハードウェアエンティティモデルのYANGモジュール」に記載されています。
<CODE BEGINS>
<CODEが開始されます>
module hardware-entities {
モジュールのハードウェアエンティティ{
namespace "http://example.com/hardware-entities";
prefix "hwe";
import ietf-yang-types {prefix "yt";} import ietf-complex-types {prefix "ct";} import udmcore {prefix "uc";}
インポートIETF-ヤン・タイプ{接頭辞 "YT";}インポートIETF-複素タイプ{接頭辞 "CT";}インポートudmcore {接頭辞 "UC";}
grouping PhysicalEntityProperties { // ... leaf mfgDate {type yang:date-and-time; } leaf-list uris {type string; } }
グループ化PhysicalEntityProperties {// ...葉mfgDate {タイプヤン：日時; }リーフリストのURI {型ストリング。 }}
// Physical entities representing equipment
機器を表す//物理的なエンティティ
ct:complex-type HWModule {
ct:extends uc:Equipment;
description "Complex type representing module entries
(entPhysicalClass = module(9)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
// ...
／／ 。。。
// Physical entities representing equipment holders
機器ホルダーを表す//物理的なエンティティ
ct:complex-type Chassis {
ct:extends uc:EquipmentHolder;
description "Complex type representing chassis entries
(entPhysicalClass = chassis(3)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
// ... }
／／ 。。。 ｝
<CODE ENDS>
<CODEはENDS>
YANG type concept is currently restricted to simple types, e.g., restrictions of primitive types, enumerations, or union of simple types.
YANGタイプの概念は、現在、単純型、例えば、プリミティブ型、列挙型、または単純な種類の労働組合の制限のために制限されています。
Complex types are types with a rich internal structure, which may be composed of substatements defined in Table 1 (e.g., lists, leafs, containers, choices). A new complex type may extend an existing complex type. This allows providing type-safe extensions to existing YANG models as instances of the new type.
複合タイプは、表1（例えば、リスト、葉、コンテナ、選択肢）で定義されたサブステートメントで構成することができる豊富な内部構造を有するタイプです。新しい複合型は、既存の複合型を拡張することができます。これは、新しいタイプのインスタンスとして既存YANGモデルにタイプセーフな拡張を提供することができます。
Complex types have the following characteristics:
複合型は、次の特性があります。
o Introduction of new types, as a named, formal description of a concrete manageable resource as well as abstract concepts.
具体的な管理可能リソースの名前の、正式な説明だけでなく、抽象的な概念として新しいタイプの導入、O。
o Types can be extended, i.e., new types can be defined by specializing existing types and adding new features. Instances of such an extended type can be used wherever instances of the base type may appear.
O型はすなわち、新しいタイプは、既存のタイプを専門にし、新しい機能を追加することによって定義することができ、拡張することができます。ベース型のインスタンスが表示されること限り、このような拡張された型のインスタンスを使用することができます。
o The type information is made part of the NETCONF payload in case a derived type substitutes a base type. This enables easy and efficient consumption of payload elements representing complex type instances.
O型情報は、派生型が基本型を代入する場合にNETCONFペイロードの一部されています。これは、複合型のインスタンスを表すペイロード要素の簡単かつ効率的に消費することが可能となります。
The extension statement "complex-type" is introduced; it accepts an arbitrary number of statements that define node trees, among other common YANG statements ("YANG Statements", Section 7 of [RFC6020]).
拡張文の「複合型」を導入しました。それは他の一般的なYANGステートメント（「YANG文」、[RFC6020]のセクション7）のうち、ノードツリーを定義文の任意の数を受け付けます。
+------------------+-------------+
| substatement | cardinality |
+------------------+-------------+
| abstract | 0..1 |
| anyxml | 0..n |
| choice | 0..n |
| container | 0..n |
| description | 0..1 |
| ct:instance | 0..n |
| ct:instance-list | 0..n |
| ct:extends | 0..1 |
| grouping | 0..n |
| if-feature | 0..n |
| key | 0..1 |
| leaf | 0..n |
| leaf-list | 0..n |
| list | 0..n |
| must | 0..n |
| ordered-by | 0..n |
| reference | 0..1 |
| refine | 0..n |
| status | 0..1 |
| typedef | 0..n |
| uses | 0..n |
+------------------+-------------+
Table 1: complex-type's Substatements
表1：複合型のサブステートメント
Complex type definitions may appear at every place where a grouping may be defined. That includes the module, submodule, rpc, input, output, notification, container, and list statements.
複合型の定義は、グループを定義することができるすべての場所で表示されることがあります。すなわち、モジュール、サブモジュール、RPC、入力、出力、通知、コンテナ、およびリスト・ステートメントを含みます。
Complex type names populate a distinct namespace. As with YANG groupings, it is possible to define a complex type and a data node (e.g., leaf, list, instance statements) with the same name in the same scope. All complex type names defined within a parent node or at the top level of the module or its submodules share the same type identifier namespace. This namespace is scoped to the parent node or module.
複合型の名前は、異なる名前空間を埋めます。 YANGグルーピングと同様に、複合型とデータノード同じスコープ内の同じ名前を持つ（例えば、葉、リスト、インスタンス文）を定義することが可能です。親ノード内またはモジュールまたはサブモジュールのトップレベルで定義されたすべての複合型の名前は、同じタイプの識別子の名前空間を共有します。この名前空間は、親ノードまたはモジュールにスコープされます。
A complex type MAY have an instance key. An instance key is either defined with the "key" statement as part of the complex type or is inherited from the base complex type. It is not allowed to define an additional key if the base complex type or one of its ancestors already defines a key.
複合型は、インスタンスキーを持っているかもしれません。インスタンスキーは、どちらかの複合型の一部としての「キー」ステートメントで定義されているまたは塩基複合タイプから継承されます。塩基複合型またはその祖先の一つが既に鍵を定義している場合、追加のキーを定義することができません。
Complex type definitions do not create nodes in the schema tree.
複合型の定義は、スキーマツリー内のノードを作成しないでください。
The "instance" extension statement is used to instantiate a complex type by creating a subtree in the management information node tree. The instance statement takes one argument that is the identifier of the complex type instance. It is followed by a block of substatements.
「インスタンス」拡張文は、管理情報ノードツリーのサブツリーを作成することにより、複合型のインスタンスを作成するために使用されます。インスタンス文は、複合型のインスタンスの識別子である一つの引数を取ります。これは、サブステートメントのブロックが続いています。
The type of the instance is specified with the mandatory "ct: instance-type" substatement. The type of an instance MUST be a complex type. Common YANG statements may be used as substatements of the "instance" statement. An instance is optional by default. To make an instance mandatory, "mandatory true" has to be applied as a substatement.
サプ：インスタンスのタイプは、必須の「インスタンス型CT」で指定されています。インスタンスのタイプは複合型でなければなりません。共通YANG文は、「インスタンス」の文のサブステートメントとして使用することができます。インスタンスは、デフォルトではオプションです。インスタンスを必須にするには、「必須真は」サブステートメントとして適用する必要があります。
+------------------+-------------+
| substatement | cardinality |
+------------------+-------------+
| description | 0..1 |
| config | 0..1 |
| ct:instance-type | 1 |
| if-feature | 0..n |
| mandatory | 0..1 |
| must | 0..n |
| reference | 0..1 |
| status | 0..1 |
| when | 0..1 |
| anyxml | 0..n |
| choice | 0..n |
| container | 0..n |
| ct:instance | 0..n |
| ct:instance-list | 0..n |
| leaf | 0..n |
| leaf-list | 0..n |
| list | 0..n |
+------------------+-------------+
Table 2: instance's Substatements
表2：インスタンスのサブステートメント
The "instance" and "instance-list" extension statements (see Section 2.4, "instance-list Extension Statement") are similar to the existing "leaf" and "leaf-list" statements, with the exception that the content is composed of subordinate elements according to the instantiated complex type.
「インスタンス」と「インスタンス・リスト」の拡張文は（セクション2.4、「インスタンス・リストの拡張に関する声明」を参照）コンテンツが構成されていることを除いて、既存の「リーフ」と「リーフリスト」の文と類似していますインスタンス化された複合型に従って従属要素。
It is also possible to add additional data nodes by using the corresponding leaf, leaf-list, list, and choice-statements, etc., as substatements of the instance declaration. This is an in-place augmentation of the used complex type confined to a complex type instantiation (see also Section 2.13, "Using Complex Types", for details on augmenting complex types).
インスタンス宣言のサブステートメントとして、等に対応するリーフ、リーフリスト、リスト、および選択・ステートメントを使用して追加のデータノードを追加することも可能です。これは、複合型のインスタンスに限定使用の複合型（複合型を増強についての詳細は、「複合型の使用」セクションも2.13を参照）のインプレース増加です。
The "instance-list" extension statement is used to instantiate a complex type by defining a sequence of subtrees in the management information node tree. In addition, the "instance-list" statement takes one argument that is the identifier of the complex type instances. It is followed by a block of substatements.
「インスタンス・リスト」の拡張文は管理情報ノードツリーにサブツリーのシーケンスを定義することにより、複合型をインスタンス化するために使用されます。また、「インスタンス・リスト」の文は、複合型のインスタンスの識別子であり、一つの引数を取ります。これは、サブステートメントのブロックが続いています。
The type of the instance is specified with the mandatory "ct: instance-type" substatement. In addition, it can be defined how often an instance may appear in the schema tree by using the "min-elements" and "max-elements" substatements. Common YANG statements may be used as substatements of the "instance-list" statement.
サプ：インスタンスのタイプは、必須の「インスタンス型CT」で指定されています。また、インスタンスが「MIN-要素」および「MAX-要素」サブステートメントを使用して、スキーマ・ツリーに表示されることがあり頻度定義することができます。共通YANG文は、「インスタンス・リスト」の文のサブステートメントとして使用することができます。
In analogy to the "instance" statement, YANG substatements like "list", "choice", "leaf", etc., MAY be used to augment the "instance-list" elements at the root level with additional data nodes.
などの「インスタンス」声明、「リスト」のようなYANGのサブステートメントは、「選択」、「葉」と同様に、では、追加のデータノードとのルートレベルにある「インスタンス・リスト」の要素を強化するために使用されるかもしれません。
+------------------+-------------+
| substatementc | cardinality |
+------------------+-------------+
| description | 0..1 |
| config | 0..1 |
| ct:instance-type | 1 |
| if-feature | 0..n |
| max-elements | 0..1 |
| min-elements | 0..1 |
| must | 0..n |
| ordered-by | 0..1 |
| reference | 0..1 |
| status | 0..1 |
| when | 0..1 |
| anyxml | 0..n |
| choice | 0..n |
| container | 0..n |
| ct:instance | 0..n |
| ct:instance-list | 0..n |
| leaf | 0..n |
| leaf-list | 0..n |
| list | 0..n |
+------------------+-------------+
Table 3: instance-list's Substatements
表3：インスタンス・リストのサブステートメント
In case the instance list represents configuration data, the used complex type of an instance MUST have an instance key.
インスタンスのリストは、構成データを表す場合には、インスタンスの使用複合型は、インスタンスキーを持たなければなりません。
Instances as well as instance lists may appear as arguments of the "deviate" statement.
インスタンスだけでなく、インスタンスのリストは、「逸脱」の文の引数として表示されることがあります。
A complex type MAY extend exactly one existing base complex type by using the "extends" extension statement. The keyword "extends" MAY occur as a substatement of the "complex-type" extension statement. The argument of the "complex-type" extension statement refers to the base complex type via its name. In case a complex type represents configuration data (the default), it MUST have a key; otherwise, it MAY have a key. A key is either defined with the "key" statement as part of the complex type or is inherited from the base complex type.
複合型は、「拡張」拡張ステートメントを使用して正確に一つの既存のベースの複合型を拡張することができます。キーワードは「複合型」の拡張文のサブステートメントとして発生する可能性のある「拡張します」。 「複合型」の拡張文の引数には、その名前を介してベース複合型を指します。複合タイプは、構成データ（デフォルト）を表す場合には、キーを持たなければなりません。それ以外の場合は、キーを持っているかもしれません。キーは、いずれかの複合型の一環として、「キー」ステートメントで定義されたまたはベース複合型から継承されます。
+--------------+-------------+
| substatement | cardinality |
+--------------+-------------+
| description | 0..1 |
| reference | 0..1 |
| status | 0..1 |
+--------------+-------------+
Table 4: extends' Substatements
表4：サブステートメントを拡張します
Complex types may be declared to be abstract by using the "abstract" extension statement. An abstract complex type cannot be instantiated, meaning it cannot appear as the most specific type of an instance in the NETCONF payload. In case an abstract type extends a base type, the base complex type MUST be also abstract. By default, complex types are not abstract.
複合型は、「抽象的」拡張ステートメントを使用して抽象的であると宣言することができます。抽象複合型は、NETCONFペイロード内のインスタンスの最も具体的なタイプとして表示することはできませんつまり、インスタンス化することはできません。場合抽象型は、基本型を拡張し、塩基複合型も抽象的でなければなりません。デフォルトでは、複合型は抽象的ではありません。
The abstract complex type serves only as a base type for derived concrete complex types and cannot be used as a type for an instance in the NETCONF payload.
抽象複合タイプは、誘導された具体的な複合型の基本型として機能し、NETCONFペイロード内のインスタンスの型として使用することができません。
The "abstract" extension statement takes a single string argument, which is either "true" or "false". In case a "complex-type" statement does not contain an "abstract" statement as a substatement, the default is "false". The "abstract" statement does not support any substatements.
「抽象的」拡張文は「true」または「false」のどちらかである単一の文字列引数を取ります。 「複合型」の文は、サブステートメントとして「抽象的」声明が含まれていない場合、デフォルトは「false」です。 「抽象」の文は、任意のサブステートメントをサポートしていません。
An "instance" node is encoded as an XML element, where an "instance-list" node is encoded as a series of XML elements. The corresponding XML element names are the "instance" and "instance-list" identifiers, respectively, and they use the same XML namespace as the module.
「インスタンス」ノードは、「インスタンスのリスト」のノードをXML要素の系列として符号化されたXML要素として符号化されます。対応するXML要素名は、それぞれ、「インスタンス」と「インスタンス・リスト」の識別子であり、それらはモジュールと同じXML名前空間を使用します。
Instance child nodes are encoded as subelements of the instance XML element. Subelements representing child nodes defined in the same complex type may appear in any order. However, child nodes of an extending complex type follow the child nodes of the extended complex type. As such, the XML encoding of lists is similar to the encoding of containers and lists in YANG.
インスタンスの子ノードは、インスタンスのXML要素のサブ要素としてエンコードされています。同じ複合型で定義された子ノードを表すサブ要素は、任意の順序で表示されることがあります。しかしながら、延在する複合型の子ノードは、拡張複合型の子ノードをたどります。このように、リストのXMLエンコードはYANGにおけるコンテナやリストの符号化と同様です。
Instance key nodes are encoded as subelements of the instance XML element. Instance key nodes must appear in the same order as they are defined within the "key" statement of the corresponding complex type definition and precede all other nodes defined in the same complex type. That is, if key nodes are defined in an extending complex type, XML elements representing key data precede all other XML elements representing child nodes. On the other hand, XML elements representing key data follow the XML elements representing data nodes of the base type.
インスタンスキーノードは、インスタンスXML要素のサブ要素として符号化されます。インスタンスキーのノードは、それらが対応する複合型定義の「キー」ステートメント内で定義されているのと同じ順序で表示され、同じ複合型で定義されている他のすべてのノードを先行しなければなりません。キーノードが延びる複合型で定義されている場合には、あるキーデータを表すXML要素は、子ノードを表し、他のすべてのXML要素に先行します。一方、鍵データを表すXML要素は、基本タイプのデータノードを表すXML要素をたどります。
The type of the actual complex type instance is encoded in a type element, which is put in front of all instance child elements, including key nodes, as described in Section 2.8 ("Type Encoding Rules").
セクション2.8（「タイプ符号化規則」）に記載されているように、実際の複合型のインスタンスのタイプは、キーノードを含むすべてのインスタンスの子要素の前に置かれた型要素に符号化されます。
The proposed XML encoding rules conform to the YANG XML encoding rules in [RFC6020]. Compared to YANG, enabling key definitions in derived hierarchies is a new feature introduced with the complex types extension. As a new language feature, complex types also introduce a new payload entry for the instance type identifier.
提案されたXML符号化規則は、[RFC6020]にYANG XML符号化規則に準拠します。 YANGと比較すると、派生階層にキー定義を有効にすると、複合型の拡張で導入された新機能です。新しい言語機能としては、複雑なタイプは、インスタンスタイプ識別子のための新しいペイロードエントリを紹介します。
Based on our implementation experience, the proposed XML encoding rules support consistent mapping of YANG models with complex types to an XML schema using XML complex types.
私たちの実装経験に基づいて、提案されているXMLの符号化規則は、XML複合型を使用してXMLスキーマに複合型を持つYANGモデルの一貫したマッピングをサポートしています。
In order to encode the type of an instance in the NETCONF payload, XML elements named "type" belonging to the XML namespace "urn:ietf:params:xml:ns:yang:ietf-complex-type-instance" are added to the serialized form of instance and instance-list nodes in the payload. The suggested namespace prefix is "cti". The "cti:type" XML elements are inserted before the serialized form of all members that have been declared in the corresponding complex type definition.
に追加される「IETF-複合型インスタンス：IETF：paramsは：XML：NS：陽URN」NETCONFペイロード内のインスタンスのタイプを符号化するために、XML要素は、XML名前空間に属している「タイプ」と命名しますペイロード内のインスタンスとインスタンスリストノードの直列化された形式。提案された名前空間接頭辞は、「CTI」です。 「CTI：タイプ」XML要素は、対応する複合型定義の中で宣言されているすべてのメンバーの直列化形式の前に挿入されています。
The "cti:type" element is inserted for each type in the extension chain to the actual type of the instance (most specific last). Each type name includes its corresponding namespace.
「CTI：タイプ」エレメントは、（最後の最も特定）インスタンスの実際のタイプに拡張チェーンの種類ごとに挿入されています。各タイプの名前は、その対応する名前空間を含んでいます。
The type of a complex type instance MUST be encoded in the reply to NETCONF <get> and <get-config> operations, and in the payload of a NETCONF <edit-config> operation if the operation is "create" or "replace". The type of the instance MUST also be specified in case <copy-config> is used to export a configuration to a resource addressed with an URI. The type of the instance has to be specified in user-defined remote procedure calls (RPCs).
操作は、「作成」または「置き換え」であれば、複合型インスタンスのタイプは、NETCONF <GET>と<GET-config>の操作への応答であり、NETCONF <編集-config>の操作のペイロードに符号化されなければなりません。また、ケース<コピー設定>で指定する必要があり、インスタンスのタイプは、URIでアドレス指定されたリソースに設定をエクスポートするために使用されます。インスタンスのタイプは、ユーザー定義のリモート・プロシージャ・コール（RPC）で指定されなければなりません。
The type of the instance MAY be specified in case the operation is "merge" (either because this is explicitly specified or no operation attribute is provided).
インスタンスのタイプは操作が「マージ」である場合に指定することができる（いずれかこれを明示的に指定されるか、または何も操作属性が提供されていないため）。
In case the node already exists in the target configuration and the type attribute (type of a complex type instance) is specified but differs from the data in the target, an <rpc-error> element is returned with an <error-app-tag> value of "wrong-complex-type". In case no such element is present in the target configuration but the type attribute is missing in the configuration data, an <rpc-error> element is returned with an <error-tag> value of "missing-attribute".
ケースでは、ノードが既に指定されている目標設定および（複合型のインスタンスのタイプ）タイプ属性に存在するが、対象のデータとは異なる、<RPCエラー>要素は、<エラーアプリタグで返されます>「間違った複合型」の値。場合にそのような要素は、ターゲット構成に存在しないが、type属性は、構成データに欠落している、<RPCエラー>要素は、「欠落属性」の<エラータグ>値が返されます。
The type MUST NOT be specified in case the operation is "delete".
タイプは、操作が「削除」である場合に指定することはできません。
The module below contains all YANG extension definitions for complex types and typed instance identifiers. In addition, a "complex-type" feature is defined, which may be used to provide conditional or alternative modeling, depending on the support status of complex types in a NETCONF server. A NETCONF server that supports the modeling features for complex types and the XML encoding for complex types as defined in this document MUST advertise this as a feature. This is done by including the feature name "complex-types" in the feature parameter list as part of the NETCONF <hello> message as described in Section 5.6.4 in [RFC6020].
モジュールは、以下の複合型および型指定されたインスタンス識別子のためのすべてのYANG拡張定義が含まれています。加えて、「複合型」特徴は、NETCONFサーバにおける複合型のサポート状況に応じて、条件付または代替モデルを提供するために使用することができる、定義されています。この文書で定義されている複合型と複合型のXMLエンコーディングのためのモデリング機能をサポートしているNETCONFサーバが機能としてこれを宣伝しなければなりません。これは[RFC6020]セクション5.6.4に記載したようにNETCONF <ハロー>メッセージの一部として機能パラメータリストに機能名「複合型」を含むことによって行われます。
<CODE BEGINS> file "ietf-complex-types@2011-03-15.yang"
ファイル "ietf-complex-types@2011-03-15.yang" <CODEが開始されます>
module ietf-complex-types {
モジュールIETF-複素タイプ{
namespace "urn:ietf:params:xml:ns:yang:ietf-complex-types";
prefix "ct";
organization
会社
"NETMOD WG";
"NETMOD WG"。
contact "Editor: Bernd Linowski <bernd.linowski.ext@nsn.com> Editor: Mehmet Ersue <mehmet.ersue@nsn.com> Editor: Siarhei Kuryla <s.kuryla@gmail.com>";
連絡先 "エディタ：ベルントLinowski <bernd.linowski.ext@nsn.com>エディタ：メフメットErsue <mehmet.ersue@nsn.com>エディタ：Siarhei Kuryla <s.kuryla@gmail.com>";
description "YANG extensions for complex types and typed instance identifiers.
説明「複合型および型指定されたインスタンス識別子のYANG拡張。
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2011 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).
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 6095; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 6095の一部です。完全な適法な通知についてはRFC自体を参照してください。 ";
revision 2011-03-15 { description "Initial revision."; }
リビジョン2011-03-15 {説明「初期リビジョン。」; }
extension complex-type {
description "Defines a complex-type.";
reference "Section 2.2, complex-type Extension Statement";
argument type-identifier {
yin-element true;
}
}
extension extends {
description "Defines the base type of a complex-type.";
reference "Section 2.5, extends Extension Statement";
argument base-type-identifier {
yin-element true;
}
} extension abstract {
description "Makes the complex-type abstract.";
reference "Section 2.6, abstract Extension Statement";
argument status;
}
extension instance {
description "Declares an instance of the given
complex type.";
reference "Section 2.3, instance Extension Statement";
argument ct-instance-identifier {
yin-element true;
}
}
extension instance-list {
description "Declares a list of instances of the given
complex type";
reference "Section 2.4, instance-list Extension Statement";
argument ct-instance-identifier {
yin-element true;
}
}
extension instance-type {
description "Tells to which type instance the instance
identifier refers.";
reference "Section 3.2, instance-type Extension Statement";
argument target-type-identifier {
yin-element true;
}
}
feature complex-types { description "Indicates that the server supports complex types and instance identifiers."; }
機能の複合タイプ{記述は、「サーバは複合型とインスタンス識別子をサポートしていることを示しています。」; }
}
｝
<CODE ENDS>
<CODEはENDS>
The example model below shows how complex types can be used to represent physical equipment in a vendor-independent, abstract way. It reuses the complex types defined in the physical resource model in Section 1.5.1.
以下の例のモデルは、ベンダに依存しない、抽象的な方法で物理的装置を表すために使用することができる方法を複合型示します。これは、セクション1.5.1における物理リソースモデルで定義された複合型を再利用します。
<CODE BEGINS>
<CODEが開始されます>
module hw {
率は{
namespace "http://example.com/hw";
prefix "hw";
import ietf-complex-types {prefix "ct"; } import udmcore {prefix "uc"; }
輸入IETF-複合タイプ{接頭辞「CT」。 }インポートudmcore {接頭辞 "UC"。 }
// Holder types
//ホルダータイプ
ct:complex-type Slot { ct:extends uc:EquipmentHolder; leaf slotNumber { type uint16; config false; } // ... }
CT：複合型スロット{CT：UCを拡張：機器ホルダー。リーフスロット番号{uint16のタイプ。設定はfalse; } // ...}
ct:complex-type Chassis { ct:extends uc:EquipmentHolder; leaf numberOfChassisSlots { type uint32; config false; } // .. }
CT：複合型シャーシ{CT：UCを拡張：機器ホルダー。リーフnumberOfChassisSlots {型UINT32。設定はfalse; } // ..}
// Equipment types
//機器の種類
ct:complex-type Card { ct:extends uc:Equipment; leaf position { type uint32; mandatory true; } leaf slotsRequired {type unit32; } }
CT：複合型カード{CT：UC延び：機器と、リーフ位置{タイプUINT32。真必須。 }葉slotsRequired {タイプunit32。 }}
// Root Element ct:instance hardware { type uc:ManagedHardware; }
//ルート要素CT：インスタンスのハードウェア{型UC：ManagedHardware。 }
} // hw module
} //率であります
<CODE ENDS>
<CODEはENDS>
Following example shows the payload of a reply to a NETCONF <get> command. The actual type of managed hardware instances is indicated with the "cti:type" elements as required by the type encoding rules. The containment hierarchy in the NETCONF XML payload reflects the containment hierarchy of hardware instances. This makes filtering based on the containment hierarchy possible without having to deal with values of leafs of type leafref that represent the tree structure in a flattened hierarchy.
例に続いて、NETCONF <GET>コマンドへの応答のペイロードを示しています。型の符号化規則によって必要とされる要素：管理ハードウェア・インスタンスの実際の型は、「タイプのCTI」と示されています。 NETCONFのXMLペイロード内の包含階層は、ハードウェアのインスタンスの包含階層を反映しています。これは、平坦化階層のツリー構造を表す型leafrefの葉の値に対処することなく、可能な包含階層に基づいてフィルタリングを行います。
<hardware> <cti:type>uc:BasicObject</cti:type> <distinguishedName>/R-T31/CH-2</distinguishedName> <globalId>6278279001</globalId> <cti:type>uc:Resource</cti:type> <cti:type>uc:PhysicalResource</cti:type> <otherIdentifier>Rack R322-1</otherIdentifier> <serialNumber>R-US-3276279a</serialNumber> <cti:type>uc:Hardware</cti:type> <cti:type>uc:ManagedHardware</cti:type> <cti:type>hw:EquipmentHolder</cti:type> <equipmentHolder> <cti:type>uc:BasicObject</cti:type> <distinguishedName>/R-T31/CH-2/SL-1</distinguishedName> <globalId>548872003</globalId> <cti:type>uc:Resource</cti:type> <cti:type>uc:PhysicalResource</cti:type> <otherIdentifier>CU-Slot</otherIdentifier> <serialNumber>T-K4733890x45</serialNumber> <cti:type>uc:Hardware</cti:type> <cti:type>uc:ManagedHardware</cti:type> <cti:type>uc:EquipmentHolder</cti:type> <equipment> <cti:type>uc:BasicObject</cti:type> <distinguishedName>/R-T31/CH-2/SL-1/C-3</distinguishedName> <globalId>89772001</globalId> <cti:type>uc:Resource</cti:type> <cti:type>uc:PhysicalResource</cti:type> <otherIdentifier>ATM-45252</otherIdentifier> <serialNumber>A-778911-b</serialNumber> <cti:type>uc:Hardware</cti:type> <cti:type>uc:ManagedHardware</cti:type> <cti:type>uc:Equipment</cti:type> <installed>true</installed> <version>A2</version> <redundancy>1</redundancy> <cti:type>hw:Card</cti:type>
<ハードウェア> <CTI：タイプ> UC：BasicObject </ CTI：タイプ> <distinguishedNameの> / R-T31 / CH-2 </ distinguishedNameの> <globalId> 6278279001 </ globalId> <CTI：タイプ> UC：リソース</ CTI：タイプ> <CTI：タイプ> UC：PhysicalResource </ CTI：タイプ> <otherIdentifier>ラックR322-1 </ otherIdentifier> <serialNumberを> R-US-3276279a </ serialNumberを> <CTI：タイプ> UC：ハードウェア< / CTI：タイプ> <CTI：タイプ> UC：ManagedHardware </ CTI：タイプ> <CTI：タイプ> HW：機器ホルダー</ CTI：タイプ> <機器ホルダー> <CTI：タイプ> UC：BasicObject </ CTI：タイプ> <distinguishedNameの> / R-T31 / CH-2 / SL-1 </ distinguishedNameの> <globalId> 548872003 </ globalId> <CTI：タイプ> UC：リソース</ CTI：タイプ> <CTI：タイプ> UC：PhysicalResource < / CTI：タイプ> <otherIdentifier> CUスロット</ otherIdentifier> <serialNumberを> T-K4733890x45 </ serialNumberを> <CTI：タイプ> UC：ハードウェア</ CTI：タイプ> <CTI：タイプ> UC：ManagedHardware </ CTI ：タイプ> <CTI：タイプ> UC：機器ホルダー</ CTI：タイプ> <装置> <CTI：タイプ> UC：BasicObject </ CTI：タイプ> <distinguishedNameの> / R-T31 / CH-2 / SL-1 / C-3 </ distinguishedNameの> <globalId> 89772001 </ globalId> <CTI：タイプ> UC：リソース</ CTI：タイプ> <CTI：TYP E> UC：PhysicalResource </ CTI：タイプ> <otherIdentifier> ATM-45252 </ otherIdentifier> <serialNumberを> A-778911-B </ serialNumberを> <CTI：タイプ> UC：ハードウェア</ CTI：タイプ> <CTI：タイプ> UC：ManagedHardware </ CTI：タイプ> <CTI：タイプ> UC：機器</ CTI：タイプ> <インストール>真</インストール> <バージョン> A2 </バージョン> <冗長性> 1 </冗長性> < CTI：タイプ> HW：カード</ CTI：タイプ>
<usedSlots>1</usedSlots> </equipment> <cti:type>hw:Slot</cti:type> <slotNumber>1</slotNumber> </equipmentHolder> <cti:type>hw:Chassis</cti:type> <numberOfChassisSlots>6</numberOfChassisSlots> // ... </hardware>
<usedSlots> 1 </ usedSlots> </設備> <CTI：タイプ> HW：スロット</ CTI：タイプ> <スロット番号> 1 </スロット番号> </機器ホルダー> <CTI：タイプ> HW：シャーシ</ CTI：タイプ> <numberOfChassisSlots> 6 </ numberOfChassisSlots> // ... </ハードウェア>
In addition to the module update rules specified in Section 10 in [RFC6020], modules that define complex types, instances of complex types, and typed instance identifiers must obey following rules:
[RFC6020]に、セクション10で指定されたモジュールの更新ルール、複合型を定義するモジュール、複合型のインスタンスに加えて、インスタンス識別子を入力した以下の規則に従わなければなりません。
o New complex types MAY be added.
O新しい複合型を追加してもよいです。
o A new complex type MAY extend an existing complex type.
O新しい複合型は、既存の複合型を延長することができます。
o New data definition statements MAY be added to a complex type only if:
O新しいデータ定義文は、場合にのみ、複合型に追加されることがあります。
* they are not mandatory or
*彼らは必須ではありませんか
* they are not conditionally dependent on a new feature (i.e., they do not have an "if-feature" statement that refers to a new feature).
*彼らは、新しい機能（すなわち、彼らは新しい機能を指し、「IF-機能」の文を持っていない）に条件付きで依存していません。
o The type referred to by the instance-type statement may be changed to a type that derives from the original type only if the original type does not represent configuration data.
Oインスタンス型ステートメントで参照されるタイプは、元の型は、構成データを表していない場合にのみ、元の型から派生型に変更してもよいです。
All data nodes defined inside a complex type reside in the complex type namespace, which is their parent node namespace.
複合型の内部で定義されているすべてのデータノードは、親ノードの名前空間である複合型の名前空間内に存在します。
It is not allowed to override a data node inherited from a base type. That is, it is an error if a type "base" with a leaf named "foo" is extended by another complex type ("derived") with a leaf named "foo" in the same module. In case they are derived in different modules, there are two distinct "foo" nodes that are mapped to the XML namespaces of the module, where the complex types are specified.
基本型から継承されたデータノードを上書きすることはできません。つまり、それは同じモジュール内に「foo」という名前のリーフと「FOO」という名前の葉を有するタイプ「塩基」とは、別の複合タイプ（「派生」）によって拡張された場合は、エラーです。それらは異なるモジュールに誘導される場合に、複雑な型が指定されているモジュールのXML名前空間にマッピングされる2つの別個の「FOO」ノードが存在します。
A complex type that extends a basic complex type may use the "refine" statement in order to improve an inherited data node. The target node identifier must be qualified by the module prefix to indicate clearly which inherited node is refined.
基本的な複合型のために、「絞り込み」ステートメントを使用することが延びている複合型が継承されたデータノードを向上させることができます。ターゲットノード識別子は、ノードが洗練されて継承されはっきり示すために、モジュールのプレフィックスで修飾されなければなりません。
The following refinements can be done:
以下の改良を行うことができます。
o A leaf or choice node may have a default value, or a new default value if it already had one.
それは既に1を持っていた場合、O葉または選択ノードには、デフォルト値、または新しいデフォルト値を有することができます。
o Any node may have a different "description" or "reference" string.
O任意のノードは、異なる「記述」または「参照」の文字列を有していてもよいです。
o A leaf, anyxml, or choice node may have a "mandatory true" statement. However, it is not allowed to change from "mandatory true" to "mandatory false".
O葉、AnyXMLで、または選択ノードは「必須真」の文を有することができます。しかし、「必須偽」に「必須真」から変更することはできません。
o A leaf, leaf-list, list, container, or anyxml node may have additional "must" expressions.
O葉、葉、リスト、リスト、コンテナ、またはAnyXMLでノードが追加の「必要」の表現を有することができます。
o A list, leaf-list, instance, or instance-list node may have a "min-elements" statement, if the base type does not have one or does not have one with a value that is greater than the minimum value of the base type.
リストO、リーフリスト、インスタンス、または塩基の種類が1つを持っていないか、の最小値よりも大きい値を有するものを持っていない場合、インスタンス・リスト・ノードは、「MIN-要素」ステートメントを有していてもよいです基本型。
o A list, leaf-list, instance, or instance-list node may have a "max-elements" statement, if the base type does not have one or does not have one with a value that is smaller than the maximum value of the base type.
リストO、リーフリスト、インスタンス、または塩基の種類が1つを持っていないか、の最大値よりも小さい値を持つものを持っていない場合、インスタンス・リスト・ノードは、「MAX-要素」ステートメントを有していてもよいです基本型。
It is not allowed to refine complex-type nodes inside "instance" or "instance-list" statements.
「インスタンス」または「インスタンス・リスト」の文の内側に複合型ノードを洗練するために許可されていません。
Augmenting complex types is only allowed if a complex type is instantiated in an "instance" or "instance-list" statement. This confines the effect of the augmentation to the location in the schema tree where the augmentation is done. The argument of the "augment" statement MUST be in the descendant form (as defined by the rule "descendant-schema-nodeid" in Section 12 in [RFC6020]).
複合型は、「インスタンス」または「インスタンス・リスト」の文でインスタンス化されている場合の複合型の拡張にのみ許可されます。これは、増強が行われたスキーマ・ツリー内の場所への増強の効果を閉じ込めます。 「増強」ステートメントの引数は子孫形態でなければならない（セクション12内のルール「子孫-スキーマNODEID」によって定義されるように[RFC6020]）。
ct:complex-type Chassis {
ct:extends EquipmentHolder;
container chassisInfo {
config false;
leaf numberOfSlots { type uint16; }
leaf occupiedSlots { type uint16; }
leaf height {type unit16;}
leaf width {type unit16;}
}
}
ct:instance-list chassis { type Chassis; augment "chassisInfo" { leaf modelId { type string; } } }
CT：インスタンスリストシャーシ{タイプシャーシ。 "chassisInfo" {葉modelId {string型を拡張します。 }}}
When augmenting a complex type, only the "container", "leaf", "list", "leaf-list", "choice", "instance", "instance-list", and "if-feature" statements may be used within the "augment" statement. The nodes added by the augmentation MUST NOT be mandatory nodes. One or many "augment" statements may not cause the creation of multiple nodes with the same name from the same namespace in the target node.
複合型、唯一の「コンテナ」、「葉」、「リスト」、「リーフリスト」、「選択」、「インスタンス」、「インスタンス・リスト」、および「IF-機能」ステートメントを使用してもよいが増大すると「増やす」ステートメント内。増強によって追加されたノードは、必須のノードにすることはできません。一つまたは多くの「オーグメント」の文は、ターゲット・ノードで同じ名前空間と同じ名前を持つ複数のノードの作成を起こさないことがあります。
To achieve less-complex modeling, this document proposes the augmentation of complex type instances without recursion.
あまり複雑なモデリングを実現するために、この文書は再帰なしで複合型のインスタンスの増強を提案しています。
A server might not want to support all complex types defined in a supported module. This issue can be addressed with YANG features as follows:
サーバーは、サポートされているモジュールで定義されたすべての複合型をサポートしたくない場合があります。この問題は、YANGで対処することができ、以下のように特徴：
o Features are defined that are used inside complex type definitions (by using "if-feature" as a substatement) to make them optional. In this case, such complex types may only be instantiated if the feature is supported (advertised as a capability in the NETCONF <hello> message).
O機能は、それらをオプションにする（サブステートメントとして「IF-機能」を使って）複合型定義の内部で使用される定義されています。機能がサポートされている場合は、この場合には、そのような複合型のみ（NETCONF <ハロー>メッセージの機能としてアドバタイズ）インスタンス化されてもよいです。
o The "deviation" statement may be applied to node trees, which are created by "instance" and "instance-list" statements. In this case, only the substatement "deviate not-supported" is allowed.
O「ずれ」文は「インスタンス」および「インスタンス・リスト」文によって作成されたノードツリーにも適用することができます。この場合、唯一のサブステートメントは、「-サポートされていません逸脱」許可されています。
o It is not allowed to apply the "deviation" statement to node tree elements that may occur because of the recursive use of a complex type. Other forms of deviations ("deviate add", "deviate replace", "deviate delete") are NOT supported inside node trees spanned by "instance" or "instance-list".
Oなぜなら複合タイプの再帰的使用のため、発生することがあり、ツリーの要素をノードに「ずれ」ステートメントを適用することは許されません。偏差の他の形態は、（「削除逸脱」、「置き換え逸脱」、「追加逸脱」）「インスタンス」または「インスタンス・リスト」が及ぶノードツリー内でサポートされていません。
As complex type definitions do not contribute by themselves to the data node tree, data node declarations inside complex types cannot be the target of deviations.
複合型の定義は、データノードツリーに自分自身で貢献していないとして、複合型内のデータノードの宣言は、偏差のターゲットにすることはできません。
In the example below, client applications are informed that the leaf "occupiedSlots" is not supported in the top-level chassis. However, if a chassis contains another chassis, the contained chassis may support the leaf that reports the number of occupied slots.
以下の例では、クライアント・アプリケーションは、リーフ「occupiedSlotsは」トップレベルのシャーシでサポートされていないことが通知されます。シャーシは別のシャーシが含まれている場合は、含まれているシャーシは、占有スロット数を報告した葉をサポートすることができます。
deviation "/chassis/chassisSpec/occupiedSlots" { deviate not-supported; }
偏差「/シャーシ/ chassisSpec / occupiedSlots」{サポートしない逸脱。 }
Typed instance identifier relationships are an addition to the relationship types already defined in YANG, where the leafref relationship is location dependent, and the instance-identifier does not specify to which type of instances the identifier points.
型指定されたインスタンス識別子の関係が既にleafref関係は位置依存性であるYANG、で定義された関係タイプに加えており、インスタンス識別子は、インスタンスのどのタイプ識別子ポイントに指定されていません。
A typed instance identifier represents a reference to an instance of a complex type without being restricted to a particular location in the containment tree. This is done by using the extension statement "instance-type" as a substatement of the existing "type instance identifier" statement.
型付けされたインスタンス識別子は、包含ツリー内の特定の場所に制限されることなく複合型のインスタンスへの参照を表します。これは、既存の「タイプのインスタンス識別子」文のサブステートメントとして延長文の「インスタンスタイプ」を使用して行われます。
Typed instance identifiers allow referring to instances of complex types that may be located anywhere in the schema tree. The "type" statement plays the role of a restriction that must be fulfilled by the target node, which is referred to with the instance identifier. The target node MUST be of a particular complex type, either the type itself or any type that extends this complex type.
型付けされたインスタンス識別子は、スキーマ・ツリー内のどこにでも配置することができる複合型のインスタンスを参照することを可能にします。 「タイプ」の文は、インスタンス識別子と呼ばれ、ターゲットノードによって満たされなければならない制限の役割を果たしています。ターゲットノードは、型自体又はこの複合型を拡張する任意のタイプのいずれかで、特定の複合型でなければなりません。
The "instance-type" extension statement specifies the complex type of the instance to which the instance-identifier refers. The referred instance may also instantiate any complex type that extends the specified complex type.
「インスタンス型」拡張文は、インスタンス識別子が参照するインスタンスの複合型を指定します。いうインスタンスはまた、指定された複合型を拡張し、任意の複合型をインスタンス化することができます。
The instance complex type is identified by the single name argument. The referred complex type MUST have a key. This extension statement MUST be used as a substatement of the "type instance-identifier" statement. The "instance-type" extension statement does not support any substatements.
インスタンスの複合型は、単一の名前引数によって識別されます。呼ば複合型はキーを持たなければなりません。この拡張文は、「インスタンス識別子を入力し、」文のサブステートメントとして使用しなければなりません。 「インスタンスタイプ」の拡張文は任意のサブステートメントをサポートしていません。
In the example below, a physical link connects an arbitrary number of physical ports. Here, typed instance identifiers are used to denote which "PhysicalPort" instances (anywhere in the data tree) are connected by a "PhysicalLink".
以下の例では、物理リンクは、物理ポートの任意の数とを接続します。ここで、インスタンス識別子が「PhysicalLink」によって接続されている「PhysicalPort」インスタンス（データツリー内のどこか）を示すために使用される型付き。
// Extended version of type Card
ct:complex-type Card {
ct:extends Equipment;
leaf usedSlot { type uint16; mandatory true; }
ct:instance-list port {
type PhysicalPort;
}
}
ct:complex-type PhysicalPort { ct:extends ManagedHardware; leaf portNumber { type int32; mandatory true; } }
CT：複合型PhysicalPort {CT：ManagedHardwareを拡張します。葉のportNumber {型INT32。真必須。 }}
ct:complex-type PhysicalLink {
ct:extends ManagedHardware;
leaf media { type string; }
leaf-list connectedPort {
type instance-identifier {
ct:instance-type PhysicalPort;
}
min-elements 2;
}
}
Below is the XML encoding of an element named "link" of type "PhysicalLink":
以下は、タイプ「PhysicalLink」の「リンク」という名前の要素のXMLエンコーディングは以下のとおりです。
<link>
<objectId>FTCL-771</objectId>
<media>Fiber</media>
<connectedPort>/hw:hardware[objectId='R-11']
/hw:equipment[objectId='AT22']/hw:port[objectId='P12']
</connectedPort>
<connectedPort>/hw:hardware[objectId='R-42]
/hw:equipment[objectId='AT30']/hw:port[objectId='P3']
</connectedPort>
<serialNumber>F-7786828</serialNumber>
<commonName>FibCon 7</commonName>
</link>
This document registers two URIs in the IETF XML registry. IANA registered the following URIs, according to [RFC3688]:
この文書は、IETF XMLレジストリ内の2つのURIを登録します。 IANAは、[RFC3688]によれば、以下のURIを登録しました：
URI: urn:ietf:params:xml:ns:yang:ietf-complex-types URI: urn:ietf:params:xml:ns:yang:ietf-complex-type-instance
URI：URN：IETF：paramsは：XML：NS：陽：IETF-複素タイプURI：URN：IETF：paramsは：XML：NS：陽：IETF-複合型のインスタンス
Registrant Contact: Bernd Linowski (bernd.linowski.ext@nsn.com) Mehmet Ersue (mehmet.ersue@nsn.com) Siarhei Kuryla (s.kuryla@gmail.com)
登録者連絡先：ベルントLinowski（bernd.linowski.ext@nsn.com）メフメトErsue（mehmet.ersue@nsn.com）Siarhei Kuryla（s.kuryla@gmail.com）
XML: N/A, the requested URIs are XML namespaces.
XML：N / A、要求されたURIは、XML名前空間です。
This document registers one module name in the "YANG Module Names" registry, defined in [RFC6020]. name: ietf-complex-types
この文書では、[RFC6020]で定義され、「YANGモジュール名」レジストリに1人のモジュール名を登録します。名前：IETF-複合タイプ
namespace: urn:ietf:params:xml:ns:yang:ietf-complex-types
名前空間：URN：IETF：のparams：XML：NS：ヤン：IETF-複合タイプ
prefix: ct
接頭辞：CT
RFC: 6095
RFC：6095
The YANG module "complex-types" in this memo defines YANG extensions for complex types and typed instance identifiers as new language statements.
このメモでYANGモジュール「複雑型は」複雑な型のためYANG拡張を定義し、新しい言語文としてインスタンス識別子を入力しました。
Complex types and typed instance identifiers themselves do not have any security impact on the Internet.
複合型と型指定されたインスタンス識別子自体は、インターネット上の任意のセキュリティへの影響はありません。
The security considerations described throughout [RFC6020] apply here as well.
[RFC6020]を通じて説明したセキュリティ上の考慮事項はここにも適用されます。
The authors would like to thank to Martin Bjorklund, Balazs Lengyel, Gerhard Muenz, Dan Romascanu, Juergen Schoenwaelder, and Martin Storch for their valuable review and comments on different versions of the document.
作者は彼らの貴重なレビューと文書の異なるバージョンへのコメントのためにマーティンBjorklund、バラージュLengyel、ゲルハルトMuenz、ダンRomascanu、ユルゲンSchoenwaelder、そしてマーティン・シュトルヒに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、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月。
[IPFIXCONF] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for IPFIX and PSAMP", Work in Progress, March 2011.
[IPFIXCONF] Muenz、G.、Claise、B.、およびP.エイトケン、 "IPFIXとPSAMPの設定データモデル"、進歩、2011年3月に作業。
[Libsmi] Kuryla, S., "Libsmi Extension for Complex Types", April 2010, <http://www.ibr.cs.tu-bs.de/svn/libsmi>.
[Libsmi] Kuryla、S.、 "複合型のためLibsmi拡張"、2010年4月、<http://www.ibr.cs.tu-bs.de/svn/libsmi>。
[Pyang] Bjorklund, M., "An extensible YANG validator and converter in python", October 2010, <http://code.google.com/p/pyang/>.
【Pyang] Bjorklund、M.、 "Pythonで拡張可能YANGバリデータとコンバータ"、2010年10月、<http://code.google.com/p/pyang/>。
[Pyang-ct] Kuryla, S., "Complex type extension for an extensible YANG validator and converter in python", April 2010, <http://code.google.com/p/pyang-ct/>.
[Pyang-CT] Kuryla、S.、 "Pythonで拡張可能YANGバリデータとコンバータの複合型エクステンション" 2010年4月、<http://code.google.com/p/pyang-ct/>。
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC4133] Bierman、A.およびK. McCloghrie、 "エンティティMIB（バージョン3）"、RFC 4133、2005年8月。
[SID_V8] TeleManagement Forum, "GB922, Information Framework (SID) Solution Suite, Release 8.0", July 2008, <http:// www.tmforum.org/DocumentsInformation/ GB922InformationFramework/35499/article.html>.
[SID_V8]テレマネージメントフォーラムは、 "GB922、情報フレームワーク（SID）ソリューションスイートは、リリース8.0"、2008年7月、<のhttp：// www.tmforum.org/DocumentsInformation/ GB922InformationFramework / 35499 / article.html>。
[UDM] NSN, "Unified Data Model SID Compliance Statement", May 2010, <http://www.tmforum.org/InformationFramework/ NokiaSiemensNetworks/8815/home.html>.
[UDM] NSN、 "ユニファイドデータモデルSID適合宣言"、2010年5月、<http://www.tmforum.org/InformationFramework/ NokiaSiemensNetworks / 8815 / home.html>。
Appendix A. YANG Modules for Physical Network Resource Model and Hardware Entities Model
物理ネットワークリソース・モデル付録A. YANGモジュールとハードウェアエンティティモデル
YANG module for the 'Physical Network Resource Model':
「物理ネットワークリソース・モデル」のYANGモジュール：
<CODE BEGINS>
<CODEが開始されます>
module udmcore {
モジュールudmcore {
namespace "http://example.com/udmcore";
prefix "udm";
import ietf-yang-types {prefix "yang";} import ietf-complex-types {prefix "ct";}
インポートIETF-ヤン・タイプ{接頭辞 "陽";}インポートIETF-複素タイプ{接頭辞 "CT";}
ct:complex-type BasicObject {
ct:abstract true;
key "distinguishedName";
leaf globalId {type int64;}
leaf distinguishedName {type string; mandatory true;}
}
ct:complex-type ManagedObject {
ct:extends BasicObject;
ct:abstract true;
leaf instance {type string;}
leaf objectState {type int32;}
leaf release {type string;}
}
ct:complex-type Resource {
ct:extends ManagedObject;
ct:abstract true;
leaf usageState {type int16;}
leaf managementMethodSupported {type string;}
leaf managementMethodCurrent {type string;}
leaf managementInfo {type string;}
leaf managementDomain {type string;}
leaf version {type string;}
leaf entityIdentification {type string;}
leaf description {type string;}
leaf rootEntityType {type string;}
} ct:complex-type LogicalResource {
ct:extends Resource;
ct:abstract true;
leaf lrStatus {type int32;}
leaf serviceState {type int32;}
leaf isOperational {type boolean;}
}
ct:complex-type PhysicalResource {
ct:extends Resource;
ct:abstract true;
leaf manufactureDate {type string;}
leaf otherIdentifier {type string;}
leaf powerState {type int32;}
leaf serialNumber {type string;}
leaf versionNumber {type string;}
}
ct:complex-type Hardware {
ct:extends PhysicalResource;
ct:abstract true;
leaf width {type string;}
leaf height {type string;}
leaf depth {type string;}
leaf measurementUnits {type int32;}
leaf weight {type string;}
leaf weightUnits {type int32;}
leaf-list physicalLink {
type instance-identifier {
ct:instance-type PhysicalLink;
}
}
ct:instance-list containedHardware {
ct:instance-type Hardware;
}
ct:instance-list physicalConnector {
ct:instance-type PhysicalConnector;
}
}
ct:complex-type PhysicalLink {
ct:extends PhysicalResource;
leaf isWireless {type boolean;}
leaf currentLength {type string;}
leaf maximumLength {type string;} leaf mediaType {type int32;}
leaf-list hardware {
type instance-identifier {
ct:instance-type Hardware;
}
}
}
ct:complex-type ManagedHardware { ct:extends Hardware; leaf additionalinfo {type string;} leaf physicalAlarmReportingEnabled {type boolean;} leaf pyhsicalAlarmStatus {type int32;} leaf coolingRequirements {type string;} leaf hardwarePurpose {type string;} leaf isPhysicalContainer {type boolean;} }
CT：複合型ManagedHardware {CT：ハードウェアを拡張します。リーフadditionalinfo {string型;}葉physicalAlarmReportingEnabled {boolean型;}葉pyhsicalAlarmStatus {型INT32;}葉coolingRequirements {string型;}葉hardwarePurpose {string型;}葉isPhysicalContainer {boolean型;}}
ct:complex-type AuxiliaryComponent {
ct:extends ManagedHardware;
ct:abstract true;
}
ct:complex-type PhysicalPort { ct:extends ManagedHardware; leaf portNumber {type int32;} leaf duplexMode {type int32;} leaf ifType {type int32;} leaf vendorPortName {type string;} }
CT：複合型PhysicalPort {CT：ManagedHardwareを拡張します。葉のportNumber {型INT32;}葉duplexMode {型INT32;}葉のifType {型INT32;}葉vendorPortName {string型;}}
ct:complex-type PhysicalConnector {
ct:extends Hardware;
leaf location {type string;}
leaf cableType {type int32;}
leaf gender {type int32;}
leaf inUse {type boolean;}
leaf pinDescription {type string;}
leaf typeOfConnector {type int32;}
leaf-list sourcePhysicalConnector {
type instance-identifier {
ct:instance-type PhysicalConnector;
}
} leaf-list targetPhysicalConnector {
type instance-identifier {
ct:instance-type PhysicalConnector;
}
}
}
ct:complex-type Equipment {
ct:extends ManagedHardware;
leaf installStatus {type int32;}
leaf expectedEquipmentType {type string;}
leaf installedEquipmentType {type string;}
leaf installedVersion {type string;}
leaf redundancy {type int32;}
leaf vendorName {type string;}
leaf dateOfLastService {type yang:date-and-time;}
leaf interchangeability {type string;}
leaf identificationCode {type string;}
ct:instance-list equipment {
ct:instance-type Equipment;
}
}
ct:complex-type EquipmentHolder { ct:extends ManagedHardware; leaf vendorName {type string;} leaf locationName {type string;} leaf dateOfLastService {type yang:date-and-time;} leaf partNumber {type string;} leaf availabilityStatus {type int16;} leaf nameFromPlanningSystem {type string;} leaf modelNumber {type string;} leaf acceptableEquipmentList {type string;} leaf isSolitaryHolder {type boolean;} leaf holderStatus {type int16;} leaf interchangeability {type string;} leaf equipmentHolderSpecificType {type string; } leaf position {type string;} leaf atomicCompositeType {type int16;} leaf uniquePhysical {type boolean;} leaf physicalDescription {type string;} leaf serviceApproach {type string;} leaf mountingOptions {type int32;} leaf cableManagementStrategy {type string;} leaf isSecureHolder {type boolean;} ct:instance-list equipment {
CT：複合型機器ホルダー{CT：ManagedHardwareを拡張します。リーフvendorName {string型;}葉のlocationName {string型;}葉dateOfLastService {タイプ陽：日時;}葉partNumberも{string型;}葉availabilityStatus {型INT16;}葉nameFromPlanningSystem {string型;}葉modelNumber {string型;}葉acceptableEquipmentList {string型;}葉isSolitaryHolder {boolean型;}葉holderStatus {型INT16;}葉互換{string型;}葉equipmentHolderSpecificType {型ストリング。 }リーフ位置{string型;}葉atomicCompositeType {型INT16;}葉uniquePhysical {boolean型;}葉physicalDescription {string型;}葉serviceApproach {string型;}葉mountingOptions {型INT32;}葉cableManagementStrategy {string型;}リーフisSecureHolder {boolean型;} CT：インスタンスリスト機器{
ct:instance-type Equipment;
}
ct:instance-list equipmentHolder {
ct:instance-type EquipmentHolder;
}
}
// ... other resource complex types ...
// ...他のリソース複合型...
} <CODE ENDS>
} <CODEを終了します>
YANG module for the 'Hardware Entities Model':
「ハードウェアエンティティモデル」のYANGモジュール：
<CODE BEGINS>
<CODEが開始されます>
module hardware-entities {
モジュールのハードウェアエンティティ{
namespace "http://example.com/:hardware-entities";
prefix "hwe";
import ietf-yang-types {prefix "yang";} import ietf-complex-types {prefix "ct";} import udmcore {prefix "uc";}
インポートIETF-ヤン・タイプ{接頭辞 "陽";}インポートIETF-複素タイプ{接頭辞 "CT";}インポートudmcore {接頭辞 "UC";}
grouping PhysicalEntityProperties { leaf hardwareRev {type string; } leaf firmwareRev {type string; } leaf softwareRev {type string; } leaf serialNum {type string; }
グルーピングPhysicalEntityProperties {葉hardwareRev {文字列型。 }葉firmwareRev {文字列型。 }葉softwareRev {文字列型。 }リーフSERIALNUM {型ストリング。 }
leaf mfgName {type string; } leaf modelName {type string; } leaf alias {type string; } leaf ssetID{type string; } leaf isFRU {type boolean; } leaf mfgDate {type yang:date-and-time; } leaf-list uris {type string; } }
リーフmfgName {文字列型。 }葉MODELNAME {文字列型。 }葉エイリアス{型ストリング。 }葉ssetID {文字列型。 }葉isFRU {boolean型。 }葉mfgDate {タイプ陽：日時。 }リーフリストのURI {型ストリング。 }}
// Physical entities representing equipment
機器を表す//物理的なエンティティ
ct:complex-type Module { ct:extends uc:Equipment; description "Complex type representing module entries
CT：複合型モジュール{CT：UC延び：機器と、説明「モジュールのエントリを表す複合型
(entPhysicalClass = module(9)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type Backplane {
ct:extends uc:Equipment;
description "Complex type representing backplane entries
(entPhysicalClass = backplane(4)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
// Physical entities representing auxiliary hardware components
補助ハードウェアコンポーネントを表す//物理的なエンティティ
ct:complex-type PowerSupply {
ct:extends uc:AuxiliaryComponent;
description "Complex type representing power supply entries
(entPhysicalClass = powerSupply(6)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type Fan {
ct:extends uc:AuxiliaryComponent;
description "Complex type representing fan entries
(entPhysicalClass = fan(7)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type Sensor {
ct:extends uc:AuxiliaryComponent;
description "Complex type representing sensor entries
(entPhysicalClass = sensor(8)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
// Physical entities representing equipment holders
機器ホルダーを表す//物理的なエンティティ
ct:complex-type Chassis {
ct:extends uc:EquipmentHolder;
description "Complex type representing chassis entries
(entPhysicalClass = chassis(3)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type Container { ct:extends uc:EquipmentHolder; description "Complex type representing container entries
CT：複合型容器{CT：UCを拡張：機器ホルダー。説明「コンテナエントリを表す複合型
(entPhysicalClass = container(5)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type Stack {
ct:extends uc:EquipmentHolder;
description "Complex type representing stack entries
(entPhysicalClass = stack(11)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
// Other kinds of physical entities
//物理的実体の他の種類
ct:complex-type Port {
ct:extends uc:PhysicalPort;
description "Complex type representing port entries
(entPhysicalClass = port(10)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
ct:complex-type CPU {
ct:extends uc:Hardware;
description "Complex type representing cpu entries
(entPhysicalClass = cpu(12)) in entPhysicalTable";
uses PhysicalEntityProperties;
}
} <CODE ENDS>
} <CODEを終了します>
Appendix B. Example YANG Module for the IPFIX/PSAMP Model
IPFIX / PSAMPモデル付録B.例YANGモジュール
B.1. Modeling Improvements for the IPFIX/PSAMP Model with Complex Types and Typed Instance Identifiers
B.1。複合型と型付きインスタンス識別子とIPFIX / PSAMPモデルのためのモデリングの改善
The module below is a variation of the IPFIX/PSAMP configuration model, which uses complex types and typed instance identifiers to model the concept outlined in [IPFIXCONF].
以下のモジュールは、複合型を使用し、[IPFIXCONF]に概説さ概念をモデル化するためのインスタンス識別子を入力IPFIX / PSAMP構成モデルの変形です。
When looking at the YANG module with complex types and typed instance identifiers, various technical improvements on the modeling level become apparent.
複合型でYANGモジュールを見て、インスタンス識別子を入力すると、モデリングレベルでの様々な技術的な改善が明らかになる。
o There is almost a one-to-one mapping between the domain concepts introduced in IPFIX and the complex types in the YANG module.
OほとんどYANGモジュールでIPFIXで導入されたドメインの概念と複合型の間に1対1のマッピングがあります。
o All associations between the concepts (besides containment) are represented with typed identifiers. That avoids having to refer to a particular location in the tree. Referring to a particular in the tree is not mandated by the original model.
O（封じ込め以外の）概念間のすべての関連付けが入力された識別子で表現されています。すなわち、ツリー内の特定の場所を参照する必要がなくなり。ツリー内の特定を参照すると、元のモデルによって義務付けられていません。
o It is superfluous to represent concept refinement (class inheritance in the original model) with containment in the form of quite big choice-statements with complex branches. Instead, concept refinement is realized by complex types extending a base complex type.
O複雑な支店を持つ、非常に大きな選択肢-文の形で封じ込めをコンセプトリファイン（オリジナルモデルでは、クラスの継承）を表現するために不必要です。代わりに、コンセプトの改良がベースの複合型を拡張する複合型によって実現されます。
o It is unnecessary to introduce metadata identities and leafs (e.g., "identity cacheMode" and "leaf cacheMode" in "grouping cacheParameters") that just serve the purpose of indicating which concrete subtype of a generic type (modeled as grouping, which contains the union of all features of all subtypes) is actually represented in the MIB.
OメタデータのIDと葉を（例えば、「cacheParametersをグループ化する」の「アイデンティティCACHEMODE」と「葉CACHEMODE」）だけでジェネリック型のどの具体的なサブタイプを示すの目的を果たす（グループとしてモデル化し、含まれて導入する必要はありすべてのサブタイプのすべての機能）の労働組合は、実際にMIBで表されます。
o Ruling out illegal use of subtype-specific properties (e.g., "leaf maxFlows") by using "when" statements that refer to a subtype discriminator is not necessary (e.g., when "../cacheMode != 'immediate'").
Oサブタイプ特異的性質の不正使用を排除（例えば、「葉maxFlows」）「と、」ステートメントのサブタイプ判別器を参照することが必要ではない使用して（例えば、とき「../cacheMode！= 『即時』」）。
o Defining properties like the configuration status wherever a so called "parameter grouping" is used is not necessary. Instead, those definitions can be put inside the complex type definition itself.
使用されている、いわゆる「パラメータグループ」は必要ありませんどこO構成ステータスのようなプロパティを定義します。代わりに、それらの定義は、複合型定義自体の内部に置くことができます。
o Separating the declaration of the key from the related data nodes definitions in a grouping (see use of "grouping selectorParameters") can be avoided.
グルーピングに関連するデータノードの定義からキーの宣言を分離oを回避することができる（「selectorParametersグルーピング」の使用を参照）。
o Complex types may be declared as optional features. If the type is indicated with an identity (e.g., "identity immediate"), this is not possible, since "if-feature" is not allowed as a substatement of "identity".
O複合型は、オプション機能として宣言することができます。型が同一で示されている場合（例えば、「同一即時」）、これは、「IF-機能」「同一性」のサプとして許可されていないので、不可能です。
B.2. IPFIX/PSAMP Model with Complex Types and Typed Instance Identifiers
B.2。複合型とIPFIX / PSAMPモデルと型付きインスタンス識別子
<CODE BEGINS>
module ct-ipfix-psamp-example {
namespace "http://example.com/ns/ct-ipfix-psamp-example";
prefix ipfix;
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; }
import ietf-complex-types {prefix "ct"; } description "Example IPFIX/PSAMP Configuration Data Model
with complex types and typed instance identifiers";
revision 2011-03-15 { description "The YANG Module ('YANG Module of the IPFIX/PSAMP Configuration Data Model') in [IPFIXCONF] modeled with complex types and typed instance identifiers. Disclaimer: This example model illustrates the use of the language extensions defined in this document and does not claim to be an exact reproduction of the original YANG model referred above. The original description texts have been shortened to increase the readability of the model example."; }
リビジョン2011-03-15 {説明「YANGモジュール（ 『IPFIX / PSAMP設定データモデルのYANGモジュール』）[IPFIXCONF]複合型でモデル化し、インスタンス識別子を入力における免責事項：この例のモデルは言語の使用方法を示し拡張この文書で定義され、元のYANGモデルの正確な再現であることを主張しないが、上記呼ばれるオリジナルの説明テキスト、モデル例の可読性を高めるために短縮されています」。。。 }
/*****************************************************************
* Features
*****************************************************************/
feature exporter { description "If supported, the Monitoring Device can be used as an Exporter. Exporting Processes can be configured."; }
特徴輸出{記述が「サポートされている場合、監視装置は輸出として使用することができるプロセスをエクスポートするように構成することができます。」; }
feature collector { description "If supported, the Monitoring Device can be used as a Collector. Collecting Processes can be configured."; }
特徴コレクタ{記述は、「サポートされている場合、監視装置は、集電体として用いることができる収集プロセスが構成されることができます。」; }
feature meter { description "If supported, Observation Points, Selection Processes, and Caches can be configured."; }
機能メーター{説明は「場合は、観測ポイント、選択プロセスをサポートし、キャッシュを設定することができます。」; }
feature psampSampCountBased { description "If supported, the Monitoring Device supports count-based Sampling..."; }
機能psampSampCountBased {説明「サポートされている場合、監視装置はカウントベースのサンプリングをサポートしています...」。 }
feature psampSampTimeBased { description "If supported, the Monitoring Device supports time-based Sampling..."; }
機能psampSampTimeBased {説明「サポートされている場合、監視装置は、時間ベースのサンプリングをサポートしています...」。 }
feature psampSampRandOutOfN {
description "If supported, the Monitoring Device supports
random n-out-of-N Sampling...";
} feature psampSampUniProb {
description "If supported, the Monitoring Device supports
uniform probabilistic Sampling...";
}
feature psampFilterMatch { description "If supported, the Monitoring Device supports property match Filtering..."; }
機能psampFilterMatch {記述は、「サポートされている場合、監視装置は、プロパティの試合のフィルタリングをサポートしています...」。 }
feature psampFilterHash { description "If supported, the Monitoring Device supports hash-based Filtering..."; }
機能psampFilterHash {記述は、「サポートされている場合、監視装置は...ハッシュベースのフィルタリングをサポートしています」。 }
feature cacheModeImmediate { description "If supported, the Monitoring Device supports Cache Mode 'immediate'."; }
機能cacheModeImmediate {記述は、「サポートされている場合、監視装置はキャッシュモード 『即時』をサポートしています。」; }
feature cacheModeTimeout { description "If supported, the Monitoring Device supports Cache Mode 'timeout'."; }
機能cacheModeTimeout {説明は、「サポートされている場合、監視装置は、キャッシュモード 『タイムアウト』をサポート。」; }
feature cacheModeNatural { description "If supported, the Monitoring Device supports Cache Mode 'natural'."; }
「サポートされている場合、監視装置はキャッシュモード 『自然』をサポートしています。」cacheModeNatural {記述を備えています。 }
feature cacheModePermanent { description "If supported, the Monitoring Device supports Cache Mode 'permanent'."; }
機能cacheModePermanent {説明「サポートされている場合、監視装置は、キャッシュモード 『永久』をサポートしています。」; }
feature udpTransport { description "If supported, the Monitoring Device supports UDP as transport protocol."; }
機能udpTransport {説明は、「サポートされている場合、監視装置は、トランスポートプロトコルとしてUDPをサポートしています。」。 }
feature tcpTransport { description "If supported, the Monitoring Device supports TCP as transport protocol."; }
機能tcpTransport {説明「サポートされている場合、監視装置は、トランスポートプロトコルとしてTCPをサポートしています。」; }
feature fileReader { description "If supported, the Monitoring Device supports the configuration of Collecting Processes as File Readers.";
機能FileReaderの{説明は、「サポートされている場合、監視装置は、ファイルリーダーとしてのプロセスを収集の構成をサポートしています。」;
}
｝
feature fileWriter { description "If supported, the Monitoring Device supports the configuration of Exporting Processes as File Writers."; }
フィーチャーてFileWriter {説明は、「サポートされている場合、監視装置は、ファイルの作家としてのプロセスのエクスポートの構成をサポートしています。」; }
/*****************************************************************
* Identities
*****************************************************************/
/*** Hash function identities ***/
identity hashFunction {
description "Base identity for all hash functions...";
}
identity BOB {
base "hashFunction";
description "BOB hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
identity IPSX {
base "hashFunction";
description "IPSX hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
identity CRC {
base "hashFunction";
description "CRC hash function";
reference "RFC 5475, Section 6.2.4.1.";
}
/*** Export mode identities ***/
identity exportMode {
description "Base identity for different usages of export
destinations configured for an Exporting Process...";
}
identity parallel {
base "exportMode";
description "Parallel export of Data Records to all
destinations configured for the Exporting Process.";
}
identity loadBalancing {
base "exportMode";
description "Load-balancing between the different
destinations...";
}
identity fallback {
base "exportMode";
description "Export to the primary destination..."; }
説明「主な目的地へのエクスポート...」。 }
/*** Options type identities ***/
identity optionsType {
description "Base identity for report types exported
with options...";
}
identity meteringStatistics {
base "optionsType";
description "Metering Process Statistics.";
reference "RFC 5101, Section 4.1.";
}
identity meteringReliability {
base "optionsType";
description "Metering Process Reliability Statistics.";
reference "RFC 5101, Section 4.2.";
}
identity exportingReliability {
base "optionsType";
description "Exporting Process Reliability
Statistics.";
reference "RFC 5101, Section 4.3.";
}
identity flowKeys {
base "optionsType";
description "Flow Keys.";
reference "RFC 5101, Section 4.4.";
}
identity selectionSequence {
base "optionsType";
description "Selection Sequence and Selector Reports.";
reference "RFC 5476, Sections 6.5.1 and 6.5.2.";
}
identity selectionStatistics {
base "optionsType";
description "Selection Sequence Statistics Report.";
reference "RFC 5476, Sections 6.5.3.";
}
identity accuracy {
base "optionsType";
description "Accuracy Report.";
reference "RFC 5476, Section 6.5.4.";
}
identity reducingRedundancy {
base "optionsType";
description "Enables the utilization of Options Templates to
reduce redundancy in the exported Data Records.";
reference "RFC 5473.";
}
identity extendedTypeInformation {
base "optionsType";
description "Export of extended type information for
enterprise-specific Information Elements used in the
exported Templates.";
reference "RFC 5610.";
}
/*****************************************************************
* Type definitions
*****************************************************************/
typedef nameType {
type string {
length "1..max";
pattern "\S(.*\S)?";
}
description "Type for 'name' leafs...";
}
typedef direction {
type enumeration {
enum ingress {
description "This value is used for monitoring incoming
packets.";
}
enum egress {
description "This value is used for monitoring outgoing
packets.";
}
enum both {
description "This value is used for monitoring incoming and
outgoing packets.";
}
}
description "Direction of packets going through an interface or
linecard.";
}
typedef transportSessionStatus {
type enumeration {
enum inactive {
description "This value MUST be used for...";
}
enum active {
description "This value MUST be used for...";
}
enum unknown {
description "This value MUST be used if the status...";
}
}
description "Status of a Transport Session.";
reference "RFC 5815, Section 8 (ipfixTransportSessionStatus).";
}
/*****************************************************************
* Complex types
*****************************************************************/
ct:complex-type ObservationPoint {
description "Observation Point";
key name;
leaf name {
type nameType;
description "Key of an observation point.";
}
leaf observationPointId {
type uint32;
config false;
description "Observation Point ID...";
reference "RFC 5102, Section 5.1.10.";
}
leaf observationDomainId {
type uint32;
mandatory true;
description "The Observation Domain ID associates...";
reference "RFC 5101.";
}
choice OPLocation {
mandatory true;
description "Location of the Observation Point.";
leaf ifIndex {
type uint32;
description "Index of an interface...";
reference "RFC 2863.";
}
leaf ifName {
type string;
description "Name of an interface...";
reference "RFC 2863.";
}
leaf entPhysicalIndex {
type uint32;
description "Index of a linecard...";
reference "RFC 4133.";
}
leaf entPhysicalName {
type string;
description "Name of a linecard...";
reference "RFC 4133.";
}
}
leaf direction {
type direction;
default both;
description "Direction of packets....";
}
leaf-list selectionProcess {
type instance-identifier { ct:instance-type SelectionProcess; }
description "Selection Processes in this list process packets
in parallel.";
}
}
ct:complex-type Selector {
ct:abstract true;
description "Abstract selector";
key name;
leaf name {
type nameType;
description "Key of a selector";
}
leaf packetsObserved {
type yang:counter64;
config false;
description "The number of packets observed ...";
reference "RFC 5815, Section 8
(ipfixSelectionProcessStatsPacketsObserved).";
}
leaf packetsDropped {
type yang:counter64;
config false;
description "The total number of packets discarded ...";
reference "RFC 5815, Section 8
(ipfixSelectionProcessStatsPacketsDropped).";
}
leaf selectorDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion at which
one or more of the Selector counters suffered a
discontinuity...";
reference "RFC 5815, Section 8 (ipfixSelectionProcessStatsDiscontinuityTime)."; } }
参照 "RFC 5815、セクション8（ipfixSelectionProcessStatsDiscontinuityTime）。"; }}
ct:complex-type SelectAllSelector {
ct:extends Selector;
description "Method that selects all packets.";
}
ct:complex-type SampCountBasedSelector {
if-feature psampSampCountBased;
ct:extends Selector;
description "Selector applying systematic count-based
packet sampling to the packet stream.";
reference "RFC 5475, Section 5.1;
RFC 5476, Section 6.5.2.1.";
leaf packetInterval {
type uint32;
units packets;
mandatory true;
description "The number of packets that are consecutively
sampled between gaps of length packetSpace.
This parameter corresponds to the Information Element
samplingPacketInterval.";
reference "RFC 5477, Section 8.2.2.";
}
leaf packetSpace {
type uint32;
units packets;
mandatory true;
description "The number of unsampled packets between two
sampling intervals.
This parameter corresponds to the Information Element
samplingPacketSpace.";
reference "RFC 5477, Section 8.2.3.";
}
}
ct:complex-type SampTimeBasedSelector {
if-feature psampSampTimeBased;
ct:extends Selector;
description "Selector applying systematic time-based
packet sampling to the packet stream.";
reference "RFC 5475, Section 5.1;
RFC 5476, Section 6.5.2.2.";
leaf timeInterval {
type uint32;
units microseconds;
mandatory true;
description "The time interval in microseconds during
which all arriving packets are sampled between gaps
of length timeSpace.
This parameter corresponds to the Information Element
samplingTimeInterval.";
reference "RFC 5477, Section 8.2.4.";
}
leaf timeSpace {
type uint32;
units microseconds;
mandatory true;
description "The time interval in microseconds during
which no packets are sampled between two sampling
intervals specified by timeInterval.
This parameter corresponds to the Information Element
samplingTimeInterval.";
reference "RFC 5477, Section 8.2.5.";
}
}
ct:complex-type SampRandOutOfNSelector {
if-feature psampSampRandOutOfN;
ct:extends Selector;
description "This container contains the configuration
parameters of a Selector applying n-out-of-N packet
sampling to the packet stream.";
reference "RFC 5475, Section 5.2.1;
RFC 5476, Section 6.5.2.3.";
leaf size {
type uint32;
units packets;
mandatory true;
description "The number of elements taken from the parent
population.
This parameter corresponds to the Information Element
samplingSize.";
reference "RFC 5477, Section 8.2.6.";
}
leaf population {
type uint32;
units packets;
mandatory true;
description "The number of elements in the parent
population.
This parameter corresponds to the Information Element
samplingPopulation.";
reference "RFC 5477, Section 8.2.7."; } }
参照 "RFC 5477、セクション8.2.7。"; }}
ct:complex-type SampUniProbSelector {
if-feature psampSampUniProb;
ct:extends Selector;
description "Selector applying uniform probabilistic
packet sampling (with equal probability per packet) to the
packet stream.";
reference "RFC 5475, Section 5.2.2.1;
RFC 5476, Section 6.5.2.4.";
leaf probability {
type decimal64 {
fraction-digits 18;
range "0..1";
}
mandatory true;
description "Probability that a packet is sampled,
expressed as a value between 0 and 1. The probability
is equal for every packet.
This parameter corresponds to the Information Element
samplingProbability.";
reference "RFC 5477, Section 8.2.8.";
}
}
ct:complex-type FilterMatchSelector {
if-feature psampFilterMatch;
ct:extends Selector;
description "This container contains the configuration
parameters of a Selector applying property match filtering
to the packet stream.";
reference "RFC 5475, Section 6.1;
RFC 5476, Section 6.5.2.5.";
choice nameOrId {
mandatory true;
description "The field to be matched is specified by
either the name or the ID of the Information
Element.";
leaf ieName {
type string;
description "Name of the Information Element.";
}
leaf ieId {
type uint16 {
range "1..32767" {
description "Valid range of Information Element
identifiers.";
reference "RFC 5102, Section 4.";
}
}
description "ID of the Information Element.";
}
}
leaf ieEnterpriseNumber {
type uint32;
description "If present, ... ";
}
leaf value {
type string;
mandatory true;
description "Matching value of the Information Element.";
}
}
ct:complex-type FilterHashSelector {
if-feature psampFilterHash;
ct:extends Selector;
description "This container contains the configuration
parameters of a Selector applying hash-based filtering
to the packet stream.";
reference "RFC 5475, Section 6.2;
RFC 5476, Section 6.5.2.6.";
leaf hashFunction {
type identityref {
base "hashFunction";
}
default BOB;
description "Hash function to be applied. According to
RFC 5475, Section 6.2.4.1, BOB hash function must be
used in order to be compliant with PSAMP.";
}
leaf ipPayloadOffset {
type uint64;
units octets;
default 0;
description "IP payload offset ... ";
reference "RFC 5477, Section 8.3.2.";
}
leaf ipPayloadSize {
type uint64;
units octets;
default 8;
description "Number of IP payload bytes ... ";
reference "RFC 5477, Section 8.3.3.";
}
leaf digestOutput {
type boolean;
default false;
description "If true, the output ... ";
reference "RFC 5477, Section 8.3.8.";
}
leaf initializerValue {
type uint64;
description "Initializer value to the hash function.
If not configured by the user, the Monitoring Device
arbitrarily chooses an initializer value.";
reference "RFC 5477, Section 8.3.9.";
}
list selectedRange {
key name;
min-elements 1;
description "List of hash function return ranges for
which packets are selected.";
leaf name {
type nameType;
description "Key of this list.";
}
leaf min {
type uint64;
description "Beginning of the hash function's selected
range.
This parameter corresponds to the Information Element
hashSelectedRangeMin.";
reference "RFC 5477, Section 8.3.6.";
}
leaf max {
type uint64;
description "End of the hash function's selected range.
This parameter corresponds to the Information Element
hashSelectedRangeMax.";
reference "RFC 5477, Section 8.3.7.";
}
}
}
ct:complex-type Cache {
ct:abstract true;
description "Cache of a Monitoring Device.";
key name;
leaf name {
type nameType;
description "Key of a cache";
}
leaf-list exportingProcess {
type leafref { path "/ipfix/exportingProcess/name"; }
description "Records are exported by all Exporting Processes
in the list.";
}
description "Configuration and state parameters of a Cache.";
container cacheLayout {
description "Cache Layout.";
list cacheField {
key name;
min-elements 1;
description "List of fields in the Cache Layout.";
leaf name {
type nameType;
description "Key of this list.";
}
choice nameOrId {
mandatory true;
description "Name or ID of the Information Element.";
reference "RFC 5102.";
leaf ieName {
type string;
description "Name of the Information Element.";
}
leaf ieId {
type uint16 {
range "1..32767" {
description "Valid range of Information Element
identifiers.";
reference "RFC 5102, Section 4.";
}
}
description "ID of the Information Element.";
}
}
leaf ieLength {
type uint16;
units octets;
description "Length of the field ... ";
reference "RFC 5101, Section 6.2; RFC 5102.";
}
leaf ieEnterpriseNumber {
type uint32;
description "If present, the Information Element is
enterprise-specific. ... ";
reference "RFC 5101; RFC 5102.";
} leaf isFlowKey {
when "(../../../cacheMode != 'immediate')
and
((count(../ieEnterpriseNumber) = 0)
or
(../ieEnterpriseNumber != 29305))" {
description "This parameter is not available
for Reverse Information Elements (which have
enterprise number 29305) or if the Cache Mode
is 'immediate'.";
}
type empty;
description "If present, this is a flow key.";
}
}
}
leaf dataRecords {
type yang:counter64;
units "Data Records";
config false;
description "The number of Data Records generated ... ";
reference "RFC 5815, Section 8
(ipfixMeteringProcessCacheDataRecords).";
}
leaf cacheDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the ... ";
reference "RFC 5815, Section 8
(ipfixMeteringProcessCacheDiscontinuityTime).";
}
}
ct:complex-type ImmediateCache {
if-feature cacheModeImmediate;
ct:extends Cache;
}
ct:complex-type NonImmediateCache {
ct:abstract true;
ct:extends Cache;
leaf maxFlows {
type uint32;
units flows;
description "This parameter configures the maximum number of
Flows in the Cache ... ";
} leaf activeFlows {
type yang:gauge32;
units flows;
config false;
description "The number of Flows currently active in this
Cache.";
reference "RFC 5815, Section 8
(ipfixMeteringProcessCacheActiveFlows).";
}
leaf unusedCacheEntries {
type yang:gauge32;
units flows;
config false;
description "The number of unused Cache entries in this
Cache.";
reference "RFC 5815, Section 8
(ipfixMeteringProcessCacheUnusedCacheEntries).";
}
}
ct:complex-type NonPermanentCache {
ct:abstract true;
ct:extends NonImmediateCache;
leaf activeTimeout {
type uint32;
units milliseconds;
description "This parameter configures the time in
milliseconds after which ... ";
}
leaf inactiveTimeout {
type uint32;
units milliseconds;
description "This parameter configures the time in
milliseconds after which ... ";
}
}
ct:complex-type NaturalCache {
if-feature cacheModeNatural;
ct:extends NonPermanentCache;
}
ct:complex-type TimeoutCache {
if-feature cacheModeTimeout;
ct:extends NonPermanentCache;
}
ct:complex-type PermanentCache {
CT：複合型PermanentCache {
if-feature cacheModePermanent;
ct:extends NonImmediateCache;
leaf exportInterval {
type uint32;
units milliseconds;
description "This parameter configures the interval for
periodical export of Flow Records in milliseconds.
If not configured by the user, the Monitoring Device sets
this parameter.";
}
}
ct:complex-type ExportDestination {
ct:abstract true;
description "Abstract export destination.";
key name;
leaf name {
type nameType;
description "Key of an export destination.";
}
}
ct:complex-type IpDestination {
ct:abstract true;
ct:extends ExportDestination;
description "IP export destination.";
leaf ipfixVersion {
type uint16;
default 10;
description "IPFIX version number.";
}
leaf destinationPort {
type inet:port-number;
description "If not configured by the user, the Monitoring
Device uses the default port number for IPFIX, which is
4739 without Transport Layer Security, and 4740 if Transport
Layer Security is activated.";
}
choice indexOrName {
description "Index or name of the interface ... ";
reference "RFC 2863.";
leaf ifIndex {
type uint32;
description "Index of an interface as stored in the ifTable
of IF-MIB.";
reference "RFC 2863.";
}
leaf ifName {
type string;
description "Name of an interface as stored in the ifTable
of IF-MIB.";
reference "RFC 2863.";
}
}
leaf sendBufferSize {
type uint32;
units bytes;
description "Size of the socket send buffer.
If not configured by the user, this parameter is set by
the Monitoring Device.";
}
leaf rateLimit {
type uint32;
units "bytes per second";
description "Maximum number of bytes per second ... ";
reference "RFC 5476, Section 6.3";
}
container transportLayerSecurity {
presence "If transportLayerSecurity is present, DTLS is
enabled if the transport protocol is SCTP or UDP, and TLS
is enabled if the transport protocol is TCP.";
description "Transport Layer Security configuration.";
uses transportLayerSecurityParameters;
}
container transportSession {
config false;
description "State parameters of the Transport Session
directed to the given destination.";
uses transportSessionParameters;
}
}
ct:complex-type SctpExporter {
ct:extends IpDestination;
description "SCTP exporter.";
leaf-list sourceIPAddress {
type inet:ip-address;
description "List of source IP addresses used ... ";
reference "RFC 4960, Section 6.4
(Multi-Homed SCTP Endpoints).";
}
leaf-list destinationIPAddress {
type inet:ip-address;
min-elements 1;
description "One or multiple IP addresses ... ";
reference "RFC 4960, Section 6.4
(Multi-Homed SCTP Endpoints).";
}
leaf timedReliability {
type uint32;
units milliseconds;
default 0;
description "Lifetime in milliseconds ... ";
reference "RFC 3758; RFC 4960.";
}
}
ct:complex-type UdpExporter {
ct:extends IpDestination;
if-feature udpTransport;
description "UDP parameters.";
leaf sourceIPAddress {
type inet:ip-address;
description "Source IP address used by the Exporting
Process ...";
}
leaf destinationIPAddress {
type inet:ip-address;
mandatory true;
description "IP address of the Collection Process to which
IPFIX Messages are sent.";
}
leaf maxPacketSize {
type uint16;
units octets;
description "This parameter specifies the maximum size of
IP packets ... ";
}
leaf templateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Templates are resent in the
UDP Transport Session. ... ";
reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
(ipfixTransportSessionTemplateRefreshTimeout).";
}
leaf optionsTemplateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Options Templates are
resent in the UDP Transport Session. ... ";
reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
(ipfixTransportSessionOptionsTemplateRefreshTimeout).";
}
leaf templateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Templates are resent in the UDP Transport Session. ... ";
reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
(ipfixTransportSessionTemplateRefreshPacket).";
}
leaf optionsTemplateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Options Templates are resent in the UDP Transport Session
protocol. ... ";
reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
(ipfixTransportSessionOptionsTemplateRefreshPacket).";
}
}
ct:complex-type TcpExporter {
ct:extends IpDestination;
if-feature tcpTransport;
description "TCP exporter";
leaf sourceIPAddress {
type inet:ip-address;
description "Source IP address used by the Exporting
Process...";
}
leaf destinationIPAddress {
type inet:ip-address;
mandatory true;
description "IP address of the Collection Process to which
IPFIX Messages are sent.";
}
}
ct:complex-type FileWriter {
ct:extends ExportDestination;
if-feature fileWriter;
description "File Writer.";
leaf ipfixVersion {
type uint16;
default 10;
description "IPFIX version number.";
}
leaf file {
type inet:uri;
mandatory true;
description "URI specifying the location of the file.";
}
leaf bytes {
type yang:counter64;
units octets;
config false;
description "The number of bytes written by the File
Writer...";
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
config false;
description "The number of IPFIX Messages written by the File
Writer. ... ";
}
leaf discardedMessages {
type yang:counter64;
units "IPFIX Messages";
config false;
description "The number of IPFIX Messages that could not be
written by the File Writer ... ";
}
leaf records {
type yang:counter64;
units "Data Records";
config false;
description "The number of Data Records written by the File
Writer. ... ";
}
leaf templates {
type yang:counter32;
units "Templates";
config false;
description "The number of Template Records (excluding
Options Template Records) written by the File Writer.
... ";
}
leaf optionsTemplates {
type yang:counter32;
units "Options Templates";
config false;
description "The number of Options Template Records written
by the File Writer. ... ";
}
leaf fileWriterDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion at which
one or more File Writer counters suffered a discontinuity.
... ";
}
list template {
config false;
description "This list contains the Templates and Options
Templates that have been written by the File Reader. ... ";
uses templateParameters;
}
}
ct:complex-type ExportingProcess {
if-feature exporter;
description "Exporting Process of the Monitoring Device.";
key name;
leaf name {
type nameType;
description "Key of this list.";
}
leaf exportMode {
type identityref {
base "exportMode";
}
default parallel;
description "This parameter determines to which configured
destination(s) the incoming Data Records are exported.";
}
ct:instance-list destination {
ct:instance-type ExportDestination;
min-elements 1;
description "Export destinations.";
}
list options {
key name;
description "List of options reported by the Exporting
Process.";
leaf name {
type nameType;
description "Key of this list.";
}
leaf optionsType {
type identityref {
base "optionsType";
}
mandatory true;
description "Type of the exported options data.";
}
leaf optionsTimeout {
type uint32;
units milliseconds;
description "Time interval for periodic export of the options
data. ... ";
}
}
}
ct:complex-type CollectingProcess {
description "A Collecting Process.";
key name;
leaf name {
type nameType;
description "Key of a collecing process.";
}
ct:instance-list sctpCollector {
ct:instance-type SctpCollector;
description "List of SCTP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
}
ct:instance-list udpCollector {
if-feature udpTransport;
ct:instance-type UdpCollector;
description "List of UDP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
}
ct:instance-list tcpCollector {
if-feature tcpTransport;
ct:instance-type TcpCollector;
description "List of TCP receivers (sockets) on which the
Collecting Process receives IPFIX Messages.";
}
ct:instance-list fileReader {
if-feature fileReader;
ct:instance-type FileReader;
description "List of File Readers from which the Collecting
Process reads IPFIX Messages.";
}
leaf-list exportingProcess {
type instance-identifier { ct:instance-type ExportingProcess; }
description "Export of received records without any
modifications. Records are processed by all Exporting
Processes in the list.";
}
} ct:complex-type Collector {
ct:abstract true;
description "Abstract collector.";
key name;
leaf name {
type nameType;
description "Key of collectors";
}
}
ct:complex-type IpCollector {
ct:abstract true;
ct:extends Collector;
description "Collector for IP transport protocols.";
leaf localPort {
type inet:port-number;
description "If not configured, the Monitoring Device uses the
default port number for IPFIX, which is 4739 without
Transport Layer Security, and 4740 if Transport Layer
Security is activated.";
}
container transportLayerSecurity {
presence "If transportLayerSecurity is present, DTLS is enabled
if the transport protocol is SCTP or UDP, and TLS is enabled
if the transport protocol is TCP.";
description "Transport Layer Security configuration.";
uses transportLayerSecurityParameters;
}
list transportSession {
config false;
description "This list contains the currently established
Transport Sessions terminating at the given socket.";
uses transportSessionParameters;
}
}
ct:complex-type SctpCollector {
ct:extends IpCollector;
description "Collector listening on an SCTP socket";
leaf-list localIPAddress {
type inet:ip-address;
description "List of local IP addresses ... ";
reference "RFC 4960, Section 6.4
(Multi-Homed SCTP Endpoints).";
}
}
ct:complex-type UdpCollector {
CT：複合型UdpCollector {
ct:extends IpCollector;
description "Parameters of a listening UDP socket at a
Collecting Process.";
leaf-list localIPAddress {
type inet:ip-address;
description "List of local IP addresses on which the Collecting
Process listens for IPFIX Messages.";
}
leaf templateLifeTime {
type uint32;
units seconds;
default 1800;
description "Sets the lifetime of Templates for all UDP
Transport Sessions ... ";
reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
(ipfixTransportSessionTemplateRefreshTimeout).";
}
leaf optionsTemplateLifeTime {
type uint32;
units seconds;
default 1800;
description "Sets the lifetime of Options Templates for all
UDP Transport Sessions terminating at this UDP socket.
... ";
reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
(ipfixTransportSessionOptionsTemplateRefreshTimeout).";
}
leaf templateLifePacket {
type uint32;
units "IPFIX Messages";
description "If this parameter is configured, Templates
defined in a UDP Transport Session become invalid if ...";
reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
(ipfixTransportSessionTemplateRefreshPacket).";
}
leaf optionsTemplateLifePacket {
type uint32;
units "IPFIX Messages";
description "If this parameter is configured, Options
Templates defined in a UDP Transport Session become
invalid if ...";
reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
(ipfixTransportSessionOptionsTemplateRefreshPacket).";
}
}
ct:complex-type TcpCollector { ct:extends IpCollector;
CT：複合型TcpCollector {CT：IpCollectorを拡張します。
description "Collector listening on a TCP socket.";
leaf-list localIPAddress {
type inet:ip-address;
description "List of local IP addresses on which the Collecting
Process listens for IPFIX Messages.";
}
}
ct:complex-type FileReader {
ct:extends Collector;
description "File Reading collector.";
leaf file {
type inet:uri;
mandatory true;
description "URI specifying the location of the file.";
}
leaf bytes {
type yang:counter64;
units octets;
config false;
description "The number of bytes read by the File Reader.
... ";
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
config false;
description "The number of IPFIX Messages read by the File
Reader. ... ";
}
leaf records {
type yang:counter64;
units "Data Records";
config false;
description "The number of Data Records read by the File
Reader. ... ";
}
leaf templates {
type yang:counter32;
units "Templates";
config false;
description "The number of Template Records (excluding
Options Template Records) read by the File Reader. ...";
}
leaf optionsTemplates {
type yang:counter32;
units "Options Templates";
config false;
description "The number of Options Template Records read by
the File Reader. ... ";
}
leaf fileReaderDiscontinuityTime {
type yang:date-and-time;
config false;
description "Timestamp of the most recent occasion ... ";
}
list template {
config false;
description "This list contains the Templates and Options
Templates that have been read by the File Reader.
Withdrawn or invalidated (Options) Templates MUST be removed
from this list.";
uses templateParameters;
}
}
ct:complex-type SelectionProcess {
description "Selection Process";
key name;
leaf name {
type nameType;
description "Key of a selection process.";
}
ct:instance-list selector {
ct:instance-type Selector;
min-elements 1;
ordered-by user;
description "List of Selectors that define the action of the
Selection Process on a single packet. The Selectors are
serially invoked in the same order as they appear in this
list.";
}
list selectionSequence {
config false;
description "This list contains the Selection Sequence IDs
which are assigned by the Monitoring Device ... ";
reference "RFC 5476.";
leaf observationDomainId {
type uint32;
description "Observation Domain ID for which the
Selection Sequence ID is assigned.";
}
leaf selectionSequenceId {
type uint64;
description "Selection Sequence ID used in the Selection
Sequence (Statistics) Report Interpretation.";
} } leaf cache { type instance-identifier { ct:instance-type Cache; } description "Cache which receives the output of the Selection Process."; } }
}}リーフキャッシュ{タイプインスタンス識別子{CT：インスタンス型キャッシュ。 }説明「選択処理の出力を受信するキャッシュ。」; }}
/*****************************************************************
* Groupings
*****************************************************************/
grouping transportLayerSecurityParameters {
description "Transport layer security parameters.";
leaf-list localCertificationAuthorityDN {
type string;
description "Distinguished names of certification authorities
whose certificates may be used to identify the local
endpoint.";
}
leaf-list localSubjectDN {
type string;
description "Distinguished names that may be used in the
certificates to identify the local endpoint.";
}
leaf-list localSubjectFQDN {
type inet:domain-name;
description "Fully qualified domain names that may be used to
in the certificates to identify the local endpoint.";
}
leaf-list remoteCertificationAuthorityDN {
type string;
description "Distinguished names of certification authorities
whose certificates are accepted to authorize remote
endpoints.";
}
leaf-list remoteSubjectDN {
type string;
description "Distinguished names that are accepted in
certificates to authorize remote endpoints.";
}
leaf-list remoteSubjectFQDN {
type inet:domain-name;
description "Fully qualified domain names that are accepted in
certificates to authorize remote endpoints.";
}
} grouping templateParameters {
description "State parameters of a Template used by an Exporting
Process or received by a Collecting Process ... ";
reference "RFC 5101; RFC 5815, Section 8 (ipfixTemplateEntry,
ipfixTemplateDefinitionEntry, ipfixTemplateStatsEntry)";
leaf observationDomainId {
type uint32;
description "The ID of the Observation Domain for which this
Template is defined.";
reference "RFC 5815, Section 8
(ipfixTemplateObservationDomainId).";
}
leaf templateId {
type uint16 {
range "256..65535" {
description "Valid range of Template Ids.";
reference "RFC 5101";
}
}
description "This number indicates the Template Id in the IPFIX
message.";
reference "RFC 5815, Section 8 (ipfixTemplateId).";
}
leaf setId {
type uint16;
description "This number indicates the Set Id of the Template.
... ";
reference "RFC 5815, Section 8 (ipfixTemplateSetId).";
}
leaf accessTime {
type yang:date-and-time;
description "Used for Exporting Processes, ... ";
reference "RFC 5815, Section 8 (ipfixTemplateAccessTime).";
}
leaf templateDataRecords {
type yang:counter64;
description "The number of transmitted or received Data
Records ... ";
reference "RFC 5815, Section 8 (ipfixTemplateDataRecords).";
}
leaf templateDiscontinuityTime {
type yang:date-and-time;
description "Timestamp of the most recent occasion at which
the counter templateDataRecords suffered a discontinuity.
... ";
reference "RFC 5815, Section 8
(ipfixTemplateDiscontinuityTime).";
} list field {
description "This list contains the (Options) Template
fields of which the (Options) Template is defined.
... ";
leaf ieId {
type uint16 {
range "1..32767" {
description "Valid range of Information Element
identifiers.";
reference "RFC 5102, Section 4.";
}
}
description "This parameter indicates the Information
Element Id of the field.";
reference "RFC 5815, Section 8 (ipfixTemplateDefinitionIeId);
RFC 5102.";
}
leaf ieLength {
type uint16;
units octets;
description "This parameter indicates the length of the
Information Element of the field.";
reference "RFC 5815, Section 8
(ipfixTemplateDefinitionIeLength); RFC 5102.";
}
leaf ieEnterpriseNumber {
type uint32;
description "This parameter indicates the IANA enterprise
number of the authority ... ";
reference "RFC 5815, Section 8
(ipfixTemplateDefinitionEnterpriseNumber).";
}
leaf isFlowKey {
when "../../setId = 2" {
description "This parameter is available for non-Options
Templates (Set Id is 2).";
}
type empty;
description "If present, this is a Flow Key field.";
reference "RFC 5815, Section 8
(ipfixTemplateDefinitionFlags).";
}
leaf isScope {
when "../../setId = 3" {
description "This parameter is available for Options
Templates (Set Id is 3).";
}
type empty;
description "If present, this is a scope field.";
reference "RFC 5815, Section 8
(ipfixTemplateDefinitionFlags).";
}
}
}
grouping transportSessionParameters {
description "State parameters of a Transport Session ... ";
reference "RFC 5101; RFC 5815, Section 8
(ipfixTransportSessionEntry,
ipfixTransportSessionStatsEntry)";
leaf ipfixVersion {
type uint16;
description "Used for Exporting Processes, this parameter
contains the version number of the IPFIX protocol ... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionIpfixVersion).";
}
leaf sourceAddress {
type inet:ip-address;
description "The source address of the Exporter of the
IPFIX Transport Session... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionSourceAddressType,
ipfixTransportSessionSourceAddress).";
}
leaf destinationAddress {
type inet:ip-address;
description "The destination address of the Collector of
the IPFIX Transport Session... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionDestinationAddressType,
ipfixTransportSessionDestinationAddress).";
}
leaf sourcePort {
type inet:port-number;
description "The transport protocol port number of the
Exporter of the IPFIX Transport Session.";
reference "RFC 5815, Section 8
(ipfixTransportSessionSourcePort).";
}
leaf destinationPort {
type inet:port-number;
description "The transport protocol port number of the
Collector of the IPFIX Transport Session... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionDestinationPort).";
}
leaf sctpAssocId {
type uint32;
description "The association id used for the SCTP session
between the Exporter and the Collector ... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionSctpAssocId),
RFC 3871";
}
leaf status {
type transportSessionStatus;
description "Status of the Transport Session.";
reference "RFC 5815, Section 8 (ipfixTransportSessionStatus).";
}
leaf rate {
type yang:gauge32;
units "bytes per second";
description "The number of bytes per second transmitted by the
Exporting Process or received by the Collecting Process.
This parameter is updated every second.";
reference "RFC 5815, Section 8 (ipfixTransportSessionRate).";
}
leaf bytes {
type yang:counter64;
units bytes;
description "The number of bytes transmitted by the
Exporting Process or received by the Collecting
Process ... ";
reference "RFC 5815, Section 8 (ipfixTransportSessionBytes).";
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
description "The number of messages transmitted by the
Exporting Process or received by the Collecting Process... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionMessages).";
}
leaf discardedMessages {
type yang:counter64;
units "IPFIX Messages";
description "Used for Exporting Processes, this parameter
indicates the number of messages that could not be
sent ...";
reference "RFC 5815, Section 8
(ipfixTransportSessionDiscardedMessages).";
}
leaf records {
type yang:counter64;
units "Data Records";
description "The number of Data Records transmitted ... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionRecords).";
}
leaf templates {
type yang:counter32;
units "Templates";
description "The number of Templates transmitted by the
Exporting Process or received by the Collecting Process.
... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionTemplates).";
}
leaf optionsTemplates {
type yang:counter32;
units "Options Templates";
description "The number of Option Templates transmitted by the
Exporting Process or received by the Collecting Process...";
reference "RFC 5815, Section 8
(ipfixTransportSessionOptionsTemplates).";
}
leaf transportSessionStartTime {
type yang:date-and-time;
description "Timestamp of the start of the given Transport
Session... ";
}
leaf transportSessionDiscontinuityTime {
type yang:date-and-time;
description "Timestamp of the most recent occasion at which
one or more of the Transport Session counters suffered a
discontinuity... ";
reference "RFC 5815, Section 8
(ipfixTransportSessionDiscontinuityTime).";
}
list template {
description "This list contains the Templates and Options
Templates that are transmitted by the Exporting Process
or received by the Collecting Process.
Withdrawn or invalidated (Options) Templates MUST be removed
from this list.";
uses templateParameters;
}
}
/*****************************************************************
* Main container
*****************************************************************/
*****************************************************************/
container ipfix {
description "Top-level node of the IPFIX/PSAMP configuration
data model.";
ct:instance-list collectingProcess {
if-feature collector;
ct:instance-type CollectingProcess;
}
ct:instance-list observationPoint {
if-feature meter;
ct:instance-type ObservationPoint;
}
ct:instance-list selectionProcess {
if-feature meter;
ct:instance-type SelectionProcess;
}
ct:instance-list cache {
if-feature meter;
description "Cache of the Monitoring Device.";
ct:instance-type Cache;
}
ct:instance-list exportingProcess {
if-feature exporter;
description "Exporting Process of the Monitoring Device.";
ct:instance-type ExportingProcess;
}
} } <CODE ENDS>
}} <CODEを終了します>
Authors' Addresses
著者のアドレス
Bernd Linowski TCS/Nokia Siemens Networks Heltorfer Strasse 1 Duesseldorf 40472 Germany
ベルントLinowski TCS /ノキアシーメンスネットワークスHeltorferシュトラーセ1デュッセルドルフ40472ドイツ
EMail: bernd.linowski.ext@nsn.com
メールアドレス：bernd.linowski.ext@nsn.com
Mehmet Ersue Nokia Siemens Networks St.-Martin-Strasse 76 Munich 81541 Germany
メフメットErsueノキアシーメンスネットワークスサンマルタンシュトラーセ76ミュンヘン81541ドイツ
EMail: mehmet.ersue@nsn.com
メールアドレス：mehmet.ersue@nsn.com
Siarhei Kuryla 360 Treasury Systems Grueneburgweg 16-18 Frankfurt am Main 60322 Germany
Siarhei Kuryla 360財務省システムGrueneburgweg 16-18フランクフルト・アム・マイン60322ドイツ午前
EMail: s.kuryla@gmail.com
メールアドレス：s.kuryla@gmail.com