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)
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）インターネット協会（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）の一部を定義します。特に、マルチプロトコルラベルスイッチング（MPLS）での使用のためのアクションを定義する設定、およびネクストホップラベル転送エントリ（NHLFE）のマッピングに転送等価クラス（FEC）を監視し、対応するために管理オブジェクトについて説明します。
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）の一部を定義します。特に、それは（MPLS）をマルチプロトコルラベルスイッチングのためのネクストホップラベル転送エントリ（NHLFE）マッピングと、対応するアクションに転送等価クラス（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ツーNHLFE（FTN）マッピング[RFC3031]を介しNHLFE（すなわち、MPLSラベル）に関連付けられています。この関係は、入口のLSRは着信パケットに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テーブル機能の一部は、LSPのプレフィックス宛てのすべてのパケットをマッピングする転送情報ベース（FIB）を用いて実施することができます。しかし、このマッピングは自然の中で粗いです。
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
FEC転送等価クラスNHLFEネクストホップラベル転送エントリFTN FECツーNHLFE MIB管理情報ベース・スイッチングMPLSマルチプロトコルラベル
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
この表は、NHLFEへのマッピングFECを指定することができます。この表の各エントリは、（この文書における「FTNエントリ」と称する）、着信（セクション5.2で説明したようにエントリがmplsFTNMapTableを使用して活性化されたインターフェイス上の）パケットとされるアクションに適用されるルールを定義しますマッチしたパケットで撮影。 mplsFTNTableは、送信元アドレス範囲、宛先アドレス範囲、ソースポート範囲、宛先ポート範囲、IPv4のプロトコルフィールド[RFC791]やIPv6の次ヘッダフィールド[RFC2460]とのDiffServコードポイントの一つ以上に基づいて6組のマッチングルールを可能にします（DSCP、[RFC2474]）を指定します。 NHLFEが非TE LSPであり、またはMPLS-TE-STD-MIB [RFC3812]でmplsTunnelEntryで場合のパケットのリダイレクトは、MPLS-LSR-STD-MIB [RFC3813]のいずれかポイントmplsXCEntryにおける行動指針に基づいています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]を使用することです。私たちは、代わりに、彼らは次のような利点を持っているので、FTN規則はmplsFTNTableでアドレス範囲の用語で表現することを可能にすることを選択しました。
- 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プレフィックスの数が非常に多いです。 192.0.2.0/27、192.0.2.32/28、192.0.2.48/29、192.0.2.56/30、たとえば、我々は、アドレスの範囲を表すために、次の6つのCIDRプレフィックス[192.0.2.0- 192.0.2.62]を必要とします192.0.2.60/31、および192.0.2.62/32。このような36の作成を必要とする「トンネル＃2までの範囲【192.0.2.128-192.0.2.190]に範囲[192.0.2.0-192.0.2.62]と宛先アドレスのソースアドレスを持つすべてのパケットをリダイレクトする」などのルールmplsFTNTableの概念的な行規則はCIDRプレフィックスとして表したが、我々は代わりにアドレス範囲を使用した場合にのみ、単一の概念的な行が必要とされる場合。
- 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.
- 特定の実装では、それがそう選択した場合、同等のCIDRプレフィックスに内部mplsFTNTableで指定されたアドレス範囲を変換して自由です。しかし、強力なレンジマッチングアルゴリズムが利用可能であることを考えると、多くの実装は、直接これらを実装することを好むことができます。
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.
このテーブルは、システム内の特定のインターフェイスにmplsFTNTableで定義された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.
- 我々は、単一のSET操作でインターフェイス上のエントリの既存のリストに新しいエントリを挿入することができなければなりません。したがって、我々は、既存のエントリを手動でインデックスの再作成を必要としない挿入操作をサポートすることができなければなりません。
- 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:
次のようにこのリンクされたリスト構造を使用して、1は、インターフェイスごとにアプリケーションのために、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.
- mplsFTNMapRowStatus.ifIndex.0.0にGETNEXT検索操作を実行する、インデックスのifIndexとの界面に第FTNエントリを決定します。返されるオブジェクトは、存在する場合、（例えば）mplsFTNMapRowStatus.ifIndex.0.n（mplsFTNMapRowStatusは概念的な列の最初のアクセス可能な円柱状のオブジェクトである）です。次いで、このインターフェイスに適用された第1 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;
ifIndexNext最初FTNエントリのインデックスは、インデックスifIndexNextとのインタフェースに適用した場合のkにFTNエントリが適用されたifTableの次のインターフェースの指標である1 mplsFTNMapRowStatus.ifIndexNext.0.k、。
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、firstIfIndexはFTNエントリがマッピングされているためにifTableの最初のエントリであるmplsFTNMapTable、には複数のエントリが存在しない場合。
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).
上記の手順は、アプリケーションのために、インターフェイスごとに全て適用エントリを取得するために使用することができます。検索操作の数（すなわち、GETNEXT操作の最小数は、任意の索引付けスキームを使用して必要な）適用FTNエントリの数に等しいことに留意されたいです。
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.
また、これは私たちが特定にマップされている最初のFTNエントリを決定することができないので、我々は代わりに私たちが選んだ「以前の」ポインタオブジェクトの「次へ」ポインタオブジェクトを使用して、このリンクされたリスト構造を作成していることができなかったことに注意してください単一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エントリを監視するために大容量のパフォーマンスカウンタを提供します。
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モジュールに固有ではありません。しかし、慎重なアプリケーションがオブジェクトmplsFTNTableLastChangedと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のトラバースを実行する前に、アプリケーションがmplsFTNMapTableLastChangedの値を取得する必要があります。テーブルの各後続GETNEXT操作は同様にこのオブジェクトを含むべきです。例えば、GETNEXT（mplsFTNMapTableLastChanged.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によってインデックス付けの後にFTNエントリを決定する（リンクされたリストの順に）、インデックスのifIndexとのインタフェースにマッピングされました。
- 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の値がトラバースを開始する前に取得した値と、この操作によって取得mplsFTNMapTableLastChangedの値を比較することにより、検索処理中に変更されていないことを確認します。
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で定義された方法を説明するために例を使用NHLFEマッピングにFECを実行するために一緒に働きます。
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で、指定されたLSPをmplsXCTableとmplsOutSegmentTableにおける次のエントリによって表される発信のifIndex = 50と転出ラベル= 150とLSPに192.0.2.63に一致する送信元IPv4アドレスを持つパケットをリダイレクトします。
In mplsXCTable:
mplsXCTableで：
{ mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00, mplsXCOutSegmentIndex = 0x03, mplsXCLabelStackIndex = 0 }
{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 }
{mplsOutSegmentIndex = 0x03の、mplsOutSegmentIfIndex = 50、mplsOutSegmentPushTopLabel =真、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で、指定されたトンネルがmplsTunnelTableの次のエントリによって表されるトンネル＃4へのIPv4範囲内のアドレス宛先とするパケット[192.0.2.32、192.0.2.96]をリダイレクトします：
{ mplsTunnelIndex = 4, -- primary tunnel mplsTunnelInstance = 0, mplsTunnelIngressLSRID = 192.0.2.1, mplsTunnelEgressLSRID = 192.0.2.2 }
{mplsTunnelIndex = 4、 - プライマリトンネル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:
アクションルール＃1の「発信のifIndex = 50と転出ラベルとLSPに192.0.2.63に一致元IPv4アドレス= 150とパケットをリダイレクト」はmplsFTNTableの次のエントリによって実現することができます。
{ 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 }
{mplsFTNIndex = 1、mplsFTNDescr = "ルール＃1"、 - 送信元アドレスのみ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.
これは、LSP LSRこの場合mplsXCLspId.1.2.1.0.1.3に、使用するLSPの対応mplsXCEntryにおける最初のアクセス可能な円柱状のオブジェクトのインスタンスにmplsFTNActionPointerを設定することにより、パケットをリダイレクトするべきかを示します。
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 }
{ - このインタフェースmplsFTNPrevIndex = 0の最初FTNエントリ - - のifIndex = 1 mplsFTNMapIndex = 1、インターフェイスにルールを適用mplsFTNTableにおける現在のエントリのインデックス、すなわち、ルール＃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]トンネル＃4を」ルール＃2 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 }
{mplsFTNIndex = 2、mplsFTNDescr = "ルール＃2"、 - 宛先アドレスのみ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はUnsigned32の（基礎となるデータ型）エンティティとして、それぞれ、アドレス192.0.2.1と192.0.2.2の表現です。
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 }
{ - インターフェイスにルールを適用するifIndex = 1 mplsFTNMapIndex = 1、 - 、（mplsFTNIndex = 1）mplsFTNPrevIndex = 1ルール＃1の後に挿入 - mplsFTNTableにおける現在のエントリのインデックス、すなわち、ルール＃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では、IPv4のトンネル＃4 [192.0.2.96、192.0.2.32]の範囲内のアドレス宛先を有するパケットをリダイレクトします。
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このルールに関連付けられた対応するアクション（すなわち、「トンネル＃4へのIPv4範囲内のアドレス宛先を有するパケット[192.0.2.32、192.0.2.96]をリダイレクトする」）は、ルール＃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.
しかし、我々は= 2のifIndexとのインタフェース上の最初のものとして、このFTNエントリをアクティブにするために、MPLS FTNマップテーブルに次の新しいエントリを作成する必要があります。
{ -- apply rule to interface ifIndex = 2 mplsFTNMapIndex = 2, -- first FTN entry on this interface mplsFTNPrevIndex = 0, -- index of current entry in mplsFTNTable mplsFTNMapCurrIndex = 2 }
{ - インターフェイスにルールを適用するifIndex = 2 mplsFTNMapIndex = 2、 - このインタフェースmplsFTNPrevIndex = 0の最初FTNエントリ、 - = 2 mplsFTNTable mplsFTNMapCurrIndexにおける現在のエントリのインデックス}
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で、我々は、トラフィックをリダイレクトしたいトンネルmplsTunnelTableの次のエントリによって表されるため、トンネル＃3にプレフィックス192.0.2.32/28に一致する宛先IPv4アドレスを持つすべてのパケットをリダイレクトします。
{ mplsTunnelIndex = 3, -- primary tunnel mplsTunnelInstance = 0, mplsTunnelIngressLSRID = 192.0.2.3, mplsTunnelEgressLSRID = 192.0.2.4 }
{mplsTunnelIndex = 3、 - プライマリトンネル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に「トンネル＃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 }
{mplsFTNIndex = 3、mplsFTNDescr = "ルール＃3"、 - 宛先アドレスのみmplsFTNMask = 0x40の、mplsFTNAddrType = IPv4の、 - CIDRプレフィックスに相当するアドレス範囲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はUnsigned32の（基礎となるデータ型）エンティティとして、それぞれ、アドレス192.0.2.3と192.0.2.4の表現です。
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 }
{ - インターフェイスにルールを適用するifIndex = 1 mplsFTNMapIndex = 1、 - 、（mplsFTNIndex = 1）mplsFTNPrevIndex = 1ルール＃1の後に挿入 - mplsFTNTableにおける現在のエントリのインデックス、すなわち、ルール＃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、次のエントリの「前の」ポインタオブジェクトmplsFTNMapPrevIndexにおけるルール＃3を挿入した後、このエントリを指すように自動的に調整（2位ルールに対応）。
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).
ifIndex = 1をインタフェースするルール＃3のアプリケーションに対応する概念的な行は、次のインデックス値を有する：mplsFTNMapIndex = 1、mplsFTNMapPrevIndex = 1、及びmplsFTNMapCurrIndex = 3この概念的な行を削除するには、ネットワーク管理アプリケーションは、設定された動作設定を行います値へのオブジェクトインスタンスはmplsFTNMapRowStatus.1.1.3破壊する（6）。エージェントは、この概念的な列を破壊します。また、自動的にmplsFTNMapPrevIndexのオブジェクトインスタンスが値1（最近破壊ルール＃3を指し、すなわち、）値3から＃2をルールに対応する調整（すなわち、ルールに＃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はFTNのエントリに一致するパケットをリダイレクトするLSPまたはTEトンネルを示しています。このオブジェクトは、管理者が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]
輸入MODULE-IDENTITY、OBJECT-TYPE、SNMPv2の-SMI FROM Unsigned32の、Counter64の、Integer32の - [RFC2578]のRowStatus、StorageType、RowPointer、テキストの表記法、のSNMPv2-TCからのタイムスタンプ - [RFC2579] MODULE-COMPLIANCE、オブジェクト・グループSNMPv2-CONF FROM - [RFC2580] InterfaceIndexOrZeroの、ifGeneralInformationGroup、ifCounterDiscontinuityGroup IF-MIB FROM - [RFC2863] SNMP-FRAMEWORK-MIBかられるSnmpAdminString - DIFFSERV-DSCP-TC FROM [RFC3411]もDscp - [RFC3289]のInetAddressType、InetAddressの、INET-ADDRESS-MIBからInetPortNumber - MPLS-TC-STD-MIB FROM [RFC3291] mplsStdMIB - [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日ORGANIZATION "マルチプロトコルラベルスイッチング（MPLS）ワーキンググループ" CONTACT-INFO「トーマスD.ナドー郵便：シスコシステムズ社250アポロドライブチェルムズフォード、MA 01824電話：+ 1-978-244-3051 Eメール：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
Arun Viswanathan Postal: Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Tel: +1-408-571-3516 Email: arunv@force10networks.com
アルンViswanathanの郵便：フォーステンネットワークス株式会社1440マッカーシーブルバードミルピタス、CA 95035電話：+ 1-408-571-3516 Eメール：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
DESCRIPTION「著作権（C）インターネット協会（2004）、このMIBモジュールの初期バージョンは、完全な適法な通知についてはRFC 3814で発表されたRFC自体を参照するか、参照してください。http://www.ietf.org/copyrights/ianamib .htmlを
This MIB module contains managed object definitions for
specifying FEC to NHLFE (FTN) mappings and corresponding
performance for MPLS."
-- Revision history.
- 改訂履歴。
REVISION "200406030000Z" -- June 3, 2004
REVISION "200406030000Z" - 2004年6月3日
DESCRIPTION "Initial version issued as part of RFC 3814."
DESCRIPTION「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.
- mplsFTNTableの次の無料のインデックス。 mplsFTNIndexNextのOBJECT-TYPE SYNTAX MplsFTNEntryIndexOrZero MAX-ACCESS read-onlyステータス現在の説明は「このオブジェクトmplsFTNTableのエントリを作成するときmplsFTNIndexに使用する次の使用可能な有効な値が含まれています。
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.
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).
それは現在、未使用であり、SETが成功すると、エージェントは、（さらなる行の作成が許可されません場合）またはゼロ（実装固有のアルゴリズムに従って）現在使用されていないゼロ以外の値にこのオブジェクトの値を変更しなければなりません。
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).
- FTNエントリの表。 MplsFTNEntry MAX-ACCESSステータス現在の説明のmplsFTNTable OBJECT-TYPE構文配列は「この表は、このテーブルには、このテーブルの各エントリが適用されるルールを定義し指定するNHLFEマッピングにFECを可能にする。現在定義されてFTNエントリが含まれ着信（FTNエントリがmplsFTNMapTableを使用して活性化されたインターフェイス上の）パケットと一致するパケット（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.
指定するプロトコルフィールド又はIPv6の次ヘッダフィールドとのDiffServコードポイント（DSCP）。
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非TE LSPのいずれかMPLS-LSR-STD-MIBにおけるmplsXCEntryのインスタンスに作用ポインタポイントである場合、またはMPLS-TE-STD-MIBにおけるmplsTunnelEntryのインスタンスにNHLFEは、発信TEトンネルである場合。 "REFERENCE" J.ポステル、インターネットプロトコル、RFC 791、STD 5、1981年9月
Deering, S., and R. Hinden, Internet Protocol, Version
6 (IPv6) Specification, RFC 2460, December 1998
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
ニコルズ、K、ブレイク、S.、ベイカー、F.とD.黒、IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義、RFC 2474、1998年12月
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS Label Switch Router Management Information Base, RFC 3813
スリニバサン、C.、A. Viswanathanの、およびT.ナドー、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.
mplsFTNIndex OBJECT-TYPE構文MplsFTNEntryIndex MAX-ACCESSステータス現在の説明は「これは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
mplsFTNDescrのOBJECT-TYPE SYNTAXれるSnmpAdminString MAX-ACCESSはリード作成しますステータス現在
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.
mplsFTNAddrTypeのOBJECT-TYPE構文InetAddressType MAX-ACCESSリード作成ステータス現在の説明は「このオブジェクトは概念的な行のソースおよび宛先アドレスオブジェクト（mplsFTNSourceAddrMin、mplsFTNSourceAddrMax、mplsFTNDestAddrMin及びmplsFTNDestAddrMax）に含まれるアドレスのタイプを決定します。
This object MUST NOT be set to unknown(0) when
mplsFTNMask has bit positions sourceAddr(0) or
destAddr(1) set to one.
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
mplsFTNSourcePortMinのOBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESSはリード作成しますステータス現在の説明
"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
mplsFTNDscpのOBJECT-TYPE SYNTAXもDscp MAX-ACCESSはリード作成しますステータス現在
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.
mplsFTNActionPointer OBJECT-TYPE構文RowPointer MAX-ACCESSはリード作成ステータス現在の説明「mplsFTNActionTypeがredirectLsp（1）である場合、このオブジェクトはにパケットを照合リダイレクトするLSPを示すmplsXCEntryのインスタンスへのzeroDotZero又は点を含まなければなりません。
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.
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.
MplsFTNMapEntry MAX-ACCESSステータス現在の説明のmplsFTNMapTable OBJECT-TYPE構文配列は「このテーブルは、システム内の特定のインターフェイスにmplsFTNTableのエントリによって定義されるようなFTN規則を適用するか、マップする能力を提供するオブジェクトが含まれている。FTNルールが比較されますそれらはインターフェイスに適用されている順序で着信パケット。
The indexing structure of mplsFTNMapTable is as
follows.
- 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は、ルールが適用されたインターフェイスを示します。 0の値は、すべてのインターフェイスへのルールの適用を表します。
- 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は1つが適用される前にインターフェイス上のルールを指定します。 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:
次のようにこのリンクされたリスト構造を使用して、1は、インターフェイスごとにアプリケーションのために、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.
- mplsFTNMapRowStatus.ifIndex.0.0にGETNEXT検索動作を実行するインデックスのifIndexとの界面に第FTNエントリを決定するステップと返されるオブジェクトは、存在する場合、（例えば）mplsFTNMapRowStatus.ifIndex.0.n（mplsFTNMapRowStatusは概念的な列の最初のアクセス可能な円柱状のオブジェクトである）です。このインターフェイスに適用された第1 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;
ifIndexNext最初FTNエントリのインデックスは、インデックスifIndexNextとのインタフェースに適用した場合のkにFTNエントリが適用されたifTableの次のインターフェースの指標である1.mplsFTNMapRowStatus.ifIndexNext.0.k、。
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、firstIfIndexはFTNエントリがマッピングされているためにifTableの最初のエントリであるmplsFTNMapTable、には複数のエントリが存在しない場合。
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エントリを取得するには、上記の手順を実行します。検索操作の数（すなわち、GETNEXT操作の最小数は、任意の索引付けスキームを使用して必要な）適用FTNエントリの数と同じであることに留意されたいです。
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.
mplsFTNMapIndex OBJECT-TYPE構文InterfaceIndexOrZeroのMAX-ACCESSステータス現在の説明「このFTNエントリが適用されていることインターフェイスインデックス。ゼロの値は、すべてのインターフェイスに適用されるエントリを示します。
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
mplsFTNMapRowStatusのOBJECT-TYPE構文RowStatusはMAX-ACCESS読作成ステータス現在{アクティブ（1）、createAndGo（4）、（6）を破壊します}
DESCRIPTION "Used for controlling the creation and deletion of this row.
この行の作成と削除を制御するために使用されDESCRIPTION」。
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.
mplsFTNPerfMatchedOctets OBJECT-TYPEの構文Counter64のMAX-ACCESS read-only説明「とは、指定されたインターフェイスに/適用マッピングされている場合、指定FTNエントリと一致したオクテットの数。
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 MODULE-COMPLIANCEステータス現在の説明 "MPLS-FTN-STD-MIBのためのフルサポートを提供エージェントのための準拠宣言。"
MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup }
MODULE-MIB IF - インタフェースグループMIB、RFC 2863. MANDATORY-GROUPS {ifGeneralInformationGroup、ifCounterDiscontinuityGroup}
MODULE -- This module. MANDATORY-GROUPS { mplsFTNRuleGroup, mplsFTNMapGroup, mplsFTNPerfGroup
MODULE - このモジュール。 MANDATORY-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."
OBJECT mplsFTNAddrType構文InetAddressType {IPv4の（1）、IPv6は（2）} DESCRIPTION「実装は、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."
OBJECT mplsFTNSourceAddrMin構文InetAddress（SIZE（4 | 20））DESCRIPTION「実装が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."
OBJECT mplsFTNSourceAddrMax構文InetAddress（SIZE（4 | 20））DESCRIPTION「実装が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."
OBJECT mplsFTNDestAddrMin構文InetAddress（SIZE（4 | 20））DESCRIPTION「実装が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 MODULE-COMPLIANCEステータス現在の説明「コンプライアンス要件
provide read-only support for MPLS-FTN-STD-MIB. Such
devices can then be monitored but cannot be configured
using this MIB module."
MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup }
MODULE IF-MIB - インターフェイスグループMIB、RFC 2863 MANDATORY-GROUPS {ifGeneralInformationGroup、ifCounterDiscontinuityGroup}
MODULE -- This module MANDATORY-GROUPS { mplsFTNRuleGroup, mplsFTNMapGroup, mplsFTNPerfGroup }
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."
OBJECT mplsFTNIndexNext MIN-ACCESSアクセス不可能説明「mplsFTNTableが読み取り専用として実装されている場合、このオブジェクトは必要ありません。」
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構文RowStatusがアクティブ{（1）} MIN-ACCESS読み取り専用説明「書き込みアクセス必要となりません、そして活性がサポートされる必要がある唯一の状態です。」
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構文InetAddressType {IPv4の（1）、IPv6の（2）} MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされない。実装がただIPv4およびIPv6アドレスをサポートするために必要とされます。"
OBJECT mplsFTNSourceAddrMin
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."
構文InetAddress（SIZE（4 | 20））MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていない実装が唯一の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."
OBJECT 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."
OBJECT 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."
OBJECT mplsFTNDestAddrMax構文InetAddress（SIZE（4 | 20））MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていない実装が唯一のIPv4アドレスとIPv6アドレスをサポートするために必要とされます。。"
OBJECT mplsFTNSourcePortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT mplsFTNSourcePortMin MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNSourcePortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT mplsFTNSourcePortMax MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNDestPortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT mplsFTNDestPortMin MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNDestPortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT mplsFTNDestPortMax MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNProtocol
OBJECT MPLS FTNプロトコル
MIN-ACCESS read-only DESCRIPTION "Write access is not required."
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."
OBJECT mplsFTNActionPointer MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNDscp MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT mplsFTNDscp MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT mplsFTNStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT 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."
OBJECT mplsFTNMapRowStatus構文RowStatusは{アクティブ（1）} MIN-ACCESS読み取り専用説明「書き込みアクセス必要とアクティブ（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モジュールはMPLSクラウドに非MPLSトラフィックをリダイレクトするためのLSRを設定するために使用することができます。このように、この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:
読み書きおよび/またはリード作成のMAX-ACCESS句でこのMIBモジュールで定義された管理オブジェクトの数があります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：
- 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モジュールで読み取り可能なオブジェクトの一部（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらく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を使用することにより、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）この内のオブジェクトが存在しません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実体が適切に実際にGETまたはSET（変化への正当な権利を持っているだけで、それらのプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任です/）/削除、それらを作成します。
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は、この文書で指定されたMPLS-FTN-STD-MIBモジュールにmplsStdMIB 8を割り当てました。
[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月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、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.、パーキンス、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と、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ベイカー、F.、チャン、K.、およびA.スミス、 "差別化サービスアーキテクチャのための管理情報ベース"、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]ダニエル、M.、ハーバーマン、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]ハリントン、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]スリニバサン、C.、Viswanathanの、A.、およびT.ナドーは、 "マルチプロトコルラベルスイッチング（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]ナドー、T.、およびJ. Cucchiara、J.、エディタ、 "（MPLS）管理をマルチプロトコルラベルスイッチングのためのテキストの表記法（TCS）の定義"、RFC 3811、2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（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]ナドー、T.、スリニバサン、C.、およびA.ファレル、 "マルチプロトコルラベルスイッチング（MPLS）管理の概要"、進歩、2003年9月の作業。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、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]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]デアリング、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、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.
私たちは特に、彼は私たちがこの文書を改善するうえで過ごしかなりの時間と労力のためにバートWijnenに感謝したいと思います。我々はまた、この文書への洞察に満ちたコメントや追加のためにデビッド・パーキンス、ジョーンCucchiara、マイクPiecuch、およびエイドリアングリスを感謝したいと思います。
Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824
トーマスD.ナドー、シスコシステムズ、株式会社300アポロドライブチェルムズフォード、MA 01824
Phone: +1-978-244-3051 EMail: tnadeau@cisco.com
電話：+ 1-978-244-3051 Eメール：tnadeau@cisco.com
Cheenu Srinivasan Bloomberg L.P. 499 Park Avenue New York, NY 10022
スリニバサンcinu blumbergaラパニューヨーク、NY 10022 499公園会場
Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net
電話：+ 1-212-893-3682 Eメール：cheenu@bloomberg.net
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035
アルンViswanathanのフォーステンネットワークス株式会社1440マッカーシーブルバードミルピタス、CA 95035
Phone: +1-408-571-3516 EMail: arunv@force10networks.com
電話：+ 1-408-571-3516 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。