[要約] RFC 3814は、MPLSネットワークでのFEC-To-NHLFEの管理情報ベース（MIB）に関するものです。このRFCの目的は、MPLSネットワークのFEC-To-NHLFEマッピングを管理するための標準的な手法を提供することです。
Network Working Group T. Nadeau
Request for Comments: 3814 Cisco Systems, Inc.
Category: Standards Track C. Srinivasan
Bloomberg L.P.
A. Viswanathan
Force10 Networks, Inc.
June 2004
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)
マルチプロトコルラベルスイッチング（MPLS）転送等価クラスへの次のホップラベル転送エントリ（FEC-to-NHLFE）管理情報ベース（MIB）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS).
このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、次のホップラベル転送エントリ（NHLFE）マッピングとマルチプロトコルラベルスイッチング（MPLS）で使用する対応するアクションを次のホップラベル転送エントリ（NHLFE）に定義、構成、および監視するための管理オブジェクトを説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used In This Document. . . . . . . . . . . . . . . 3
4. The Internet-Standard Management Framework . . . . . . . . . . 3
5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. mplsFTNTable . . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. Advantages of Address Ranges Over CIDR Prefixes. 4
5.2. mplsFTNMapTable. . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Indexing Requirements. . . . . . . . . . . . . . 5
5.2.2. How the Current Indexing Works . . . . . . . . . 5
5.3. mplsFTNPerfTable . . . . . . . . . . . . . . . . . . . . 7
6. Avoiding Retrieval-Modification Interactions . . . . . . . . . 7
7. Example Illustrating MIB Module Components . . . . . . . . . . 8
7.1. Sample FTN Rules . . . . . . . . . . . . . . . . . . . . 8
7.2. Creating FTN Entries and Applying them to Interfaces . . 9
7.3. Mapping an FTN Entry to Multiple Interfaces. . . . . . . 10
7.4. Inserting an Entry Into Existing List. . . . . . . . . . 11
7.5. Pictorial Tabular Relationship . . . . . . . . . . . . . 13
7.6. Deleting an Entry. . . . . . . . . . . . . . . . . . . . 14
8. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 16
9. MPLS-FTN-STD-MIB Definitions . . . . . . . . . . . . . . . . . 16
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
11.1. IANA Considerations for MPLS-FTN-STD-MIB . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for specifying Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for Multiprotocol Label Switching (MPLS).
このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、次のホップラベル転送エントリ（NHLFE）マッピングとマルチプロトコルラベルスイッチング（MPLS）の対応するアクションを転送する等価クラス（FEC）を指定するための管理オブジェクトについて説明します。
At the ingress of an MPLS network, packets entering the MPLS domain are assigned to an FEC. Those packets belonging to an FEC are associated with an NHLFE (i.e., MPLS label) via the FEC-to-NHLFE (FTN) mapping [RFC3031]. This relationship defines how ingress LSRs will impose MPLS labels onto incoming packets. It also defines how egress LSRs will decapsulate the MPLS shim header from MPLS packets.
MPLSネットワークの侵入では、MPLSドメインを入力するパケットがFECに割り当てられます。FECに属するこれらのパケットは、FEC-to-NHLFE（FTN）マッピング[RFC3031]を介してNHLFE（つまり、MPLSラベル）に関連付けられています。この関係は、Ingress LSRSがMPLSラベルを着信パケットにどのように課すかを定義します。また、LSRがMPLSパケットからMPLSシムヘッダーを脱カプセル化する方法も定義します。
Conceptually, some of the FTN table functionality could be implemented using the Forwarding Information Base (FIB) to map all packets destined for a prefix to an LSP. However, this mapping is coarse in nature.
概念的には、FTNテーブル機能の一部を転送情報ベース（FIB）を使用して実装して、LSPのプレフィックスに向けたすべてのパケットをマッピングできます。ただし、このマッピングは本質的に粗いです。
Similar functionality is already being used in other contexts such as security filters, access filters, and RSVP flow identification. All of these require various combinations of matching based on IP header and upper-layer header information to identify packets for a particular treatment. When packets match a particular rule, a corresponding action is executed on those packets. For example, two popular actions to take when a successful match is identified are allowing the packet to be forwarded or to discard it. However, other actions are possible, such as modifying the TOS byte, or redirecting a packet to a particular outgoing interface. In the context of MPLS, the possible actions performed by an NHLFE are to redirect packets to either an MPLS Label Switched Path (LSP) or an MPLS Traffic Engineered (TE) Tunnel.
セキュリティフィルター、アクセスフィルター、RSVPフロー識別など、他のコンテキストでも同様の機能が使用されています。これらのすべては、特定の治療のパケットを特定するために、IPヘッダーと上層ヘッダー情報に基づいて一致するさまざまな組み合わせが必要です。パケットが特定のルールと一致する場合、それらのパケットで対応するアクションが実行されます。たとえば、成功した試合が特定されたときに取るべき2つの一般的なアクションにより、パケットを転送するか、破棄することができます。ただし、TOSバイトの変更や特定の発信インターフェイスへのパケットのリダイレクトなど、他のアクションが可能です。MPLSのコンテキストでは、NHLFEによって実行される可能なアクションは、パケットをMPLSラベルスイッチドパス（LSP）またはMPLSトラフィック（TE）トンネルのいずれかにリダイレクトすることです。
This document attempts to consolidate the various matching requirements and associated action options needed for MPLS into a single specification.
このドキュメントは、MPLSに必要なさまざまな一致する要件と関連するアクションオプションを単一の仕様に統合しようとします。
Although all of the terminology used in this document is either covered in the MPLS Architecture [RFC3031] or in the SNMP Architecture [RFC3411], it is informational to define some immediately pertinent acronyms/terminology here.
このドキュメントで使用されているすべての用語は、MPLSアーキテクチャ[RFC3031]またはSNMPアーキテクチャ[RFC3411]でカバーされていますが、ここではすぐに適切な頭字語/用語を定義することは情報に基づいています。
MPLS Multiprotocol Label Switching FEC Forwarding Equivalence Class NHLFE Next-Hop Label Forwarding Entry FTN FEC-to-NHLFE MIB Management Information Base
MPLSマルチプロトコルラベルスイッチングFEC転送等価クラスNHLFE NEXT-HOPラベル転送エントリFTN FEC-TO-NLFEMIB管理情報ベース
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準管理フレームワークを説明するドキュメントの詳細な概要については、RFC 3410 [RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBオブジェクトは通常、単純なネットワーク管理プロトコル（SNMP）からアクセスされます。MIBのオブジェクトは、管理情報の構造（SMI）で定義されたメカニズムを使用して定義されます。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [RFC2580]に記載されているSMIV2に準拠したMIBモジュールを指定します。
This MIB module resides on any LSR which does the FEC-to-NHLFE mapping in order to map traffic into the MPLS domain. This MIB module consists of three tables:
このMIBモジュールは、トラフィックをMPLSドメインにマッピングするためにFECからNHLFEマッピングを行うLSRに存在します。このMIBモジュールは、3つのテーブルで構成されています。
- mplsFTNTable defines the rule base against which incoming packets are matched and defines the actions to be taken on matching packets;
- mplsftntableは、着信パケットが一致するルールベースを定義し、一致するパケットで実行するアクションを定義します。
- mplsFTNMapTable defines the application of these rules to specific interfaces;
- mplsftnmaptableこれらのルールの特定のインターフェイスへの適用を定義します。
- mplsFTNPerfTable provides performance counters for every entry in mplsFTNTable that is active on one or more interfaces, on a per-interface basis.
- mplsftnperftableは、1つ以上のインターフェイスでアクティブなMPLSFTNTABLEのすべてのエントリに対して、インターフェイスごとにアクティブなパフォーマンスカウンターを提供します。
This table allows FEC to NHLFE mappings to be specified. Each entry in this table (also referred to as an "FTN entry" in this document) defines a rule to be applied to incoming packets (on interfaces that the entry is activated on using mplsFTNMapTable as explained in Section 5.2) and an action to be taken on matching packets. mplsFTNTable allows 6-tuple matching rules based on one or more of source address range, destination address range, source port range, destination port range, IPv4 Protocol field [RFC791] or IPv6 next-header field [RFC2460], and the DiffServ Code Point (DSCP, [RFC2474]) to be specified. Packet redirection is based on an action pointer which points either at an mplsXCEntry in MPLS-LSR-STD-MIB [RFC3813] when the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE-STD-MIB [RFC3812] when the NHLFE is the origin of a TE tunnel.
このテーブルでは、FECからNHLFEマッピングを指定できます。このテーブルの各エントリ（このドキュメントの「FTNエントリ」とも呼ばれます）は、受信パケットに適用するルール（セクション5.2で説明したようにMPLSFTNMAPTABLEを使用するとエントリがアクティブ化されるインターフェイスで）およびアクションを定義し、マッチングパケットで撮影。MPLSFTNTABLEは、1つ以上のソースアドレス範囲、宛先アドレス範囲、ソースポート範囲、IPv4プロトコルフィールド[RFC791]またはIPv6 Next-Headerフィールド[RFC2460]、および拡散コードポイントに基づいて、6タプルのマッチングルールを許可します。（DSCP、[RFC2474]）指定する。パケットリダイレクトは、NHLFEが非TELSPである場合、MPLS-LSR-STD-MIB [RFC3813]のMPLSXCENTRY [RFC3813]のいずれか、またはMPLS-TE-STD-MIB [RFC3812]のMPLSTUNNENENTRYのいずれかを指すアクションポインターに基づいています。NHLFEがTEトンネルの起源である場合。
One possible way of specifying a set of addresses as part of an FTN rule is to use CIDR prefixes [RFC1519]. We have instead chosen to allow FTN rules to be expressed in terms of address ranges in mplsFTNTable because they have the following advantages.
FTNルールの一部としてアドレスのセットを指定する1つの可能な方法は、CIDRプレフィックス[RFC1519]を使用することです。代わりに、次の利点があるため、MPLSFTNTABLEのアドレス範囲に関してFTNルールを表現できるようにしました。
- The number of CIDR prefixes needed to represent some address ranges is very large. For example, we need the following 6 CIDR prefixes to represent the range of addresses [192.0.2.0- 192.0.2.62]: 192.0.2.0/27, 192.0.2.32/28, 192.0.2.48/29, 192.0.2.56/30, 192.0.2.60/31, and 192.0.2.62/32. A rule such as "redirect all packets with a source address in the range [192.0.2.0-192.0.2.62] and destination address in the range [192.0.2.128-192.0.2.190] to tunnel #2" would require the creation of 36 conceptual rows in mplsFTNTable if the rules were expressed as CIDR prefixes, but only a single conceptual row would be required if we used address ranges instead.
- 一部のアドレス範囲を表すために必要なCIDRプレフィックスの数は非常に大きいです。たとえば、アドレスの範囲を表すために、次の6つのCIDRプレフィックスが必要です[192.0.2.0- 192.0.2.62]：192.0.2.2.32/28、192.0.2.48/29、192.0.2.56/30、192.0.2.60/31、および192.0.2.62/32。「192.0.2.0-192.0.2.62]のソースアドレスですべてのパケットをリダイレクトし、範囲の宛先アドレス[192.0.2.128-192.0.2.2.190]にトンネル＃2に36の作成を必要とするなどのルールルールがCIDRプレフィックスとして表された場合、MPLSFTNTABLEの概念行ですが、代わりにアドレス範囲を使用した場合は単一の概念的行のみが必要になります。
- Every CIDR prefix can be expressed as a single equivalent address range.
- すべてのCIDRプレフィックスは、単一の同等のアドレス範囲として表現できます。
- A particular implementation is free to translate the address ranges specified in mplsFTNTable internally to equivalent CIDR prefixes, if it so chooses. However, given that powerful range matching algorithms are available, many implementations may prefer to implement these directly.
- 特定の実装では、MPLSFTNTABLEで指定されたアドレスの範囲を、そのように選択した場合、同等のCIDRプレフィックスに自由に翻訳できます。ただし、強力な範囲マッチングアルゴリズムが利用可能であることを考えると、多くの実装がこれらを直接実装することを好む場合があります。
This table provides the capability to activate or map FTN entries defined in mplsFTNTable to specific interfaces in the system. Packets received on an interface are compared against FTN entries in the order in which entries are applied to the interface.
このテーブルは、システム内の特定のインターフェイスにMPLSFTNTALTで定義されたFTNエントリをアクティブ化またはマップする機能を提供します。インターフェイスで受信したパケットは、インターフェイスにエントリが適用される順序でFTNエントリと比較されます。
The indexing structure of mplsFTNMapTable was designed to satisfy the following requirements.
mplsftnmaptableのインデックス構造は、次の要件を満たすように設計されています。
- We must be able to insert a new entry into an existing list of entries on an interface with a single SET operation. Thus, we must be able to support an insertion operation that does not require manual reindexing of existing entries.
- 単一のセット操作を備えたインターフェイス上の既存のエントリリストに新しいエントリを挿入できる必要があります。したがって、既存のエントリの手動での再インデックスを必要としない挿入操作をサポートできる必要があります。
- A management application must be able to traverse entries that have been applied to a particular interface in the order of application. The number of (non-bulk) retrieval operations to obtain this information as dictated by the particular indexing scheme that we choose for mplsFTNMapTable must be no more than that dictated by any other indexing scheme. For example, the indexing scheme must not force the Network Management Application to retrieve all the entries in the table and sift through them offline to obtain this information.
- 管理アプリケーションは、アプリケーションの順に特定のインターフェイスに適用されたエントリを通過できる必要があります。MPLSFTNMAPTABLEに選択した特定のインデックス作成スキームによって決定されるこの情報を取得するための（非バルク）検索操作の数は、他のインデックス作成スキームによって指示されたもの以上のものでなければなりません。たとえば、インデックス作成スキームは、ネットワーク管理アプリケーションにテーブル内のすべてのエントリを取得するように強制し、この情報を取得するためにオフラインをふるいにかけてはなりません。
The natural data-structure for implementing constant time insertions between two existing entries and for supporting in-order traversals is a linked-list.
2つの既存のエントリ間で一定の時間挿入を実装し、次数のトラバーサルをサポートするための自然なデータ構造は、リンクリストです。
The chosen indexing structure of mplsFTNMapTable makes the entries in the table behave like items in a linked-list. Each conceptual row has an object, mplsFTNMapPrevIndex, which is a pointer to the previous entry that is applied to a particular interface. This object is self-adjusting, i.e., its value is automatically adjusted by the agent, if necessary, after an insertion or deletion operation.
Mplsftnmaptableの選択されたインデックス構造により、テーブル内のエントリはリンクリストのアイテムのように動作します。各概念行には、特定のインターフェイスに適用される前のエントリへのポインターであるオブジェクトMplsftnmapprevindexがあります。このオブジェクトは自己調整です。つまり、その値は、必要に応じて挿入または削除操作の後にエージェントによって自動的に調整されます。
This indexing scheme provides a mechanism to 'insert' an FTN entry between two existing entries already applied on an interface. This is done by specifying the entry after which a new entry should be inserted in mplsFTNMapPrevIndex.
このインデックス作成スキームは、インターフェイスに既に適用されている2つの既存のエントリ間にFTNエントリを「挿入」するメカニズムを提供します。これは、新しいエントリをmplsftnmapprevindexに挿入する必要があるエントリを指定することによって行われます。
Using this linked-list structure, one can retrieve FTN entries in the order of application on a per-interface basis as follows:
このリンクリスト構造を使用して、次のように、インターフェイスごとにアプリケーションの順にFTNエントリを取得できます。
- To determine the first FTN entry on an interface with index ifIndex, perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.0.0; the returned object, if one exists, is (say) mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus is the first accessible columnar object in the conceptual row). Then, the index of the first FTN entry applied on this interface is n.
- インデックスIfindexを使用したインターフェイスで最初のFTNエントリを決定するには、mplsftnmaprowstatus.ifindex.0.0でgetNext取得操作を実行します。返されたオブジェクトは、存在する場合、（たとえば）mplsftnmaprowstatus.ifindex.0.n（mplsftnmaprowstatusは、概念行の最初のアクセス可能な列オブジェクトです）です。次に、このインターフェイスに適用される最初のFTNエントリのインデックスはnです。
- To determine the FTN entry applied to an interface after the one indexed by n, perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.n.0. If such an entry exists, the returned object would be of the form mplsFTNMapRowStatus.ifIndex.n.m. Then, the index of the next FTN entry applied on this interface is m.
- nによってインデックス付けされた後にインターフェイスに適用されるFTNエントリを決定するには、mplsftnmaprowstatus.ifindex.n.0でgetNext取得操作を実行します。そのようなエントリが存在する場合、返されたオブジェクトはmplsftnmaprowstatus.ifindex.n.mの形式になります。次に、このインターフェイスに適用される次のFTNエントリのインデックスはmです。
- If the FTN entry indexed by n is the last entry applied to the interface with index ifIndex, then the object returned would either be:
- nによってインデックス付けされたFTNエントリがインデックスifindexを使用してインターフェイスに適用される最後のエントリである場合、返されるオブジェクトは次のとおりです。
1. mplsFTNMapRowStatus.ifIndexNext.0.k, where ifIndexNext is the index of the next interface in ifTable to which an FTN entry has been applied, in which case k is the index of the first FTN entry applied to the interface with index ifIndexNext;
1. mplsftnmaprowstatus.ifindexnext.0.k。ここで、ifindexNextはFTNエントリが適用されているiFTABLEの次のインターフェイスのインデックスです。
or:
または：
2. mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more entries in mplsFTNMapTable, where firstIfIndex is the first entry in ifTable to which an FTN entry has been mapped.
2. mplsftnmapstoragetype.firstifindex.0.p、mplsftnmaptableにこれ以上のエントリがない場合、FirstifindexはFTNエントリがマッピングされたIFTableの最初のエントリです。
The above steps can be used to retrieve all the applied entries on a per-interface basis in application order. Note that the number of retrieval operations is equal to the number of applied FTN entries (i.e., the minimum number of GETNEXT operations needed using any indexing scheme).
上記の手順を使用して、アプリケーションごとにすべての適用されたエントリをアプリケーションごとに取得できます。検索操作の数は、適用されたFTNエントリの数（つまり、任意のインデックス作成スキームを使用して必要なgetNext操作の最小数）に等しいことに注意してください。
Also note that we could not have created this linked-list structure using a 'next' pointer object instead of the 'previous' pointer object that we chose because this would not allow us to determine the first FTN entry that has been mapped to a specific interface using a single SNMP (non-bulk) retrieval operation.
また、このリンクリスト構造を作成して、特定の「以前の」ポインターオブジェクトの代わりに「次の」ポインターオブジェクトを使用して作成できなかったことに注意してください。単一のSNMP（非バルク）検索操作を使用したインターフェイス。
The use of this indexing structure is further illustrated using an example in Section 7.
このインデックス構造の使用は、セクション7の例を使用してさらに説明されています。
If an FTN entry has been applied to one or more interfaces, this table provides high-capacity performance counters to monitor each such FTN entry on a per-interface basis.
FTNエントリが1つ以上のインターフェイスに適用されている場合、このテーブルは、そのようなFTNエントリごとに各FTNエントリを監視するための大容量性能カウンターを提供します。
The problem of an ongoing traversal or retrieval operation on an SNMP table being affected by a concurrent modification operation on that table is not unique to this MIB module. However, it is useful to note that a cautious application can keep track of the state of the modifiable tables in this MIB module using the objects mplsFTNTableLastChanged and mplsFTNMapTableLastChanged.
そのテーブルの同時変更操作の影響を受けるSNMPテーブルでの進行中のトラバーサルまたは検索操作の問題は、このMIBモジュールに固有のものではありません。ただし、慎重なアプリケーションは、このMPLSFTNTNTABLELASTCHANGEDおよびMPLSFTNMAPTABLELASTCHANGEDを使用して、このMIBモジュールの変更可能なテーブルの状態を追跡できることに注意することで有用です。
For instance, before performing a traversal of mplsFTNMapTable, the application should retrieve the value of mplsFTNMapTableLastChanged. Each subsequent GETNEXT operation on the table should include this object as well. For example, GETNEXT(mplsFTNMapTableLastChanged.0, mplsFTNMapRowStatus.ifIndex.n.0) can be used to:
たとえば、mplsftnmaptableのトラバーサルを実行する前に、アプリケーションはmplsftnmaptableLelastChangedの値を取得する必要があります。テーブル上のその後の各getNext操作には、このオブジェクトも含める必要があります。たとえば、getnext（mplsftnmaptablelelastchanged.0、mplsftnmaprowstatus.ifindex.n.0）を使用できます。
- Determine the FTN entry after the one indexed by n (in linked-list order) mapped to the interface with index ifIndex, as explained in Section 5.2.2;
- セクション5.2.2で説明されているように、n（リンクリストの順序で）でインデックスがインデックスにマッピングされた後、n（リンクリスト順）でインデックス付けされた後にFTNエントリを決定します。
- Verify that the value of mplsFTNMapTable has not been modified during the retrieval process by comparing the value of mplsFTNMapTableLastChanged retrieved by this operation with the value retrieved before the traversal was begun.
- MPLSFTNMAPTABLEの値は、この操作によって取得されたMPLSFTNMMAPTABLELASTCHANGEDの値と、移動が開始される前に取得された値を取得することにより、検索プロセス中に変更されていないことを確認します。
Using this technique, an application can ensure the validity of the retrieved information with minimal overhead. This is particularly important while retrieving information from frequently modified tables.
この手法を使用すると、アプリケーションは、最小限のオーバーヘッドで取得した情報の有効性を確保できます。これは、頻繁に変更されるテーブルから情報を取得する際に特に重要です。
In this section, we use an example to illustrate how the objects defined in MPLS-FTN-STD-MIB work together to perform FEC to NHLFE mapping.
このセクションでは、例を使用して、MPLS-FTN-STD-MIBで定義されたオブジェクトが協力してFECからNHLFEマッピングを実行する方法を示します。
Note that for the various table entries involved in this example, we only show the objects that help illustrate each case.
この例に関係するさまざまなテーブルエントリについて、各ケースを説明するのに役立つオブジェクトのみを表示することに注意してください。
Suppose that we wish to activate the following two FTN rules.
次の2つのFTNルールをアクティブにしたいとします。
Rule #1: On interface ifIndex = 1, redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150 where the specified LSP is represented by the following entries in mplsXCTable and mplsOutSegmentTable.
ルール＃1：インターフェイスIFINDEX = 1で、ソースIPv4アドレスを一致させるパケットをリダイレクト192.0.2.63を発信するIFIndex = 50および発信ラベル= 150に一致します。
In mplsXCTable:
mplsxctableで：
{
mplsXCIndex = 0x02,
mplsXCInSegmentIndex = 0x00,
mplsXCOutSegmentIndex = 0x03,
mplsXCLabelStackIndex = 0
}
The value 0x00 for mplsXCInSegmentIndex represents an originating LSP [RFC3813].
mplsxcinsegmentindexの値0x00は、発生するLSP [RFC3813]を表します。
In mplsOutSegmentTable:
mplsoutsegmentTable：
{
mplsOutSegmentIndex = 0x03,
mplsOutSegmentIfIndex = 50,
mplsOutSegmentPushTopLabel = true,
mplsOutSegmentTopLabel = 150
}
Rule #2: On interface ifIndex = 1, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4, where the specified tunnel is represented by the following entry in mplsTunnelTable:
ルール＃2：インターフェイスifindex = 1で、範囲内の宛先IPv4アドレスを備えたパケットをリダイレクト[192.0.2.32、192.0.2.96]に＃4にリダイレクトします。ここで、指定されたトンネルはMplstunneltableの次のエントリで表されます。
{
mplsTunnelIndex = 4,
-- primary tunnel
mplsTunnelInstance = 0,
mplsTunnelIngressLSRID = 192.0.2.1,
mplsTunnelEgressLSRID = 192.0.2.2
}
The action "redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150" in Rule #1 can be implemented by the following entry in mplsFTNTable:
アクション「ソースIPv4アドレスでパケットをリダイレクトする192.0.2.63が発信IFINDEX = 50および発信ラベル= 150」を備えたLSPに一致します。
{
mplsFTNIndex = 1,
mplsFTNDescr = "Rule #1",
-- source address only
mplsFTNMask = 0x80,
mplsFTNAddrType = ipv4,
mplsFTNSourceAddrMin = 192.0.2.63,
mplsFTNSourceAddrMax = 192.0.2.63,
mplsFTNActionType = redirectLsp(1),
mplsFTNActionPointer = mplsXCLspId.1.2.1.0.1.3
}
This indicates to which LSP the LSR should redirect packets by setting mplsFTNActionPointer to the first accessible columnar object instance in mplsXCEntry that corresponds of the LSP to use, in this case mplsXCLspId.1.2.1.0.1.3.
これは、MPLSFTNACTIONPOINTERをMPLSXCLSPID.1.2.1.0.1.3に対応するMPLSFTNACTIONPOINTERにMPLSFTNACTIONPOINTERをMPLSXCENTRYの最初のアクセス可能な列オブジェクトインスタンスに設定することにより、LSPがパケットをリダイレクトするかを示しています。
This action is then activated on "interface ifIndex = 1" by the following entry in mplsFTNMapTable to complete the implementation of Rule #1:
このアクションは、ルール＃1の実装を完了するために、mplsftnmaptableの次のエントリによって「インターフェイスifindex = 1」でアクティブになります。
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- first FTN entry on this interface
mplsFTNPrevIndex = 0,
-- index of current entry in mplsFTNTable, i.e., Rule #1
mplsFTNMapCurrIndex = 1
}
The action "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4" in Rule #2 can be implemented by the following entry in mplsFTNTable:
アクション「範囲の宛先IPv4アドレスを使用してパケットをリダイレクト[192.0.2.32、192.0.2.96]からルール＃2のトンネル＃4へ」は、MPLSFTNTABLEの次のエントリによって実装できます。
{
mplsFTNIndex = 2,
mplsFTNDescr = "Rule #2",
-- destination address only
mplsFTNMask = 0x40,
mplsFTNAddrType = ipv4,
mplsFTNDestAddrMin = 192.0.2.32,
mplsFTNDestAddrMax = 192.0.2.96,
mplsFTNActionType = redirectTunnel(2),
mplsFTNActionPointer = mplsTunnelName.4.0.3221225985.3221225986
}
where 3221225985 and 3221225986 are representations of the addresses 192.0.2.1 and 192.0.2.2, respectively, as Unsigned32 (the underlying data type) entities.
3221225985および3221225986は、それぞれ192.0.2.1および192.0.2.2のアドレスの表現であり、unsigned32（基礎となるデータ型）エンティティとして。
This rule needs to be activated on "interface ifIndex = 1" after Rule #1 which was previously activated on this interface. This is done by the following entry in mplsFTNMapTable to complete the implementation of Rule #2:
このルールは、このインターフェイスで以前にアクティブ化されたルール＃1の後、「インターフェイスifindex = 1」でアクティブにする必要があります。これは、ルール＃2の実装を完了するために、mplsftnmaptableの次のエントリによって行われます。
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- insert after Rule #1 (mplsFTNIndex = 1)
mplsFTNPrevIndex = 1,
-- index of current entry in mplsFTNTable, i.e., Rule #2
mplsFTNMapCurrIndex = 2
}
Suppose we now wish to activate the following rule:
次のルールをアクティブにしたいとします。
Rule #2b: On interface ifIndex = 2, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4.
ルール＃2B：インターフェイスIFINDEX = 2で、範囲[192.0.2.32、192.0.2.96]の範囲内の宛先IPv4アドレスを持つパケットをリダイレクトします。
Notice that the FEC and corresponding action associated with this rule (i.e., "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4") are the same as that associated with Rule #2. Hence, we can reuse the existing entry with mplsFTNIndex = 2 from mplsFTNTable.
このルールに関連付けられたFECおよび対応するアクション（つまり、「192.0.2.32、192.0.2.96」からトンネル＃4 "への宛先IPv4アドレスを持つ「パケットをリダイレクト）は、ルール＃2に関連付けられたものと同じであることに注意してください。したがって、既存のエントリをMPLSFTNTABLEからMPLSFTNINDEX = 2で再利用できます。
However, we have to create the following new entry in mplsFTNMapTable to activate this FTN entry as the first one on the interface with ifIndex = 2.
ただし、MPLSFTNMAPTABLEで次の新しいエントリを作成して、このFTNエントリを有効にして、IFIndex = 2のインターフェイスの最初のエントリとしてアクティブ化する必要があります。
{
-- apply rule to interface ifIndex = 2
mplsFTNMapIndex = 2,
-- first FTN entry on this interface
mplsFTNPrevIndex = 0,
-- index of current entry in mplsFTNTable
mplsFTNMapCurrIndex = 2
}
At a later point, suppose that we wish to introduce the following Rule between Rules #1 and #2.
後の時点で、ルール＃1と＃2の間に次のルールを紹介したいとします。
Rule #3: On interface ifIndex = 1, redirect all packets with destination IPv4 address matching the prefix 192.0.2.32/28 to tunnel #3, where the tunnel we wish to redirect traffic to is represented by the following entry in mplsTunnelTable:
ルール＃3：インターフェイスifindex = 1で、すべてのパケットを宛先IPv4アドレスでリダイレクトして、プレフィックス192.0.2.32/28にトンネル＃3に一致します。
{
mplsTunnelIndex = 3,
-- primary tunnel
mplsTunnelInstance = 0,
mplsTunnelIngressLSRID = 192.0.2.3,
mplsTunnelEgressLSRID = 192.0.2.4
}
Note that the ordering of the rules on a particular interface is critical since the range of addresses specified in Rule #3 is a subset of the ones specified in Rule #2.
ルール＃3で指定されているアドレスの範囲は、ルール＃2で指定されたもののサブセットであるため、特定のインターフェイスでのルールの順序付けは重要であることに注意してください。
Without the linked-list style insertion feature supported by mplsFTNMapTable, we would possibly have had to reindex existing entries (or plan for such changes by leaving sufficient gaps between indexes, something that only postpones the problem). With the existing tables, we solve this problem by creating the following entries.
mplsftnmaptableによってサポートされているリンクリストスタイルの挿入機能がなければ、既存のエントリを再インドする必要があった可能性があります（または、問題を延期するだけのインデックス間で十分なギャップを残すことで、そのような変更を計画します）。既存のテーブルを使用すると、次のエントリを作成することでこの問題を解決します。
We implement the phrase "redirect all packets with destination IPv4 address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by creating the following entry in mplsFTNTable:
MPLSFTNTABLEで次のエントリを作成することにより、ルール＃3のプレフィックス1.4.0.0/16に一致する宛先IPv4アドレスですべてのパケットをリダイレクトするすべてのパケットを実装します。
{
mplsFTNIndex = 3,
mplsFTNDescr = "Rule #3",
-- destination address only
mplsFTNMask = 0x40,
mplsFTNAddrType = ipv4,
-- address range equivalent to CIDR prefix 192.0.2.32/28
mplsFTNDestAddrMin = 192.0.2.32,
mplsFTNDestAddrMax = 192.0.2.47,
mplsFTNActionType = redirectTunnel,
mplsFTNActionPointer = mplsTunnelName.3.0.3221225987.3221225988
}
where 3221225987 and 3221225988 are representations of the addresses 192.0.2.3 and 192.0.2.4, respectively, as Unsigned32 (the underlying data type) entities.
3221225987および3221225988は、それぞれ192.0.2.3および192.0.2.4のアドレスの表現であり、unsigned32（基礎となるデータ型）エンティティとして。
We next insert this rule in mplsFTNMapTable just after Rule #1 as follows:
次に、次のように、ルール＃1の直後にmplsftnmaptableにこのルールを挿入します。
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- insert after Rule #1 (mplsFTNIndex = 1)
mplsFTNPrevIndex = 1,
-- index of current entry in mplsFTNTable i.e., Rule #3
mplsFTNMapCurrIndex = 3
}
After the insertion of Rule #3 in mplsFTNMapTable, the 'previous' pointer object mplsFTNMapPrevIndex of the next entry (corresponding to Rule #2) adjusts automatically to point to this entry.
mplsftnmaptableにルール＃3を挿入した後、次のエントリ（ルール＃2に対応）の「以前の」ポインターオブジェクトmplsftnmapprevindexが自動的に調整してこのエントリを指すように調整します。
Note that, of the existing entries in the table, the only one that is impacted by an insertion operation is the entry on that particular interface immediately after the newly inserted one, if one exists. None of the other entries in mplsFTNMapTable are impacted. For instance, in this particular example, when the entry for Rule #3 was inserted between those for Rules #1 and #2, the entries for Rules #1 and #2b were not impacted.
テーブル内の既存のエントリのうち、挿入操作の影響を受ける唯一のエントリは、新しく挿入されたインターフェイスの直後にその特定のインターフェイスのエントリであることに注意してください。mplsftnmaptableの他のエントリはどれも影響を受けません。たとえば、この特定の例では、ルール＃3のエントリがルール＃1と＃2のエントリの間に挿入されたとき、ルール＃1と＃2Bのエントリは影響を受けませんでした。
At this point, the relationship between different table entries can be represented pictorially as follows. For each conceptual row instance, we show the table that it belongs to, along with its indices in parentheses. (Note that various conceptual rows are depicted in a way that is convenient for showing the interrelationships and are not necessarily in lexicographical order.)
この時点で、異なるテーブルエントリ間の関係は、次のように絵で表現できます。各概念の行インスタンスについて、括弧内のインデックスとともに、それが属するテーブルを示します。（さまざまな概念の行は、相互関係を示すのに便利であり、必ずしも辞書編集順にない方法で描かれていることに注意してください。）
ifTable, The Interfaces Group MIB [RFC2863]:
+-> ifEntry (1)
| (ifIndex = 1)
|
| mplsFTNMapTable:
| mplsFTNMapEntry (1.0.1): <--------------------+
+<-- (mplsFTNMapIndex = 1, |
| mplsFTNMapPrevIndex = 0, ---> (NULL) |
| mplsFTNMapCurrIndex = 1) ------------+ |
| | |
| mplsFTNMapEntry (1.1.3): <------------------+ |
+<-- (mplsFTNMapIndex = 1, | | |
| mplsFTNMapPrevIndex = 1, ----------->+ | |
| mplsFTNMapCurrIndex = 3) ---------+ | | |
| | | | |
| mplsFTNMapEntry (1.3.2): <----------------+ | |
+<-- (mplsFTNMapIndex = 1, | | | | |
mplsFTNMapPrevIndex = 3, -------->+ | | | |
mplsFTNMapCurrIndex = 2) ----+ | | | | |
| | | | | |
mplsFTNTable: | | | | | |
mplsFTNEntry (2): | | | | | |
+--> (mplsFTNIndex = 2) <----------+ | | | | |
| | | | | |
| mplsFTNEntry (3): | | | | |
| (mplsFTNIndex = 3) <---------------+ | | | |
| | | | |
| mplsFTNEntry (1): | | | |
| (mplsFTNIndex = 1) <------------------+ | | |
| | | |
| mplsFTNPerfTable: | | |
| mplsFTNPerfEntry (1.2): | | |
| (mplsFTNPerfIndex = 1, | | |
| mplsFTNPerfCurrIndex = 2) --------------+ | |
| | |
| mplsFTNPerfEntry (1.3): | |
| (mplsFTNPerfIndex = 1, | |
| mplsFTNPerfCurrIndex = 3) ---------------+ |
| |
| mplsFTNPerfEntry (1.1): |
| (mplsFTNPerfIndex = 1, |
| mplsFTNPerfCurrIndex = 1) ------------------+
|
| mplsFTNPerfEntry (2.2):
| (mplsFTNPerfIndex = 2,
| mplsFTNPerfCurrIndex = 2) ------------------+
| |
| ifTable, The Interfaces Group MIB [RFC2863]: |
+---> ifEntry (2): |
| | (ifIndex = 2) |
| | |
| | mplsFTNMapEntry (2.1.2): <--------------------+
+----- (mplsFTNMapIndex = 2
| mplsFTNMapPrevIndex = 0 ---> (NULL)
+---- mplsFTNMapCurrIndex = 2)
Let us next look at how we can remove the recently applied Rule #3 and how the existing conceptual rows behave in this situation.
次に、最近適用されたルール＃3を削除する方法と、この状況で既存の概念行がどのように振る舞うかを見てみましょう。
The conceptual row corresponding to the application of Rule #3 to interface ifIndex = 1 has the following index values: mplsFTNMapIndex = 1, mplsFTNMapPrevIndex = 1, and mplsFTNMapCurrIndex = 3. To delete this conceptual row, the Network Management Application performs a SET operation setting the object instance mplsFTNMapRowStatus.1.1.3 to the value destroy(6). The agent then destroys this conceptual row. It also automatically adjusts the object instance of mplsFTNMapPrevIndex corresponding to Rule #2 from the value 3 (i.e., pointing to the recently destroyed Rule #3) to the value 1 (i.e., to Rule #1).
ルール＃3のインターフェイスへのアプリケーションに対応する概念行は、次のインデックス値を持っています：mplsftnmapindex = 1、mplsftnmapprevindex = 1、およびmplsftnmapcurrindex = 3を削除するには、ネットワーク管理アプリケーションは設定された操作設定を実行するために、ネットワーク管理アプリケーションは設定設定設定を実行します。オブジェクトインスタンスmplsftnmaprowstatus.1.1.3から値破壊（6）。エージェントはこの概念的行を破壊します。また、値3（つまり、最近破壊されたルール＃3を指している）からルール＃2に対応するmplsftnmapprevindexのオブジェクトインスタンスを自動的に調整します（つまり、ルール＃1）。
At this point, the rules applied to interface ifIndex = 1 are Rule #1 and Rule #2, in that order. The relationship between different table entries can be represented pictorially as follows.
この時点で、Ifindex = 1インターフェイスに適用されるルールは、その順序でルール＃1およびルール＃2です。異なるテーブルエントリ間の関係は、次のように絵で表現できます。
ifTable, The Interfaces Group MIB [RFC2863]:
+-> ifEntry (1)
| (ifIndex = 1)
|
| mplsFTNMapTable:
| mplsFTNMapEntry (1.0.1): <--------------------+
+<-- (mplsFTNMapIndex = 1, |
| mplsFTNMapPrevIndex = 0, ---> (NULL) |
| mplsFTNMapCurrIndex = 1) ------------+ |
| | |
| mplsFTNMapEntry (1.1.2): <----------------+ |
+<-- (mplsFTNMapIndex = 1, | | |
mplsFTNMapPrevIndex = 1, ------------+ | |
mplsFTNMapCurrIndex = 2) ----+ | | |
| | | |
mplsFTNTable: | | | |
mplsFTNEntry (2): | | | |
+--> (mplsFTNIndex = 2) <----------+ | | |
| | | |
| mplsFTNEntry (3): | | |
| (mplsFTNIndex = 3) | | |
| | | |
| mplsFTNEntry (1): | | |
| (mplsFTNIndex = 1) <------------------+ | |
| | |
| mplsFTNPerfTable: | |
| mplsFTNPerfEntry (1.2): | |
| (mplsFTNPerfIndex = 1, | |
| mplsFTNPerfCurrIndex = 2) --------------+ |
| |
| mplsFTNPerfEntry (1.1): |
| (mplsFTNPerfIndex = 1, |
| mplsFTNPerfCurrIndex = 1) ------------------+
|
| mplsFTNPerfEntry (2.2):
| (mplsFTNPerfIndex = 2,
| mplsFTNPerfCurrIndex = 2) ------------------+
| |
| ifTable, The Interfaces Group MIB [RFC2863]: |
+---> ifEntry (2): |
| | (ifIndex = 2) |
| | |
| | mplsFTNMapEntry (2.1.2): <--------------------+
+----- (mplsFTNMapIndex = 2
| mplsFTNMapPrevIndex = 0 ---> (NULL)
+---- mplsFTNMapCurrIndex = 2)
Note that the FTN entry for Rule #3 still exists in mplsFTNTable at this point but is not referenced by any conceptual row in mplsFTNMapTable or mplsFTNPerfTable.
ルール＃3のFTNエントリは、この時点でMPLSFTNTABLEに存在するが、MPLSFTNMAPTABLEまたはMPLSFTNPERFTABLEのいかなる概念行でも参照されていないことに注意してください。
Also note that the deletion of an entry from mplsFTNMapTable only impacts the entry on that particular interface immediately after the deleted entry, if one exists. None of the other conceptual rows in mplsFTNMapTable are impacted. For instance, in this particular example, when the entry for Rule #3 was deleted, the entries for Rules #1 and #2b were not impacted.
また、mplsftnmaptableからのエントリの削除は、削除されたエントリの直後にその特定のインターフェイスのエントリにのみ影響を与えることに注意してください。mplsftnmaptableの他の概念的行はどれも影響を受けません。たとえば、この特定の例では、ルール＃3のエントリが削除されたとき、ルール＃1と＃2Bのエントリは影響を受けませんでした。
RowPointer is a textual convention used to identify a conceptual row in a conceptual table in a MIB by pointing to the first accessible object. In this MIB module, in mplsFTNTable, the RowPointer object mplsFTNActionPointer indicates the LSP or TE Tunnel to redirect packets matching an FTN entry to. This object MUST point to the first instance of the first accessible columnar object in the appropriate conceptual row in order to allow the manager to find the appropriate corresponding entry in either MPLS-LSR-STD-MIB [RFC3813] or MPLS-TE-STD-MIB [RFC3812]. If this object returns zeroDotZerok, it implies that there is no currently defined action that is associated with that particular FTN entry.
Rowpointerは、最初のアクセス可能なオブジェクトを指すことにより、MIBの概念テーブルの概念的行を識別するために使用されるテキスト慣習です。このMIBモジュールでは、mplsftntableでは、rowpointerオブジェクトmplsftnactionpointerがLSPまたはTEトンネルを示し、FTNエントリに一致するパケットをリダイレクトします。このオブジェクトは、マネージャーがMPLS-LSR-STD-MIB [RFC3813]またはMPLS-TE-STD-のいずれかで適切な対応するエントリを見つけることができるように、適切な概念行の最初のアクセス可能な列オブジェクトの最初のインスタンスを指す必要があります。MIB [RFC3812]。このオブジェクトがZerodotzerokを返す場合、その特定のFTNエントリに関連付けられている現在の定義されたアクションがないことを意味します。
MPLS-FTN-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32
FROM SNMPv2-SMI -- [RFC2578]
RowStatus, StorageType, RowPointer,
TEXTUAL-CONVENTION, TimeStamp
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
InterfaceIndexOrZero,
ifGeneralInformationGroup, ifCounterDiscontinuityGroup
FROM IF-MIB -- [RFC2863]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
Dscp
FROM DIFFSERV-DSCP-TC -- [RFC3289]
InetAddressType, InetAddress, InetPortNumber
FROM INET-ADDRESS-MIB -- [RFC3291]
mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811]
;
;
mplsFTNStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 6, 2004 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Thomas D. Nadeau Postal: Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Tel: +1-978-244-3051 Email: tnadeau@cisco.com
mplsftnstdmib module-Identity last-updated "200406030000z" - 2004年6月6日組織 "マルチプロトコルラベルスイッチング（MPLS）ワーキンググループ" Contact-info "Thomas D. Nadeau Postal：Cisco Systems Inc. 250 Apollo Drive Chelmsford、MA 01824 Tel：1-978-244-3051メール：tnadeau@cisco.com
Cheenu Srinivasan Postal: Bloomberg L.P. 499 Park Avenue New York, NY 10022 Tel: +1-212-893-3682 Email: cheenu@bloomberg.net
Cheenu Srinivasan Postal：Bloomberg L.P. 499 Park Avenue New York、NY 10022 Tel：1-212-893-3682メール：cheenu@bloomberg.net
Arun Viswanathan Postal: Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Tel: +1-408-571-3516 Email: arunv@force10networks.com
Arun Viswanathan Postal：Force10 Networks、Inc。1440 McCarthy Blvd Milpitas、CA 95035 Tel：1-408-571-3516メール：arunv@force10networks.com
IETF MPLS Working Group email: mpls@uu.net"
IETF MPLSワーキンググループメール：mpls@uu.net "
DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3814. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html
説明 "Copyright（c）The Internet Society（2004）。このMIBモジュールの初期バージョンはRFC 3814に掲載されました。完全な法的通知については、RFC自体を参照するか、http：//www.ietf.org/copyrights/ianamibib.html
This MIB module contains managed object definitions for specifying FEC to NHLFE (FTN) mappings and corresponding performance for MPLS."
このMIBモジュールには、FECからNHLFE（FTN）マッピングとMPLSの対応するパフォーマンスを指定するための管理されたオブジェクト定義が含まれています。」
-- Revision history.
- 改訂履歴。
REVISION "200406030000Z" -- June 3, 2004
リビジョン「200406030000Z」 - 2004年6月3日
DESCRIPTION "Initial version issued as part of RFC 3814."
説明「RFC 3814の一部として発行された初期バージョン。」
::= { mplsStdMIB 8 }
-- TEXTUAL-CONVENTIONs used in this MIB.
MplsFTNEntryIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an entry in mplsFTNTable."
SYNTAX Unsigned32 (1..4294967295)
MplsFTNEntryIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an entry in mplsFTNTable or the special value
zero. The value zero is object-specific and must
therefore be defined as part of the description of any
object which uses this syntax. Examples of the usage
of zero might include situations when none or all
entries in mplsFTNTable need to be referenced."
SYNTAX Unsigned32 (0..4294967295)
-- Top-Level Components of this MIB.
- このMIBのトップレベルコンポーネント。
mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNStdMIB 0 }
mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNStdMIB 1 }
mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNStdMIB 2 }
-- Next free index in mplsFTNTable.
mplsFTNIndexNext OBJECT-TYPE
SYNTAX MplsFTNEntryIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next available valid value to
be used for mplsFTNIndex when creating entries in the
mplsFTNTable.
When creating a new conceptual row (configuration entry) in mplsFTNTable with an SNMP SET operation the command generator (Network Management Application) must first issue a management protocol retrieval operation to obtain the current value of this object.
SNMPセット操作を使用してMPLSFTNTABLEで新しい概念行（構成エントリ）を作成する場合、コマンドジェネレーター（ネットワーク管理アプリケーション）は、まずこのオブジェクトの現在の値を取得するための管理プロトコル検索操作を発行する必要があります。
If the command responder (agent) does not wish to allow creation of more entries in mplsFTNTable, possibly because of resource exhaustion, this object MUST return a value of 0.
コマンドレスポンダー（エージェント）が、おそらくリソースの使い果たしのために、MPLSFTNTABLEでより多くのエントリの作成を許可したくない場合、このオブジェクトは0の値を返す必要があります。
If a non-zero value is returned the Network Management Application must determine whether the value is indeed still unused since two Network Management Applications may attempt to create a row simultaneously and use the same value.
ゼロ以外の値が返される場合、ネットワーク管理アプリケーションは、2つのネットワーク管理アプリケーションが同時に行を作成して同じ値を使用しようとする可能性があるため、値が実際にまだ使用されていないかどうかを判断する必要があります。
If it is currently unused and the SET succeeds, the agent MUST change the value of this object to a currently unused non-zero value (according to an implementation specific algorithm) or zero (if no further row creation will be permitted).
現在使用されていない場合、セットが成功した場合、エージェントはこのオブジェクトの値を現在使用されていない非ゼロ値（実装固有のアルゴリズムに従って）またはゼロ（それ以上行の作成が許可されない場合）に変更する必要があります。
If the value is in use, however, the SET fails and the
Network Management Application must then reread this
object to obtain a new usable value."
::= { mplsFTNObjects 1 }
-- Last time an object in mplsFTNTable changed.
mplsFTNTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the last time an entry was added, deleted or
modified in mplsFTNTable. Management stations should
consult this object to determine if mplsFTNTable
requires their attention. This object is particularly
useful for applications performing a retrieval on
mplsFTNTable to ensure that the table is not modified
during the retrieval operation."
::= { mplsFTNObjects 2 }
-- Table of FTN entries.
mplsFTNTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the currently defined FTN entries.
This table allows FEC to NHLFE mappings to be
specified. Each entry in this table defines a rule to
be applied to incoming packets (on interfaces that the
FTN entry is activated on using mplsFTNMapTable) and an
action to be taken on matching packets
(mplsFTNActionPointer).
This table supports 6-tuple matching rules based on one or more of source address range, destination address range, source port range, destination port range, IPv4 Protocol field or IPv6 next-header field and the DiffServ Code Point (DSCP) to be specified.
このテーブルは、1つ以上のソースアドレス範囲、宛先アドレス範囲、ソースポート範囲、宛先ポート範囲、IPv4プロトコルフィールドまたはIPv6次元フィールド、および指定するDiffservコードポイント（DSCP）に基づく6タプルマッチングルールをサポートしています。。
The action pointer points either to instance of mplsXCEntry in MPLS-LSR-STD-MIB when the NHLFE is a non-TE LSP, or to an instance of mplsTunnelEntry in the MPLS-TE-STD-MIB when the NHLFE is an originating TE tunnel." REFERENCE "J. Postel, Internet Protocol, RFC 791, STD 5, September 1981
アクションポインターは、NHLFEが非TTE LSPである場合のMPLS-LSR-STD-MIBのMPLSXCentryのインスタンス、またはNHLFEが起源のTEトンネルであるMPLS-TE-STD-MIBのMPLSTUNNELENTRYのインスタンスのいずれかを指します。 "参照" J.Postel、Internet Protocol、RFC 791、STD 5、1981年9月
Deering, S., and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998
ディアリング、S。、およびR.ヒンデン、インターネットプロトコル、バージョン6（IPv6）仕様、RFC 2460、1998年12月
Nichols, K, Blake, S., Baker, F. and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998
Nichols、K、Blake、S.、Baker、F。and D. Black、IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義、RFC 2474、1998年12月
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS Label Switch Router Management Information Base, RFC 3813
Srinivasan、C.、A。Viswanathan、およびT. Nadeau、MPLSラベルスイッチルーター管理情報ベース、RFC 3813
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
Traffic Engineering Management Information Base,
RFC 3812"
::= { mplsFTNObjects 3 }
mplsFTNEntry OBJECT-TYPE
SYNTAX MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents one FTN entry which defines a
rule to compare incoming packets with and an action to
be taken on matching packets."
INDEX { mplsFTNIndex }
::= { mplsFTNTable 1 }
MplsFTNEntry ::= SEQUENCE {
mplsFTNIndex MplsFTNEntryIndex,
mplsFTNRowStatus RowStatus,
mplsFTNDescr SnmpAdminString,
mplsFTNMask BITS,
mplsFTNAddrType InetAddressType,
mplsFTNSourceAddrMin InetAddress,
mplsFTNSourceAddrMax InetAddress,
mplsFTNDestAddrMin InetAddress,
mplsFTNDestAddrMax InetAddress,
mplsFTNSourcePortMin InetPortNumber,
mplsFTNSourcePortMax InetPortNumber,
mplsFTNDestPortMin InetPortNumber,
mplsFTNDestPortMax InetPortNumber,
mplsFTNProtocol Integer32,
mplsFTNDscp Dscp,
mplsFTNActionType INTEGER,
mplsFTNActionPointer RowPointer,
mplsFTNStorageType StorageType
}
mplsFTNIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is the unique index for a conceptual row in
mplsFTNTable.
To create a new conceptual row in mplsFTNTable a
Network Management Application SHOULD retrieve the
current value of mplsFTNIndexNext to determine the next
valid available value of mplsFTNIndex."
::= { mplsFTNEntry 1 }
mplsFTNRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used for controlling the creation and deletion of this
row. All writeable objects in this row may be modified
at any time. If a Network Management Application
attempts to delete a conceptual row by setting this
object to 'destroy' and there are one or more entries
in mplsFTNMapTable pointing to the row (i.e., when
mplsFTNIndex of the conceptual row being deleted is
equal to mplsFTNMapCurrIndex for one or more entries in
mplsFTNMapTable), the agent MUST also destroy the
corresponding entries in mplsFTNMapTable."
::= { mplsFTNEntry 2 }
mplsFTNDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The description of this FTN entry. Since the index for
this table has no particular significance or meaning,
this object should contain some meaningful text that an
operator could use to further distinguish entries in
this table."
::= { mplsFTNEntry 3 }
mplsFTNMask OBJECT-TYPE
SYNTAX BITS {
sourceAddr(0),
destAddr(1),
sourcePort(2),
destPort(3),
protocol(4),
dscp(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This bit map indicates which of the fields described
next, namely source address range, destination address
range, source port range, destination port range, IPv4
Protocol field or IPv6 next-header field and
Differentiated Services Code Point (DSCP) is active for
this FTN entry. If a particular bit is set to zero then
the corresponding field in the packet MUST be ignored
for comparison purposes."
::= { mplsFTNEntry 4 }
mplsFTNAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object determines the type of address contained in
the source and destination address objects
(mplsFTNSourceAddrMin, mplsFTNSourceAddrMax,
mplsFTNDestAddrMin and mplsFTNDestAddrMax) of a
conceptual row.
This object MUST NOT be set to unknown(0) when mplsFTNMask has bit positions sourceAddr(0) or destAddr(1) set to one.
mplsftnmaskがビット位置を持っている場合、このオブジェクトは不明（0）に設定してはなりません。
When both these bit positions of mplsFTNMask are set to
zero the value of mplsFTNAddrType SHOULD be set to
unknown(0) and the corresponding source and destination
address objects SHOULD be set to zero-length strings."
::= { mplsFTNEntry 5 }
mplsFTNSourceAddrMin OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the source address range. The type of
this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 6 }
mplsFTNSourceAddrMax OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of the source address range. The type of
this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 7 }
mplsFTNDestAddrMin OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination address range. The
type of this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 8 }
mplsFTNDestAddrMax OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination address range. The
type of this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 9 }
mplsFTNSourcePortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the source port range."
DEFVAL { 0 }
::= { mplsFTNEntry 10 }
mplsFTNSourcePortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the source port range "
DEFVAL { 65535 }
::= { mplsFTNEntry 11 }
mplsFTNDestPortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination port range."
DEFVAL { 0 }
::= { mplsFTNEntry 12 }
mplsFTNDestPortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination port range."
DEFVAL { 65535 }
::= { mplsFTNEntry 13 }
mplsFTNProtocol OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP protocol to match against the IPv4 protocol
number or IPv6 Next-Header number in the packet. A
value of 255 means match all. Note that the protocol
number of 255 is reserved by IANA, and Next-Header
number of 0 is used in IPv6."
DEFVAL { 255 }
::= { mplsFTNEntry 14 }
mplsFTNDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contents of the DSCP field."
REFERENCE
"Nichols, K., Blake, S., Baker, F. and D. Black,
Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers, RFC 2474, December
1998."
::= { mplsFTNEntry 15 }
mplsFTNActionType OBJECT-TYPE
SYNTAX INTEGER {
redirectLsp(1), -- redirect into LSP
redirectTunnel(2) -- redirect into tunnel
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of action to be taken on packets matching this
FTN entry."
::= { mplsFTNEntry 16 }
mplsFTNActionPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If mplsFTNActionType is redirectLsp(1), then this
object MUST contain zeroDotZero or point to a instance
of mplsXCEntry indicating the LSP to redirect matching
packets to.
If mplsFTNActionType is redirectTunnel(2), then this object MUST contain zeroDotZero or point to a instance of mplsTunnelEntry indicating the MPLS TE tunnel to redirect matching packets to.
mplsftnactiontypeがリダイレクトンネル（2）の場合、このオブジェクトはゼロドッツロを含めるか、mplstunnelentryのインスタンスを指している必要があります。
If this object points to a conceptual row instance in a table consistent with mplsFTNActionType but this instance does not currently exist then no action will be taken on packets matching such an FTN entry till this instance comes into existence.
このオブジェクトは、mplsftnactionTypeと一致するテーブルの概念的行のインスタンスを指しているが、このインスタンスは現在存在しない場合、このインスタンスが存在するまでそのようなFTNエントリに一致するパケットにはアクションは取られません。
If this object contains zeroDotZero then no action will
be taken on packets matching such an FTN entry till it
is populated with a valid pointer consistent with the
value of mplsFTNActionType as explained above."
::= { mplsFTNEntry 17 }
mplsFTNStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this FTN entry. Conceptual rows
having the value 'permanent' need not allow write-
access to any columnar objects in the row."
DEFVAL { nonVolatile }
::= { mplsFTNEntry 18 }
-- End of mplsFTNTable.
- mplsftntableの終わり。
-- Last time an object in mplsFTNMapTable changed.
- 前回、mplsftnmaptableのオブジェクトが変更されました。
mplsFTNMapTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the last time an entry was added, deleted or
modified in mplsFTNMapTable. Management stations should
consult this object to determine if the table requires
their attention. This object is particularly useful
for applications performing a retrieval on
mplsFTNMapTable to ensure that the table is not
modified during the retrieval operation."
::= { mplsFTNObjects 4 }
-- FTN to interface mapping table.
-FTNからインターフェイスマッピングテーブルへ。
mplsFTNMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains objects which provide the
capability to apply or map FTN rules as defined by
entries in mplsFTNTable to specific interfaces in the
system. FTN rules are compared with incoming packets
in the order in which they are applied on an interface.
The indexing structure of mplsFTNMapTable is as follows.
mplsftnmaptableのインデックス構造は次のとおりです。
- mplsFTNMapIndex indicates the interface to which the rule is being applied. A value of 0 represents the application of the rule to all interfaces.
- mplsftnmapindexは、ルールが適用されているインターフェイスを示します。値は、すべてのインターフェイスへのルールの適用を表します。
- mplsFTNMapPrevIndex specifies the rule on the interface prior to the one being applied. A value of 0 specifies that the rule is being inserted at the head of the list of rules currently applied to the interface.
- mplsftnmapprevindexが適用される前に、インターフェイスのルールを指定します。0の値は、現在インターフェイスに適用されているルールのリストのヘッドにルールが挿入されていることを指定します。
- mplsFTNMapCurrIndex is the index in mplsFTNTable corresponding to the rule being applied.
- mplsftnmapcurrindexは、適用されるルールに対応するmplsftntableのインデックスです。
This indexing structure makes the entries in the table behave like items in a linked-list. The object mplsFTNMapPrevIndex in each conceptual row is a pointer to the previous entry that is applied to a particular interface. This allows a new entry to be 'inserted' at an arbitrary position in a list of entries currently applied to an interface. This object is self-adjusting, i.e., its value is automatically adjusted by the agent, if necessary, after an insertion or deletion operation.
このインデックス構造により、テーブル内のエントリはリンクリストのアイテムのように動作します。各概念行のオブジェクトmplsftnmapprevindexは、特定のインターフェイスに適用される前のエントリへのポインターです。これにより、現在インターフェイスに適用されているエントリのリストで、新しいエントリを任意の位置に「挿入」することができます。このオブジェクトは自己調整です。つまり、その値は、必要に応じて挿入または削除操作の後にエージェントによって自動的に調整されます。
Using this linked-list structure, one can retrieve FTN entries in the order of application on a per-interface basis as follows:
このリンクリスト構造を使用して、次のように、インターフェイスごとにアプリケーションの順にFTNエントリを取得できます。
- To determine the first FTN entry on an interface with index ifIndex perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.0.0; the returned object, if one exists, is (say) mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus is the first accessible columnar object in the conceptual row). Then the index of the first FTN entry applied on this interface is n.
- インデックス付きインターフェイスで最初のFTNエントリを決定するには、mplsftnmaprowstatus.ifindex.0.0でgetNext取得操作を実行します。返されたオブジェクトは、存在する場合、（たとえば）mplsftnmaprowstatus.ifindex.0.n（mplsftnmaprowstatusは、概念行の最初のアクセス可能な列オブジェクトです）です。次に、このインターフェイスに適用される最初のFTNエントリのインデックスはnです。
- To determine the FTN entry applied to an interface after the one indexed by n perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.n.0. If such an entry exists the returned object would be of the form mplsFTNMapRowStatus.ifIndex.n.m. Then the index of the next FTN entry applied on this interface is m.
- nによってインデックス付けされたものがmplsftnmaprowstatus.ifindex.n.0でgetNext取得操作を実行した後、インターフェイスに適用されるFTNエントリを決定するため。そのようなエントリが存在する場合、返されたオブジェクトはmplsftnmaprowstatus.ifindex.n.mの形式になります。次に、このインターフェイスに適用される次のFTNエントリのインデックスはmです。
- If the FTN entry indexed by n is the last entry applied to the interface with index ifIndex then the object returned would either be:
- nによってインデックス付けされたFTNエントリがインデックスifindexを使用してインターフェイスに適用される最後のエントリである場合、返されるオブジェクトは次のとおりです。
1.mplsFTNMapRowStatus.ifIndexNext.0.k, where ifIndexNext is the index of the next interface in ifTable to which an FTN entry has been applied, in which case k is the index of the first FTN entry applied to the interface with index ifIndexNext;
1.mplsftnmaprowstatus.ifindexnext.0.k。ここで、ifindexNextはFTNエントリが適用されているiFTABLEの次のインターフェイスのインデックスです。
or:
または：
2.mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more entries in mplsFTNMapTable, where firstIfIndex is the first entry in ifTable to which an FTN entry has been mapped.
2.mplsftnmapstoragetype.firstifindex.0.p、Mplsftnmaptableにこれ以上のエントリがない場合、FirstIfindexはFTNエントリがマッピングされたIFTableの最初のエントリです。
Use the above steps to retrieve all the applied FTN entries on a per-interface basis in application order. Note that the number of retrieval operations is the same as the number of applied FTN entries (i.e., the minimum number of GETNEXT operations needed using any indexing scheme).
上記の手順を使用して、アプリケーションごとに適用されたすべてのFTNエントリをアプリケーションごとに取得します。検索操作の数は、適用されたFTNエントリの数（つまり、インデックス作成スキームを使用して必要なgetNext操作の最小数）と同じであることに注意してください。
Agents MUST NOT allow the same FTN entry as specified by mplsFTNMapCurrIndex to be applied multiple times to the same interface.
エージェントは、MPLSFTNMAPCURRINDEXによって指定された同じFTNエントリを同じインターフェイスに複数回適用することを許可してはなりません。
Agents MUST NOT allow the creation of rows in this table until the corresponding rows are created in the mplsFTNTable.
エージェントは、対応する行がmplsftntableで作成されるまで、このテーブルで行の作成を許可してはなりません。
If a row in mplsFTNTable is destroyed, the agent MUST
destroy the corresponding entries (i.e., ones with a
matching value of mplsFTNCurrIndex) in this table as
well."
::= { mplsFTNObjects 5 }
mplsFTNMapEntry OBJECT-TYPE
SYNTAX MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each conceptual row represents the application of an
FTN rule at a specific position in the list of FTN
rules applied on an interface. "
INDEX {
mplsFTNMapIndex,
mplsFTNMapPrevIndex,
mplsFTNMapCurrIndex
}
::= { mplsFTNMapTable 1 }
MplsFTNMapEntry ::= SEQUENCE {
mplsFTNMapIndex InterfaceIndexOrZero, mplsFTNMapPrevIndex MplsFTNEntryIndexOrZero, mplsFTNMapCurrIndex MplsFTNEntryIndex, mplsFTNMapRowStatus RowStatus, mplsFTNMapStorageType StorageType }
mplsftnmapindex interfaceindexorzero、mplsftnmapprevindex mplsftnentryindexorzero、mplsftnmapcurrindex mplsftnentryindex、mplsftnmaprowstatus rowstatus、mplsftnmapstoragetype storagetype}
mplsFTNMapIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The interface index that this FTN entry is being
applied to. A value of zero indicates an entry that is
applied all interfaces.
Entries mapped to an interface by specifying its (non-
zero) interface index in mplsFTNMapIndex are applied
ahead of entries with mplsFTNMapIndex equal to zero."
::= { mplsFTNMapEntry 1 }
mplsFTNMapPrevIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of the previous FTN entry that was applied to
this interface. The special value zero indicates that
this should be the first FTN entry in the list."
::= { mplsFTNMapEntry 2 }
mplsFTNMapCurrIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of the current FTN entry that is being applied to
this interface."
::= { mplsFTNMapEntry 3 }
mplsFTNMapRowStatus OBJECT-TYPE
SYNTAX RowStatus {
active(1),
createAndGo(4),
destroy(6)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used for controlling the creation and deletion of this
row.
All writable objects in this row may be modified at any time.
この行のすべての書き込みオブジェクトは、いつでも変更できます。
If a conceptual row in mplsFTNMapTable points to a
conceptual row in mplsFTNTable which is subsequently
deleted, the corresponding conceptual row in
mplsFTNMapTable MUST also be deleted by the agent."
::= { mplsFTNMapEntry 4 }
mplsFTNMapStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this entry. Conceptual rows
having the value 'permanent' need not allow write-
access to any columnar objects in this row."
DEFVAL { nonVolatile }
::= { mplsFTNMapEntry 5 }
-- End of mplsFTNMapTable
-mplsftnmaptableの終わり
-- FTN entry performance table
-FTNエントリパフォーマンステーブル
mplsFTNPerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains performance statistics on FTN
entries on a per-interface basis."
::= { mplsFTNObjects 6 }
mplsFTNPerfEntry OBJECT-TYPE
SYNTAX MplsFTNPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains performance information for the
specified interface and an FTN entry mapped to this
interface."
INDEX { mplsFTNPerfIndex, mplsFTNPerfCurrIndex }
::= { mplsFTNPerfTable 1 }
MplsFTNPerfEntry ::= SEQUENCE {
mplsFTNPerfIndex InterfaceIndexOrZero,
mplsFTNPerfCurrIndex MplsFTNEntryIndex,
mplsFTNPerfMatchedPackets Counter64,
mplsFTNPerfMatchedOctets Counter64,
mplsFTNPerfDiscontinuityTime TimeStamp
}
mplsFTNPerfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The interface index of an interface that an FTN entry
has been applied/mapped to. Each instance of this
object corresponds to an instance of mplsFTNMapIndex."
::= { mplsFTNPerfEntry 1 }
mplsFTNPerfCurrIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of an FTN entry that has been applied/mapped to
the specified interface. Each instance of this object
corresponds to an instance of mplsFTNMapCurrIndex."
::= { mplsFTNPerfEntry 2 }
mplsFTNPerfMatchedPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of packets that matched the specified FTN entry
if it is applied/mapped to the specified interface.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
mplsFTNDiscontinuityTime."
::= { mplsFTNPerfEntry 3 }
mplsFTNPerfMatchedOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of octets that matched the specified FTN entry
if it is applied/mapped to the specified interface.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
mplsFTNDiscontinuityTime."
::= { mplsFTNPerfEntry 4 }
mplsFTNPerfDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which any one or more of this entry's counters suffered
a discontinuity. If no such discontinuities have
occurred since the last re-initialization of the local
management subsystem, then this object contains a zero
value."
::= { mplsFTNPerfEntry 5 }
-- End of mplsFTNPerfTable
-mplsftnperftableの終了
-- Module compliance.
- モジュールコンプライアンス。
-- Top level object IDs.
- トップレベルオブジェクトID。
mplsFTNGroups
OBJECT IDENTIFIER ::= { mplsFTNConformance 1 }
mplsFTNCompliances
OBJECT IDENTIFIER ::= { mplsFTNConformance 2 }
-- Compliance requirement for fully compliant implementations. mplsFTNModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-FTN-STD-MIB."
- 完全に準拠した実装のコンプライアンス要件。mplsftnmodulefullcomplianceモジュールコンプライアンスステータス現在の説明「MPLS-FTN-STD-MIBの完全なサポートを提供するエージェントのコンプライアンスステートメント」。
MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
MODULE -- This module. MANDATORY-GROUPS { mplsFTNRuleGroup, mplsFTNMapGroup, mplsFTNPerfGroup
モジュール - このモジュール。Anctoration-Groups {mplsftnrulegroup、mplsftnmapgroup、mplsftnperfgroup
}
}
OBJECT mplsFTNAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR."
オブジェクトmplsftnaddrtype syntax inetaddresstype {ipv4（1）、ipv6（2）}説明「実装は、IPv4および/またはIPv6アドレスをサポートするためにのみ必要です。実装は、LSRで実際にサポートされているアドレスタイプをサポートするためにのみ必要です。」
OBJECT mplsFTNSourceAddrMin SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR."
オブジェクトmplsftnsourceaddrmin構文inetAddress（サイズ（4 | 20））説明「実装は、IPv4および/またはIPv6アドレスをサポートするためにのみ必要です。実際にLSRでサポートされているアドレスタイプをサポートするために実装は必要です。」
OBJECT mplsFTNSourceAddrMax SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR."
オブジェクトmplsftnsourceaddrmax intaddress（size（4 | 20））説明「実装は、IPv4および/またはIPv6アドレスをサポートするためにのみ必要です。実装は、実際にLSRでサポートされているアドレスタイプをサポートするためにのみ必要です。」
OBJECT mplsFTNDestAddrMin SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR."
オブジェクトmplsftndestaddrmin構文inetAddress（サイズ（4 | 20））説明「実装は、IPv4および/またはIPv6アドレスをサポートするためにのみ必要です。実際にLSRでサポートされているアドレスタイプをサポートするために実装は必要です。」
OBJECT mplsFTNDestAddrMax
SYNTAX InetAddress (SIZE (4 | 20))
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
::= { mplsFTNCompliances 1 }
-- Compliance requirement for read-only implementations. mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only
- 読み取り専用の実装のコンプライアンス要件。mplsftnmodulereadonlycomplianceモジュールコンプライアンスステータス現在の説明 "実装のみのコンプライアンス要件
provide read-only support for MPLS-FTN-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module."
MPLS-FTN-STD-MIBの読み取り専用サポートを提供します。そのようなデバイスは監視できますが、このMIBモジュールを使用して構成することはできません。」
MODULE IF-MIB -- The interfaces Group MIB, RFC 2863
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
MODULE -- This module
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup,
mplsFTNPerfGroup
}
OBJECT mplsFTNIndexNext MIN-ACCESS not-accessible DESCRIPTION "This object is not needed when mplsFTNTable is implemented as read-only."
オブジェクトmplsftnindexnext min-accessアクセス不可能な説明
OBJECT mplsFTNRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported."
Object Mplsftnrowstatus Syntax RowStatus {Active（1）} Min-Access読み取り専用説明「書き込みアクセスは不要であり、Activeはサポートする必要がある唯一のステータスです。」
OBJECT mplsFTNDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required."
Object mplsftndescr min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNMask MIN-ACCESS read-only DESCRIPTION "Write access is not required."
Object mplsftnmask min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses."
Object Mplsftnaddrtype Syntax InetAddressType {IPv4（1）、IPv6（2）}最小アクセス読み取り専用説明 "書き込みアクセスは不要です。実装はIPv4およびIPv6アドレスをサポートするためにのみ必要です。」
OBJECT mplsFTNSourceAddrMin SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses."
オブジェクトmplsftnsourceaddrmin構文inetaddress（size（4 | 20））min-access read-only description "書き込みアクセスは必要ありません。実装はIPv4およびIPv6アドレスをサポートするためにのみ必要です。」
OBJECT mplsFTNSourceAddrMax SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses."
オブジェクトmplsftnsourceaddrmax構文inetaddress（size（4 | 20））min-access読み取り専用説明「書き込みアクセスは必要ありません。実装はIPv4およびIPv6アドレスをサポートするためにのみ必要です。」
OBJECT mplsFTNDestAddrMin SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses."
オブジェクトmplsftndestaddrmin構文inetAddress（size（4 | 20））min-access読み取り専用説明「書き込みアクセスは不要です。IPv4およびIPv6アドレスをサポートするためにのみ実装が必要です。」
OBJECT mplsFTNDestAddrMax SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses."
オブジェクトmplsftndestaddrmax構文inetAddress（size（4 | 20））min-access読み取り専用説明「書き込みアクセスは必要ありません。実装はIPv4およびIPv6アドレスをサポートするためにのみ必要です。」
OBJECT mplsFTNSourcePortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftnsourceportmin min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNSourcePortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftnsourceportmax min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNDestPortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftndestminmin min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNDestPortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftndestportmax min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required."
Object Mplsftnprotocol min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNActionType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
Object MplsftNactionType Min-Access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNActionPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftnactionpointer min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNDscp MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftndscp min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトmplsftnstorageType min-access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT mplsFTNMapRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported."
オブジェクトmplsftnmaprowstatus構文rowStatus {active（1）} min-access read-only description "書き込みアクセスは不要であり、アクティブ（1）はサポートする必要がある唯一のステータスです。」
OBJECT mplsFTNMapStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { mplsFTNCompliances 2 }
-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
OBJECTS {
mplsFTNIndexNext,
mplsFTNTableLastChanged,
mplsFTNRowStatus,
mplsFTNDescr,
mplsFTNMask,
mplsFTNAddrType,
mplsFTNSourceAddrMin,
mplsFTNSourceAddrMax,
mplsFTNDestAddrMin,
mplsFTNDestAddrMax,
mplsFTNSourcePortMin,
mplsFTNSourcePortMax,
mplsFTNDestPortMin,
mplsFTNDestPortMax,
mplsFTNProtocol,
mplsFTNActionType,
mplsFTNActionPointer,
mplsFTNDscp,
mplsFTNStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement MPLS FTN rules."
::= { mplsFTNGroups 1 }
mplsFTNMapGroup OBJECT-GROUP
OBJECTS {
mplsFTNMapTableLastChanged,
mplsFTNMapRowStatus,
mplsFTNMapStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement activation of MPLS
FTN entries on interfaces."
::= { mplsFTNGroups 2 }
mplsFTNPerfGroup OBJECT-GROUP
OBJECTS {
mplsFTNPerfMatchedPackets,
mplsFTNPerfMatchedOctets,
mplsFTNPerfDiscontinuityTime
}
STATUS current
DESCRIPTION
"Collection of objects providing MPLS FTN performance
information."
::= { mplsFTNGroups 3 }
END
終わり
This MIB module can be used to configure LSRs to redirect non-MPLS traffic into an MPLS cloud. As such, improper manipulation of the objects represented in this MIB module may result in traffic being redirected to unintended destinations, potentially resulting in denial of service to end-users.
このMIBモジュールを使用して、LSRSを構成して、非MPLSトラフィックをMPLSクラウドにリダイレクトできます。そのため、このMIBモジュールに表されるオブジェクトの不適切な操作により、トラフィックが意図しない目的地にリダイレクトされ、エンドユーザーのサービスが拒否される可能性があります。
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を備えた管理オブジェクトが多数あります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セキュア環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。これらはテーブルとオブジェクトであり、その感度/脆弱性です。
- mplsFTNTable and mplsFTNMapTable can be used to create packet matching rules for classifying IPv4 or IPv6 traffic and redirecting matched packets into the MPLS cloud. Modifying objects in these tables can result in the misdirection of traffic and potential denial of service to end-users. It may also result in traffic which was intended to be redirected into the MPLS cloud being routed through the IP network instead, potentially resulting in degradation of service quality or outright denial of service.
- MPLSFTNTABLEおよびMPLSFTNMAPTABLEを使用して、IPv4またはIPv6トラフィックを分類し、マッチングされたパケットをMPLSクラウドにリダイレクトするためのパケットマッチングルールを作成できます。これらのテーブルでオブジェクトを変更すると、トラフィックの誤った方向に向かって、エンドユーザーに対するサービス拒否の可能性があります。また、代わりにIPネットワークを介してルーティングされるMPLSクラウドにリダイレクトされることを目的としたトラフィックをもたらす可能性があり、潜在的にサービスの品質または完全なサービス拒否を低下させることができます。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュールの読み取り可能なオブジェクトのいくつか（つまり、アクセスできないこと以外に最大アクセスを備えたオブジェクト）は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのオブジェクトへのアクセスを取得および/または通知することさえ制御し、SNMPを介してネットワーク上に送信するときにこれらのオブジェクトの値を暗号化することも重要です。これらはテーブルとオブジェクトであり、その感度/脆弱性です。
- mplsFTNPerfTable provides counters for monitoring the performance of packet classification rules defined in mplsFTNTable and mplsFTNMapTable. Unauthorized read access to objects in these tables may be used to gain traffic flow information.
- mplsftnperftableは、mplsftntableおよびmplsftnmaptableで定義されたパケット分類ルールのパフォーマンスを監視するためのカウンターを提供します。これらのテーブルのオブジェクトへの不正な読み取りアクセスを使用して、トラフィックフロー情報を取得できます。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPV3以前のSNMPバージョンには、適切なセキュリティは含まれていませんでした。ネットワーク自体が（たとえばIPSECを使用して）安全である場合でも、それでもセキュアネットワーク上の誰がアクセス/セット/セット（読み取り/変更/作成/削除/削除）を制御することはできません。MIBモジュール。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
実装者は、SNMPV3暗号化メカニズム（認証とプライバシー用）の完全なサポートを含む、SNMPV3フレームワーク（[RFC3410]、セクション8を参照）で提供されるセキュリティ機能を考慮することをお勧めします。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and cryptographic security be enabled. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects to only those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPV3より前のSNMPバージョンの展開は推奨されません。代わりに、SNMPV3を展開し、暗号化セキュリティを有効にすることをお勧めします。その場合、このMIBモジュールのインスタンスへのアクセスを提供するSNMPエンティティが、実際に取得または設定する正当な権利を持つプリンシパル（ユーザー）のみにオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です（変更を変更します（変更）/作成/削除）それら。
As described in [MPLSMGMT] and as requested in [RFC3811], MPLS related standards-track MIB modules should be rooted under the mplsStdMIB subtree. New assignments can only be made by a standards action as specified in [RFC2434].
[MPLSMGMT]で説明されており、[RFC3811]で要求されているように、MPLS関連の標準トラックMIBモジュールは、MPLSSTDMIBサブツリーの下にルート化する必要があります。新しい割り当ては、[RFC2434]で指定されているように、標準アクションによってのみ行うことができます。
The IANA has assigned mplsStdMIB 8 to the MPLS-FTN-STD-MIB module specified in this document.
IANAは、このドキュメントで指定されたMPLSSTDMIB 8をMPLS-FTN-STD-MIBモジュールに割り当てました。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[RFC3289] Baker、F.、Chan、K。、およびA. Smith、「差別化されたサービスアーキテクチャの管理情報ベース」、RFC 3289、2002年5月。
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002.
[RFC3291] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキストコンベンション」、RFC 3291、2002年5月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルーター（LSR）管理情報ベース（MIB）」、RFC 3813、2004年6月。
[RFC3811] Nadeau, T., and J. Cucchiara, J., Editors, "Definition of Textual Conventions (TCs) for Multi-Protocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811] Nadeau、T。、およびJ. Cucchiara、J.、編集者、「マルチプロトコルラベルスイッチング（MPLS）管理のためのテキストコンベンション（TCS）の定義」、2004年6月、RFC 3811。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）、RFC 3812、2004年6月。
[MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003.
[Mplsmgmt] Nadeau、T.、Srinivasan、C。、およびA. Farrel、「Multiprotocol Label Switching（MPLS）管理概要」、2003年9月の進行中の作業。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、1993年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
We would particularly like to thank Bert Wijnen for the substantial time and effort he spent in helping us improve this document. We would also like to thank David Perkins, Joan Cucchiara, Mike Piecuch, and Adrien Grise for their insightful comments and additions to this document.
特に、この文書の改善を支援するために彼が費やしたかなりの時間と努力について、Bert Wijnenに感謝したいと思います。また、この文書への洞察に富んだコメントと追加について、David Perkins、Joan Cucchiara、Mike Peatuch、およびAdrien Griseに感謝します。
Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824
Thomas D. Nadeau Cisco Systems、Inc。300 Apollo Drive Chelmsford、MA 01824
Phone: +1-978-244-3051
EMail: tnadeau@cisco.com
Cheenu Srinivasan Bloomberg L.P. 499 Park Avenue New York, NY 10022
Cheenu Srinivasan Bloomberg L.P. 499 Park Avenue New York、NY 10022
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035
Arun Viswanathan Force10 Networks、Inc。1440 McCarthy Blvd Milpitas、CA 95035
Phone: +1-408-571-3516
EMail: arunv@force10networks.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。