RFC3811 日本語訳
3811 Definitions of Textual Conventions (TCs) for Multiprotocol LabelSwitching (MPLS) Management. T. Nadeau, Ed., J. Cucchiara, Ed.. June 2004. (Format: TXT=40353 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Nadeau, Ed.
Request for Comments: 3811 Cisco Systems, Inc.
Category: Standards Track J. Cucchiara, Ed.
Marconi Communications, Inc.
June 2004
ワーキンググループのT.ナドー、エドをネットワークでつないでください。コメントのために以下を要求してください。 3811年のシスコシステムズInc.カテゴリ: エド標準化過程J.Cucchiara、マルコニーコミュニケーションInc.2004年6月
Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management
Multiprotocolラベルの切り換え(MPLS)管理のための原文のコンベンション(TCs)の定義
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 Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.
このメモは一般的に使用されたMultiprotocol Label Switching(MPLS)経営情報を表すTextual Conventionsを含むManagement Information基地(MIB)のモジュールを定義します。 意図は輸入されていて、MPLSで使用されるこれらのTEXTUAL CONVENTIONS(TCs)がそうでなければそれら自身の表現を定義するMIBモジュールを関係づけたということです。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework. . . . . . . . . . 2
3. MPLS Textual Conventions MIB Definitions. . . . . . . . . . . 2
4. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Normative References. . . . . . . . . . . . . . . . . . 16
4.2. Informative References. . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. インターネット標準の管理枠組み。 . . . . . . . . . 2 3. MPLSの原文のコンベンションMIB定義。 . . . . . . . . . . 2 4. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. 引用規格。 . . . . . . . . . . . . . . . . . 16 4.2. 有益な参照。 . . . . . . . . . . . . . . . . 17 5. セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 17 7。 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 18 8つの承認。 . . . . . . . . . . . . . . . . . . . . . . 19 9. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 19 10. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 20
Nadeau & Cucchiara Standards Track [Page 1] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[1ページ]。
1. Introduction
1. 序論
This document defines a MIB module which contains Textual Conventions for Multiprotocol Label Switching (MPLS) networks. These Textual Conventions should be imported by MIB modules which manage MPLS networks.
このドキュメントはMultiprotocol Label Switching(MPLS)ネットワークのためにTextual Conventionsを含むMIBモジュールを定義します。 MPLSネットワークを経営するMIBモジュールでこれらのTextual Conventionsを輸入するべきです。
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
For an introduction to the concepts of MPLS, see [RFC3031].
MPLSの概念への序論に関しては、[RFC3031]を見てください。
2. The Internet-Standard Management Framework
2. インターネット標準の管理枠組み
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モジュールを指定します。
3. MPLS Textual Conventions MIB Definitions
3. MPLSの原文のコンベンションMIB定義
MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN
MPLS Tc STD-MIB定義:、:= 始まってください。
IMPORTS
輸入
MODULE-IDENTITY,
Unsigned32, Integer32,
transmission FROM SNMPv2-SMI -- [RFC2578]
MODULE-IDENTITY、Unsigned32、Integer32、トランスミッションFROM SNMPv2-SMI--[RFC2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC2579]
SNMPv2-Tcからの原文のコンベンション。 -- [RFC2579]
mplsTCStdMIB MODULE-IDENTITY
LAST-UPDATED "200406030000Z" -- June 3, 2004
ORGANIZATION
"IETF Multiprotocol Label Switching (MPLS) Working
Group."
CONTACT-INFO
" Thomas D. Nadeau
mplsTCStdMIBモジュールアイデンティティは"200406030000Z"をアップデートしました--2004年6月3日組織「IETF Multiprotocolラベルの切り換え(MPLS)作業部会。」 コンタクトインフォメーション「トーマス・D.ナドー」
Nadeau & Cucchiara Standards Track [Page 2] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[2ページ]。
Cisco Systems, Inc.
tnadeau@cisco.com
シスコシステムズInc. tnadeau@cisco.com
Joan Cucchiara
Marconi Communications, Inc.
jcucchiara@mindspring.com
ジョーンCucchiaraマルコニーコミュニケーションInc. jcucchiara@mindspring.com
Cheenu Srinivasan
Bloomberg L.P.
cheenu@bloomberg.net
Cheenu SrinivasanブルームバーグL.P. cheenu@bloomberg.net
Arun Viswanathan
Force10 Networks, Inc.
arunv@force10networks.com
アルンViswanathan Force10はInc. arunv@force10networks.com をネットワークでつなぎます。
Hans Sjostrand
ipUnplugged
hans@ipunplugged.com
ハンスシェストランドipUnplugged hans@ipunplugged.com
Kireeti Kompella
Juniper Networks
kireeti@juniper.net
Kireeti Kompella杜松は kireeti@juniper.net をネットワークでつなぎます。
Email comments to the MPLS WG Mailing List at
mpls@uu.net."
DESCRIPTION
"Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3811. For full legal notices see the RFC
itself or see:
http://www.ietf.org/copyrights/ianamib.html
「 mpls@uu.net のMPLS WG Mailing Listにコメントをメールしてください。」 記述「Copyright(C)インターネット協会(2004)。」 このMIBモジュールの初期のバージョンはRFC3811で発行されました。 完全な法定の通知に関しては、RFC自身を見るか、または見てください: http://www.ietf.org/copyrights/ianamib.html
This MIB module defines TEXTUAL-CONVENTIONs
for concepts used in Multiprotocol Label
Switching (MPLS) networks."
「このMIBモジュールはMultiprotocol Label Switching(MPLS)ネットワークに使用される概念のためにTEXTUAL-CONVENTIONsを定義します。」
REVISION "200406030000Z" -- June 3, 2004
DESCRIPTION
"Initial version published as part of RFC 3811."
REVISION"200406030000Z"--2004年6月3日に、記述は「RFC3811の一部として発行されたバージョンに頭文字をつけます」。
::= { mplsStdMIB 1 }
::= mplsStdMIB1
mplsStdMIB OBJECT IDENTIFIER
mplsStdMIB物の識別子
::= { transmission 166 }
::= トランスミッション166
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
MplsAtmVcIdentifier:、:= 原文のコンベンション表示ヒント「d」
Nadeau & Cucchiara Standards Track [Page 3] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[3ページ]。
STATUS current
DESCRIPTION
"A Label Switching Router (LSR) that
creates LDP sessions on ATM interfaces
uses the VCI or VPI/VCI field to hold the
LDP Label.
STATUSの現在の記述、「ATMインタフェースの自由民主党のセッションを作成するLabel Switching Router(LSR)は自由民主党Labelを持つのにVCIかVPI/VCI分野を使用します」。
VCI values MUST NOT be in the 0-31 range.
The values 0 to 31 are reserved for other uses
by the ITU and ATM Forum. The value
of 32 can only be used for the Control VC,
although values greater than 32 could be
configured for the Control VC.
VCI値が0-31範囲にあるはずがありません。 値0〜31はITUとATM Forumによる他の用途のために予約されます。 Control VCに32の値を使用できるだけです、Control VCのために値より多くの32を構成できましたが。
If a value from 0 to 31 is used for a VCI
the management entity controlling the LDP
subsystem should reject this with an
inconsistentValue error. Also, if
the value of 32 is used for a VC which is
NOT the Control VC, this should
result in an inconsistentValue error."
REFERENCE
"MPLS using LDP and ATM VC Switching, RFC3035."
SYNTAX Integer32 (32..65535)
0〜31までの値がVCIに使用されるなら、自由民主党サブシステムを制御する経営体はinconsistentValue誤りでこれを拒絶するべきです。 「また、32の値がControl VCでないVCに使用されるなら、これはinconsistentValue誤りをもたらすべきです。」 「自由民主党と気圧VCの切り換えを使用するMPLS、RFC3035」という参照。 構文Integer32(32..65535)
MplsBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"If the value of this object is greater than zero,
then this represents the bandwidth of this MPLS
interface (or Label Switched Path) in units of
'1,000 bits per second'.
MplsBitRate:、:= 「d」STATUSの現在の記述「この物の値がゼロ以上であるなら、これはMPLSがユニットで連結する(または、Label Switched Path)この帯域幅を表す'という1,000bps'というTEXTUAL-CONVENTION DISPLAY-ヒント、」
The value, when greater than zero, represents the
bandwidth of this MPLS interface (rounded to the
nearest 1,000) in units of 1,000 bits per second.
If the bandwidth of the MPLS interface is between
((n * 1000) - 500) and ((n * 1000) + 499), the value
of this object is n, such that n > 0.
ゼロ以上であるときに、値は1,000のbpsのユニットにおける、このMPLSインタフェース(最も近い1,000に、一周する)の帯域幅を表します。 ((n*1000)--500)と(n*1000)+499)の間には、MPLSインタフェースの帯域幅があるなら、この物の値はnであり、そのようなものはそのn>0です。
If the value of this object is 0 (zero), this
means that the traffic over this MPLS interface is
considered to be best effort."
SYNTAX Unsigned32 (0|1..4294967295)
「この物の値が0(ゼロ)であるなら、これは、このMPLSインタフェースの上の交通がベストエフォート型であると考えられることを意味します。」 構文Unsigned32(0|1..4294967295)
MplsBurstSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
MplsBurstSize:、:= 原文のコンベンション表示ヒント「d」
Nadeau & Cucchiara Standards Track [Page 4] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[4ページ]。
STATUS current
DESCRIPTION
"The number of octets of MPLS data that the stream
may send back-to-back without concern for policing.
The value of zero indicates that an implementation
does not support Burst Size."
SYNTAX Unsigned32 (0..4294967295)
STATUSの現在の記述、「流れがそうするMPLSデータの八重奏の数は取り締まりに関する心配なしで背中合わせの状態で発信します」。 「ゼロの値は、実現がBurst Sizeを支持しないのを示します。」 構文Unsigned32(0..4294967295)
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
MplsExtendedTunnelId:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「MPLS Tunnelに、ユニークな識別子。」 これはイングレスか出口LSRのIPv4アドレスをトンネルに表すかもしれません。 「CR-自由民主党のためにRSVPかIngress Router IDでExtended Tunnel Idからこの値を得ます。」 参照、「RSVP-Te:」 LSP TunnelsのためのRSVP、[RFC3209]への拡大。
Constraint-Based LSP Setup using LDP, [RFC3212]."
SYNTAX Unsigned32(0..4294967295)
「自由民主党、[RFC3212]を使用して、規制ベースのLSPはセットアップします。」 構文Unsigned32(0..4294967295)
MplsLabel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[RFC3471].
MplsLabel:、:= 「[RFC3031]、[RFC3032]、[RFC3034]、[RFC3035]、および[RFC3471]で定義されて、この値はMPLSラベルを表す」TEXTUAL-CONVENTION STATUSの現在の記述。
The label contents are specific to the label being
represented, such as:
ラベル含有量は以下のように表されるラベルに特定です。
* The label carried in an MPLS shim header
(for LDP this is the Generic Label) is a 20-bit
number represented by 4 octets. Bits 0-19 contain
a label or a reserved label value. Bits 20-31
MUST be zero.
* MPLS詰め物のヘッダー(自由民主党において、これはGeneric Labelである)で運ばれたラベルは4つの八重奏で表された20ビットの数です。 ビット0-19はラベルか予約されたラベル値を含んでいます。 ビット20-31はゼロであるに違いありません。
The following is quoted directly from [RFC3032].
There are several reserved label values:
以下は直接[RFC3032]から引用されます。 いくつかの予約されたラベル値があります:
i. A value of 0 represents the
'IPv4 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
i。 0の値は'IPv4 Explicit NULL Label'を表します。 このラベル値は単にラベルの下の方スタックで法的です。 それは、ラベルスタックが飛び出してその時に基づいているパケット必須の推進であるに違いないことを示します。
Nadeau & Cucchiara Standards Track [Page 5] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[5ページ]。
IPv4 header.
IPv4ヘッダー。
ii. A value of 1 represents the
'Router Alert Label'. This label value is
legal anywhere in the label stack except at
the bottom. When a received packet
contains this label value at the top of
the label stack, it is delivered to a
local software module for processing.
The actual forwarding of the packet
is determined by the label beneath it
in the stack. However, if the packet is
forwarded further, the Router Alert Label
should be pushed back onto the label stack
before forwarding. The use of this label
is analogous to the use of the
'Router Alert Option' in IP packets
[RFC2113]. Since this label
cannot occur at the bottom of the stack,
it is not associated with a
particular network layer protocol.
ii。 1の値は'ルータAlert Label'を表します。 下部を除いて、このラベル値はラベルスタックでどこでも法的です。 容認されたパケットがラベルスタックの先端にこのラベル値を保管しているとき、処理のためのローカルのソフトウェア・モジュールにそれを届けます。 パケットの実際の推進はスタックでそれの下でラベルで決定します。 しかしながら、さらにパケットを進めるなら、推進の前にラベルスタックにRouter Alert Labelを押し戻すべきです。 このラベルの使用はIPパケット[RFC2113]における'ルータAlert Option'の使用に類似しています。 このラベルがスタックの下部に現れることができないので、それは特定のネットワーク層プロトコルに関連づけられません。
iii. A value of 2 represents the
'IPv6 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
IPv6 header.
iii。 2の値は'IPv6 Explicit NULL Label'を表します。 このラベル値は単にラベルの下の方スタックで法的です。 それはラベルスタックが飛び出さなければならなくて、次に、パケットの推進をIPv6ヘッダーに基礎づけなければならないのを示します。
iv. A value of 3 represents the
'Implicit NULL Label'.
This is a label that an LSR may assign and
distribute, but which never actually
appears in the encapsulation. When an
LSR would otherwise replace the label
at the top of the stack with a new label,
but the new label is 'Implicit NULL',
the LSR will pop the stack instead of
doing the replacement. Although
this value may never appear in the
encapsulation, it needs to be specified in
the Label Distribution Protocol, so a value
is reserved.
iv。 3の値は'内在しているNULL Label'を表します。 これはLSRが割り当てて、分配するかもしれませんが、実際にカプセル化では決して現れないラベルです。 そうでなければ、LSRがスタックの先端でラベルを新しいラベルに取り替えるでしょうが、新しいラベルが'内在しているNULL'であるときに、LSRは交換することの代わりにスタックを飛び出させるでしょう。 この値がカプセル化では決して現れないかもしれませんが、Label Distributionプロトコルで指定されるのが必要であるので、値は予約されています。
v. Values 4-15 are reserved.
v。 値4-15は予約されています。
* The frame relay label can be either 10-bits or
* またはフレームリレーラベルが10ビットであることができる。
Nadeau & Cucchiara Standards Track [Page 6] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[6ページ]。
23-bits depending on the DLCI field size and the
upper 22-bits or upper 9-bits must be zero,
respectively.
23ビットの9DLCI分野サイズに依存して、上側の22ビットビットはそれぞれゼロであるに違いありません。
* For an ATM label the lower 16-bits represents the
VCI, the next 12-bits represents the VPI and the
remaining bits MUST be zero.
* ATMラベルに関しては、低級16ビットはVCIを表します、そして、次の12ビットはVPIを表します、そして、残っているビットはゼロであるに違いありません。
* The Generalized-MPLS (GMPLS) label contains a
value greater than 2^24-1 and used in GMPLS
as defined in [RFC3471]."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
* 「Generalized-MPLS(GMPLS)ラベルは[RFC3471]で定義されるように2^24-1より大きくてGMPLSで中古の値を含んでいます。」 「Multiprotocolラベル切り換え構造、RFC3031」という参照。
MPLS Label Stack Encoding, [RFC3032].
[RFC3032]、MPLSはスタックコード化をラベルします。
Use of Label Switching on Frame Relay Networks,
RFC3034.
フレームリレーネットワーク、RFC3034におけるラベルの切り換えの使用。
MPLS using LDP and ATM VC Switching, RFC3035.
Generalized Multiprotocol Label Switching
(GMPLS) Architecture, [RFC3471]."
SYNTAX Unsigned32 (0..4294967295)
自由民主党と気圧VCの切り換えを使用するMPLS、RFC3035。 「[RFC3471]、一般化されたMultiprotocolは切り換え(GMPLS)を構造とラベルします。」 構文Unsigned32(0..4294967295)
MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label distribution method which is also called
the label advertisement mode [RFC3036].
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
MplsLabelDistributionMethod:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「また、ラベル広告モード[RFC3036]と呼ばれるラベル分配方法。」 「LSRの上の各インタフェースはDemandの上のDownstream UnsolicitedかDownstreamのどちらかで作動するために構成されます。」 「Multiprotocolラベル切り換え構造、RFC3031」という参照。
LDP Specification, RFC3036, Section 2.6.3."
SYNTAX INTEGER {
downstreamOnDemand(1),
downstreamUnsolicited(2)
}
「自由民主党仕様、RFC3036、セクション2.6.3。」 構文整数downstreamOnDemand(1)、downstreamUnsolicited(2)
MplsLdpIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"The LDP identifier is a six octet
MplsLdpIdentifier:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「1d.1d.1d.1d: 2d」STATUSの現在の記述は「自由民主党識別子は6八重奏です」です。
Nadeau & Cucchiara Standards Track [Page 7] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[7ページ]。
quantity which is used to identify a
Label Switching Router (LSR) label space.
Label Switching Router(LSR)ラベルスペースを特定するのに使用される量。
The first four octets identify the LSR and
must be a globally unique value, such as a
32-bit router ID assigned to the LSR, and the
last two octets identify a specific label
space within the LSR."
SYNTAX OCTET STRING (SIZE (6))
「最初の4つの八重奏が、LSRを特定して、IDがLSRに割り当てた32ビットのルータなどのグローバルにユニークな値であるに違いありません、そして、最後の2つの八重奏がLSRの中で特定のラベルスペースを特定します。」 構文八重奏ストリング(サイズ(6))
MplsLsrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Label Switching Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol
(LDP) identifier."
SYNTAX OCTET STRING (SIZE (4))
MplsLdpLabelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Layer 2 label types which are defined for MPLS
LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3)."
SYNTAX INTEGER {
generic(1),
atm(2),
frameRelay(3)
}
MplsLsrIdentifier:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「Label Switching Router(LSR)識別子はLabel Distributionプロトコル(自由民主党)識別子の最初の4バイトです」。 構文八重奏ストリング、((4)) サイズMplsLdpLabelType:、:= 「MPLS LDP、そして/または、CR-自由民主党のために定義されるLayer2ラベル形式は、ジェネリック(1)、気圧(2)、またはframeRelay(3)TEXTUAL-CONVENTION STATUSの現在の記述です」。 構文整数ジェネリック(1)、気圧(2)、frameRelay(3)
MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier within an MPLS network that is
assigned to each LSP. This is assigned at the head
end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are
being swapped to other labels for this LSP. This
object can also be used to disambiguate LSPs that
share the same RSVP sessions between the same
source and destination.
MplsLSPID:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「各LSPに割り当てられるMPLSネットワークの中のユニークな識別子。」 これをLSPのギヤエンドに割り当てて、すべてのLSRsが、このLSPを特定するのに使用できます。 このLSPがネットワークの中で合図されるとき、この値はシグナリングプロトコルによって背負われます。 そして、どのラベルがこのLSPのために他のラベルと交換されているかを特定するのに各LSRでこの識別子を使用できます。 また、同じソースと目的地との同じRSVPセッションを共有するLSPsのあいまいさを除くのにこの物を使用できます。
For LSPs established using CR-LDP, the LSPID is
composed of the ingress LSR Router ID (or any of
its own IPv4 addresses) and a locally unique
CR-LSP ID to that LSR. The first two bytes carry
CR-自由民主党を使用することで設立されたLSPsに関しては、LSPIDはそのLSRにイングレスLSR Router ID(または、それ自身のIPv4アドレスのどれか)と局所的にユニークなCR-LSP IDで構成されます。 最初の2バイトは運ばれます。
Nadeau & Cucchiara Standards Track [Page 8] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[8ページ]。
the CR-LSPID, and the remaining 4 bytes carry
the Router ID. The LSPID is useful in network
management, in CR-LSP repair, and in using
an already established CR-LSP as a hop in
an ER-TLV.
CR-LSPID、および4バイトの残っているキャリーRouter ID。 LSPIDはネットワークマネージメントと、CR-LSP修理と、ホップとしてER-TLVで既に確立したCR-LSPを使用する際に役に立ちます。
For LSPs signaled using RSVP-TE, the LSP ID is
defined as a 16-bit (2 byte) identifier used
in the SENDER_TEMPLATE and the FILTER_SPEC
that can be changed to allow a sender to
share resources with itself. The length of this
object should only be 2 or 6 bytes. If the length
of this octet string is 2 bytes, then it must
identify an RSVP-TE LSPID, or it is 6 bytes,
it must contain a CR-LDP LSPID."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
RSVP-TEを使用することで合図されたLSPsに関しては、LSP IDは送付者がそれ自体とリソースを共有するのを許容するために変えることができるSENDER_TEMPLATEとFILTER_SPECで使用される16ビット(2バイト)の識別子と定義されます。 この物の長さは、2バイトか6バイトであるにすぎないべきです。 「6バイトである、この八重奏ストリングの長さが2バイトであるならRSVP-TE LSPIDを特定しなければなりませんか、またはCR-LDP LSPIDを含まなければなりません。」 参照、「RSVP-Te:」 LSP TunnelsのためのRSVP、[RFC3209]への拡大。
Constraint-Based LSP Setup using LDP,
[RFC3212]."
SYNTAX OCTET STRING (SIZE (2|6))
「自由民主党、[RFC3212]を使用して、規制ベースのLSPはセットアップします。」 構文八重奏ストリング(サイズ(2|6))
MplsLspType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Types of Label Switch Paths (LSPs)
on a Label Switching Router (LSR) or a
Label Edge Router (LER) are:
MplsLspType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「Label Switching Router(LSR)かLabel Edge Router(LER)の上のLabel Switch Paths(LSPs)のタイプは以下の通りです」
unknown(1) -- if the LSP is not known
to be one of the following.
未知(1)--LSPが以下の1つであることは知られないなら。
terminatingLsp(2) -- if the LSP terminates
on the LSR/LER, then this
is an egressing LSP
which ends on the LSR/LER,
terminatingLsp(2)--LSPがLSR/LERで終わるなら、これはLSR/LERで終わるegressing LSPです。
originatingLsp(3) -- if the LSP originates
from this LSR/LER, then
this is an ingressing LSP
which is the head-end of
the LSP,
originatingLsp(3)--LSPがこのLSR/LERから発するなら、これはLSPのギヤエンドであるingressing LSPです。
crossConnectingLsp(4) -- if the LSP ingresses
and egresses on the LSR,
then it is
cross-connecting on that
crossConnectingLsp(4)--LSRの上のLSP進入と出口であるなら、それはそれで接続に交差しています。
Nadeau & Cucchiara Standards Track [Page 9] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[9ページ]。
LSR."
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
"LSR"。 構文整数未知(1)、terminatingLsp(2)、originatingLsp(3)、crossConnectingLsp(4)
MplsOwner ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the local network
management subsystem that originally created
the object(s) in question. The values of
this enumeration are defined as follows:
MplsOwner:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「元々問題の状態で物を作成した企業内情報通信網管理サブシステムを示これが反対するします」。 この列挙の値は以下の通り定義されます:
unknown(1) - the local network management
subsystem cannot discern which
component created the object.
未知(1)--企業内情報通信網管理サブシステムは、どのコンポーネントが物を作成したかを明察できません。
other(2) - the local network management
subsystem is able to discern which component
created the object, but the component is not
listed within the following choices,
e.g., command line interface (cli).
他の(2)--企業内情報通信網管理サブシステムは、どのコンポーネントが物を作成したかを裁量できますが、コンポーネントは以下の選択(例えば、コマンドラインインタフェース(cli))の中に記載されていません。
snmp(3) - The Simple Network Management Protocol
was used to configure this object initially.
snmp(3)--Simple Network Managementプロトコルは、初めはこの物を構成するのに使用されました。
ldp(4) - The Label Distribution Protocol was
used to configure this object initially.
ldp(4)--Label Distributionプロトコルは、初めはこの物を構成するのに使用されました。
crldp(5) - The Constraint-Based Label Distribution
Protocol was used to configure this object
initially.
crldp(5)--ベースのConstraint Label Distributionプロトコルは、初めはこの物を構成するのに使用されました。
rsvpTe(6) - The Resource Reservation Protocol was
used to configure this object initially.
rsvpTe(6)--Resource予約プロトコルは、初めはこの物を構成するのに使用されました。
policyAgent(7) - A policy agent (perhaps in
combination with one of the above protocols) was
used to configure this object initially.
policyAgent(7)--方針エージェント(恐らく上のプロトコルの1つと組み合わせた)は、初めはこの物を構成するのに使用されました。
An object created by any of the above choices
MAY be modified or destroyed by the same or a
different choice."
SYNTAX INTEGER {
unknown(1),
「上の選択のいずれでも作成された物は、同じくらいか異なった選択で変更されるか、または破壊されるかもしれません。」 SYNTAX INTEGER、未知(1)
Nadeau & Cucchiara Standards Track [Page 10] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[10ページ]。
other(2),
snmp(3),
ldp(4),
crldp(5),
rsvpTe(6),
policyAgent(7)
}
他の(2)、snmp(3)、ldp(4)、crldp(5)、rsvpTe(6)、policyAgent(7)
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific
path used by a tunnel. A value of 0 (zero) means
that no path is in use."
SYNTAX Unsigned32(0..4294967295)
MplsPathIndexOrZero:、:= 「ユニークな識別子はトンネルによって使用される特定の経路を特定するのに使用した」TEXTUAL-CONVENTION STATUSの現在の記述。 「0(ゼロ)の値は、どんな経路も使用中でないことを意味します。」 構文Unsigned32(0..4294967295)
MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique value to index (by Path number) an
entry in a table."
SYNTAX Unsigned32(1..4294967295)
MplsPathIndex:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「テーブルでエントリーに索引をつける(Path番号に従って)ユニークな値。」 構文Unsigned32(1..4294967295)
MplsRetentionMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label retention mode which specifies whether
an LSR maintains a label binding for a FEC
learned from a neighbor that is not its next hop
for the FEC.
MplsRetentionMode:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「LSRがFECにおいて拘束力があるようにラベルを維持するかどうか指定するラベル保有モードはFECのためのその次のホップでない隣人から学びました」。
If the value is conservative(1) then advertised
label mappings are retained only if they will be
used to forward packets, i.e., if label came from
a valid next hop.
それらがパケットを進めるのに使用される場合にだけ、広告を出しているラベルマッピングは保有されます、値が保守的な人(1)であるならすなわち、ラベルが次の有効なホップから来たなら。
If the value is liberal(2) then all advertised
label mappings are retained whether they are from
a valid next hop or not."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
「値が自由主義者(2)であるなら、次の有効なホップから来ているか否かに関係なく、すべての広告を出しているラベルマッピングが保有されます。」 「Multiprotocolラベル切り換え構造、RFC3031」という参照。
LDP Specification, RFC3036, Section 2.6.2."
SYNTAX INTEGER {
conservative(1),
liberal(2)
}
「自由民主党仕様、RFC3036、セクション2.6.2。」 構文整数保守的な人(1)、自由主義者(2)
Nadeau & Cucchiara Standards Track [Page 11] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[11ページ]。
MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Describes the configured 32-bit Include-any,
include-all, or exclude-all constraint for
constraint-based link selection."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC3209, Section 4.7.4."
SYNTAX Unsigned32(0..4294967295)
MplsTunnelAffinity:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「規制ベースのリンク選択のためにいくらかすべてを含んでいるか、またはすべてを除いている構成された32ビットのInclude規制について説明します」。 参照、「RSVP-Te:」 「LSP Tunnels、RFC3209、セクション4.7.4のためのRSVPへの拡大。」 構文Unsigned32(0..4294967295)
MplsTunnelIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP Tunnel ID
used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
MplsTunnelIndex:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「mplsTunnelTableへのユニークなインデックス。」 「RSVPを使用することで合図されたトンネルに関して、この値はRSVP-TEセッションに使用されるRSVP Tunnel IDに対応するべきです。」 構文Unsigned32(0..65535)
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The tunnel entry with instance index 0
should refer to the configured tunnel
interface (if one exists).
MplsTunnelInstanceIndex:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「例のインデックス0があるトンネルエントリーは構成されたトンネルのインタフェースについて言及(1つが存在しているなら)であるべきである」。
Values greater than 0, but less than or
equal to 65535, should be used to indicate
signaled (or backup) tunnel LSP instances.
For tunnel LSPs signaled using RSVP,
this value should correspond to the
RSVP LSP ID used for the RSVP-TE
LSP.
0にもかかわらず、65535以下が示すのに使用されるべきであるより大きい値は(または、バックアップ)トンネルLSP例を示しました。 RSVPを使用することで合図されたトンネルLSPsに関しては、この値はRSVP-TE LSPに使用されるRSVP LSP IDに対応するべきです。
Values greater than 65535 apply to FRR
detour instances."
SYNTAX Unsigned32(0|1..65535|65536..4294967295)
「65535以上がFRRに適用する値は例を迂回します。」 構文Unsigned32(0|1..65535|65536..4294967295)
TeHopAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of address for a
Traffic Engineered (TE) Tunnel hop.
TeHopAddressType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「Traffic Engineered(TE)トンネルホップのための一種のアドレスを表す値。」
unknown(0) An unknown address type. This value
MUST be used if the value of the
corresponding TeHopAddress object is a
未知のアドレスがタイプする未知(0)。 対応するTeHopAddress物の値がaであるならこの値を使用しなければなりません。
Nadeau & Cucchiara Standards Track [Page 12] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[12ページ]。
zero-length string. It may also be
used to indicate a TeHopAddress which
is not in one of the formats defined
below.
ゼロ長ストリング。 また、それは、以下で定義された書式の1つにはないTeHopAddressを示すのに使用されるかもしれません。
ipv4(1) An IPv4 network address as defined by
the InetAddressIPv4 TEXTUAL-CONVENTION
[RFC3291].
InetAddressIPv4 TEXTUAL-CONVENTION[RFC3291]によって定義されるようにIPv4ネットワークが記述するipv4(1)。
ipv6(2) A global IPv6 address as defined by
the InetAddressIPv6 TEXTUAL-CONVENTION
[RFC3291].
InetAddressIPv6 TEXTUAL-CONVENTION[RFC3291]によって定義されるようにグローバルなIPv6が記述するipv6(2)。
asnumber(3) An Autonomous System (AS) number as
defined by the TeHopAddressAS
TEXTUAL-CONVENTION.
TeHopAddressAS TEXTUAL-CONVENTIONによって定義されるようにAutonomous System(AS)が付番するasnumber(3)。
unnum(4) An unnumbered interface index as
defined by the TeHopAddressUnnum
TEXTUAL-CONVENTION.
TeHopAddressUnnum TEXTUAL-CONVENTIONによって定義されるように無数のインタフェースが索引をつけるunnum(4)。
lspid(5) An LSP ID for TE Tunnels
(RFC3212) as defined by the
MplsLSPID TEXTUAL-CONVENTION.
lspid(5)、MplsLSPID TEXTUAL-CONVENTIONによって定義されるTE Tunnels(RFC3212)のためのLSP ID。
Each definition of a concrete TeHopAddressType
value must be accompanied by a definition
of a TEXTUAL-CONVENTION for use with that
TeHopAddress.
TEXTUAL-CONVENTIONの定義でそのTeHopAddressとの使用のために具体的なTeHopAddressType価値の各定義に伴わなければなりません。
To support future extensions, the TeHopAddressType
TEXTUAL-CONVENTION SHOULD NOT be sub-typed in
object type definitions. It MAY be sub-typed in
compliance statements in order to require only a
subset of these address types for a compliant
implementation.
今後の拡大、TeHopAddressType TEXTUAL-CONVENTION SHOULDを支持するには、物の型定義にサブタイプされないでください。 それは、対応する実現のためにこれらのアドレスタイプの部分集合だけを必要とする承諾にサブタイプされた声明であるかもしれません。
Implementations must ensure that TeHopAddressType
objects and any dependent objects
(e.g., TeHopAddress objects) are consistent.
An inconsistentValue error must be generated
if an attempt to change a TeHopAddressType
object would, for example, lead to an
undefined TeHopAddress value that is
not defined herein. In particular,
TeHopAddressType/TeHopAddress pairs
must be changed together if the address
type changes (e.g., from ipv6(2) to ipv4(1))."
実現は、TeHopAddressType物とどんな依存する物(例えば、TeHopAddress物)も一貫しているのを確実にしなければなりません。 例えば、TeHopAddressType物を変える試みがここに定義されない未定義のTeHopAddress値につながるなら、inconsistentValue誤りは発生しなければなりません。 「アドレスタイプが変化するなら特に、TeHopAddressType/TeHopAddress組を一緒に変えなければならない、(例えば、ipv6(2)からipv4(1))、」
Nadeau & Cucchiara Standards Track [Page 13] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[13ページ]。
REFERENCE
"TEXTUAL-CONVENTIONs for Internet Network
Addresses, RFC3291.
「インターネットネットワーク・アドレス、RFC3291のための原文のコンベンション」の参照。
Constraint-Based LSP Setup using LDP,
[RFC3212]"
「自由民主党、[RFC3212]を使用する規制ベースのLSPセットアップ」
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
asnumber(3),
unnum(4),
lspid(5)
}
構文整数未知(0)、ipv4(1)、ipv6(2)、asnumber(3)、unnum(4)、lspid(5)
TeHopAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Tunnel hop address,
that is, the address of a node which
an LSP traverses, including the source
and destination nodes. An address may be
very concrete, for example, an IPv4 host
address (i.e., with prefix length 32);
if this IPv4 address is an interface
address, then that particular interface
must be traversed. An address may also
specify an 'abstract node', for example,
an IPv4 address with prefix length
less than 32, in which case, the LSP
can traverse any node whose address
falls in that range. An address may
also specify an Autonomous System (AS),
in which case the LSP can traverse any
node that falls within that AS.
TeHopAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「一般的なTunnelホップアドレス、すなわち、ソースと目的地ノードを含んでいて、LSPが横断するノードのアドレスを指示します」。 例えば、アドレスは非常に具体的であるかもしれなく、IPv4はホスト・アドレス(すなわち、接頭語長さ32で)です。 このIPv4アドレスがインターフェース・アドレスであるなら、その特定のインタフェースを横断しなければなりません。 また、アドレスは32未満の接頭語の長さで'抽象的なノード'、例えばIPv4アドレスを指定するかもしれません、その場合、LSPはアドレスがその範囲に下がるどんなノードも横断できます。 また、アドレスはAutonomous System(AS)を指定するかもしれません、その場合、LSPがそのASの中に落ちるどんなノードも横断できます。
A TeHopAddress value is always interpreted within
the context of an TeHopAddressType value. Every
usage of the TeHopAddress TEXTUAL-CONVENTION
is required to specify the TeHopAddressType object
which provides the context. It is suggested that
the TeHopAddressType object is logically registered
before the object(s) which use the TeHopAddress
TEXTUAL-CONVENTION if they appear in the
same logical row.
TeHopAddress値はTeHopAddressType価値の文脈の中でいつも解釈されます。 TeHopAddress TEXTUAL-CONVENTIONのあらゆる使用法が、文脈を提供するTeHopAddressType物を指定するのに必要です。 船をこぐ前にTeHopAddressType物が論理的に登録されることが提案されます。
The value of a TeHopAddress object must always be
TeHopAddress物の値がいつもあるに違いありません。
Nadeau & Cucchiara Standards Track [Page 14] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[14ページ]。
consistent with the value of the associated
TeHopAddressType object. Attempts to set a
TeHopAddress object to a value which is
inconsistent with the associated TeHopAddressType
must fail with an inconsistentValue error."
SYNTAX OCTET STRING (SIZE (0..32))
関連TeHopAddressType物の値と一致しています。 「inconsistentValue誤りに応じて、関連TeHopAddressTypeに矛盾した値にTeHopAddress物を設定する試みは失敗しなければなりません。」 構文八重奏ストリング(サイズ(0 .32))
TeHopAddressAS ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a two or four octet AS number.
The AS number is represented in network byte
order (MSB first). A two-octet AS number has
the two MSB octets set to zero."
REFERENCE
"Textual Conventions for Internet Network
Addresses, [RFC3291]. The
InetAutonomousSystemsNumber TEXTUAL-CONVENTION
has a SYNTAX of Unsigned32, whereas this TC
has a SYNTAX of OCTET STRING (SIZE (4)).
Both TCs represent an autonomous system number
but use different syntaxes to do so."
SYNTAX OCTET STRING (SIZE (4))
TeHopAddressAS:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「2か4八重奏AS番号を表します」。 AS番号はネットワークバイトオーダー(MSB1番目)で表されます。 「2八重奏のAS番号で、2つのMSB八重奏をゼロに設定します。」 「インターネットネットワーク・アドレスのための原文のコンベンション、[RFC3291]」という参照。 このTCにはOCTET STRINGのSYNTAXがUnsigned32ありますが、InetAutonomousSystemsNumber TEXTUAL-CONVENTIONにSYNTAXがあります。(SIZE(4))。 「両方のTCsは自律システム番号を表しますが、そうするのに異なった構文を使用します。」 構文八重奏ストリング(サイズ(4))
TeHopAddressUnnum ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an unnumbered interface:
TeHopAddressUnnum:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「無数のインタフェースを表します:、」
octets contents encoding
1-4 unnumbered interface network-byte order
1-4 無数のインタフェースネットワークバイトオーダーをコード化する八重奏コンテンツ
The corresponding TeHopAddressType value is
unnum(5)."
SYNTAX OCTET STRING(SIZE(4))
「対応するTeHopAddressType値はunnum(5)です。」 構文八重奏ストリング(サイズ(4))
END
終わり
Nadeau & Cucchiara Standards Track [Page 15] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[15ページ]。
4. References
4. 参照
4.1. Normative References
4.1. 引用規格
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998.
[RFC2434] NartenとT.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、BCP: 26 1998年10月のRFC2434。
[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月のための順応声明。」
[RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswananthan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Federokow, G., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、Rekhter、Y.、タッパン、D.、ファリナッチ、D.、Federokow、G.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification", RFC 3034,
January 2001.
[RFC3034] コンタ、A.、Doolan、P.、およびA.Malis、「フレームリレーにおけるラベルの切り換えの使用は仕様をネットワークでつなぎます」、RFC3034、2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
and ATM VC Switching", RFC 3035, January 2001.
[RFC3035] デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP.Doolan、「自由民主党と気圧VCの切り換えを使用するMPLS」、RFC3035(2001年1月)。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
Nadeau & Cucchiara Standards Track [Page 16] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[16ページ]。
[RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002.
[RFC3212]Jamoussi、B.(エド)、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
[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がそうするかもしれません。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3471, January 2003.
[RFC3471] バーガー、L.、エディタ、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3471、2003年1月。
4.2. Informative References
4.2. 有益な参照
[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月)。
5. Security Considerations
5. セキュリティ問題
This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects.
このモジュールはどんな管理物も定義しません。 代わりに、それは管理物を定義するのに他のMPLS MIBモジュールで使用されるかもしれない1セットの原文のコンベンションを定義します。
Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet.
管理物を定義するMIBモジュールで重要なセキュリティ問題を書くことができるだけです。 したがって、このドキュメントはインターネットのセキュリティに変化も与えません。
6. IANA Considerations
6. IANA問題
IANA has made a MIB OID assignment under the transmission branch,
that is, assigned the mplsStdMIB under { transmission 166 }. This
sub-id is requested because 166 is the ifType for mpls(166) and is
available under transmission.
IANAはトランスミッションでのMIB OID課題を分岐させて、それはそうです、mplsStdMIBがトランスミッション166で割り当てられて。 166がmpls(166)のためのifTypeであり、トランスミッションで利用可能であるので、このサブイドは要求されています。
In the future, MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. The IANA is requested to manage that namespace. New assignments can only be made via a Standards Action as specified in [RFC2434].
将来、MPLSの関連する標準化過程MIBモジュールはmplsStdMIB下位木の下に根づくべきです。 IANAがその名前空間を管理するよう要求されています。 [RFC2434]の指定されるとしてのStandards Actionを通して新しい課題をすることができるだけです。
The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB
specified in this document.
IANAはMPLS-TC-STD-MIBへのまた、割り当てられたmplsStdMIB1を本書では指定させます。
Nadeau & Cucchiara Standards Track [Page 17] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[17ページ]。
7. Contributors
7. 貢献者
This document was created by combining TEXTUAL-CONVENTIONS from current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also contributed greatly to the revisions of this document. These co- authors addresses are included here because they are useful future contacts for information about this document. These co-authors are:
このドキュメントは、現在のMPLS MIBsとTE-WG MIBからTEXTUAL-CONVENTIONSを結合することによって、作成されました。 それぞれのこれらのMIBsの上の共著者はこのMIBで含まれてまた、このドキュメントの改正に大いに寄付されたTEXTUAL-CONVENTIONSに貢献しました。 自分達がこのドキュメントの情報に関する役に立つ今後の接触であるので、共同作者が記述するこれらはここに含まれています。 これらの共著者は以下の通りです。
Cheenu Srinivasan
Bloomberg L.P.
499 Park Ave.
New York, NY 10022
Cheenu SrinivasanブルームバーグL.P.499はAveを駐車します。 ニューヨーク、ニューヨーク 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
Hans Sjostrand
ipUnplugged
P.O. Box 101 60
S-121 28 Stockholm, Sweden
ハンスシェストランドipUnplugged P.O. Box10160秒間-121 28ストックホルム(スウェーデン)
Phone: +46-8-725-5900
EMail: hans@ipunplugged.com
以下に電話をしてください。 +46-8-725-5900 メールしてください: hans@ipunplugged.com
Kireeti Kompella
Juniper Networks
1194 Mathilda Ave
Sunnyvale, CA 94089
Kireeti Kompella杜松は1194マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
Phone: +1-408-745-2000
EMail: kireeti@juniper.net
以下に電話をしてください。 +1-408-745-2000 メールしてください: kireeti@juniper.net
Nadeau & Cucchiara Standards Track [Page 18] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[18ページ]。
8. Acknowledgements
8. 承認
This document is a product of the MPLS Working Group. The editors and contributors would like to thank Mike MacFadden and Adrian Farrel for their helpful comments on several reviews. Also, the editors and contributors would like to give a special acknowledgement to Bert Wijnen for his many detailed reviews. Bert's assistance and guidance is greatly appreciated.
このドキュメントはMPLS作業部会の製品です。 エディタと貢献者はいくつかのレビューのときに彼らの役に立つコメントについてマイクMacFaddenとエードリアン・ファレルに感謝したがっています。 また、エディタと貢献者は彼の多くの詳細なレビューのために特別な承認をバートWijnenに与えたがっています。 バートの支援と指導に大いに感謝します。
9. Authors' Addresses
9. 作者のアドレス
Thomas D. Nadeau Cisco Systems, Inc. BXB300/2/ 300 Beaver Brook Road Boxborough, MA 01719
トーマスD.ナドーシスコシステムズInc.BXB300/2/ 300ビーバーブルック道路Boxborough、MA 01719
Phone: +1-978-936-1470 EMail: tnadeau@cisco.com
以下に電話をしてください。 +1-978-936-1470 メールしてください: tnadeau@cisco.com
Joan E. Cucchiara Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851
ジョーンE.CucchiaraマルコニーコミュニケーションInc.900チェルムズフォード通りローウェル、MA 01851
Phone: +1-978-275-7400 EMail: jcucchiara@mindspring.com
以下に電話をしてください。 +1-978-275-7400 メールしてください: jcucchiara@mindspring.com
Nadeau & Cucchiara Standards Track [Page 19] RFC 3811 MPLS TC MIB June 2004
ナドーとCucchiara規格はMPLS Tc MIB2004年6月にRFC3811を追跡します[19ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
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 & Cucchiara Standards Track [Page 20]
ナドーとCucchiara標準化過程[20ページ]
一覧
スポンサーリンク
