RFC3814 日本語訳
3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) ManagementInformation Base (MIB). T. Nadeau, C. Srinivasan, A. Viswanathan. June 2004. (Format: TXT=87518 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループT.ナドーの要求をネットワークでつないでください: 3814年のシスコシステムズInc.カテゴリ: 規格はInc.2004年6月にC.SrinivasanブルームバーグL.P.A.Viswanathan Force10ネットワークを追跡します。
Multiprotocol Label Switching (MPLS) Forwarding Equivalence
Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)
Management Information Base (MIB)
次のホップラベル推進エントリー(FECからNHLFE)管理情報ベースに同値類を送るMultiprotocolラベルの切り換え(MPLS)(MIB)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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).
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはNext Hop Label Forwarding Entry(NHLFE)マッピングにForwarding Equivalence Class(FEC)を定義して、構成して、モニターするための管理オブジェクトとMultiprotocol Label Switching(MPLS)との使用のための対応する動作について説明します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 本書では使用されるコンベンション。 . . . . . . . . . . . . . . 3 4. インターネット標準の管理枠組み. . . . . . . . . . 3 5。 概説します。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1mplsFTNTable. . . . . . . . . . . . . . . . . . . . . . 4 5.1.1。 アドレスの利点はCIDR接頭語に広がっています。 4 5.2mplsFTNMapTable。 . . . . . . . . . . . . . . . . . . . . 5 5.2.1. 要件に索引をつけます。 . . . . . . . . . . . . . 5 5.2.2. 現在のインデックスはどう.55.3mplsFTNPerfTable. . . . . . . . . . . . . . . . . . . . 7 6を扱うか。 検索変更相互作用. . . . . . . . . 7を避けます。
Nadeau, et al. Standards Track [Page 1] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[1ページ]。
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
7. 例の例証しているMIBモジュールの部品. . . . . . . . . . 8 7.1。 FTN規則. . . . . . . . . . . . . . . . . . . . 8 7.2を抽出してください。 FTN EntriesとApplyingを作成する、Interfaces. . 9 7.3への彼ら FTNエントリーを複数のインタフェースに写像します。 . . . . . . 10 7.4. エントリーを存在するのに挿入して、記載してください。 . . . . . . . . . 11 7.5. 絵の表関係. . . . . . . . . . . . . 13 7.6。 エントリーを削除します。 . . . . . . . . . . . . . . . . . . . 14 8. RowPointerの使用。 . . . . . . . . . . . . . . . . . . . . 16 9. MPLS-FTN-STD-MIB定義. . . . . . . . . . . . . . . . . 16 10。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 38 11. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 39 11.1. MPLS-FTN-STD-MIB. . . . . . . . 39 12のためのIANA問題。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 39 12.1。 引用規格. . . . . . . . . . . . . . . . . . 39 12.2。 有益な参照. . . . . . . . . . . . . . . . . 40 13。 承認. . . . . . . . . . . . . . . . . . . . . . . 41 14。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 41 15。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 42
1. Introduction
1. 序論
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).
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはNext Hop Label Forwarding Entry(NHLFE)マッピングにForwarding Equivalence Class(FEC)を指定するための管理オブジェクトとMultiprotocol Label Switching(MPLS)のための対応する動作について説明します。
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に属すそれらのパケットは、[RFC3031]を写像しながら、FECからNHLFE(FTN)を通してNHLFE(すなわち、MPLSラベル)に関連しています。 この関係はイングレスLSRsがどう入って来るパケットにMPLSラベルを課すかを定義します。 また、それは出口LSRsがMPLSパケットからMPLS詰め物のヘッダーをどうdecapsulateするかを定義します。
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.
概念的に、接頭語のためにLSPに運命づけられたすべてのパケットを写像するのに、Forwarding Information基地(FIB)を使用することでFTNテーブルの機能性のいくつかを実行できるでしょう。 しかしながら、このマッピングは現実に粗いです。
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
同様の機能性はセキュリティフィルタや、アクセスフィルタや、RSVP流れ識別などの他の文脈で既に使用されています。 これらはすべて、IPヘッダーと上側の層のヘッダー情報に基づいて特別の処理のためにパケットを特定するために合う様々な組み合わせを必要とします。 パケットが特定の規則に合っていると、対応する動作はそれらのパケットの上で実行されます。 うまくいっているマッチが特定されるとき、例えば、取る2つの民衆訴訟で、パケットは、進めるか、またはそれを捨てています。 しかしながら、別に
Nadeau, et al. Standards Track [Page 2] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[2ページ]。
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.
動作はTOSバイトを変更するか、または特定の外向的なインタフェースにパケットを向け直すのなどように可能です。 MPLSの文脈では、NHLFEによって実行された可能な動作はMPLS Label Switched Path(LSP)かMPLS Traffic Engineered(TE)トンネルのどちらかにパケットを向け直すことです。
This document attempts to consolidate the various matching requirements and associated action options needed for MPLS into a single specification.
このドキュメントは、MPLSに必要である様々な合っている要件と関連動作オプションをただ一つの仕様に統合するのを試みます。
2. Terminology
2. 用語
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 Architecture[RFC3031]で覆われるか、SNMP Architecture[RFC3411]のどちらかにありますが、ここで何らかのすぐに適切な頭文字語/用語を定義するのは情報です。
MPLS Multiprotocol Label Switching
FEC Forwarding Equivalence Class
NHLFE Next-Hop Label Forwarding Entry
FTN FEC-to-NHLFE
MIB Management Information Base
MPLS Multiprotocolラベル切り換えFEC推進同値類NHLFE次のホップラベル推進エントリーFTN FECからNHLFE MIBへの管理情報ベース
3. Conventions Used In This Document
3. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
4. The Internet-Standard Management Framework
4. インターネット標準の管理枠組み
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概観について、RFC3410[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].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIB物はSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBの物は、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
Nadeau, et al. Standards Track [Page 3] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[3ページ]。
5. Outline
5. アウトライン
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のあらゆるエントリーに性能カウンタを提供します、aで-、インタフェース基礎。
5.1. mplsFTNTable
5.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は、指定されるために、1に基づいた合っている規則を6-tupleに許容するか、またはIPv4プロトコルの一層のソースアドレス範囲、目的地のアドレスの範囲、ソースのポート範囲、仕向港の範囲、分野RFC791またはIPv6に次のヘッダー分野RFC2460、およびDiffServ Code Point(DSCP、RFC2474)を許容します。 パケットリダイレクションはNHLFEがTEトンネルの起源であるならNHLFEが非TE LSPであるときにMPLS-LSR-STD-MIB[RFC3813]でmplsXCEntryを指し示す動作ポインタの上、または、MPLS-TE- STD-MIB[RFC3812]のmplsTunnelEntryでベースです。
5.1.1. Advantages of Address Ranges Over CIDR Prefixes
5.1.1. アドレスの利点はCIDR接頭語に広がっています。
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.
CIDRを使用しながらFTN規則の一部がことである1セットのアドレスを指定する1つの可能な方法が[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
- いくつかのアドレスの範囲を表すのに必要であるCIDR接頭語の数は非常に大きいです。 例えば、私たちはアドレス[192.0.2.0- 192.0.2.62]の範囲を表すために以下の6つのCIDR接頭語を必要とします: 192.0.2.0/27、192.0.2 28、.32/192.0.2 29、.48/192.0.2 30、.56/192.0.2 31、および.60/192.0.2.62/32 「ソースアドレスが範囲[192.0.2.0-192.0.2.62]にある状態で、すべてのパケットを向け直してください。そうすれば、#何2インチもトンネルを堀る範囲[192.0.2.128-192.0.2.190]の送付先アドレスは創造を必要とであるだろうことなど」の規則
Nadeau, et al. Standards Track [Page 4] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[4ページ]。
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.
36では、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.
- 特定の実現は無料でmplsFTNTableで内部的に同等なCIDR接頭語に指定されたアドレスの範囲を翻訳できます、そう選ぶなら。 しかしながら、強力な範囲マッチングアルゴリズムが利用可能であるなら、多くの実現が、直接これらを実行するのを好むかもしれません。
5.2. mplsFTNMapTable
5.2. mplsFTNMapTable
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エントリーに対して比較されます。
5.2.1. Indexing Requirements
5.2.1. 要件に索引をつけます。
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に選ぶ特定のインデックス計画によって書き取られるようにこの情報を得る(非大量)の検索操作の数はそれがいかなる他のインデックス計画でも命令したより多いはずがありません。 例えば、インデックス計画は、Network Management Applicationがテーブルですべてのエントリーを検索して、この情報を得るためにそれらをオフラインで調べるのを強制してはいけません。
5.2.2. How the Current Indexing Works
5.2.2. 現在のインデックスはどう働いているか。
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
mplsFTNMapTableの選ばれたインデックス構造で、テーブルのエントリーは繋がっているリストの項目のように振る舞います。 それぞれの概念的な列
Nadeau, et al. Standards Track [Page 5] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[5ページ]。
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.
物、mplsFTNMapPrevIndexを持っています。(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つは申込順に以下の1インタフェースあたり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.
- インデックスifIndexとのインタフェースで最初のFTNエントリーを決定するために、GETNEXT検索操作をmplsFTNMapRowStatus.ifIndexに実行してください、.0、.0、。 1つが存在しているなら、返された物は(言います)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エントリーを決定するには、GETNEXT検索操作をmplsFTNMapRowStatus.ifIndex.n.0に実行してください。 そのようなエントリーが存在しているなら、返された物はフォーム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、その場合、kはインデックスifIndexNextとのインタフェースに付けられた最初のFTNエントリーのインデックスです。(そこでは、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).
アプリケーション命令における1インタフェースあたり1個のベースですべての適用されたエントリーを検索するのに上のステップを使用できます。 検索操作の数が適用されたFTNエントリーの数と等しいことに注意してください(すなわち、GETNEXT操作の最小の数は、どんなインデックス計画も使用する必要がありました)。
Nadeau, et al. Standards Track [Page 6] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[6ページ]。
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(非嵩)検索操作を使用することで特定のインタフェースに写像された最初のFTNエントリーを決定できないでしょう、したがって、私たちが選んだ'前'のポインタ物の代わりに'次'のポインタ物を使用することでこの繋がっているリスト構造を作成できないだろうことに注意してください。
The use of this indexing structure is further illustrated using an example in Section 7.
これの構造に索引をつける使用は、セクション7の例を使用することでさらに例証されます。
5.3. mplsFTNPerfTable
5.3. mplsFTNPerfTable
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つ以上のインタフェースに付けてあるなら、このテーブルは、1インタフェースあたり1個のベースでそのようなそれぞれのFTNエントリーをモニターするために高容量性能カウンタを提供します。
6. Avoiding Retrieval-Modification Interactions
6. 検索変更相互作用を避けます。
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;
- インデックスifIndexとのインタフェースに写像されたn(繋がっているリストオーダーにおける)でものが索引をつけた後にFTNエントリーを決定してください、セクション5.2.2で説明されるように。
- 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.
このテクニックを使用して、アプリケーションは最小量のオーバーヘッドで検索された情報の正当性を確実にすることができます。 これは頻繁に変更されたテーブルからの情報を検索している間、特に重要です。
Nadeau, et al. Standards Track [Page 7] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[7ページ]。
7. Example Illustrating MIB Module Components
7. 例の例証しているMIBモジュールの部品
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.
このセクションでは、私たちは、物がNHLFEマッピングにFECを実行するためにMPLS-FTN-STD-MIBでどう仕事を一緒に定義したかを例証するのに例を使用します。
Note that for the various table entries involved in this example, we only show the objects that help illustrate each case.
この例にかかわる様々なテーブル項目に私たちが各ケースを例証するのを助ける物を案内するだけであることに注意してください。
7.1. Sample FTN Rules
7.1. サンプルFTN規則
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、指定されたLSPがmplsXCTableとmplsOutSegmentTableに以下のエントリーで表される外向的なifIndex=50と外向的なラベル=150でのLSPに。
In mplsXCTable:
mplsXCTableで:
{
mplsXCIndex = 0x02,
mplsXCInSegmentIndex = 0x00,
mplsXCOutSegmentIndex = 0x03,
mplsXCLabelStackIndex = 0
}
mplsXCIndexは0×02、mplsXCInSegmentIndex=0x00と等しく、mplsXCOutSegmentIndexは0×03、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
}
本当の=mplsOutSegmentTopLabel mplsOutSegmentIndex=0x03、mplsOutSegmentIfIndex=50、mplsOutSegmentPushTopLabel=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に以下のエントリーで表されます)。
Nadeau, et al. Standards Track [Page 8] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[8ページ]。
{
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}
7.2. Creating FTN Entries and Applying them to Interfaces
7.2. FTN EntriesとApplyingを作成する、Interfacesへの彼ら
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インチがRule#にあるLSPに、mplsFTNTableで以下のエントリーで1を実行できます:
{
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だけ=0×80、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.
これは、LSRが対応するLSPのmplsXCEntryにおける最初のアクセスしやすい円柱状の物の例にmplsFTNActionPointerを設定することによってどのLSPにパケットを向け直すはずであるかを使用、この場合mplsXCLspId.1に示します。.2 .1 .0 .1 .3。
This action is then activated on "interface ifIndex = 1" by the following entry in mplsFTNMapTable to complete the implementation of Rule #1:
そして、この動作は「インタフェースifIndexはRule#1の実現を終了するためにmplsFTNMapTableで以下のエントリーで何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
}
--規則を適用して、1ifIndex=mplsFTNMapIndex=1--このインタフェースmplsFTNPrevIndex=0の最初のFTNエントリー--mplsFTNTableの現在のエントリーのインデックスを連結してください、すなわち、Rule#1mplsFTNMapCurrIndex=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] #Ruleで#4インチにトンネルを堀るには、mplsFTNTableで以下のエントリーで2を実行できます:、」
Nadeau, et al. Standards Track [Page 9] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[9ページ]。
{
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と等しい、」
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:
この規則は、「以前にこれで動かされたRule#1、が連結した後にインタフェースifIndex=1インチ」で動かされる必要があります。 Rule#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
}
--規則を適用して、1ifIndex=mplsFTNMapIndex=1--Rule#1(mplsFTNIndex=1)mplsFTNPrevIndex=1時以降差し込み--mplsFTNTableの現在のエントリーのインデックスを連結してください、すなわち、Rule#2mplsFTNMapCurrIndex=2
7.3. Mapping an FTN Entry to Multiple Interfaces
7.3. FTNエントリーを複数のインタフェースに写像します。
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アドレスが範囲にある状態でパケットを向け直してください、[192.0 .2 .32 192.0 .2 .96] トンネル#4に。
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と対応する動作がこの規則と交際したのに注意してください、(「送付先IPv4アドレスが範囲にある状態でパケットを向け直してください、[192.0 .2 .32 192.0 .2 #何4インチもトンネルを堀る.96]) それと同じくらいはRule#2インチ、に関連していますか? したがって、私たちはmplsFTNIndex=2でmplsFTNTableから既存のエントリーを再利用できます。
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.
しかしながら、私たちは、ifIndex=2とのインタフェースの最初のものとしてこのFTNエントリーを起動するためにmplsFTNMapTableで以下の新しいエントリーを作成しなければなりません。
Nadeau, et al. Standards Track [Page 10] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[10ページ]。
{
-- apply rule to interface ifIndex = 2
mplsFTNMapIndex = 2,
-- first FTN entry on this interface
mplsFTNPrevIndex = 0,
-- index of current entry in mplsFTNTable
mplsFTNMapCurrIndex = 2
}
--規則を適用する、2ifIndex=mplsFTNMapIndex=2--このインタフェースmplsFTNPrevIndex=0の最初のFTNエントリー--mplsFTNTable mplsFTNMapCurrIndex=2の現在のエントリーのインデックスを連結してください
7.4. Inserting an Entry Into Existing List
7.4. エントリーを存在するのに挿入して、記載してください。
At a later point, suppose that we wish to introduce the following Rule between Rules #1 and #2.
後のポイントでは、Rules#1、と#2の間に以下のRuleを導入したいと思うと仮定してください。
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に合っていて、そうしたいと思うトンネルが交通を向け直すところで#3、にトンネルを堀る.32/28はmplsTunnelTableに以下のエントリーで表されます:
{
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.
特定のインタフェースでの規則の注文がRule#3で指定されたアドレスの範囲がRule#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:
私たちが句を実行する、「送付先IPv4アドレスが接頭語に合っているすべてのパケットを向け直してください、1.4 .0 .0 mplsFTNTableで以下のエントリーを作成するRule#3におけるトンネル#3インチへの/16:、」
Nadeau, et al. Standards Track [Page 11] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[11ページ]。
{
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 = "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.
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.
We next insert this rule in mplsFTNMapTable just after Rule #1 as follows:
We next insert this rule in mplsFTNMapTable just after Rule #1 as follows:
{
-- 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
}
{ -- 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.
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.
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.
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.
Nadeau, et al. Standards Track [Page 12] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 12] RFC 3814 MPLS FTN MIB June 2004
7.5. Pictorial Tabular Relationship
7.5. Pictorial Tabular Relationship
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.)
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) ---------------+ |
| |
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) ---------------+ | | |
Nadeau, et al. Standards Track [Page 13] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 13] RFC 3814 MPLS FTN MIB June 2004
| 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)
| 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)
7.6. Deleting an Entry
7.6. Deleting an Entry
Let us next look at how we can remove the recently applied Rule #3 and how the existing conceptual rows behave in this situation.
Let us next look at how we can remove the recently applied Rule #3 and how the existing conceptual rows behave in this situation.
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).
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).
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.
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.
Nadeau, et al. Standards Track [Page 14] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 14] RFC 3814 MPLS FTN MIB June 2004
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)
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)
Nadeau, et al. Standards Track [Page 15] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 15] RFC 3814 MPLS FTN MIB June 2004
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.
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.
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.
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.
8. The Use of RowPointer
8. The Use of RowPointer
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 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.
9. MPLS-FTN-STD-MIB Definitions
9. MPLS-FTN-STD-MIB Definitions
MPLS-FTN-STD-MIB DEFINITIONS ::= BEGIN
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]
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]
Nadeau, et al. Standards Track [Page 16] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 16] RFC 3814 MPLS FTN MIB June 2004
;
;
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" -- 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
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 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
Arun Viswanathan Postal: Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Tel: +1-408-571-3516 Email: arunv@force10networks.com
IETF MPLS Working Group email: mpls@uu.net"
IETF MPLS Working Group email: 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 "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
This MIB module contains managed object definitions for
specifying FEC to NHLFE (FTN) mappings and corresponding
performance for MPLS."
This MIB module contains managed object definitions for specifying FEC to NHLFE (FTN) mappings and corresponding performance for MPLS."
-- Revision history.
-- Revision history.
REVISION
"200406030000Z" -- June 3, 2004
REVISION "200406030000Z" -- June 3, 2004
DESCRIPTION
"Initial version issued as part of RFC 3814."
DESCRIPTION "Initial version issued as part of RFC 3814."
Nadeau, et al. Standards Track [Page 17] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 17] RFC 3814 MPLS FTN MIB June 2004
::= { mplsStdMIB 8 }
::= { mplsStdMIB 8 }
-- TEXTUAL-CONVENTIONs used in this MIB.
MplsFTNEntryIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an entry in mplsFTNTable."
SYNTAX Unsigned32 (1..4294967295)
-- 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)
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.
-- Top-Level Components of this MIB.
mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNStdMIB 0 }
mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNStdMIB 1 }
mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNStdMIB 2 }
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.
-- 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.
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.
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.
If a non-zero value is returned the Network Management
If a non-zero value is returned the Network Management
Nadeau, et al. Standards Track [Page 18] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 18] RFC 3814 MPLS FTN MIB June 2004
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.
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.
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 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 }
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 }
-- 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).
-- 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
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
Nadeau, et al. Standards Track [Page 19] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 19] RFC 3814 MPLS FTN MIB June 2004
Protocol field or IPv6 next-header field and the
DiffServ Code Point (DSCP) to be specified.
Protocol field or IPv6 next-header field and the DiffServ Code Point (DSCP) to be specified.
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
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
Deering, S., and R. Hinden, Internet Protocol, Version
6 (IPv6) Specification, RFC 2460, December 1998
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
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
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
Label Switch Router Management Information Base,
RFC 3813
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS Label Switch Router Management Information Base, RFC 3813
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
Traffic Engineering Management Information Base,
RFC 3812"
::= { mplsFTNObjects 3 }
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 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,
MplsFTNEntry ::= SEQUENCE { mplsFTNIndex MplsFTNEntryIndex, mplsFTNRowStatus RowStatus, mplsFTNDescr SnmpAdminString, mplsFTNMask BITS, mplsFTNAddrType InetAddressType, mplsFTNSourceAddrMin InetAddress, mplsFTNSourceAddrMax InetAddress,
Nadeau, et al. Standards Track [Page 20] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 20] RFC 3814 MPLS FTN MIB June 2004
mplsFTNDestAddrMin InetAddress,
mplsFTNDestAddrMax InetAddress,
mplsFTNSourcePortMin InetPortNumber,
mplsFTNSourcePortMax InetPortNumber,
mplsFTNDestPortMin InetPortNumber,
mplsFTNDestPortMax InetPortNumber,
mplsFTNProtocol Integer32,
mplsFTNDscp Dscp,
mplsFTNActionType INTEGER,
mplsFTNActionPointer RowPointer,
mplsFTNStorageType StorageType
}
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 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 }
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 }
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 read-create STATUS current
Nadeau, et al. Standards Track [Page 21] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 21] RFC 3814 MPLS FTN MIB June 2004
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 }
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 }
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 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.
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
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
Nadeau, et al. Standards Track [Page 22] RFC 3814 MPLS FTN MIB June 2004
Nadeau, et al. Standards Track [Page 22] RFC 3814 MPLS FTN MIB June 2004
address objects SHOULD be set to zero-length strings."
::= { mplsFTNEntry 5 }
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 }
mplsFTNSourceAddrMin OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「ソースの下側の端は範囲を扱う」STATUSの現在の記述を読書して作成します。 「このオブジェクトのタイプは対応するmplsFTNAddrTypeオブジェクトで決定します。」 ::= mplsFTNEntry6
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 }
mplsFTNSourceAddrMax OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「ソースの上側の端は範囲を扱う」STATUSの現在の記述を読書して作成します。 「このオブジェクトのタイプは対応するmplsFTNAddrTypeオブジェクトで決定します。」 ::= mplsFTNEntry7
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 }
mplsFTNDestAddrMin OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「目的地の下側の端は範囲を扱う」STATUSの現在の記述を読書して作成します。 「このオブジェクトのタイプは対応するmplsFTNAddrTypeオブジェクトで決定します。」 ::= mplsFTNEntry8
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 }
mplsFTNDestAddrMax OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「目的地の上位は範囲を扱う」STATUSの現在の記述を読書して作成します。 「このオブジェクトのタイプは対応するmplsFTNAddrTypeオブジェクトで決定します。」 ::= mplsFTNEntry9
mplsFTNSourcePortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
mplsFTNSourcePortMin OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSはSTATUSの現在の記述を読書して作成します。
Nadeau, et al. Standards Track [Page 23] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[23ページ]。
"The lower end of the source port range."
DEFVAL { 0 }
::= { mplsFTNEntry 10 }
「ソースポート範囲の下側の端。」 DEFVAL0:、:= mplsFTNEntry10
mplsFTNSourcePortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the source port range "
DEFVAL { 65535 }
::= { mplsFTNEntry 11 }
mplsFTNSourcePortMax OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSはSTATUSの現在の記述「ソースポート範囲の上位」DEFVAL65535を読書して作成します:、:= mplsFTNEntry11
mplsFTNDestPortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination port range."
DEFVAL { 0 }
::= { mplsFTNEntry 12 }
mplsFTNDestPortMin OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「仕向港の範囲の下側の端。」 DEFVAL0:、:= mplsFTNEntry12
mplsFTNDestPortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination port range."
DEFVAL { 65535 }
::= { mplsFTNEntry 13 }
mplsFTNDestPortMax OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「仕向港の範囲の上位。」 DEFVAL65535:、:= mplsFTNEntry13
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 }
mplsFTNProtocol OBJECT-TYPE SYNTAX Integer32(0 .255)マックス-ACCESSは「IPはパケットでIPv4プロトコル番号かIPv6 Next-ヘッダー番号に対して合うように議定書の中で述べる」STATUSの現在の記述を読書して作成します。 255の値は、すべてを合わせることを意味します。 「255のプロトコル番号がIANAによって予約されて、0のNext-ヘッダー番号がIPv6で使用されることに注意してください。」 DEFVAL255:、:= mplsFTNEntry14
mplsFTNDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS read-create
STATUS current
mplsFTNDscp OBJECT-TYPE SYNTAX Dscpマックス-ACCESSはSTATUS海流を読書して引き起こします。
Nadeau, et al. Standards Track [Page 24] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[24ページ]。
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 }
「DSCPの内容はさばく」記述。 「差別化されたサービスのニコルズとK.とブレークとS.とベイカーとF.とD.黒、定義はIPv4とIPv6ヘッダーの(DS分野)をさばきます、RFC2474、1998年12月」という参照。 ::= mplsFTNEntry15
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 }
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。mplsFTNActionType OBJECT-TYPE SYNTAX INTEGER、LSP redirectTunnel(2)への再直接のredirectLsp(1)がトンネルに向け直す、「このFTNエントリーに合っているはやり出さされたパケットである動作のタイプ。」 ::= mplsFTNEntry16
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 SYNTAX RowPointerマックス-ACCESSは「mplsFTNActionTypeはredirectLsp(1)、このオブジェクトが合っているパケットを向け直すためにzeroDotZeroを含まなければならないか、またはLSPを示すmplsXCEntryのインスタンスを示さなければならないその時です」ならSTATUSの現在の記述を読書して作成します。
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がredirectTunnel(2)であるなら、このオブジェクトは、zeroDotZeroを含まなければならないか、または合っているパケットを向け直すMPLS TEトンネルを示す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 }
「このオブジェクトがzeroDotZeroを含んでいると、上で説明されるようなそれがmplsFTNActionTypeの値と一致した有効な指針で居住されるまでのFTNエントリーに合いながら、パケットの上で行動を全く取らないでしょう。」 ::= mplsFTNEntry17
Nadeau, et al. Standards Track [Page 25] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[25ページ]。
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 }
mplsFTNStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「ストレージはこのFTNエントリーにタイプする」STATUSの現在の記述を読書して作成します。 「'永久的'に値を持っていると許容される必要はない概念的な行は行でどんな円柱状のオブジェクトへのアクセスも書きます。」 DEFVAL、不揮発性:、:= mplsFTNEntry18
-- 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 }
mplsFTNMapTableLastChanged OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「最後の時間、エントリーがmplsFTNMapTableで加えられたか、削除されたか、または変更されたのを示します」。 管理局は、テーブルが彼らの注意を必要とするかどうか決定するためにこのオブジェクトに相談するはずです。 「このオブジェクトは特にテーブルが検索操作の間変更されないのを保証するためにmplsFTNMapTableに検索を実行するアプリケーションの役に立ちます。」 ::= mplsFTNObjects4
-- 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.
「システムの特定のインタフェースへのmplsFTNTableでエントリーで定義されて、このテーブルは適用する能力を提供するオブジェクトか地図FTN規則を含む」mplsFTNMapTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNMapEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 FTN規則はそれらがインタフェースで適用されるオーダーで入って来るパケットと比較されます。
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は規則が付けられるインタフェースを示します。 0の値は規則の適用をすべてのインタフェースに表します。
Nadeau, et al. Standards Track [Page 26] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[26ページ]。
- 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:
この繋がっているリスト構造を使用して、1つは申込順に以下の1インタフェースあたり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.
- インデックスifIndexとのインタフェースで最初のFTNエントリーを決定するために、GETNEXT検索操作をmplsFTNMapRowStatus.ifIndexに実行してください、.0、.0、。 1つが存在しているなら、返されたオブジェクトは(言います)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エントリーを決定するには、GETNEXT検索操作をmplsFTNMapRowStatus.ifIndex.n.0に実行してください。 そのようなエントリーが存在しているなら、返されたオブジェクトはフォーム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
1. ifIndexNextが次のインタフェースのインデックスであるところのmplsFTNMapRowStatus.ifIndexNext.0.k
Nadeau, et al. Standards Track [Page 27] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[27ページ]。
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;
その場合、FTNエントリーが適用されたifTable、kはインデックスifIndexNextとのインタフェースに付けられた最初のFTNエントリーのインデックスです。
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).
上のステップを使用して、アプリケーション命令における1インタフェースあたり1個のベースですべての適用された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 }
「mplsFTNTableの行が破壊されるなら、エージェントはまた、このテーブルで対応するエントリー(すなわち、mplsFTNCurrIndexの合っている値があるもの)を破壊しなければなりません。」 ::= mplsFTNObjects5
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 OBJECT-TYPE SYNTAX MplsFTNMapEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「それぞれの概念的な行はインタフェースで適用されたFTN規則のリストの特定の見解にFTN規則の適用を表します」。 「mplsFTNMapIndex、mplsFTNMapPrevIndex、mplsFTNMapCurrIndexに索引をつけてください:、:、」= mplsFTNMapTable1
MplsFTNMapEntry ::= SEQUENCE {
MplsFTNMapEntry:、:= 系列
Nadeau, et al. Standards Track [Page 28] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[28ページ]。
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 SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「この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 }
「mplsFTNMapIndexの(非ゼロ)インタフェースインデックスを指定することによってインタフェースに写像されたエントリーはゼロに合わせるために等しいmplsFTNMapIndexとのエントリーの前に適用されます。」 ::= mplsFTNMapEntry1
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 }
mplsFTNMapPrevIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このインタフェースに付けられた前のFTNエントリーのインデックス。」 「特別な値ゼロは、これがリストで最初のFTNエントリーであるべきであることを示します。」 ::= mplsFTNMapEntry2
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 }
mplsFTNMapCurrIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndexのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「このインタフェースに付けられている現在のFTNエントリーに索引をつけます」。 ::= mplsFTNMapEntry3
mplsFTNMapRowStatus OBJECT-TYPE
SYNTAX RowStatus {
active(1),
createAndGo(4),
destroy(6)
}
MAX-ACCESS read-create
STATUS current
mplsFTNMapRowStatus OBJECT-TYPE SYNTAX RowStatus、アクティブな(1)、createAndGo(4)が(6)を破壊する、マックス-ACCESSはSTATUS海流を読書して引き起こします。
Nadeau, et al. Standards Track [Page 29] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[29ページ]。
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 }
「また、mplsFTNMapTableの概念的な行が次に削除されるmplsFTNTableの概念的な行を示すなら、エージェントはmplsFTNMapTableの対応する概念的な行を削除しなければなりません。」 ::= mplsFTNMapEntry4
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 }
mplsFTNMapStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「ストレージはこのエントリーにタイプする」STATUSの現在の記述を読書して作成します。 「'永久的'に値を持っていると許容される必要はない概念的な行はこの行でどんな円柱状のオブジェクトへのアクセスも書きます。」 DEFVAL、不揮発性:、:= mplsFTNMapEntry5
-- 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 }
mplsFTNPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNPerfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルは1インタフェースあたり1個のベースのFTNエントリーにおける性能統計を含んでいます」。 ::= mplsFTNObjects6
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 OBJECT-TYPE SYNTAX MplsFTNPerfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「各エントリーはこのインタフェースに写像された指定されたインタフェースとFTNエントリーのための性能情報を含んでいます」。 mplsFTNPerfIndex、mplsFTNPerfCurrIndexに索引をつけてください:、:= mplsFTNPerfTable1
Nadeau, et al. Standards Track [Page 30] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[30ページ]。
MplsFTNPerfEntry ::= SEQUENCE {
mplsFTNPerfIndex InterfaceIndexOrZero,
mplsFTNPerfCurrIndex MplsFTNEntryIndex,
mplsFTNPerfMatchedPackets Counter64,
mplsFTNPerfMatchedOctets Counter64,
mplsFTNPerfDiscontinuityTime TimeStamp
}
MplsFTNPerfEntry:、:= 系列mplsFTNPerfIndex InterfaceIndexOrZero、mplsFTNPerfCurrIndex MplsFTNEntryIndex、mplsFTNPerfMatchedPackets Counter64、mplsFTNPerfMatchedOctets Counter64、mplsFTNPerfDiscontinuityTimeタイムスタンプ
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 }
mplsFTNPerfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「FTNエントリーが付けられるか、または写像されたインタフェースのインタフェースインデックス。」 「このオブジェクトの各インスタンスはmplsFTNMapIndexのインスタンスに対応しています。」 ::= mplsFTNPerfEntry1
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 }
アクセスしやすくないSTATUS現在の記述が「指定されたインタフェースに適用されたFTNエントリーに索引をつけるか、または写像した」mplsFTNPerfCurrIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndexマックス-ACCESS。 「このオブジェクトの各インスタンスはmplsFTNMapCurrIndexのインスタンスに対応しています。」 ::= mplsFTNPerfEntry2
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 }
書き込み禁止のSTATUSの現在の記述が「指定されたインタフェースにそれが適用されているなら指定されたFTNエントリーに合っていたパケットに付番するか、または写像した」mplsFTNPerfMatchedPackets OBJECT-TYPE SYNTAX Counter64マックス-ACCESS。 「このカウンタの値における不連続はマネージメントシステムの再初期化においてmplsFTNDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= mplsFTNPerfEntry3
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.
書き込み禁止のSTATUSの現在の記述が「指定されたインタフェースにそれが適用されているなら指定されたFTNエントリーに合っていた八重奏に付番するか、または写像した」mplsFTNPerfMatchedOctets OBJECT-TYPE SYNTAX Counter64マックス-ACCESS。
Nadeau, et al. Standards Track [Page 31] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[31ページ]。
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 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてmplsFTNDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= mplsFTNPerfEntry4
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 }
mplsFTNPerfDiscontinuityTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「いくらかものかこの一層のエントリーのカウンタが不連続を受けた最新の時のsysUpTimeの値。」 「現地管理職者サブシステムの最後の再初期化以来どれかそのような不連続が起こっていないなら、このオブジェクトはaゼロ値を含んでいます。」 ::= mplsFTNPerfEntry5
-- End of mplsFTNPerfTable
-- mplsFTNPerfTableの端
-- Module compliance.
-- モジュールコンプライアンス。
-- Top level object IDs.
-- 最高平らなオブジェクトID。
mplsFTNGroups
OBJECT IDENTIFIER ::= { mplsFTNConformance 1 }
mplsFTNCompliances
OBJECT IDENTIFIER ::= { mplsFTNConformance 2 }
mplsFTNGroupsオブジェクト識別子:、:= mplsFTNConformance1mplsFTNCompliancesオブジェクト識別子:、:= mplsFTNConformance2
-- 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 STATUSの現在の記述のための「MPLS-FTN-STD-MIBの全面的な支援を提供するエージェントのための承諾声明」という承諾要件。
MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
モジュール、-、MIB、--インタフェースがMIB、RFC2863を分類する 義務的なグループifGeneralInformationGroup、ifCounterDiscontinuityGroup
MODULE -- This module.
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup,
mplsFTNPerfGroup
MODULE--このモジュール。 義務的なグループ、mplsFTNRuleGroup、mplsFTNMapGroup、mplsFTNPerfGroup
Nadeau, et al. Standards Track [Page 32] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[32ページ]。
}
}
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 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."
「IPv4、そして/または、IPv6アドレスであるとサポート実装が必要であるだけである」OBJECT mplsFTNSourceAddrMin SYNTAX InetAddress(SIZE(4|20))記述。 「実装がアドレスが実際に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."
「IPv4、そして/または、IPv6アドレスであるとサポート実装が必要であるだけである」OBJECT mplsFTNSourceAddrMax SYNTAX InetAddress(SIZE(4|20))記述。 「実装がアドレスが実際に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."
「IPv4、そして/または、IPv6アドレスであるとサポート実装が必要であるだけである」OBJECT mplsFTNDestAddrMin SYNTAX InetAddress(SIZE(4|20))記述。 「実装がアドレスが実際に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 }
「IPv4、そして/または、IPv6アドレスであるとサポート実装が必要であるだけである」OBJECT mplsFTNDestAddrMax SYNTAX InetAddress(SIZE(4|20))記述。 「実装がアドレスが実際にLSRでサポートされるタイプであるとサポートするのに必要であるだけです。」 ::= mplsFTNCompliances1
-- Compliance requirement for read-only implementations.
mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance requirement for implementations that only
-- 書き込み禁止実装mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE STATUSの現在の記述のための承諾要件、「実装のための承諾要件、それ、単に」
Nadeau, et al. Standards Track [Page 33] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[33ページ]。
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 IF-MIB--インタフェースGroup MIB、RFC2863MANDATORY-GROUPSifGeneralInformationGroup、ifCounterDiscontinuityGroup
MODULE -- This module
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup,
mplsFTNPerfGroup
}
MODULE--このモジュールMANDATORY-GROUPSmplsFTNRuleGroup、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 SYNTAX 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 SYNTAX InetAddressType、ipv4(1)、ipv6(2)、MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 「実装がIPv4とIPv6がアドレスであるとサポートするのに必要であるだけです。」
OBJECT mplsFTNSourceAddrMin
オブジェクトmplsFTNSourceAddrMin
Nadeau, et al. Standards Track [Page 34] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[34ページ]。
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."
SYNTAX 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 SYNTAX 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 SYNTAX 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 SYNTAX 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
オブジェクトmplsFTNProtocol
Nadeau, et al. Standards Track [Page 35] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[35ページ]。
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 SYNTAX RowStatusのアクティブな(1)、MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でなく、アクティブな(1)がサポートされる必要がある唯一の状態である、」
OBJECT mplsFTNMapStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { mplsFTNCompliances 2 }
OBJECT mplsFTNMapStorageType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 ::= mplsFTNCompliances2
-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
OBJECTS {
mplsFTNIndexNext,
mplsFTNTableLastChanged,
mplsFTNRowStatus,
mplsFTNDescr,
mplsFTNMask,
mplsFTNAddrType,
mplsFTNSourceAddrMin,
mplsFTNSourceAddrMax,
-- 順応ユニットのmplsFTNRuleGroup OBJECT-GROUP OBJECTS、mplsFTNIndexNext、mplsFTNTableLastChanged、mplsFTNRowStatus、mplsFTNDescr、mplsFTNMask、mplsFTNAddrType、mplsFTNSourceAddrMin、mplsFTNSourceAddrMax
Nadeau, et al. Standards Track [Page 36] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[36ページ]。
mplsFTNDestAddrMin,
mplsFTNDestAddrMax,
mplsFTNSourcePortMin,
mplsFTNSourcePortMax,
mplsFTNDestPortMin,
mplsFTNDestPortMax,
mplsFTNProtocol,
mplsFTNActionType,
mplsFTNActionPointer,
mplsFTNDscp,
mplsFTNStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement MPLS FTN rules."
::= { mplsFTNGroups 1 }
mplsFTNDestAddrMin、mplsFTNDestAddrMax、mplsFTNSourcePortMin、mplsFTNSourcePortMax、mplsFTNDestPortMin、mplsFTNDestPortMax、mplsFTNProtocol、mplsFTNActionType、mplsFTNActionPointer、mplsFTNDscp、mplsFTNStorageType STATUSの現在の記述、「MPLS FTNを実装するオブジェクトの収集は統治します」。 ::= mplsFTNGroups1
mplsFTNMapGroup OBJECT-GROUP
OBJECTS {
mplsFTNMapTableLastChanged,
mplsFTNMapRowStatus,
mplsFTNMapStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement activation of MPLS
FTN entries on interfaces."
::= { mplsFTNGroups 2 }
mplsFTNMapGroup OBJECT-GROUP OBJECTS、mplsFTNMapTableLastChanged、mplsFTNMapRowStatus、mplsFTNMapStorageType、STATUSの現在の記述、「インタフェースにおけるMPLS FTNエントリーの起動を実装するオブジェクトの収集。」 ::= mplsFTNGroups2
mplsFTNPerfGroup OBJECT-GROUP
OBJECTS {
mplsFTNPerfMatchedPackets,
mplsFTNPerfMatchedOctets,
mplsFTNPerfDiscontinuityTime
}
STATUS current
DESCRIPTION
"Collection of objects providing MPLS FTN performance
information."
::= { mplsFTNGroups 3 }
mplsFTNPerfGroup OBJECT-GROUP OBJECTS、mplsFTNPerfMatchedPackets、mplsFTNPerfMatchedOctets、mplsFTNPerfDiscontinuityTime、STATUSの現在の記述、「性能情報をMPLS FTNに供給するオブジェクトの収集。」 ::= mplsFTNGroups3
END
終わり
Nadeau, et al. Standards Track [Page 37] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[37ページ]。
10. Security Considerations
10. セキュリティ問題
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.
MPLS雲の中に非MPLSトラフィックを向け直すためにLSRsを構成するのにこのMIBモジュールを使用できます。 そういうものとして、この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:
aがあります。読書して書くことのマックス-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.
- IPv4かIPv6トラフィックを分類して、MPLS雲の中に取り組んでいるパケットを向け直すためのパケットの合っている規則を作成するのにmplsFTNTableとmplsFTNMapTableを使用できます。 これらのテーブルでオブジェクトを変更すると、トラフィックの誤まった指示と潜在的エンドユーザに対するサービスの否定はもたらされることができます。 また、それは代わりに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モジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
- 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を使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこの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).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Nadeau, et al. Standards Track [Page 38] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[38ページ]。
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バージョンの展開はNOT RECOMMENDEDです。 代わりに、SNMPv3が配布していて暗号のセキュリティであることはRECOMMENDEDです。可能にされます。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
11. IANA Considerations
11. IANA問題
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]での指定されるとしての規格動作で新しい課題をすることができるだけです。
11.1. IANA Considerations for MPLS-FTN-STD-MIB
11.1. MPLS-FTN-STD-MIBのためのIANA問題
The IANA has assigned mplsStdMIB 8 to the MPLS-FTN-STD-MIB module specified in this document.
IANAは本書では指定されたMPLS-FTN-STD-MIBモジュールにmplsStdMIB8を割り当てました。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、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、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[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"、STD58、RFC2579、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"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、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.スミス、「差別化されたサービスアーキテクチャのための管理情報ベース」RFC3289)は2002がそうするかもしれません。
Nadeau, et al. Standards Track [Page 39] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[39ページ]。
[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、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC3291)は2002がそうするかもしれません。
[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)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(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.ナドー、「Multiprotocolはラベル切り換えルータ(LSR)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3813、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)の定義」RFC3811(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] Srinivasan、C.、Viswanathan、A.、およびT.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
12.2. Informative References
12.2. 有益な参照
[MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
Label Switching (MPLS) Management Overview", Work in
Progress, September 2003.
[MPLSMGMT] ナドー、T.、Srinivasan、C.、およびA.ファレル、「Multiprotocolラベルの切り換え(MPLS)マネジメントの展望」は進歩、2003年9月に働いています。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Nadeau, et al. Standards Track [Page 40] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[40ページ]。
[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分野)の定義」、RFC2474(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.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
13. Acknowledgements
13. 承認
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、およびAdrien Griseに感謝申し上げます。
14. Authors' Addresses
14. 作者のアドレス
Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824
トーマスD.ナドーシスコシステムズInc.300アポロDriveチェルムズフォード、MA 01824
Phone: +1-978-244-3051 EMail: tnadeau@cisco.com
以下に電話をしてください。 +1-978-244-3051 メールしてください: tnadeau@cisco.com
Cheenu Srinivasan Bloomberg L.P. 499 Park Avenue New York, NY 10022
Cheenu SrinivasanブルームバーグL.P.499パーク・アベニューニューヨーク、ニューヨーク 10022
Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net
以下に電話をしてください。 +1-212-893-3682 メールしてください: cheenu@bloomberg.net
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035
アルンViswanathan Force10はInc.1440マッカーシー・Blvdミルピタス、カリフォルニア 95035をネットワークでつなぎます。
Phone: +1-408-571-3516 EMail: arunv@force10networks.com
以下に電話をしてください。 +1-408-571-3516 メールしてください: arunv@force10networks.com
Nadeau, et al. Standards Track [Page 41] RFC 3814 MPLS FTN MIB June 2004
ナドー、他 規格はMPLS FTN MIB2004年6月にRFC3814を追跡します[41ページ]。
15. Full Copyright Statement
15. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Nadeau, et al. Standards Track [Page 42]
ナドー、他 標準化過程[42ページ]
一覧
スポンサーリンク
