RFC4204 日本語訳
4204 Link Management Protocol (LMP). J. Lang, Ed.. October 2005. (Format: TXT=186515 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Lang, Ed. Request for Comments: 4204 Sonos, Inc. Category: Standards Track October 2005
ワーキンググループのJ.ラング、エドをネットワークでつないでください。コメントのために以下を要求してください。 4204年のSonos Inc.カテゴリ: 標準化過程2005年10月
Link Management Protocol (LMP)
リンク管理プロトコル(LMP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.
スケーラビリティ目的において、ただ一つの交通工学(TE)リンクを形成するために複数のデータ・リンクを結合できます。 その上、TEリンクの管理は、バンドにおけるメッセージングに制限されませんが、代わりにバンドの外でテクニックを使用し終わることができます。 このドキュメントは1組のノードの間で稼働していて、TEリンクを管理するのに使用されるリンク管理プロトコル(LMP)を指定します。 明確に、LMPは、保護/回復目的のために複数の種類のネットワークでコントロールチャンネルの接続性を維持して、データ・リンクの物理的な接続性について確かめて、リンク特性の情報を関連させて、川下のアラームを抑圧して、リンクの故障をローカライズするのに使用されるでしょう。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. LMP Overview ....................................................6
3. Control Channel Management ......................................8
3.1. Parameter Negotiation ......................................9
3.2. Hello Protocol ............................................10
4. Link Property Correlation ......................................13
5. Verifying Link Connectivity ....................................15
5.1. Example of Link Connectivity Verification .................18
6. Fault Management ...............................................19
6.1. Fault Detection ...........................................20
6.2. Fault Localization Procedure ..............................20
6.3. Examples of Fault Localization ............................21
1. 序論…3 1.1. 用語…5 2. LMP概要…6 3. チャンネル管理を制御してください…8 3.1. パラメタ交渉…9 3.2. こんにちは、議定書を作ってください…10 4. 特性の相関関係をリンクしてください…13 5. リンクの接続性について確かめます…15 5.1. リンク接続性検証に関する例…18 6. 障害管理…19 6.1. 欠点検出…20 6.2. 欠点ローカライズ手順…20 6.3. 欠点ローカライズに関する例…21
Lang Standards Track [Page 1] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[1ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
6.4. Channel Activation Indication .............................22
6.5. Channel Deactivation Indication ...........................23
7. Message_Id Usage ...............................................23
8. Graceful Restart ...............................................24
9. Addressing .....................................................25
10. Exponential Back-off Procedures ...............................26
10.1. Operation ...............................................26
10.2. Retransmission Algorithm ................................27
11. LMP Finite State Machines .....................................28
11.1. Control Channel FSM .....................................28
11.2. TE Link FSM .............................................32
11.3. Data Link FSM ...........................................34
12. LMP Message Formats ...........................................38
12.1. Common Header ...........................................39
12.2. LMP Object Format .......................................41
12.3. Parameter Negotiation Messages ..........................42
12.4. Hello Message (Msg Type = 4) ............................43
12.5. Link Verification Messages ..............................43
12.6. Link Summary Messages ...................................47
12.7. Fault Management Messages ...............................49
13. LMP Object Definitions ........................................50
13.1. CCID (Control Channel ID) Class .........................50
13.2. NODE_ID Class ...........................................51
13.3. LINK_ID Class ...........................................52
13.4. INTERFACE_ID Class ......................................53
13.5. MESSAGE_ID Class ........................................54
13.6. CONFIG Class ............................................55
13.7. HELLO Class .............................................56
13.8. BEGIN_VERIFY Class ......................................56
13.9. BEGIN_VERIFY_ACK Class ..................................58
13.10. VERIFY_ID Class ........................................59
13.11. TE_LINK Class ..........................................59
13.12. DATA_LINK Class ........................................61
13.13. CHANNEL_STATUS Class ...................................65
13.14. CHANNEL_STATUS_REQUEST Class ...........................68
13.15. ERROR_CODE Class .......................................70
14. References ....................................................71
14.1. Normative References ....................................71
14.2. Informative References ..................................72
15. Security Considerations .......................................73
15.1. Security Requirements ...................................73
15.2. Security Mechanisms .....................................74
16. IANA Considerations ...........................................76
17. Acknowledgements ..............................................83
18. Contributors ..................................................83
6.4. チャンネル活性化指示…22 6.5. チャンネル非活性化指示…23 7. メッセージ_イド用法…23 8. 優雅な再開…24 9. 扱います。25 10. 指数の下に後部手順…26 10.1. 操作…26 10.2. Retransmissionアルゴリズム…27 11. LMP有限状態機械…28 11.1. チャンネルFSMを制御してください…28 11.2. TeリンクFSM…32 11.3. データはFSMをリンクします…34 12. LMPメッセージ・フォーマット…38 12.1. 一般的なヘッダー…39 12.2. LMPオブジェクト形式…41 12.3. パラメタ交渉メッセージ…42 12.4. こんにちは、メッセージ(エムエスジーは=4をタイプします)…43 12.5. 検証メッセージをリンクしてください…43 12.6. 概要メッセージをリンクしてください…47 12.7. 障害管理メッセージ…49 13. LMPオブジェクト定義…50 13.1. CCID(コントロールチャンネルID)のクラス…50 13.2. ノード_IDのクラス…51 13.3. _IDのクラスをリンクしてください…52 13.4. _IDのクラスを連結してください…53 13.5. メッセージ_IDのクラス…54 13.6. コンフィグのクラス…55 13.7. こんにちは、クラス…56 13.8. 始まってください。_クラスについて確かめてください…56 13.9. 始まってください。__ACKのクラスについて確かめてください…58 13.10. _IDのクラスについて確かめてください…59 13.11. Te_はクラスをリンクします…59 13.12. データ_はクラスをリンクします…61 13.13. _状態のクラスはチャネルを開設します…65 13.14. チャンネル_状態_はクラスを要求します…68 13.15. 誤り_はクラスをコード化します…70 14. 参照…71 14.1. 標準の参照…71 14.2. 有益な参照…72 15. セキュリティ問題…73 15.1. セキュリティ要件…73 15.2. セキュリティメカニズム…74 16. IANA問題…76 17. 承認…83 18. 貢献者…83
Lang Standards Track [Page 2] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[2ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
1. Introduction
1. 序論
Networks are being developed with routers, switches, crossconnects, dense wavelength division multiplexed (DWDM) systems, and add-drop multiplexors (ADMs) that use a common control plane, e.g., Generalized MPLS (GMPLS), to dynamically allocate resources and to provide network survivability using protection and restoration techniques. A pair of nodes may have thousands of interconnects, where each interconnect may consist of multiple data links when multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division multiplexed (TDM) slots or wavelength division multiplexed (WDM) wavelengths at Layer 1) is used. For scalability purposes, multiple data links may be combined into a single traffic-engineering (TE) link.
ネットワークはダイナミックにリソースを割り当てて、保護と回復のテクニックを使用することでネットワークの生存性を提供するのに、共通制御機構飛行機、例えばGeneralized MPLS(GMPLS)を使用するルータ、スイッチ、crossconnects、濃い波長分割多重送信された(DWDM)システム、および-低下するように言い足しているマルチプレクサー(ADMs)で発展しています。 1組のノードには、何千もの内部連絡があるかもしれません、(Layer1の例えば、Layer2のFrame Relay DLCIs、時間の分割の多重送信された(TDM)スロットまたは波長の分割の多重送信された(WDM)波長)を多重送信するのが使用されているとき、各内部連絡が複数のデータ・リンクから成るかもしれないところで。 スケーラビリティ目的のために、複数のデータ・リンクがただ一つの交通工学(TE)リンクに結合されるかもしれません。
To enable communication between nodes for routing, signaling, and link management, there must be a pair of IP interfaces that are mutually reachable. We call such a pair of interfaces a control channel. Note that "mutually reachable" does not imply that these two interfaces are (directly) connected by an IP link; there may be an IP network between the two. Furthermore, the interface over which the control messages are sent/received may not be the same interface over which the data flows. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links and verify reachability of the control channel. For the purposes of this document, such nodes are considered "LMP neighbors" or simply "neighboring nodes".
ルーティング、シグナリング、およびリンク管理のためのノードのコミュニケーションを可能にするために、1組の互いに届いているIPインタフェースがあるに違いありません。 私たちは、インタフェースの制御チャンネルあたり1組にそのようなものに電話をします。 それに注意してください、「互いに届く、」 これらの2つのインタフェースがIPリンクによって(直接)接続されるのを含意しません。 2つの間には、IPネットワークがあるかもしれません。 その上、コントロールメッセージが送るか、または受信されているインタフェースはデータが流れる同じインタフェースでないかもしれません。 このドキュメントは、1組のノードの間で稼働するリンク管理プロトコル(LMP)を指定して、TEリンクを管理して、制御チャンネルの可到達性について確かめるのに使用されます。 このドキュメントの目的のために、そのようなノードは「LMP隣人」か単に「隣接しているノード」であると考えられます。
In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. For example, a control channel could use a separate virtual circuit, wavelength, fiber, Ethernet link, an IP tunnel routed over a separate management network, or a multi-hop IP network. A consequence of allowing the control channel(s) between two nodes to be logically or physically diverse from the associated data links is that the health of a control channel does not necessarily correlate to the health of the data links, and vice- versa. Therefore, a clean separation between the fate of the control channel and data links must be made. New mechanisms must be developed to manage the data links, both in terms of link provisioning and fault management.
GMPLSでは、2つの隣接しているノードの間の制御チャンネルは、それらのノードの間のデータ・リンクと同じ物理的な媒体を使用するのにもう必要ではありません。 例えば、制御チャンネルは別々の仮想の回路、波長、ファイバー、イーサネットリンク、別々のマネジメント・ネットワークの上に発送されたIPトンネル、またはマルチホップIPネットワークを使用できました。 2つのノードの間の制御チャンネルが関連データリンクから論理的か物理的に多様であることを許容する結果は制御チャンネルの健康が必ずデータ・リンク、および副versaの健康に関連するというわけではないということです。 したがって、制御チャンネルとデータ・リンクの運命の間の清潔な分離をしなければなりません。 リンクの食糧を供給するのと障害管理に関してデータ・リンクを管理するために新しいメカニズムを開発しなければなりません。
Among the tasks that LMP accomplishes is checking that the grouping of links into TE links, as well as the properties of those links, are the same at both end points of the links -- this is called "link property correlation". Also, LMP can communicate these link properties to the IGP module, which can then announce them to other
LMPが達成するタスクの中に、TEリンクへのリンクの組分け、およびそれらのリンクの特性がリンクの両端点で同じであることをチェックするのがあります--これは「リンク特性の相関関係」と呼ばれます。 また、LMPはIGPモジュールへのこれらのリンクの特性を伝えることができます。(次に、モジュールはそれらを他に発表できます)。
Lang Standards Track [Page 3] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[3ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
nodes in the network. LMP can also tell the signaling module the mapping between TE links and control channels. Thus, LMP performs a valuable "glue" function in the control plane.
ネットワークにおけるノード。 また、LMPはTEリンクの間のマッピングをシグナル伝達モジュールに言って、チャンネルをコントロールに言うことができます。 したがって、LMPは制御飛行機で貴重な「接着剤」機能を実行します。
Note that while the existence of the control network (single or multi-hop) is necessary for enabling communication, it is by no means sufficient. For example, if the two interfaces are separated by an IP network, faults in the IP network may result in the lack of an IP path from one interface to another, and therefore an interruption of communication between the two interfaces. On the other hand, not every failure in the control network affects a given control channel, hence the need for establishing and managing control channels.
規制ネットワーク(シングルかマルチホップ)の存在がコミュニケーションを可能にするのに必要ですが、それが決して十分でないことに注意してください。 例えば、2つのインタフェースがIPネットワークによって切り離されるなら、IPネットワークにおける欠点は、2つのインタフェースの間で1つのインタフェースから別のインタフェースまでのIP経路の不足をもたらして、したがって、通信の不通をもたらすかもしれません。 他方では、規制ネットワークにおけるあらゆる失敗が与えられた制御チャンネル、したがって、制御チャンネルを確立して、管理する必要性に影響するというわけではありません。
For the purposes of this document, a data link may be considered by each node that it terminates on as either a 'port' or a 'component link', depending on the multiplexing capability of the endpoint on that link; component links are multiplex capable, whereas ports are not multiplex capable. This distinction is important since the management of such links (including, for example, resource allocation, label assignment, and their physical verification) is different based on their multiplexing capability. For example, a Frame Relay switch is able to demultiplex an interface into virtual circuits based on DLCIs; similarly, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams. If multiple interfaces are grouped together into a single TE link using link bundling [RFC4201], then the link resources must be identified using three levels: Link_Id, component interface Id, and label identifying virtual circuit, timeslot, etc. Resource allocation happens at the lowest level (labels), but physical connectivity happens at the component link level. As another example, consider the case where an optical switch (e.g., PXC) transparently switches OC-192 lightpaths. If multiple interfaces are once again grouped together into a single TE link, then link bundling [RFC4201] is not required and only two levels of identification are required: Link_Id and Port_Id. In this case, both resource allocation and physical connectivity happen at the lowest level (i.e., port level).
このドキュメントの目的のために、データ・リンクはそれが'ポート'か'コンポーネントリンク'のどちらかとして終わる各ノードによって考えられるかもしれません、そのリンクの上の終点のマルチプレクシング能力によって。 コンポーネントリンクはマルチプレックスできますが、ポートはマルチプレックスできません。 能力を多重送信することに基づいてそのようなリンク(例えば資源配分、ラベル課題、および彼らの物理的な検証を含んでいる)の管理が異なっているので、この区別は重要です。 例えば、Frame Relayスイッチは仮想の回路へのインタフェースがDLCIsに基礎づけた「反-マルチプレックス」にできます。 同様に、OC-192インタフェースがあるSonet crossconnectはOC-192が4つのOC-48ストリームに流す「反-マルチプレックス」にできるかもしれません。複数のインタフェースがリンクバンドリング[RFC4201]を使用することで単一のTEリンクに一緒に分類されるなら、3つのレベルを使用することでリンクリソースを特定しなければなりません: リンク_Id、コンポーネントインタフェースId、および仮想の回路、timeslotなどを特定するラベル 資源配分は最も低いレベル(ラベル)で起こりますが、物理的な接続性はコンポーネントリンク・レベルで起こります。 別の例と、光学スイッチ(例えば、PXC)が透過的にOC-192 lightpathsを切り換えるケースを考えてください。 複数のインタフェースがもう一度単一のTEリンクに一緒に分類されるなら、リンクバンドリング[RFC4201]は必要ではありません、そして、識別の2つのレベルだけが必要です: リンク_イドとポート_アイダホ州 この場合、資源配分と物理的な接続性の両方が最も低いレベルで起こります(すなわち、レベルを移植してください)。
To ensure interworking between data links with different multiplexing capabilities, LMP-capable devices SHOULD allow sub-channels of a component link to be locally configured as (logical) data links. For example, if a Router with 4 OC-48 interfaces is connected through a 4:1 MUX to a cross-connect with OC-192 interfaces, the cross-connect should be able to configure each sub-channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data link.
異なったマルチプレクシング能力とのデータ・リンクの間で織り込むのを保証するために、(論理的)のデータがリンクされるとき、LMPできるデバイスSHOULDは、コンポーネントリンクのサブチャンネルが局所的に構成されるのを許容します。 例えば、4つのOC-48インタフェースがあるRouterが4:1多重化装置を通してOC-192インタフェースで十字接続に接続されるなら、十字接続はデータ・リンクとしてそれぞれのサブチャンネル(4:1多重化装置であるなら、例えば、STS-48c SPEはSonet多重化装置である)を構成できるべきです。
Lang Standards Track [Page 4] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[4ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
LMP is designed to support aggregation of one or more data links into a TE link (either ports into TE links, or component links into TE links). The purpose of forming a TE link is to group/map the information about certain physical resources (and their properties) into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling.
LMPは、TEリンク(TEリンクへのポートかTEリンクへのコンポーネントリンクのどちらか)に1個以上のデータ・リンクの集合をサポートするように設計されています。 TEリンクを形成する目的は、ある物理資源(そして、彼らの特性)の情報を経路計算の目的のためのConstrained SPF、およびGMPLSシグナリングによって使用される情報に分類するか、または写像することです。
1.1. Terminology
1.1. 用語
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The reader is assumed to be familiar with the terminology in [RFC3471], [RFC4202], and [RFC4201].
読者が[RFC3471]、[RFC4202]、および[RFC4201]の用語によく知られさせると思われます。
Bundled Link:
添付されたリンク:
As defined in [RFC4201], a bundled link is a TE link such that,
for the purpose of GMPLS signaling, a combination of <link
identifier, label> is not sufficient to unambiguously identify the
appropriate resources used by an LSP. A bundled link is composed
of two or more component links.
添付されたリンクが[RFC4201]で定義されるようにTEリンクであるので、GMPLSシグナリングの目的、<リンク識別子の組み合わせでは、ラベル>はLSPで明白に適切な運用資金を特定するために十分ではありません。 添付されたリンクは2個以上のコンポーネントリンクで構成されます。
Control Channel:
チャンネルを監督してください:
A control channel is a pair of mutually reachable interfaces that
are used to enable communication between nodes for routing,
signaling, and link management.
制御チャンネルはルーティング、シグナリング、およびリンク管理のためのノードの間のコミュニケーションを可能にするのに使用される互いに届いているインタフェースの1組です。
Component Link:
コンポーネントリンク:
As defined in [RFC4201], a component link is a subset of resources
of a TE Link such that (a) the partition is minimal, and (b)
within each subset a label is sufficient to unambiguously identify
the appropriate resources used by an LSP.
(b) (a) パーティションはコンポーネントリンクが[RFC4201]で定義されるようにTE Linkに関するリソースの部分集合であるので、最小限です、そして、各部分集合の中では、ラベルはLSPで明白に適切な運用資金を特定するために十分です。
Data Link:
データはリンクされます:
A data link is a pair of interfaces that are used to transfer user
data. Note that in GMPLS, the control channel(s) between two
adjacent nodes are no longer required to use the same physical
medium as the data links between those nodes.
データ・リンクは利用者データを移すのに使用される1組のインタフェースです。 GMPLSでは、2つの隣接しているノードの間の制御チャンネルはそれらのノードの間のデータ・リンクと同じ物理的な媒体を使用するのにもう必要でないことに注意してください。
Link Property Correlation:
特性の相関関係をリンクしてください:
This is a procedure to correlate the local and remote properties
of a TE link.
これはTEリンクの地方の、そして、リモートな特性を関連させる手順です。
Lang Standards Track [Page 5] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[5ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Multiplex Capability:
能力を多重送信してください:
The ability to multiplex/demultiplex a data stream into sub-rate
streams for switching purposes.
サブレートへのデータ・ストリームが切り換え目的のために流すマルチプレックス/「反-マルチプレックス」への能力。
Node_Id:
ノード_イド:
For a node running OSPF, the LMP Node_Id is the same as the
address contained in the OSPF Router Address TLV. For a node
running IS-IS and advertising the TE Router ID TLV, the Node_Id is
the same as the advertised Router ID.
OSPFを実行するノードに関しては、LMP Node_IdはOSPF Router Address TLVに含まれたアドレスと同じです。 そして、ノード実行、-、TE Router ID TLVの広告を出して、Node_Idは広告を出しているRouter IDと同じです。
Port:
ポート:
An interface that terminates a data link.
データ・リンクを終えるインタフェース。
TE Link:
Teリンク:
As defined in [RFC4202], a TE link is a logical construct that
represents a way to group/map the information about certain
physical resources (and their properties) that interconnect LSRs
into the information that is used by Constrained SPF for the
purpose of path computation, and by GMPLS signaling.
[RFC4202]で定義されるように、TEリンクは経路計算の目的のためのConstrained SPF、およびGMPLSシグナリングによって使用される情報とLSRsとインタコネクトするある物理資源(そして、彼らの特性)の情報を分類するか、または写像する方法を表す論理的な構造物です。
Transparent:
透明:
A device is called X-transparent if it forwards incoming signals
from input to output without examining or modifying the X aspect
of the signal. For example, a Frame Relay switch is network-layer
transparent; an all-optical switch is electrically transparent.
入力から出力まで信号のX局面を調べるか、または変更しないで入って来る信号を転送するなら、デバイスはX透明であると呼ばれます。 例えば、Frame Relayスイッチはネットワーク層透明です。 オール光学のスイッチは電気的に透明です。
2. LMP Overview
2. LMP概要
The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify the TE link configuration.
LMPの2つのコア手順が、コントロールチャンネル管理であり、特性の相関関係をリンクします。 コントロールチャンネル管理は、隣接しているノードの間の制御チャンネルを確立して、維持するのに使用されます。 これはConfig交換処理とノードの間の速い生きている生活費メカニズムを使用し終わっています。 低レベルメカニズムがコントロールチャンネルの故障を検出するために利用可能でないなら、後者が必要です。 リンク特性の相関関係は、TEリンクの特性を同期させて、TEリンク構成について確かめるのに使用されます。
LMP requires that a pair of nodes have at least one active bi- directional control channel between them. Each direction of the control channel is identified by a Control Channel Id (CC_Id), and the two directions are coupled together using the LMP Config message exchange. Except for Test messages, which may be limited by the
LMPは、それらの間には、1組のノードに少なくとも1個の活発な両性愛者の方向の制御チャンネルがあるのを必要とします。 制御チャンネルの各方向はControl Channel Idによって特定されます、そして、(_IdをCCしてください)2つの方向が、LMP Config交換処理を使用することで連結されます。 Testメッセージを除いて、どれが制限されるかもしれないか。
Lang Standards Track [Page 6] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[6ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
transport mechanism for in-band messaging, all LMP packets are run over UDP with an LMP port number. The link level encoding of the control channel is outside the scope of this document.
バンドにおけるメッセージングのためにメカニズムを輸送してください、そして、すべてのLMPパケットはLMPポートナンバーがあるUDPの上の走行です。 このドキュメントの範囲の外に制御チャンネルのリンク・レベルコード化があります。
An "LMP adjacency" is formed between two nodes when at least one bi- directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes.
少なくとも1個の両性愛者の方向の制御チャンネルがそれらの間で確立されるとき、「LMP隣接番組」は2つのノードの間で形成されます。 各隣接番組に、複合管理チャンネルは同時に、活発であるかもしれません。 しかしながら、それぞれの制御チャンネルのために個別にコントロールチャンネルパラメタを交渉しなければなりません。 制御チャンネルの上に生きているLMP速い生活費を使用するなら、制御チャンネルの上とLMP Helloメッセージを交換しなければなりません。 他のLMPメッセージは1組の隣接しているノードの間の活発な制御チャンネルのどれかの上に送られるかもしれません。 1個以上の活発な制御チャンネルがシグナリング、ルーティング、およびリンク特性の相関関係目的のために論理的な制御チャンネルに分類されるかもしれません。
The link property correlation function of LMP is designed to aggregate multiple data links (ports or component links) into a TE link and to synchronize the properties of the TE link. As part of the link property correlation function, a LinkSummary message exchange is defined. The LinkSummary message includes the local and remote Link_Ids, a list of all data links that comprise the TE link, and various link properties. A LinkSummaryAck or LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummary message indicating agreement or disagreement on the link properties.
LMPのリンク特性の相関関数は、TEリンクへの複数のデータ・リンク(ポートかコンポーネントリンク)に集めて、TEリンクの特性を同期させるように設計されています。 リンク特性の相関関数の一部と、LinkSummary交換処理は定義されます。 LinkSummaryメッセージは地方の、そして、リモートなLink_Ids、TEリンク、および様々なリンクの特性を包括するすべてのデータ・リンクのリストを含んでいます。 リンク所有地の上に協定か不一致を示すLinkSummaryメッセージの領収書に対応してLinkSummaryAckかLinkSummaryNackメッセージを送らなければなりません。
LMP messages are transmitted reliably using Message_Ids and retransmissions. Message_Ids are carried in MESSAGE_ID objects. No more than one MESSAGE_ID object may be included in an LMP message. For control-channel-specific messages, the Message_Id is within the scope of the control channel over which the message is sent. For TE-link-specific messages, the Message_Id is within the scope of the LMP adjacency. The value of the Message_Id is monotonically increasing and wraps when the maximum value is reached.
LMPメッセージは、Message_Idsと「再-トランスミッション」を確かに使用することで送られます。 メッセージ_IdsはMESSAGE_IDオブジェクトで運ばれます。 1個未満のMESSAGE_IDオブジェクトがLMPメッセージに含まれるかもしれません。 コントロールチャンネル詳細メッセージに関しては、メッセージが送られる制御チャンネルの範囲の中にMessage_Idがあります。 TEリンク詳細メッセージに関しては、LMP隣接番組の範囲の中にMessage_Idがあります。 Idが単調に増強しているMessage_と最大値に達している機密の値。
In this document, two additional LMP procedures are defined: link connectivity verification and fault management. These procedures are particularly useful when the control channels are physically diverse from the data links. Link connectivity verification is used for data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels or component link identifiers, depending on the configuration), and physical connectivity verification. This is done by sending Test messages over the data links and TestStatus messages back over the control channel. Note that the Test message is the only LMP message that must be transmitted over the data link. The ChannelStatus message exchange is used between adjacent nodes for both the suppression of downstream alarms and the localization of faults for protection and restoration.
本書では、2つの追加LMP手順が定義されます: 接続性検証と障害管理をリンクしてください。 制御チャンネルがデータ・リンクから物理的に多様であるときに、これらの手順は特に役に立ちます。 リンク接続性検証はデータ飛行機発見、Interface_Id交換(インタフェース_IdsはGMPLSシグナリングに使用されます、ポートラベルかコンポーネントリンク識別子として、構成によって)、および物理的な接続性検証に使用されます。 制御チャンネルの上にデータ・リンクとTestStatusメッセージの上でメッセージをTestに送ることによって、これをします。 Testメッセージがデータ・リンクの上に送らなければならない唯一のLMPメッセージであることに注意してください。 ChannelStatus交換処理は川下のアラームの秘匿と保護のための欠点のローカライズと回復の両方に隣接しているノードの間で使用されます。
Lang Standards Track [Page 7] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[7ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
For LMP link connectivity verification, the Test message is transmitted over the data links. For X-transparent devices, this requires examining and modifying the X aspect of the signal. The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various aspects of transparency, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data links must lose their transparency simultaneously; but, at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST be terminated by the same two control elements that control the TE link. Since the BeginVerify message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links in and out of the transparent mode.
LMPリンク接続性検証において、Testメッセージはデータ・リンクの上に送られます。 X透明なデバイスに関しては、これはX局面を調べて、変更するのを信号を要求します。 LMPリンク接続性検証手続は、制御チャンネルの上にBeginVerify交換処理を使用することで連携しています。 透明の種々相をサポートするために、Verify Transport MechanismはBeginVerifyとBeginVerifyAckメッセージに含まれています。 すべてのデータ・リンクが同時にそれらの透明を失わなければならないという要件が全くないことに注意してください。 しかし、最小限では、一度に一つそれらを終えるのは可能であるに違いありません。 また、制御チャンネルとTEリンクが同じ物理的な媒体を使用するという要件が全くありません。 しかしながら、TEリンクを制御するのと同じ2個の制御要素で制御チャンネルを終えなければなりません。 BeginVerify交換処理がTest手順を調整するので、また、それは透過モードと透過モードからデータ・リンクの変遷を自然に調整します。
The LMP fault management procedure is based on a ChannelStatus message exchange that uses the following messages: ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. The ChannelStatus message is sent unsolicited and is used to notify an LMP neighbor about the status of one or more data channels of a TE link. The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus message. The ChannelStatusRequest message is used to query an LMP neighbor for the status of one or more data channels of a TE Link. The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest message and indicate the states of the queried data links.
LMP障害管理手順は以下のメッセージを使用するChannelStatus交換処理に基づいています: ChannelStatus、ChannelStatusAck、ChannelStatusRequest、およびChannelStatusResponse。 そして、ChannelStatusメッセージを送る、求められていなさ、TEリンクの1人以上のデータ・チャンネルの状態に関してLMP隣人に通知するために、使用されます。 ChannelStatusAckメッセージは、ChannelStatusメッセージの領収書を受け取ったことを知らせるのに使用されます。 ChannelStatusRequestメッセージは、TE Linkの1人以上のデータ・チャンネルの状態にLMP隣人について質問するのに使用されます。 ChannelStatusResponseメッセージは、ChannelStatusRequestメッセージの領収書を受け取ったことを知らせて、質問されたデータ・リンクの州を示すのに使用されます。
3. Control Channel Management
3. コントロールチャンネル管理
To initiate an LMP adjacency between two nodes, one or more bi- directional control channels MUST be activated. The control channels can be used to exchange control-plane information such as link provisioning and fault management information (implemented using a messaging protocol such as LMP, proposed in this document), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [RFC3209]), and network topology and state distribution information (implemented using traffic engineering extensions of protocols such as OSPF [RFC3630] and IS-IS [RFC3784]).
2つのノード、1または、より両性愛者の方向の制御チャンネルの間のLMP隣接番組を開始するのは活性であるに違いありません。 そして、リンクの食糧を供給するのや障害管理情報(本書では提案されたLMPなどのメッセージング・プロトコルを使用することで、実装される)の制御飛行機情報、経路管理、ラベル分配情報(RSVP-TE[RFC3209]などのシグナリングプロトコルを使用することで、実装される)、ネットワーク形態、および州の分配情報を交換するのに制御チャンネルを使用できる、(OSPF[RFC3630]などのプロトコルの交通工学拡張子を使用することで実装される、-、[RFC3784。)
For the purposes of LMP, the exact implementation of the control channel is not specified; it could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, or the overhead bytes of a data link. Each node assigns a node-wide, unique, 32-bit, non-zero integer control channel identifier (CC_Id). This identifier comes from the
LMPの目的として、制御チャンネルの正確な実装は指定されません。 例えば、それは、別々のマネジメント・ネットワーク、またはデータ・リンクのオーバーヘッドバイトを通した別々の波長かファイバー、イーサネットリンク、IPトンネルであるかもしれません。 各ノードはノード全体の、そして、ユニークで、32ビットの非ゼロ整数コントロールチャンネル識別子を割り当てます(_IdをCCしてください)。 この識別子は来ます。
Lang Standards Track [Page 8] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[8ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
same space as the unnumbered interface Id. Furthermore, LMP packets are run over UDP with an LMP port number. Thus, the link level encoding of the control channel is not part of the LMP specification.
無数のインタフェースアイダホ州と同じスペース その上、LMPパケットはLMPポートナンバーがあるUDPの上の走行です。 したがって、制御チャンネルのリンク・レベルコード化はLMP仕様の一部ではありません。
To establish a control channel, the destination IP address on the far end of the control channel must be known. This knowledge may be manually configured or automatically discovered. Note that for in- band signaling, a control channel could be explicitly configured on a particular data link. In this case, the Config message exchange can be used to dynamically learn the IP address on the far end of the control channel. This is done by sending the Config message with the unicast IP source address and the multicast IP destination address (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack messages MUST be sent to the source IP address found in the IP header of the received Config message.
目的地IPの制御チャンネルを証明するために、制御チャンネルの遠端に関するアドレスを知っていなければなりません。 この知識は、手動で構成されるか、または自動的に発見されるかもしれません。 コネバンドシグナリングにおいて、特定のデータ・リンクの上で制御チャンネルを明らかに構成できたことに注意してください。 この場合、ダイナミックに制御チャンネルの遠端に関するIPアドレスを学ぶのにConfig交換処理を使用できます。 ユニキャストがあるConfigメッセージにIPソースアドレスを送って、受信者IPアドレスをマルチキャストに送ることによってこれをする、(224.0 .0 .1かff02: : 1)。 アドレスが受信されたConfigメッセージのIPヘッダーで見つけたソースIPにConfigAckとConfigNackメッセージを送らなければなりません。
Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. As such, control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH).
制御チャンネルはTEリンクの如何にかかわらず存在しています、そして、複合管理チャンネルは同時に、1組のノードの間で活発であるかもしれません。 異なった方法で独特の制御チャンネルを実現できます。 1つは実装されて、別のものである間、ファイバーの外でファイバーでは、実装されるかもしれないということであるかもしれません。 そういうものとして、それぞれの独特の制御チャンネルの上にコントロールチャンネルパラメタを交渉しなければなりません、そして、他のメカニズムが利用可能でないなら、LMPの接続性を維持するためにそれぞれの制御チャンネルの上とLMP Helloパケットを交換しなければなりません。 制御チャンネルが各ノードで電気的に終えられるので、コントロールチャンネルの故障を検出するのは下層(例えば、Sonet/SDH)を使用することで可能であるかもしれません。
There are four LMP messages that are used to manage individual control channels. They are the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel to which they refer. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes.
独特の制御チャンネルを管理するのに使用される4つのLMPメッセージがあります。 それらは、Configと、ConfigAckと、ConfigNackと、Helloメッセージです。 それらが参照するチャンネルでこれらのメッセージを送らなければなりません。 他のすべてのLMPメッセージがノードに隣接して1組のLMPの間の活発な制御チャンネルのどれかの上に送られるかもしれません。
In order to maintain an LMP adjacency, it is necessary to have at least one active control channel between a pair of adjacent nodes (recall that multiple control channels can be active simultaneously between a pair of nodes). In the event of a control channel failure, alternate active control channels can be used and it may be possible to activate additional control channels as described below.
LMP隣接番組を維持するために、1組の隣接しているノードの間には、少なくとも1個の活発な制御チャンネルがあるのが必要です(複合管理チャンネルが同時に1組のノードの間で活発である場合があると思い出してください)。 コントロールチャンネルの故障の場合、代替の活発な制御チャンネルを使用できます、そして、以下で説明される追加制御チャンネルを動かすのは可能であるかもしれません。
3.1. Parameter Negotiation
3.1. パラメタ交渉
Control channel activation begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N bit in the object header). Negotiable objects can be used to let LMP peers
パラメタ交渉交換がConfig、ConfigAck、およびConfigNackメッセージを使用している状態で、コントロールチャンネル活性化は始まります。 LMPオブジェクトを使用するのはこれらのメッセージの内容に建てられます。(交渉可能であるか、またはオブジェクトは譲渡禁止である場合があります(オブジェクトヘッダーのNビットで、特定されます))。 LMP同輩をさせるのに交渉可能なオブジェクトを使用できます。
Lang Standards Track [Page 9] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[9ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
agree on certain values. Non-negotiable objects are used for the announcement of specific values that do not need, or do not allow, negotiation.
ある値に同意してください。 譲渡禁止のオブジェクトは交渉を必要でなく、また許さない特定の値の発表に使用されます。
To activate a control channel, a Config message MUST be transmitted to the remote node, and in response, a ConfigAck message MUST be received at the local node. The Config message contains the Local Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for reliable messaging, and a CONFIG object. It is possible that both the local and remote nodes initiate the configuration procedure at the same time. To avoid ambiguities, the node with the higher Node_Id wins the contention; the node with the lower Node_Id MUST stop transmitting the Config message and respond to the Config message it received. If the Node_Ids are equal, then one (or both) nodes have been misconfigured. The nodes MAY continue to retransmit Config messages in hopes that the misconfiguration is corrected. Note that the problem may be solved by an operator changing the Node_Ids on one or both nodes.
制御チャンネルを動かすために、Configメッセージを遠隔ノードに送らなければなりません、そして、応答では、ローカルのノードにConfigAckメッセージを受け取らなければなりません。 ConfigメッセージはLocal Control Channel Id(CC_Id)、送付者のNode_Id、信頼できるメッセージングのためのMessage_Id、およびCONFIGオブジェクトを含んでいます。 両方の地方の、そして、リモートなノードが同時に構成手順に着手するのは、可能です。 あいまいさを避けるために、より高いNode_Idとのノードは主張を得ます。 下側のNode_Idとのノードは、Configメッセージを送るのを止めて、それが受け取ったConfigメッセージにこたえなければなりません。 Node_Idsが等しいなら、1つ(ともに)のノードがmisconfiguredされました。 ノードは、misconfigurationが直っているという望みでConfigメッセージを再送し続けるかもしれません。 問題が1でNode_Idsを変えるオペレータかノードの両方によって解決されるかもしれないことに注意してください。
The ConfigAck message is used to acknowledge receipt of the Config message and express agreement on ALL of the configured parameters (both negotiable and non-negotiable).
ConfigAckメッセージは、Configメッセージの領収書を受け取ったことを知らせて、構成されたパラメタのすべての協定を表すこと(交渉可能なものと同様に譲渡禁止の)に使用されます。
The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable CONFIG objects are unacceptable, and to propose alternate values for the negotiable parameters.
ConfigNackメッセージはConfigメッセージの領収書を受け取ったことを知らせるのに使用されます、そして、どの(もしあれば)譲渡禁止のCONFIGオブジェクトが容認できないかを示してください、そして、提案するために、交渉可能なパラメタのために値を交替してください。
If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters.
ノードが交渉可能なパラメタのために許容できる代替の値でConfigNackメッセージを受け取るなら、ノードSHOULDは、それらのパラメタにこれらの値を使用することでConfigメッセージを送ります。
If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages in hopes that the misconfiguration is corrected. Note that the problem may be solved by an operator changing parameters on one or both nodes.
ノードが容認できない代替の値でConfigNackメッセージを受け取るなら、ノードは、misconfigurationが直っているという望みでConfigメッセージを再送し続けるかもしれません。 問題が1に関するパラメタかノードの両方を変えるオペレータによって解決されるかもしれないことに注意してください。
In the case where multiple control channels use the same physical interface, the parameter negotiation exchange is performed for each control channel. The various LMP parameter negotiation messages are associated with their corresponding control channels by their node- wide unique identifiers (CC_Ids).
複合管理チャンネルが同じ物理インターフェースを使用する場合では、パラメタ交渉交換はそれぞれの制御チャンネルのために実行されます。 様々なLMPパラメタ交渉メッセージは彼らのノードの広いユニークな識別子で彼らの対応する制御チャンネルに関連しています(_IdsをCCしてください)。
3.2. Hello Protocol
3.2. こんにちは、プロトコル
Once a control channel is activated between two adjacent nodes, the LMP Hello protocol can be used to maintain control channel connectivity between the nodes and to detect control channel
制御チャンネルが2つの隣接しているノードの間をいったん動くと、ノードの間のコントロールチャンネルの接続性を維持して、制御チャンネルを検出するのにLMP Helloプロトコルを使用できます。
Lang Standards Track [Page 10] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[10ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
failures. The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link-state adjacencies are not removed unnecessarily.
失敗。 LMP Helloプロトコルがライト級が急速にコントロールチャンネルの故障に反応するメカニズムを生かすということであることを意図するので、失われなかったIGPハローズと関連リンク州の隣接番組は不必要に取り除かれません。
3.2.1. Hello Parameter Negotiation
3.2.1. こんにちは、パラメタ交渉
Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will be sent, and is measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150 ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms).
メッセージをHelloに送る前に、地方の、そして、リモートなノードはHelloIntervalとHelloDeadIntervalパラメタに同意しなければなりません。 Configメッセージでこれらのパラメタを交換します。 HelloIntervalはLMP Helloメッセージがどれくらい頻繁に送られるかを示して、ミリセカンド(ms)で測定されます。 例えば、伝えるノードは値が150であるなら少なくともあらゆる150原稿をHelloメッセージに送るでしょうに。HelloDeadIntervalは、どれくらい長いデバイスが制御チャンネルが死んでいると宣言する前にHelloメッセージを受け取るのを待つべきであり、ミリセカンド(ms)で測定されるかを示します。
The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero.
HelloDeadIntervalはHelloIntervalの値のHelloInterval、およびSHOULDよりすばらしい少なくとも3倍でなければなりません。 速さがメカニズムを生かすなら、使用されないLMP、HelloInterval、およびHelloDeadIntervalでは、ゼロにパラメタを設定しなければなりません。
The values for the HelloInterval and HelloDeadInterval should be selected carefully to provide rapid response time to control channel failures without causing congestion. As such, different values will likely be configured for different control channel implementations. When the control channel is implemented over a directly connected link, the suggested default values for the HelloInterval is 150 ms and for the HelloDeadInterval is 500 ms.
HelloIntervalとHelloDeadIntervalのための値が混雑を引き起こさないでチャンネルの故障を制御する迅速な応答時間を提供するのが慎重に選択されるべきです。 そういうものとして、異価は異なったコントロールチャンネル実装のためにおそらく構成されるでしょう。 制御チャンネルがHelloIntervalが150msであり、HelloDeadIntervalのための500原稿であるので直接接続されたリンク、提案されたデフォルト値の上で実装されるとき
When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has sent a Hello message and received a valid Hello message (i.e., with expected sequence numbers; see Section 3.2.2), the control channel moves to the up state. (It is also possible to move to the up state without sending Hellos if other methods are used to indicate bi-directional control-channel connectivity. For example, indication of bi-directional connectivity may be learned from the transport layer.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages and the control channel SHOULD NOT move to the up state. See Section 11.1 for the complete control channel FSM.
ノードがConfigAckメッセージを送るか、または受け取ったとき、それは、メッセージをHelloに送り始めるかもしれません。 それは、一度、Helloメッセージを送って、有効なHelloメッセージ(すなわち、期待している一連番号で; セクション3.2.2を見てください)(上の状態へのコントロールチャンネル移動)を受け取ったことがあります。 (また、他のメソッドが双方向の制御チャンネルの接続性を示すのに使用されるならハローズを送らないで上の状態に移行するのも可能です。 例えば、双方向の接続性のしるしはトランスポート層から学習されるかもしれません。) しかしながら、ノードがConfigAckメッセージの代わりにConfigNackメッセージを受け取るなら、ノードはメッセージをHelloに送ってはいけません、そして、制御チャンネルSHOULD NOTは上の状態に移行します。 完全なコントロールチャンネルFSMに関してセクション11.1を見てください。
Lang Standards Track [Page 11] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[11ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
3.2.2. Fast Keep-alive
3.2.2. 速い生きている生活費
Each Hello message contains two sequence numbers: the first sequence number (TxSeqNum) is the sequence number for the Hello message being sent and the second sequence number (RcvSeqNum) is the sequence number of the last Hello message received from the adjacent node over this control channel.
それぞれのHelloメッセージは2つの一連番号を含んでいます: 最初の一連番号(TxSeqNum)は送られるHelloメッセージのための一連番号です、そして、2番目の一連番号(RcvSeqNum)は隣接しているノードからこの制御チャンネルの上に受け取られた最後のHelloメッセージの一連番号です。
There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. TxSeqNum = 1 is used to indicate that the sender has just started or has restarted and has no recollection of the last TxSeqNum that was sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used is 2, not 0 or 1, as these have special meanings.
2つの特別な一連番号があります。 かつて、TxSeqNumは0歳であるはずがありません。 TxSeqNum=1は、送付者がちょうど始まったところであるか、または再開したのを示すのに使用されて、送られた最後のTxSeqNumの回想を全く持っていません。 したがって、送られた最初のHelloは1のTxSeqNumと0のRxSeqNumを持っています。 TxSeqNumが-1に達するとき(2^32)、これらに特別な意味があるとき、使用される次の一連番号は0か1ではなく、2です。
Under normal operation, the difference between the RcvSeqNum in a Hello message that is received and the local TxSeqNum that is generated will be at most 1. This difference can be more than one only when a control channel restarts or when the values wrap.
通常の操作で、Helloメッセージの受け取られていているRcvSeqNumと発生している地方のTxSeqNumの違いは高々1になるでしょう。 制御チャンネルが単に再開するか、値の包装であるときに、この違いは1以上であることができます。
Since the 32-bit sequence numbers may wrap, the following expression may be used to test if a newly received TxSeqNum value is less than a previously received value:
32ビットの一連番号以来、包装、以下の式は新たに受け取られたTxSeqNum値が以前に容認された値以下であるならテストするのに使用されるかもしれません:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
((int)古い_イド--(int)新しい_イド>0)新しい値は古い値以下です。
Having sequence numbers in the Hello messages allows each node to verify that its peer is receiving its Hello messages. By including the RcvSeqNum in Hello packets, the local node will know which Hello packets the remote node has received.
Helloメッセージの一連番号を持っているのに、各ノードは、同輩がHelloメッセージを受け取っていることを確かめることができます。 HelloパケットにRcvSeqNumを含んでいることによって、ローカルのノードは、遠隔ノードがどのHelloパケットを受けたかを知るでしょう。
The following example illustrates how the sequence numbers operate. Note that only the operation at one node is shown, and alternative scenarios are possible:
以下の例は一連番号がどう作動するかを例証します。 1つのノードでの操作だけが示されて、予備のプランが可能であることに注意してください:
1) After completing the configuration stage, Node A sends Hello
messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
1) 構成ステージ、Aが送るNodeを完成した、HelloがNode Bへ通信する後TxSeqNum=1;、RcvSeqNum=0
2) Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}.
When the HelloInterval expires on Node A, it sends Hellos to Node
B with {TxSeqNum=2;RcvSeqNum=1}.
2) ノードAがNode BからのHelloを受ける、TxSeqNum=1;、RcvSeqNum=1 いつと共にHelloIntervalがNode Aで期限が切れて、Node Bにハローズを送るか、TxSeqNum=2;、RcvSeqNum=1
3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}.
When the HelloInterval expires on Node A, it sends Hellos to Node
B with {TxSeqNum=3;RcvSeqNum=2}.
3) ノードAがNode BからのHelloを受ける、TxSeqNum=2;、RcvSeqNum=2 いつと共にHelloIntervalがNode Aで期限が切れて、Node Bにハローズを送るか、TxSeqNum=3;、RcvSeqNum=2
Lang Standards Track [Page 12] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[12ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
3.2.3. Control Channel Down
3.2.3. チャンネルのために下にを制御してください。
To allow bringing a control channel down gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links.
管理目的、ControlChannelDown旗のために制御チャンネルを優雅に落ち込ませるのを許容するのはLMPパケットのCommon Headerで利用可能です。 データであるときに、リンクは1組のノードの間でまだ使用中です、コントロールチャンネルSHOULD。データ・リンクを管理するのに使用できる他の活発な制御チャンネルがあるときだけ、行政上降ろされます。
When bringing a control channel down administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node that initiated the control channel down procedure may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set.
制御チャンネルを行政上落ち込ませるとき、ノードは制御チャンネルの上に送られたすべてのLMPメッセージにControlChannelDown旗をはめ込まなければなりません。 制御チャンネルに手順の下側に着手したノードは、HelloDeadInterval秒が経過した後かそれがControlChannelDown旗のセットの同じ制御チャンネルの上にLMPメッセージを受け取ること場合メッセージをHelloに送るのを止めるかもしれません。
When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the down state.
ノードがいつControlChannelDown旗でLMPパケットを受けるかはセットして、それはSHOULDです。ControlChannelDown旗のセットがあるHelloメッセージを送ってください、そして、制御チャンネルを下に状態に動かしてください。
3.2.4. Degraded State
3.2.4. 降格している状態
A consequence of allowing the control channels to be physically diverse from the associated data links is that there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down a link that is carrying user traffic simply because the control channel is no longer available; however, the traffic that is using the data links may no longer be guaranteed the same level of service. Hence, the TE link is in a Degraded state.
制御チャンネルが関連データリンクから物理的に多様であることを許容する結果はデータ・リンクがまだ使用中である間利用可能などんな活発な制御チャンネルもないかもしれないということです。 多くのアプリケーションに、制御チャンネルがもう単に利用可能でないのでユーザトラフィックを運ぶリンクを取りこわすのは容認できません。 しかしながら、同じレベルのサービスはもうデータ・リンクを使用しているトラフィックに保証されないかもしれません。 したがって、TEリンクがDegraded状態にあります。
When a TE link is in the Degraded state, routing and signaling SHOULD be notified so that new connections are not accepted and the TE link is advertised with no unreserved resources.
TEリンクがDegraded状態、ルーティング、およびシグナリングSHOULDにあるときには、新しい接続が受け入れられないで、TEリンクが無遠慮なリソースなしで広告に掲載されるように、通知されてください。
4. Link Property Correlation
4. リンク特性の相関関係
As part of LMP, a link property correlation exchange is defined for TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N flag in the object header). Negotiable objects can be used to let both sides agree on certain link parameters. Non-negotiable objects are used for announcement of specific values that do not need, or do not allow, negotiation.
LMPの一部として、リンク特性の相関関係交換は、LinkSummary、LinkSummaryAck、およびLinkSummaryNackメッセージを使用することでTEリンクと定義されます。 LMPオブジェクトを使用するのはこれらのメッセージの内容に建てられます。(交渉可能であるか、またはオブジェクトは譲渡禁止である場合があります(オブジェクトヘッダーのN旗で、特定されます))。 両側をあるリンクパラメータに同意させるのに交渉可能なオブジェクトを使用できます。 譲渡禁止のオブジェクトは交渉を必要でなく、また許さない特定の値の発表に使用されます。
Lang Standards Track [Page 13] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[13ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Each TE link has an identifier (Link_Id) that is assigned at each end of the link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. If a LinkSummary message is received with different local and remote TE link types, then a LinkSummaryNack message MUST be sent with Error Code "Bad TE Link Object". Similarly, each data link is assigned an identifier (Interface_Id) at each end. These identifiers MUST also be the same type at both ends. If a LinkSummary message is received with different local and remote Interface_Id types, then a LinkSummaryNack message MUST be sent with Error Code "Bad Data Link Object".
それぞれのTEリンクには、リンクの各端に割り当てられる識別子(リンク_Id)があります。 これらの識別子は両端において同じタイプであるに違いありません(i.e、IPv6の、そして、無数のIPv4)。 異なった地方の、そして、リモートなTEリンク型でLinkSummaryメッセージを受け取るなら、Error Code「悪いTeリンクオブジェクト」でLinkSummaryNackメッセージを送らなければなりません。 同様に、各データ・リンクは識別子(インタフェース_Id)を各端に割り当てられます。 また、これらの識別子は両端において同じタイプであるに違いありません。 異なった地方の、そして、リモートなInterface_IdタイプでLinkSummaryメッセージを受け取るなら、Error Code「悪いデータ・リンクオブジェクト」でLinkSummaryNackメッセージを送らなければなりません。
Link property correlation SHOULD be done before the link is brought up and MAY be done any time a link is up and not in the Verification process.
リンク特性の相関関係SHOULDはリンクが上がっている何時でもリンクを持って来て、するかもしれない前にして、Verificationで処理しません。
The LinkSummary message is used to verify for consistency the TE and data link information on both sides. Link Summary messages are also used (1) to aggregate multiple data links (either ports or component links) into a TE link; (2) to exchange, correlate (to determine inconsistencies), or change TE link parameters; and (3) to exchange, correlate (to determine inconsistencies), or change Interface_Ids (either Port_Ids or component link identifiers).
LinkSummaryメッセージは、一貫性のために両側でTEとデータリンク情報について確かめるのに使用されます。 また、リンクSummaryメッセージはTEリンクへの複数のデータ・リンク(ポートかコンポーネントリンクのどちらか)に集める中古の(1)です。 (2) TEを交換するか、関連するか(矛盾を決定する)、または変えるには、パラメタをリンクしてください。 そして、Interface_Ids(Port_Idsかコンポーネントリンク識別子のどちらか)を交換するか、関連するか(矛盾を決定する)、または変える(3)。
The LinkSummary message includes a TE_LINK object followed by one or more DATA_LINK objects. The TE_LINK object identifies the TE link's local and remote Link_Id and indicates support for fault management and link verification procedures for that TE link. The DATA_LINK objects are used to characterize the data links that comprise the TE link. These objects include the local and remote Interface_Ids, and may include one or more sub-objects further describing the properties of the data links.
LinkSummaryメッセージはTE_LINKオブジェクトを含んでいます、続いて、1個以上のDATA_LINKオブジェクトを含んでいます。 TE_LINKオブジェクトは、TEリンクの地方の、そして、リモートなLink_Idを特定して、障害管理のサポートとリンク検証手続をそのTEリンクに示します。 DATA_LINKオブジェクトは、TEリンクを包括するデータ・リンクを特徴付けるのに使用されます。 これらのオブジェクトは、地方の、そして、リモートなInterface_Idsを含んでいて、さらにデータ・リンクの特性について説明しながら、1個以上のサブオブジェクトを含むかもしれません。
If the LinkSummary message is received from a remote node, and the Interface_Id mappings match those that are stored locally, then the two nodes have agreement on the Verification procedure (see Section 5) and data link identification configuration. If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration.
遠隔ノードからLinkSummaryメッセージを受け取って、Interface_Idマッピングが局所的に保存されるものに合っているなら、2つのノードには、Verification手順(セクション5を見る)とデータ・リンク識別構成の協定があります。 検証手続が使用されていないなら、手動の構成の協定について確かめるのにLinkSummaryメッセージを使用できます。
The LinkSummaryAck message is used to signal agreement on the Interface_Id mappings and link property definitions. Otherwise, a LinkSummaryNack message MUST be transmitted, indicating which Interface mappings are not correct and/or which link properties are not accepted. If a LinkSummaryNack message indicates that the Interface_Id mappings are not correct and the link verification procedure is enabled, the link verification process SHOULD be repeated for all mismatched, free data links; if an allocated data link has a mapping mismatch, it SHOULD be flagged and verified when
LinkSummaryAckメッセージは、Interface_Idマッピングの協定に合図して、特性の定義をリンクするのに使用されます。 さもなければ、LinkSummaryNackメッセージを送らなければなりません、どのInterfaceマッピングが正しくないか、そして、どのリンク資産が受け入れられないかを示して。 LinkSummaryNackメッセージが、Interface_Idマッピングが正しくないのを示して、リンク検証手続が可能にされるなら、リンク検証プロセスSHOULDがミスマッチされたすべてのために繰り返されて、無料のデータはリンクされます。 リンクにはマッピングミスマッチが割り当てられたデータであるならあって、それが旗を揚げられて、確かめられたSHOULDである、いつ
Lang Standards Track [Page 14] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[14ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
it becomes free. If a LinkSummaryNack message includes negotiable parameters, then acceptable values for those parameters MUST be included. If a LinkSummaryNack message is received and includes negotiable parameters, then the initiator of the LinkSummary message SHOULD send a new LinkSummary message. The new LinkSummary message SHOULD include new values for the negotiable parameters. These values SHOULD take into account the acceptable values received in the LinkSummaryNack message.
それは自由になります。 LinkSummaryNackメッセージが交渉可能なパラメタを含んでいるなら、それらのパラメタのための許容値を含まなければなりません。 LinkSummaryNackメッセージが受け取られていて、交渉可能なパラメタを含んでいるなら、そして、SHOULDが新しいLinkSummaryメッセージを送るLinkSummaryメッセージの創始者です。 新しいLinkSummaryメッセージSHOULDは交渉可能なパラメタのための新しい値を含んでいます。 SHOULDが連れていくこれらの値はLinkSummaryNackメッセージに受け取られた許容値を説明します。
It is possible that the LinkSummary message could grow quite large due to the number of DATA LINK objects. An LMP implementation SHOULD be able to fragment when transmitting LMP messages, and MUST be able to re-assemble IP fragments when receiving LMP messages.
LinkSummaryメッセージがDATA LINKオブジェクトの数のためにかなり大きくなることができたのは、可能です。 LMP実装SHOULDはLMPメッセージを送るとき、断片化できて、LMPメッセージを受け取るとき、IP断片を組み立て直すことができなければなりません。
5. Verifying Link Connectivity
5. リンクの接続性について確かめます。
In this section, an optional procedure is described that may be used to verify the physical connectivity of the data links and dynamically learn (i.e., discover) the TE link and Interface_Id associations. The procedure SHOULD be done when establishing a TE link, and subsequently, on a periodic basis for all unallocated (free) data links of the TE link.
すなわち、このセクションで、データ・リンクの物理的な接続性について確かめて、ダイナミックに学ぶのに用いられるかもしれない任意の手順が説明される、(発見、)、TEリンクとInterface_Id協会。 次にTEリンクを設立するとき、手順SHOULDをして、TEのすべての「非-割り当て」られた(自由な)データ・リンク周期的ベースでは、リンクしてください。
Support for this procedure is indicated by setting the "Link Verification Supported" flag in the TE_LINK object of the LinkSummary message.
この手順のサポートは、LinkSummaryメッセージのTE_LINKオブジェクトに「検証が支えたリンク」旗を設定することによって、示されます。
If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code indicating, "Link Verification Procedure not supported for this TE Link."
BeginVerifyメッセージが受信されていて、リンク検証がTEリンクにサポートされないなら、「このTE LinkのためにサポートされなかったリンクVerification Procedure」と、Error Codeが示していて、BeginVerifyNackメッセージを送らなければなりません。
A unique characteristic of transparent devices is that the data is not modified or examined during normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establishing the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that, until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.) and, hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages.
透明なデバイスのユニークな特性はデータが通常の操作の間変更もされませんし、調べられもしないということです。 この特性はデータ・リンクの接続性を有効にして、ラベルマッピングを確立するための挑戦を引き起こします。 したがって、データ・リンクの接続性の適切な検証を確実にするために、それらがユーザトラフィックのためにデータ・リンクを割り当てるまで不透明であるに違いないことが(すなわち、それらの透明を失ってください)必要です。 Testメッセージを輸送するために様々な度合いの不透明(例えば、IPペイロードを終えて、オーバーヘッドバイトを調べますなど)としたがって、異なったメカニズムをサポートするために、Verify Transport Mechanism分野はBeginVerifyとBeginVerifyAckメッセージに含まれています。
There is no requirement that all data links be terminated simultaneously; but, at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so
すべてのデータ・リンクが同時に終えられるという要件が全くありません。 しかし、最小限では、データ・リンクは一度に一つ、終えることができなければなりません。 その上、リンク検証手続において、こぶのようなアーキテクチャがそのように設計されていると思われます。
Lang Standards Track [Page 15] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[15ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device; but that in transparent devices this is an additional requirement.
どんなデータ・リンクの上にもメッセージを送って、受け取ることができます。 不透明なデバイスに、この要件が次の不透明なデバイスに送る前に、各データ・リンクを電気的に終えて、処理するので些細であることに注意してください。 しかし、透明なデバイスでは、これは追加要件です。
To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link.
2つのノードとインタコネクトするために、TEリンクはそれらの間で定義されます、そして、最小限には、ノードの間には、少なくとも1個の活発な制御チャンネルがあるに違いありません。 リンク検証のために、TEリンクは少なくとも1個のデータ・リンクを含まなければなりません。
Once a control channel has been established between the two nodes, data link connectivity can be verified by exchanging Test messages over each of the data links specified in the TE link. It should be noted that all LMP messages except the Test message are exchanged over the control channels and that Hello messages continue to be exchanged over each control channel during the data link verification process. The Test message is sent over the data link that is being verified. Data links are tested in the transmit direction because they are unidirectional; therefore, it may be possible for both nodes to (independently) exchange the Test messages simultaneously.
制御チャンネルがいったん2つのノードを間に確立されると、TEリンクで指定されたそれぞれのデータ・リンクの上とTestメッセージを交換することによって、データ・リンクの接続性について確かめることができます。 Testメッセージ以外のすべてのLMPメッセージを制御チャンネルの上と交換して、Helloメッセージが、データ・リンク検証プロセスの間、それぞれの制御チャンネルの上と交換され続けていることに注意されるべきです。 確かめられているデータ・リンクの上にTestメッセージを送ります。 データ・リンクがテストされる、それらが単方向ので、方向を伝えてください。 したがって、両方のノードが同時に(独自に)Testメッセージを交換するのは、可能であるかもしれません。
To initiate the link verification procedure, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the local Link_Id MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. For the case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that have not yet been assigned to a TE link. Specifically, verification of data links that span multiple TE links is indicated by setting the local Link_Id field to zero and setting the "Verify all Links" flag. Verification of data links that have not yet been assigned to a TE link is indicated by setting the local Link_Id field to zero and clearing the "Verify all Links" flag.
リンク検証手続に着手するために、ローカルのノードは制御チャンネルの上にBeginVerifyメッセージを送らなければなりません。 Link Verificationの範囲を特定のTE Link、地方のLink_Idに制限するのは、非ゼロであるに違いありません。 この分野がゼロであるなら、データ・リンクは複数のTEリンクにかかることができます、そして、それらはまだ構成していてはいけないTEリンクを包括するかもしれません。 地方のLink_Id分野がゼロであるケースにおいて、「すべてのリンクスについて確かめてください」というBEGIN_VERIFYオブジェクトの旗は、複数のその長さTEのデータ・リンクの間でまだTEリンクに割り当てられていないリンクとものを区別するのに使用されます。 明確に、複数のTEリンクにかかるデータ・リンクの検証は、地方のLink_Id分野をゼロに設定して、「すべてのリンクスについて確かめてください」という旗を設定することによって、示されます。 まだTEリンクに割り当てられていないデータ・リンクの検証は、地方のLink_Id分野をゼロに設定して、「すべてのリンクスについて確かめてください」という旗をきれいにすることによって、示されます。
The BeginVerify message also contains the number of data links that are to be verified; the interval (called VerifyInterval) at which the Test messages will be sent; the encoding scheme and transport mechanisms that are supported; the data rate for Test messages; and, when the data links correspond to fibers, the wavelength identifier over which the Test messages will be transmitted.
また、BeginVerifyメッセージは確かめられることになっているデータ・リンクの数を含んでいます。 Testメッセージが送られる間隔(VerifyIntervalと呼ばれます)。 サポートされるコード化体系と移送機構。 Testメッセージのためのデータ信号速度。 そして、データがリンクされるときには、ファイバー、Testメッセージが送られる波長識別子に対応してください。
If the remote node receives a BeginVerify message and it is ready to process Test messages, it MUST send a BeginVerifyAck message back to the local node specifying the desired transport mechanism for the TEST messages. The remote node includes a 32-bit, node-unique
遠隔ノードがBeginVerifyメッセージを受け取って、Testメッセージを処理する準備ができているなら、それはTESTメッセージに必要な移送機構を指定するローカルのノードにBeginVerifyAckメッセージを送り返さなければなりません。 遠隔ノードはノードユニークな状態で32ビットを含んでいます。
Lang Standards Track [Page 16] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[16ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be randomly selected; however, it MUST NOT overlap any other Verify_Id currently being used by the node selecting it. The Verify_Id is then used in all corresponding verification messages to differentiate them from different LMP peers and/or parallel Test procedures. When the local node receives a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the Verify_Id and the local Interface_Id for the associated data link. The remote node MUST send either a TestStatusSuccess or a TestStatusFailure message in response for each data link. A TestStatusAck message MUST be sent to confirm receipt of the TestStatusSuccess and TestStatusFailure messages. Unacknowledged TestStatusSuccess and TestStatusFailure messages SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
BeginVerifyAckメッセージで_Idについて確かめてください。 Verify_Idは手当たりしだいに選択されるかもしれません。 しかしながら、現在それを選択するノードによって使用されて、それはいかなる他のVerify_Idも重ね合わせてはいけません。 そして、Verify_Idは異なったLMP同輩、そして/または、平行なTest手順とそれらを区別するすべての対応する検証メッセージで使用されます。 ローカルのノードが遠隔ノードからBeginVerifyAckメッセージを受け取るとき、それは、周期的なTestメッセージを各データ・リンクの上に送ることによってデータ・リンクをテストし始めるかもしれません。 Testメッセージは関連データリンクへのVerify_Idと地方のInterface_Idを含んでいます。 遠隔ノードは各データ・リンクのための応答におけるTestStatusSuccessかTestStatusFailureメッセージのどちらかを送らなければなりません。 TestStatusSuccessとTestStatusFailureメッセージの領収書を確認するためにTestStatusAckメッセージを送らなければなりません。 不承認のTestStatusSuccessとSHOULDがメッセージが承認されるまで再送されるか、または再試行限界まで届いているという(また、セクション10を見てください)TestStatusFailureメッセージ。
It is also permissible for the sender to terminate the Test procedure anytime after sending the BeginVerify message. An EndVerify message SHOULD be sent for this purpose.
また、BeginVerifyメッセージを送った後に送付者がいつでもTest手順を終えるのも、許されています。 EndVerifyはSHOULDを通信させます。このために、送ります。
Message correlation is done using message identifiers and the Verify_Id; this enables verification of data links, belonging to different link bundles or LMP sessions, in parallel.
メッセージ相関関係はメッセージ識別子とVerify_Idを使用し終わっています。 これは異なったリンクバンドルかLMPセッションに属して、平行なデータ・リンクの検証を可能にします。
When the Test message is received, the received Interface_Id (used in GMPLS as either a Port label or component link identifier, depending on the configuration) is recorded and mapped to the local Interface_Id for that data link, and a TestStatusSuccess message MUST be sent. The TestStatusSuccess message includes the local Interface_Id along with the Interface_Id and Verify_Id received in the Test message. The receipt of a TestStatusSuccess message indicates that the Test message was detected at the remote node and the physical connectivity of the data link has been verified. When the TestStatusSuccess message is received, the local node SHOULD mark the data link as up and send a TestStatusAck message to the remote node. If, however, the Test message is not detected at the remote node within an observation period (specified by the VerifyDeadInterval), the remote node MUST send a TestStatusFailure message over the control channel, which indicates that the verification of the physical connectivity of the data link has failed. When the local node receives a TestStatusFailure message, it SHOULD mark the data link as FAILED and send a TestStatusAck message to the remote node. When all the data links on the list have been tested, the local node SHOULD send an EndVerify message to indicate that testing is complete on this link.
Testメッセージが受信されているとき、そのデータ・リンクのために、容認されたInterface_Id(GMPLSでは、構成によって、Portラベルかコンポーネントリンク識別子のどちらかとして使用される)を地方のInterface_Idに記録して、写像します、そして、TestStatusSuccessメッセージを送らなければなりません。 TestStatusSuccessメッセージはTestメッセージに受け取られたInterface_IdとVerify_Idに伴う地方のInterface_Idを含んでいます。 TestStatusSuccessメッセージの領収書は、Testメッセージが遠隔ノードに検出されて、データ・リンクの物理的な接続性が確かめられたのを示します。 TestStatusSuccessメッセージが受信されているとき、ローカルのノードSHOULDはデータ・リンクを値上げして、TestStatusAckメッセージを遠隔ノードに送ります。 しかしながら、Testメッセージが観測の期間(VerifyDeadIntervalによって指定される)以内に遠隔ノードに検出されないなら、遠隔ノードは制御チャンネルの上にTestStatusFailureメッセージを送らなければなりません。チャンネルはデータ・リンクの物理的な接続性の検証が失敗したのを示します。 ローカルのノードが受信するとき、a TestStatusFailureは通信して、それはデータがFAILEDとしてリンクして、遠隔ノードへのTestStatusAckメッセージを送るSHOULDマークです。 リストの上のすべてのデータ・リンクがテストされたとき、ローカルのノードSHOULDはテストがこのリンクで完全であることを示すEndVerifyメッセージを送ります。
Lang Standards Track [Page 17] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[17ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
If the local/remote data link mappings are known, then the link verification procedure can be optimized by testing the data links in a defined order known to both nodes. The suggested criterion for this ordering is by increasing the value of the remote Interface_Id.
地方の、または、リモートなデータ・リンクマッピングが知られているなら、両方のノードに知られている定義されたオーダーでデータ・リンクをテストすることによって、リンク検証手続を最適化できます。 この注文のための提案された評価基準が、遠く離れたInterface_アイダホ州の値を増加させることによって、あります。
Both the local and remote nodes SHOULD maintain the complete list of Interface_Id mappings for correlation purposes.
地方の、そして、リモートなノードSHOULDは相関関係目的のためのInterface_Idマッピングに関する全リストを維持します。
5.1. Example of Link Connectivity Verification
5.1. リンク接続性検証に関する例
Figure 1 shows an example of the link verification scenario that is executed when a link between Node A and Node B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows:
図1は、Node AとNode Bとのリンクがいつ加えられるかを実行されるリンク検証シナリオに関する例に示します。 この例では、TEリンクは、3つの自由港(別々のファイバーに沿って伝えられたそれぞれ)から成って、双方向の制御チャンネル(「c」で、示される)に関連しています。 検証の過程は以下の通りです:
o A sends a BeginVerify message over the control channel to B,
indicating it will begin verifying the ports that form the TE
link. The LOCAL_LINK_ID object carried in the BeginVerify message
carries the identifier (IP address or interface index) that A
assigns to the link.
o Upon receipt of the BeginVerify message, B creates a Verify_Id and
binds it to the TE Link from A. This binding is used later when B
receives the Test messages from A, and these messages carry the
Verify_Id. B discovers the identifier (IP address or interface
index) that A assigns to the TE link by examining the
LOCAL_LINK_ID object carried in the received BeginVerify message.
(If the data ports are not yet assigned to the TE Link, the
binding is limited to the Node_Id of A.) In response to the
BeginVerify message, B sends the BeginVerifyAck message to A. The
LOCAL_LINK_ID object carried in the BeginVerifyAck message is used
to carry the identifier (IP address or interface index) that B
assigns to the TE link. The REMOTE_LINK_ID object carried in the
BeginVerifyAck message is used to bind the Link_Ids assigned by
both A and B. The Verify_Id is returned to A in the
BeginVerifyAck message over the control channel.
o When A receives the BeginVerifyAck message, it begins transmitting
periodic Test messages over the first port (Interface Id=1). The
Test message includes the Interface_Id for the port and the
Verify_Id that was assigned by B.
o When B receives the Test messages, it maps the received
Interface_Id to its own local Interface_Id = 10 and transmits a
TestStatusSuccess message over the control channel back to Node A.
The TestStatusSuccess message includes both the local and received
Interface_Ids for the port as well as the Verify_Id. The
o AはBの制御チャンネルの上にBeginVerifyメッセージを送ります、TEリンクを形成するポートについて確かめ始めるのを示して。 BeginVerifyメッセージで運ばれたLOCAL_LINK_ID物はAがリンクに割り当てる識別子(IPアドレスかインタフェースインデックス)を運びます。BeginVerifyメッセージのo Upon領収書、BがAからTestメッセージを受け取るとき、Bは、後での使用されるA.This結合から、Verify_Idを作成して、TE Linkにそれを縛って、これらのメッセージはVerify_アイダホ州を運びます。 BはAが受信されたBeginVerifyメッセージで運ばれたLOCAL_LINK_ID物を調べることによってTEリンクに割り当てる識別子(IPアドレスかインタフェースインデックス)を発見します。 (データポートがまだTE Linkに割り当てられていないなら、結合はA.のNode_Idに制限されます) BeginVerifyメッセージに対応してBはBeginVerifyAckメッセージをA.に送ります。BeginVerifyAckメッセージで運ばれたLOCAL_LINK_ID物は、BがTEリンクに割り当てる識別子(IPアドレスかインタフェースインデックス)を運ぶのに使用されます。 BeginVerifyAckメッセージで運ばれたREMOTE_LINK_ID物は、BeginVerifyAckメッセージでAとVerify_Idが返されるB.のAへの両方によって制御チャンネルの上に割り当てられたLink_Idsを縛るのに使用されます。o When AはBeginVerifyAckメッセージを受け取って、それは最初のポート(インタフェースId=1)にわたって周期的なTestメッセージを送り始めます。 TestメッセージがポートへのInterface_Idを含んでいて、B.o When Bによって割り当てられたVerify_IdがTestメッセージを受け取って、それは、それ自身の地方のInterface_Id=10に容認されたInterface_Idを写像して、TestStatusSuccessメッセージがポートへの地方の、そして、容認されたInterface_IdsとVerify_アイダホ州の両方を含んでいるというNode A.の制御チャンネルの上のTestStatusSuccessメッセージを送ります。 The
Lang Standards Track [Page 18] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[18ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Verify_Id is used to determine the local/remote TE link
identifiers (IP addresses or interface indices) to which the data
links belong.
o A will send a TestStatusAck message over the control channel back
to B, indicating it received the TestStatusSuccess message.
o The process is repeated until all of the ports are verified.
o At this point, A will send an EndVerify message over the control
channel to B, indicating that testing is complete.
o B will respond by sending an EndVerifyAck message over the control
channel back to A.
_使用されるIdについて確かめます。o AはBの制御チャンネルの上にTestStatusAckメッセージを送るでしょう、データ・リンクが属する地方の、または、リモートなTEリンク識別子(IPアドレスかインタフェースインデックスリスト)を決定してください、そして、TestStatusSuccessメッセージを受け取ったのを示して; これが指すo At、AはBの制御チャンネルの上にEndVerifyメッセージを送るでしょう、o BがAの制御チャンネルの上にEndVerifyAckメッセージを送ることによって応じるのを示して。○ ポートのすべてが確かめられるまで、過程は繰り返されます。テストは完全です。
Note that this procedure can be used to "discover" the
connectivity of the data ports.
データポートの接続性を「発見すること」にこの手順を用いることができることに注意してください。
+---------------------+ +---------------------+ + + + + + Node A +<-------- c --------->+ Node B + + + + + + + + + + 1 +--------------------->+ 10 + + + + + + + + + + 2 + /---->+ 11 + + + /----/ + + + + /---/ + + + 3 +----/ + 12 + + + + + + + + + + 4 +--------------------->+ 14 + + + + + +---------------------+ +---------------------+
+---------------------+ +---------------------+ + + + + + ノードは+<です。-------- c--------->+ノードB++++++++++1+--------------------->+10++++++++++2+/---->+11+++/----/ + + + + /---/ + + + 3 +----/ + 12 + + + + + + + + + + 4 +--------------------->+14++++++---------------------+ +---------------------+
Figure 1: Example of link connectivity between Node A and Node B.
図1: Node AとNode Bの間のリンクの接続性に関する例。
6. Fault Management
6. 障害管理
In this section, an optional LMP procedure is described that is used to manage failures by rapid notification of the status of one or more data channels of a TE Link. The scope of this procedure is within a TE link, and as such, the use of this procedure is negotiated as part of the LinkSummary exchange. The procedure can be used to rapidly isolate data link and TE link failures, and is designed to work for both unidirectional and bi-directional LSPs.
このセクションで、TE Linkの1人以上のデータ・チャンネルの状態の急速な通知で失敗を管理するのに用いられる任意のLMP手順は説明されます。 TEリンクの中にこの手順の範囲があります、そして、そういうものとして、この手順の使用はLinkSummary交換の一部として交渉されます。 手順は、急速にデータ・リンクとTEリンクの故障を隔離するのに用いることができて、単方向、双方向のLSPsの両方のために働くように設計されています。
Lang Standards Track [Page 19] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[19ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
An important implication of using transparent devices is that traditional methods that are used to monitor the health of allocated data links may no longer be appropriate. Instead of fault detection being in layer 2 or layer 3, it is delegated to the physical layer (i.e., loss of light or optical monitoring of the data).
透明な装置を使用する重要な含意は割り当てられたデータ・リンクの健康をモニターするのに使用される伝統的方法がもう適切でないかもしれないということです。 層2か層3の中にある欠点検出の代わりに、物理的な層(すなわち、データの軽いか光学のモニターの損失)へそれを代表として派遣します。
Recall that a TE link connecting two nodes may consist of a number of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification so that appropriate protection/restoration mechanisms can be initiated. If the failure is subsequently cleared, then a mechanism must be used to notify that the failure is clear and the channel status is OK.
2つのノードを接続するTEリンクが多くのデータ・リンクから成ったかもしれないと思い出してください。 1個以上のデータ・リンクが2つのノードの間で失敗するなら、適切な保護/回復メカニズムを開始できて、急速な失敗通知にメカニズムを使用しなければなりません。 失敗が次にクリアされるなら、メカニズムはそれに通知するのに使用されて、失敗が明確であり、チャンネル状態がOKであるということであるに違いありません。
6.1. Fault Detection
6.1. 欠点検出
Fault detection should be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is detecting loss of light (LOL). Other techniques for monitoring optical signals are still being developed and will not be further considered in this document. However, it should be clear that the mechanism used for fault notification in LMP is independent of the mechanism used to detect the failure, and simply relies on the fact that a failure is detected.
欠点検出は失敗の最も近くで層で扱われるべきです。 光学ネットワークにおいて、これは物理的な(光学)層です。 物理的な層での欠点検出の1つの手段が光(LOL)の損失を検出しています。 モニターしている光学信号のための他の技術は、まだ見いだされていて、さらに本書では考えられないでしょう。 しかしながら、LMPの欠点通知に使用されるメカニズムが失敗を検出するのに使用されるメカニズムから独立していて、単に、失敗が検出されるという事実を当てにするのは、明確であるはずです。
6.2. Fault Localization Procedure
6.2. 欠点ローカライズ手順
In some situations, a data link failure between two nodes is propagated downstream such that all the downstream nodes detect the failure without localizing the failure. To avoid multiple alarms stemming from the same failure, LMP provides failure notification through the ChannelStatus message. This message may be used to indicate that a single data channel has failed, multiple data channels have failed, or an entire TE link has failed. Failure correlation is done locally at each node upon receipt of the failure notification.
いくつかの状況で、2つのノードの間のデータ・リンクの故障は失敗を局所化する伝播された川下のそのようなものですすべての川下のノードが失敗を検出する。 同じ失敗による複数のアラームを避けるために、LMPはChannelStatusメッセージを通して失敗通知を提供します。 このメッセージは、単独のデータ・チャンネルが失敗したか、複数のデータ・チャンネルが失敗したか、または全体のTEリンクが失敗したのを示すのに使用されるかもしれません。 失敗通知を受け取り次第各ノードで局所的に失敗相関関係をします。
To localize a fault to a particular link between adjacent nodes, a downstream node (downstream in terms of data flow) that detects data link failures will send a ChannelStatus message to its upstream neighbor indicating that a failure has been detected (bundling together the notification of all the failed data links). An upstream node that receives the ChannelStatus message MUST send a ChannelStatusAck message to the downstream node indicating it has received the ChannelStatus message. The upstream node should correlate the failure to see if the failure is also detected locally for the corresponding LSP(s). If, for example, the failure is clear on the input of the upstream node or internally, then the upstream
隣接しているノード、川下のノード(データフロー川下の)の間の特定のリンクに欠点を局所化するように、それは、失敗が上流の隣人へのChannelStatusメッセージを送るデータ・リンクが、失敗が検出されたのを(すべての失敗したデータ・リンクの通知を一緒に束ねます)示すのを検出します。 ChannelStatusメッセージを受け取る上流のノードはChannelStatusメッセージを受け取ったのを示す川下のノードにChannelStatusAckメッセージを送らなければなりません。 上流のノードはまた、失敗が対応するLSP(s)のために局所的に検出されるかどうかを見ないことを関連させるはずです。 例えば、失敗は上流のノードの入力に関して明確であるか、そして、内部的、そして、上流
Lang Standards Track [Page 20] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[20ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
node will have localized the failure. Once the failure is correlated, the upstream node SHOULD send a ChannelStatus message to the downstream node indicating that the channel is failed or is OK. If a ChannelStatus message is not received by the downstream node, it SHOULD send a ChannelStatusRequest message for the channel in question. Once the failure has been localized, the signaling protocols may be used to initiate span or path protection and restoration procedures.
ノードは失敗を局所化してしまうでしょう。 失敗がいったん関連していると、上流のノードSHOULDはチャンネルが失敗されているか、またはOKであることを示す川下のノードにChannelStatusメッセージを送ります。 メッセージはChannelStatusであるなら川下ノードによって受け取られません、それ。SHOULDは問題のチャンネルへのChannelStatusRequestメッセージを送ります。 失敗がいったん局所化されると、シグナリングプロトコルは、長さか経路保護と回復手順に着手するのに使用されるかもしれません。
If all of the data links of a TE link have failed, then the upstream node MAY be notified of the TE link failure without specifying each data link of the failed TE link. This is done by sending failure notification in a ChannelStatus message identifying the TE Link without including the Interface_Ids in the CHANNEL_STATUS object.
TEリンクのデータ・リンクのすべてが失敗したなら、失敗したTEリンクの各データ・リンクを指定しないで、上流のノードはTEリンクの故障について通知されるかもしれません。 ChannelStatusメッセージにおける失敗通知にCHANNEL_STATUS物にInterface_Idsを含んでいなくてTE Linkを特定させることによって、これをします。
6.3. Examples of Fault Localization
6.3. 欠点ローカライズに関する例
In Figure 2, a sample network is shown where four nodes are connected in a linear array configuration. The control channels are bi- directional and are labeled with a "c". All LSPs are also bi- directional.
図2では、サンプルネットワークは4つのノードが線形配列構成でどこに接続されるかが示されます。 制御チャンネルは、2方向上であり、「c」でレッテルを貼られます。 また、すべてのLSPsも2方向上です。
In the first example [see Fig. 2(a)], there is a failure on one direction of the bi-directional LSP. Node 4 will detect the failure and will send a ChannelStatus message to Node 3 indicating the failure (e.g., LOL) to the corresponding upstream node. When Node 3 receives the ChannelStatus message from Node 4, it returns a ChannelStatusAck message back to Node 4 and correlates the failure locally. When Node 3 correlates the failure and verifies that the failure is clear, it has localized the failure to the data link between Node 3 and Node 4. At that time, Node 3 should send a ChannelStatus message to Node 4 indicating that the failure has been localized.
最初の例[図2(a)を見る]には、失敗が双方向のLSPの一方向にあります。 ノード4は、失敗を検出して、失敗(例えば、LOL)を対応する上流のノードに示すNode3にChannelStatusメッセージを送るでしょう。 Node3がNode4からChannelStatusメッセージを受け取るとき、それは、ChannelStatusAckメッセージをNode4に返して戻して、失敗を局所的に関連させます。 Node3が、失敗を関連させて、失敗が明確であることを確かめるとき、それはNode3とNode4とのデータ・リンクに失敗を局所化しました。 その時、Node3は失敗が局所化されたのを示すNode4にChannelStatusメッセージを送るはずです。
In the second example [see Fig. 2(b)], a single failure (e.g., fiber cut) affects both directions of the bi-directional LSP. Node 2 (Node 3) will detect the failure of the upstream (downstream) direction and send a ChannelStatus message to the upstream (in terms of data flow) node indicating the failure (e.g., LOL). Simultaneously (ignoring propagation delays), Node 1 (Node 4) will detect the failure on the upstream (downstream) direction, and will send a ChannelStatus message to the corresponding upstream (in terms of data flow) node indicating the failure. Node 2 and Node 3 will have localized the two directions of the failure.
例を後援してください。中、[図2(b)]を見てください、そして、ただ一つの失敗(例えば、ファイバーカット)は双方向のLSPの両方の指示に影響します。 ノード2(ノード3)は、上流(川下)の指示の失敗を検出して、失敗(例えば、LOL)を示す上流(データフローに関する)のノードにChannelStatusメッセージを送るでしょう。 同時(伝播遅延を無視する)に、Node1(ノード4)は上流(川下)の指示に失敗を検出して、失敗を示す対応する上流(データフローに関する)のノードにChannelStatusメッセージを送るでしょう。 ノード2とNode3は失敗の2つの方向を局所化してしまうでしょう。
Lang Standards Track [Page 21] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[21ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
+-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+ + Node1++Node2++Node3++Node4+++--、c---+ +--c---+ +--c---+ + ----+---+ + + + + + + \<。---+---\\--+--------+-------+---\ + + + /--+--->+\--+--------+-------+---\\---+-------+---##---+---//--+---- + + + + \---+-------+--------+---/+++++++(a)++----+-------+--------+---+ + + + + \<。---+-------+--------+---\\--+---##---+--\ + + + + + + \--+---##---+--\\+++++++(b)+\\--+--------+-------+--->+++++\--+--------+-------+---- + + + + + + + + +-------+ +-------+ +-------+ +-------+
Figure 2: Two types of data link failures are shown (indicated
by ## in the figure):
(A) a data link corresponding to the downstream direction of a
bi-directional LSP fails,
(B) two data links corresponding to both directions of a bi-
directional LSP fail. The control channel connecting two
nodes is indicated with a "c".
図2: 2つのタイプのデータ・リンクの故障は示されます(図の##で、示されます): (A) 双方向のLSPの川下の方向に対応するデータ・リンクは失敗します、両性愛者の方向のLSPの両方の方向に対応するデータ・リンクが失敗する(B)two。 2つのノードを接続する制御チャンネルは「c」で示されます。
6.4. Channel Activation Indication
6.4. チャンネル活性化指示
The ChannelStatus message may also be used to notify an LMP neighbor that the data link should be actively monitored. This is called Channel Activation Indication. This is particularly useful in networks with transparent nodes where the status of data links may need to be triggered using control channel messages. For example, if a data link is pre-provisioned and the physical link fails after verification and before inserting user traffic, a mechanism is needed to indicate the data link should be active, otherwise the failure may not be detectable.
また、ChannelStatusメッセージは、データ・リンクが活発にモニターされるべきであるようにLMP隣人に通知するのに使用されるかもしれません。 これはChannel Activation Indicationと呼ばれます。 これはネットワークでデータ・リンクの状態がコントロールチャンネルメッセージを使用することで引き起こされる必要があるかもしれない見え透いたノードで特に役に立ちます。 例えば、データ・リンクにあらかじめ食糧を供給されて、検証の後とユーザ交通を挿入する前に物理的なリンクが失敗するなら、メカニズムが、データ・リンクがアクティブであるべきであることを示すのに必要です。さもなければ、失敗は検出可能でないかもしれません。
The ChannelStatus message is used to indicate that a channel or group of channels are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message. When a ChannelStatus message is received, the corresponding data link(s) MUST be put into the Active state. If upon putting them into the Active state, a failure is detected, the ChannelStatus message SHOULD be transmitted as described in Section 6.2.
ChannelStatusメッセージは、チャンネルのチャンネルかグループが現在活動的であることを示すのに使用されます。 ChannelStatusメッセージを受け取り次第ChannelStatusAckメッセージを送らなければなりません。 ChannelStatusメッセージが受信されているとき、Active状態に対応するデータ・リンクを入れなければなりません。 Active状態にそれらを入れることに関して失敗は検出されます、ChannelStatusメッセージSHOULD。説明されるとして、セクション6.2で伝えられてください。
Lang Standards Track [Page 22] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[22ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
6.5. Channel Deactivation Indication
6.5. チャンネル非活性化指示
The ChannelStatus message may also be used to notify an LMP neighbor that the data link no longer needs to be actively monitored. This is the counterpart to the Channel Active Indication.
また、ChannelStatusメッセージは、もうデータ・リンクによって活発にモニターされる必要はないようにLMP隣人に通知するのに使用されるかもしれません。 これは英仏海峡Active Indicationへの対応者です。
When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state.
Channel Deactive Indicationと共にChannelStatusメッセージを受け取るとき、Active状態から対応するデータ・リンクを取り出さなければなりません。
7. Message_Id Usage
7. メッセージ_イド用法
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP messages to support reliable message delivery. This section describes the usage of these objects. The MESSAGE_ID and MESSAGE_ID_ACK objects contain a Message_Id field.
MESSAGE_IDとMESSAGE_ID_ACK物は信頼できるメッセージ配送を支持するLMPメッセージに含まれています。 このセクションはこれらの物の使用法を説明します。 MESSAGE_IDとMESSAGE_ID_ACK物はMessage_Id分野を含んでいます。
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
どんなLMPメッセージにも1個のMESSAGE_ID/MESSAGE_ID_ACK物だけを含んでもよいです。
For control-channel-specific messages, the Message_Id field is within the scope of the CC_Id. For TE link specific messages, the Message_Id field is within the scope of the LMP adjacency.
コントロールチャンネル詳細メッセージに関しては、CC_アイダホ州の範囲の中にMessage_Id分野があります。 TEに関しては、特定のメッセージをリンクしてください、そして、LMP隣接番組の範囲の中にMessage_Id分野があります。
The Message_Id field of the MESSAGE_ID object contains a generator- selected value. This value MUST be monotonically increasing. A value is considered to be previously used when it has been sent in an LMP message with the same CC_Id (for control channel specific messages) or LMP adjacency (for TE Link specific messages). The Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id field of the message being acknowledged.
MESSAGE_ID物のMessage_Id分野はジェネレータの選択された値を含んでいます。 この値は単調に増加しなければなりません。 LMPメッセージでそれを送ったなら以前同じCC_Id(コントロールが特定のメッセージを向けるので)かLMP隣接番組(TE Linkの特定のメッセージのための)で値が使用されていると考えられます。 承認されていて、MESSAGE_ID_ACK物のMessage_Id分野はメッセージのMessage_Id分野を含んでいます。
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
メッセージが承認されるか、または再試行限界に達するまで、MESSAGE_ID物のSHOULDが再送されている状態で、不承認のメッセージは発信しました(また、セクション10を見てください)。
Note that the 32-bit Message_Id value may wrap. The following expression may be used to test if a newly received Message_Id value is less than a previously received value:
32ビットのMessage_Id値が包装するかもしれない注意。 以下の表現は新たに受け取られたMessage_Id値が以前に容認された値以下であるならテストするのに使用されるかもしれません:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
((int)古い_イド--(int)新しい_イド>0)新しい値は古い値以下です。
Lang Standards Track [Page 23] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[23ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Nodes processing incoming messages SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages can be identified by examining the value in the Message_Id field. If a message is determined to be out-of-order, that message should be silently dropped.
ノード処理入力メッセージSHOULDは、新たに受け取られたメッセージを故障していて、無視できるかどうか確認するためにチェックします。 Message_Id分野で値を調べることによって、不適切なメッセージを特定できます。 メッセージが故障していることを決定しているなら、そのメッセージは静かに落とされるべきです。
If the message is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the CC_Id, then the message SHOULD be treated as being out-of- order.
a Configがメッセージがそうなら通信して、_Idが最も大きいMessage_Id値以前に以下であることを評価するMessageが_CC Idのために送付者から受信して、次に、メッセージSHOULDが存在として扱われたアウトである、-、オーダーについて。
If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out-of-order.
メッセージがLinkSummaryメッセージであり、_Idが最も大きいMessage_Id値以前に以下であることを評価するMessageがTE Link、次に、メッセージSHOULDのために送付者から故障しているとして扱われた状態で受信したなら。
If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise, the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel.
メッセージがChannelStatusメッセージであり、_Idが最も大きいMessage_Id値以前に以下であることを評価するMessageが送付者から指定されたTEリンクに受信したなら、受信機SHOULDは以前にChannelStatusメッセージに各データ・チャンネルを含む状態に受け取られたMessage_Id値をチェックします。 Message_Id値が大部分が最近少なくともメッセージに含まれているデータ・チャンネルのひとりに関連しているMessage_Id値を受けたより大きいなら、故障するとしてメッセージを扱ってはいけません。 そうでなければ、故障しているとして扱われた状態でSHOULDを通信させてください。 しかしながら、_Idが最も最近以下であることを評価するMessageがデータ・チャンネルに関連しているMessage_Id値を受けたなら、どんなデータ・チャンネルの状態もアップデートしてはいけません。
All other messages MUST NOT be treated as out-of-order.
故障するとして他のすべてのメッセージを扱わなければならないというわけではありません。
8. Graceful Restart
8. 優雅な再開
This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after a control communications failure. A control communications failure may be the result of an LMP adjacency failure or a nodal failure wherein the LMP control state is lost, but the data plane is unaffected. The latter is detected by setting the "LMP Restart" bit in the Common Header of the LMP messages. When the control plane fails due to the loss of the control channel, the LMP link information should be retained. It is possible that a node may be capable of retaining the LMP link information across a nodal failure. However, in both cases the status of the data channels MUST be synchronized.
このセクションは、コントロール飛行機再開の後にLMP状態を再連動させるようにメカニズムについて説明します。 コントロールコミュニケーション失敗の後に第1代制御チャンネルを育てるとき、コントロール飛行機再開は起こるかもしれません。 コントロールコミュニケーション失敗はLMPコントロール状態が無くなりますが、データ飛行機が影響を受けないLMP隣接番組の故障かこぶのような失敗の結果であるかもしれません。 後者は、「LMP再開」ビットをLMPメッセージのCommon Headerにはめ込むことによって、検出されます。 制御飛行機が制御チャンネルの損失のため失敗すると、LMPリンク情報は保有されるべきです。 ノードがこぶのような失敗の向こう側にLMPリンク情報を保有できるのは、可能です。 しかしながら、どちらの場合も、データ・チャンネルの状態は同期しなければなりません。
Lang Standards Track [Page 24] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[24ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
It is assumed the Node_Id and Local Interface_Ids remain stable across a control plane restart.
それはNode_Idであると思われます、そして、Local Interface_Idsはコントロール飛行機再開の向こう側に安定した状態を保ちます。
After the control plane of a node restarts, the control channel(s) must be re-established using the procedures of Section 3.1. When re-establishing control channels, the Config message SHOULD be sent using the unicast IP source and destination addresses.
ノードの制御飛行機が再開した後に、セクション3.1の手順を用いることで制御チャンネルを復職させなければなりません。 送られた使用がユニキャストIPソースと送付先アドレスであったなら制御チャンネル、ConfigメッセージSHOULDを復職させるとき。
If the control plane failure was the result of a nodal failure where the LMP control state is lost, then the "LMP Restart" flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is up and the LMP neighbor has detected the restart.
コントロール飛行機の故障がLMPコントロール状態が無くなるこぶのような失敗の結果であったなら、LMPメッセージに地方のTxSeqNumと等しいRcvSeqNumと共にHelloメッセージを受け取るまで「LMP再開」旗を設定しなければなりません。 これは、制御チャンネルが起きていて、LMP隣人が再開を検出したのを示します。
The following assumes that the LMP component restart only occurred on one end of the TE Link. If the LMP component restart occurred on both ends of the TE Link, the normal procedures for LinkSummary should be used, as described in Section 4.
以下は、LMPコンポーネント再開がTE Linkの片端に起こっただけであると仮定します。 LMPコンポーネント再開がTE Linkの両端に起こるなら、LinkSummaryに、正常な手順は用いられるでしょうに、セクション4で説明されるように。
Once a control channel is up, the LMP neighbor MUST send a LinkSummary message for each TE Link across the adjacency. All the objects of the LinkSummary message MUST have the N-bit set to 0, indicating that the parameters are non-negotiable. This provides the local/remote Link_Id and Interface_Id mappings, the associated data link parameters, and indication of which data links are currently allocated to user traffic. When a node receives the LinkSummary message, it checks its local configuration. If the node is capable of retaining the LMP link information across a restart, it must process the LinkSummary message as described in Section 4 with the exception that the allocated/de-allocated flag of the DATA_LINK object received in the LinkSummary message MUST take precedence over any local value. If, however, the node was not capable of retaining the LMP link information across a restart, the node MUST accept the data link parameters of the received LinkSummary message and respond with a LinkSummaryAck message.
制御チャンネルがいったん起きているようになると、LMP隣人は隣接番組の向こう側に各TE LinkへのLinkSummaryメッセージを送らなければなりません。 LinkSummaryメッセージのすべての物で、パラメタが譲渡禁止であることを示して、N-ビットを0に設定しなければなりません。 これはマッピング、関連データリンクパラメータ、およびデータ・リンクが現在ユーザ交通に割り当てられる指示を地方の、または、リモートなLink_IdとInterface_Idに供給します。 ノードがLinkSummaryメッセージを受け取るとき、それは地方の構成をチェックします。 ノードが再開の向こう側にLMPリンク情報を保有できるなら、セクション4で例外でLinkSummaryメッセージに受け取られたDATA_LINK物の割り当てられたか反-割り当てられた旗がどんな地方の値の上でも優先しなければならないと説明するので、それはLinkSummaryメッセージを処理しなければなりません。 しかしながら、ノードが再開の向こう側にLMPリンク情報を保有できなかったなら、ノードは、受信されたLinkSummaryメッセージに関するデータリンクパラメータを受け入れて、LinkSummaryAckメッセージで応じなければなりません。
Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels.
LinkSummary交換、再開したノードの完成のときに、制御飛行機SHOULDはそのTEリンクへのChannelStatusRequestメッセージを送ります。 また、ノードSHOULDはすべての「非-割り当て」られたデータ・チャンネルの接続性について確かめます。
9. Addressing
9. アドレシング
All LMP messages are run over UDP with an LMP port number (except, in some cases, the Test messages, which may be limited by the transport mechanism for in-band messaging). The destination address of the IP packet MAY be either the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the
すべてのLMPメッセージはLMPポートナンバー(いくつかの場合におけるバンドにおけるメッセージングのために移送機構によって制限されるかもしれないTestメッセージを除いた)があるUDPの上の走行です。 IPパケットの送付先アドレスがConfiguration手順で学習されたアドレスであるかもしれない、(すなわち、アドレスがIPヘッダーをコネに見つけたSource IP
Lang Standards Track [Page 25] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[25ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
received Config message), an IP address configured on the remote node, or the Node_Id. The Config message is an exception as described below.
受信されたConfigメッセージ)、IPアドレスは遠隔ノード、またはNodeで_アイダホ州を構成しました。 Configメッセージは以下で説明されるように例外です。
The manner in which a Config message is addressed may depend on the signaling transport mechanism. When the transport mechanism is a point-to-point link, Config messages SHOULD be sent to the Multicast address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be sent to an IP address on the neighboring node. This may be configured at both ends of the control channel or may be automatically discovered.
Configメッセージが記述される方法はシグナリング移送機構によるかもしれません。 ConfigメッセージSHOULD、移送機構がポイントツーポイント接続である、Multicastアドレスに送ってください、(224.0 .0 .1かff02: : 1)。 さもなければ、隣接しているノードでConfigメッセージをIPアドレスに送らなければなりません。 これは、制御チャンネルの両端で構成されるか、または自動的に発見されるかもしれません。
10. Exponential Back-off Procedures
10. 指数の下に後部手順
This section is based on [RFC2961] and provides exponential back-off procedures for message retransmission. Implementations MUST use the described procedures or their equivalent.
このセクションは、[RFC2961]に基づいていて、指数の下に後部手順をメッセージの再送に提供します。 実現は説明された手順かそれらの同等物を用いなければなりません。
10.1. Operation
10.1. 操作
The following operation is one possible mechanism for exponential back-off retransmission of unacknowledged LMP messages. The sending node retransmits the message until an acknowledgement message is received or until a retry limit is reached. When the sending node receives the acknowledgement, retransmission of the message is stopped. The interval between message retransmission is governed by a rapid retransmission timer. The rapid retransmission timer starts at a small interval and increases exponentially until it reaches a threshold.
以下の操作は不承認のLMPメッセージの指数の下に後部「再-トランスミッション」のための1台の可能なメカニズムです。 確認メッセージが受信されているか、または再試行限界に達するまで、送付ノードはメッセージを再送します。 送付ノードが承認を受けるとき、メッセージの「再-トランスミッション」は止められます。 メッセージの再送の間隔は急速な再送信タイマーによって治められます。 急速な再送信タイマーは、小さい間隔で、始まって、敷居に達するまで、指数関数的に増加します。
The following time parameters are useful to characterize the procedures:
以下の時間パラメタは手順を特徴付けるために役に立ちます:
Rapid retransmission interval Ri:
急速な再送信間隔Ri:
Ri is the initial retransmission interval for unacknowledged
messages. After sending the message for the first time, the
sending node will schedule a retransmission after Ri milliseconds.
Riは不承認のメッセージのための初期の再送信間隔です。 初めてメッセージを送った後に、送付ノードはRiミリセカンドの後に「再-トランスミッション」の計画をするでしょう。
Rapid retry limit Rl:
急速な再試行限界Rl:
Rl is the maximum number of times a message will be transmitted
without being acknowledged.
Rlはメッセージが承認されないで送られるという回の最大数です。
Lang Standards Track [Page 26] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[26ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Increment value Delta:
増加デルタ:
Delta governs the speed with which the sender increases the
retransmission interval. The ratio of two successive
retransmission intervals is (1 + Delta).
デルタは速度を送付者が再送信間隔を増加させる決定します。 2回の連続した再送信間隔の比率は(1+デルタ)です。
Suggested default values for an initial retransmission interval (Ri) of 500 ms are a power of 2 exponential back-off (Delta = 1) and a retry limit of 3.
500msの初期の再送信間隔(Ri)の間の提案されたデフォルト値は、下に2の指数の後部(デルタ=1)のパワーと3の再試行限界です。
10.2. Retransmission Algorithm
10.2. 再送信アルゴリズム
After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The retransmission will continue until either an appropriate acknowledgement message is received or the rapid retry limit, Rl, has been reached.
ノードが承認を必要とするメッセージを送った後に、それはRi秒以降にすぐに、「再-トランスミッション」の計画をするべきです。 対応する承認であるならRi秒、次に、メッセージの再送SHOULDの前にメッセージを受け取ります。取り消します。 さもなければ、それは(1+デルタ)*Ri秒以降、メッセージを再送するでしょう。 適切な確認メッセージが受信されているか、または急速な再試行限界(Rl)に達するまで、「再-トランスミッション」は続くでしょう。
A sending node can use the following algorithm when transmitting a message that requires acknowledgement:
承認を必要とするメッセージを送るとき、送付ノードは以下のアルゴリズムを使用できます:
Prior to initial transmission, initialize Rk = Ri and Rn = 0.
初期のトランスミッションの前に、Rk=RiとRn=0を初期化してください。
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;
(Rn++<Rl)はRkミリセカンドの後に目覚めてください; RkがRk*(1+デルタ)と等しいというメッセージを送りますが、/*承認されたメッセージが伸ばしますが、受信機とRlからのどんな回答も清潔な状態で必要であることで、/がいくらかそうする*を伸ばしませんでした。 出てください。
Asynchronously, when a sending node receives a corresponding acknowledgment message, it will change the retry count, Rn, to Rl.
送付ノードが対応する承認メッセージを受け取るとき、非同期に、それは再試行カウント、RnをRlに変えるでしょう。
Note that the transmitting node does not advertise or negotiate the use of the described exponential back-off procedures in the Config or LinkSummary messages.
伝えるノードがConfigかLinkSummaryメッセージにおける説明された指数の下に後部手順の使用を広告を出しもしませんし、交渉もしないことに注意してください。
Lang Standards Track [Page 27] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[27ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
11. LMP Finite State Machines
11. LMP有限状態機械
11.1. Control Channel FSM
11.1. コントロールチャンネルFSM
The control channel FSM defines the states and logics of operation of an LMP control channel.
制御チャンネルFSMはLMP制御チャンネルの操作の州と論理を定義します。
11.1.1. Control Channel States
11.1.1. コントロールチャンネル州
A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end.
制御チャンネルが以下で説明された州の1つにあることができます。 あらゆる状態が、制御チャンネルのある状態に対応している、通常、定期的に遠端に送られる特定のタイプのLMPメッセージに関連しています。
Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values.
以下より倒してください。 これは初期のコントロールチャンネル状態です。 この状態では、制御チャンネルを育てるのを試みを全くしていません、そして、LMPメッセージを全く送りません。 コントロールチャンネルパラメタは初期の値に設定されるべきです。
ConfSnd: The control channel is in the parameter negotiation
state. In this state the node periodically sends a
Config message, and is expecting the other side to reply
with either a ConfigAck or ConfigNack message. The FSM
does not transition into the Active state until the
remote side positively acknowledges the parameters.
ConfSnd: 制御チャンネルがパラメタ交渉状態にあります。 この状態では、ノードは、定期的にConfigメッセージを送って、反対側がConfigAckかConfigNackメッセージのどちらかで返答すると予想しています。 遠隔地側が明確にパラメタを承認するまで、FSMはActive状態にどんな変化もしません。
ConfRcv: The control channel is in the parameter negotiation
state. In this state, the node is waiting for acceptable
configuration parameters from the remote side. Once such
parameters are received and acknowledged, the FSM can
transition to the Active state.
ConfRcv: 制御チャンネルがパラメタ交渉状態にあります。 この状態では、ノードは遠隔地側からの許容できる設定パラメータを待っています。 そのようなパラメタがいったん受け取られて、承認されると、FSMはActive状態への変遷を承認できます。
Active: In this state the node periodically sends a Hello message
and is waiting to receive a valid Hello message. Once a
valid Hello message is received, it can transition to the
up state.
アクティブ: この状態では、ノードは、定期的にHelloメッセージを送って、有効なHelloメッセージを受け取るのを待っています。 有効なHelloメッセージがいったん受信されるようになると、それは上の状態に移行できます。
Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages.
上がる: CCが操作上の状態にあります。 ノードは、有効なHelloメッセージを受け取って、メッセージをHelloに送ります。
GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends.
GoingDown: CCは管理動作のためにこの状態に入るかもしれません。 CCがこの状態にある間、ノードはそれが送るすべてのメッセージにControlChannelDownビットをはめ込みます。
Lang Standards Track [Page 28] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[28ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
11.1.2. Control Channel Events
11.1.2. コントロールチャンネルイベント
Operation of the LMP control channel is described in terms of FSM states and events. Control channel events are generated by the underlying protocols and software modules, as well as by the packet processing routines and FSMs of associated TE links. Every event has its number and a symbolic name. Description of possible control channel events is given below.
LMP制御チャンネルの操作はFSM州と出来事に関して説明されます。 コントロールチャンネルイベントは関連TEリンクのパケット処理の基本的なプロトコルとソフトウェア・モジュール、ルーチン、およびFSMsによって発生します。 あらゆる出来事には、番号と英字名があります。 可能なコントロールチャンネルイベントの記述を以下に与えます。
1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin.
This event, for example, may be triggered by an
operator command, by the successful completion of a
control channel bootstrap procedure, or by
configuration. Depending on the configuration,
this will trigger either
1a) the sending of a Config message,
1b) a period of waiting to receive a Config
message from the remote node.
1 : evBringUp: これはコントロールチャンネル交渉が始まるべきであるのを示す外部的に引き起こされた出来事です。 例えばこの出来事がオペレータコマンドによって引き起こされるかもしれなくて、制御チャンネルの無事終了で手順を独力で進むか、または構成で。 構成によって、これはConfigメッセージ1b) (遠隔ノードからa Configメッセージを受け取る期間の待ち)の発信を引き金の1a)に望んでいます。
2 : evCCDn: This event is generated when there is indication
that the control channel is no longer available.
2 : evCCDn: 制御チャンネルがもう利用可能でないという指示があるとき、この出来事は発生します。
3 : evConfDone: This event indicates a ConfigAck message has been
received, acknowledging the Config parameters.
3 : evConfDone: Configパラメタを承認して、この出来事は、ConfigAckメッセージが受け取られたのを示します。
4 : evConfErr: This event indicates a ConfigNack message has been
received, rejecting the Config parameters.
4 : evConfErr: Configパラメタを拒絶して、この出来事は、ConfigNackメッセージが受け取られたのを示します。
5 : evNewConfOK: New Config message was received from neighbor and
positively acknowledged.
5 : evNewConfOK: 新しいConfigメッセージは、隣人から受け取られて、明確に承認されました。
6 : evNewConfErr: New Config message was received from neighbor and
rejected with a ConfigNack message.
6 : evNewConfErr: 新しいConfigメッセージは、隣人から受け取られて、ConfigNackメッセージで拒絶されました。
7 : evContenWin: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The local node wins the contention. As
a result, the received Config message is ignored.
7 : evContenWin: Configメッセージが隣人に送られた同時代に隣人から新しいConfigメッセージを受け取りました。 ローカルのノードは主張を得ます。 その結果、受信されたConfigメッセージは無視されます。
8 : evContenLost: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The local node loses the contention.
8a) The Config message is positively
acknowledged.
8b) The Config message is negatively
acknowledged.
8 : evContenLost: Configメッセージが隣人に送られた同時代に隣人から新しいConfigメッセージを受け取りました。 ローカルのノードは主張を失います。 8a) Configメッセージは明確に承認されます。 8b) Configメッセージは否定的に承認されます。
Lang Standards Track [Page 29] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[29ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
9 : evAdminDown: The administrator has requested that the control
channel is brought down administratively.
9 : evAdminDown: 管理者は、制御チャンネルが行政上落ち込むよう要求しました。
10: evNbrGoesDn: A packet with ControlChannelDown flag is received
from the neighbor.
10: evNbrGoesDn: 隣人からControlChannelDown旗があるパケットを受け取ります。
11: evHelloRcvd: A Hello packet with expected SeqNum has been
received.
11: evHelloRcvd: 予想されたSeqNumがあるHelloパケットを受け取りました。
12: evHoldTimer: The HelloDeadInterval timer has expired indicating
that no Hello packet has been received. This moves
the control channel back into the Negotiation
state, and depending on the local configuration,
this will trigger either
12a) the sending of periodic Config messages,
12b) a period of waiting to receive Config
messages from the remote node.
12: evHoldTimer: Helloパケットが全く受け取られていないのを示しながら、HelloDeadIntervalタイマは期限が切れました。 12b) 受信するのを待つのについて以上、Configは遠隔ノードからこれは制御チャンネルをNegotiation状態に動かして戻して、地方の構成で依存を動かして、この意志の引き金の12a)が周期的なConfigメッセージの発信であることを通信します。
13: evSeqNumErr: A Hello with unexpected SeqNum received and
discarded.
13: evSeqNumErr: 予期していなかったSeqNumとHelloは受信して、捨てました。
14: evReconfig: Control channel parameters have been reconfigured
and require renegotiation.
14: evReconfig: コントロールチャンネルパラメタは、再構成されて、再交渉を必要とします。
15: evConfRet: A retransmission timer has expired and a Config
message is resent.
15: evConfRet: 再送信タイマーは期限が切れました、そして、Configメッセージを再送します。
16: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent.
16: evHelloRet: HelloIntervalタイマは期限が切れました、そして、Helloパケットを送ります。
17: evDownTimer: A timer has expired and no messages have been
received with the ControlChannelDown flag set.
17: evDownTimer: タイマは期限が切れました、そして、ControlChannelDown旗のセットでメッセージを全く受け取っていません。
11.1.3. Control Channel FSM Description
11.1.3. コントロールチャンネルFSM記述
Figure 3 illustrates operation of the control channel FSM in a form of FSM state transition diagram.
図3はFSM状態遷移ダイヤグラムの形における、制御チャンネルFSMの操作を例証します。
Lang Standards Track [Page 30] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[30ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9| 2| 2|
| ||1b 1a| | | | |
| || v |2,9 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
+--------+ +----------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、--+ | +--------->| 下に| <、-、-、-、-、-、-、-、-、--+ | | |+---------| | <、-、-、-、-、-、--+ | | | || +--------+ | | | | || | ^ 2,9| 2| 2| | ||1b 1a| | | | | | || v|2,9 | | | | || +--------+ | | | | || +->| | <、-、-、-、-、--+| | | | || 4,7,| |ConfSnd| || | | | || 14,15+--| | <、-、-、--+ || | | | || +--------+ | || | | | || 3 8a| | | || | | | || +---------+ |8b14、12a| || | | | || | v| || | | | |+-|------>+--------+ | || | | | | | +->| |-----|-|+ | | | | |6,14| |ConfRcv| | | | | | | | +--| | <--+ | | | | | | | +--------+ | | | | | | | | 5| ^ | | | | | | | +---------+ | | | | | | | | | | | | | | | | | | | vに対して|6 12b| | | | | | |10 +--------+ | | | | | | +----------| | | | | | | | | +--| アクティブ|---|-+ | | | 10,17| | 5,16| | |-------|---+ | +-------+ 9 | 13 +->|、|、|、|、|、| 行きます。| <--、|、-、-、-、-、-、-、-、-、--+--------+ | | | | 下に| | 11| ^ | | | +-------+ | | |5 | | | ^ | v| 6 12b| | | |9 |10 +--------+ | |12a、14| | +----------| |---+ | | | | 上がる|-------+ | +------------------| |---------------+ +--------+ | ^ | | +---+ 11,13,16
Figure 3: Control Channel FSM
図3: コントロールチャンネルFSM
Lang Standards Track [Page 31] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[31ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Event evCCDn always forces the FSM to the down state. Events evHoldTimer and evReconfig always force the FSM to the Negotiation state (either ConfSnd or ConfRcv).
イベントevCCDnはいつも下に状態にFSMを強制します。 イベントのevHoldTimerとevReconfigはいつもNegotiation状態(ConfSndかConfRcvのどちらか)にFSMを強制します。
11.2. TE Link FSM
11.2. TeリンクFSM
The TE Link FSM defines the states and logics of operation of the LMP TE Link.
TE Link FSMはLMP TE Linkの操作の州と論理を定義します。
11.2.1. TE Link States
11.2.1. Teリンク州
An LMP TE link can be in one of the states described below. Every state corresponds to a certain condition of the TE link and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links.
LMP TEリンクが以下で説明された州の1つにあることができます。 あらゆる状態が、TEリンクのある状態に対応している、通常、特定のタイプの関連制御チャンネルで遠端に定期的に伝えられたか、またはデータ・リンクを通してバンドであるLMPメッセージに関連しています。
Down: There are no data links allocated to the TE link.
以下より倒してください。 TEリンクに割り当てられたデータ・リンクが全くありません。
Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP
neighbor. The LinkSummary message is periodically
transmitted to the LMP neighbor.
イニット: TEリンクにデータ・リンクを割り当てましたが、LMP隣人と構成をまだ同期させていません。 LinkSummaryメッセージは定期的にLMP隣人に送られます。
Up: This is the normal operational state of the TE link. At
least one LMP control channel is required to be
operational between the nodes sharing the TE link. As
part of normal operation, the LinkSummary message may be
periodically transmitted to the LMP neighbor or generated
by an external request.
上がる: これはTEリンクの正常な操作上の状態です。 少なくとも1個のLMP制御チャンネルが、TEリンクを共有しながらノードの間で操作上であるのに必要です。 通常の操作の一部として、LinkSummaryメッセージは、定期的にLMP隣人に送られるか、または外部要求で発生するかもしれません。
Degraded: In this state, all LMP control channels are down, but the
TE link still includes some data links that are allocated
to user traffic.
降格する: この状態では、すべてのLMP制御チャンネルが下がっていますが、TEリンクはまだユーザ交通に割り当てられるいくつかのデータ・リンクを含んでいます。
11.2.2. TE Link Events
11.2.2. Teリンクイベント
Operation of the LMP TE link is described in terms of FSM states and events. TE Link events are generated by the packet processing routines and by the FSMs of the associated control channel(s) and the data links. Every event has its number and a symbolic name. Descriptions of possible events are given below.
LMP TEリンクの操作はFSM州と出来事に関して説明されます。 TE Link出来事はパケット処理ルーチンと関連制御チャンネルとデータ・リンクのFSMsによって発生します。 あらゆる出来事には、番号と英字名があります。 可能な出来事の記述を以下に与えます。
1 : evDCUp: One or more data channels have been enabled and
assigned to the TE Link.
1 : evDCUp: 1人以上のデータ・チャンネルが、TE Linkに可能にされて、選任されました。
2 : evSumAck: LinkSummary message received and positively
acknowledged.
2 : evSumAck: 受け取られて、明確に承認されたLinkSummaryメッセージ。
Lang Standards Track [Page 32] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[32ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
3 : evSumNack: LinkSummary message received and negatively
acknowledged.
3 : evSumNack: 受け取られて、否定的に承認されたLinkSummaryメッセージ。
4 : evRcvAck: LinkSummaryAck message received acknowledging the
TE Link Configuration.
4 : evRcvAck: LinkSummaryAckメッセージは、TE Link Configurationを承認しながら、受信されました。
5 : evRcvNack: LinkSummaryNack message received.
5 : evRcvNack: LinkSummaryNackメッセージは受信されました。
6 : evSumRet: Retransmission timer has expired and LinkSummary
message is resent.
6 : evSumRet: 再送信タイマーは期限が切れました、そして、LinkSummaryメッセージを再送します。
7 : evCCUp: First active control channel goes up.
7 : evCCUp: 最初の活発な制御チャンネルは上がります。
8 : evCCDown: Last active control channel goes down.
8 : evCCDown: 最後の活発な制御チャンネルは落ちます。
9 : evDCDown: Last data channel of TE Link has been removed.
9 : evDCDown: TE Linkの最後のデータ・チャンネルを免職しました。
11.2.3. TE Link FSM Description
11.2.3. TeリンクFSM記述
Figure 4 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram.
図4はFSM状態遷移ダイヤグラムの形における、LMP TE Link FSMの操作を例証します。
Lang Standards Track [Page 33] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[33ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6
3,7,8 +--+ | | | +に対して--------+ | | +------------>| 下に| <、-、-、-、-、-、-、-、--+ | | | | | +--------+ | | | ^ | | 1| |9 | | v| | | +--------+ | | | | <、-+ | | | イニット| |3,5,6 |9 | | |--+ 7,8 | 9| +--------+ | | | | | 2,4| | | v| +--------+ 7 +--------+ | | |、-、-、-、-、--、>| |----------+ | 度| | 上がる| | | <、-、-、-、-、--、|、| +--------+ 8 +--------+ | ^ | | +--+ 2,3,4,5,6
Figure 4: LMP TE Link FSM
図4: LMP TeリンクFSM
In the above FSM, the sub-states that may be implemented when the link verification procedure is used have been omitted.
上のFSMでは、リンク検証手続が使用されているとき実行されるかもしれないサブ州は省略されました。
11.3. Data Link FSM
11.3. データ・リンクFSM
The data link FSM defines the states and logics of operation of a data link within an LMP TE link. Operation of a data link is described in terms of FSM states and events. Data links can either be in the active (transmitting) mode, where Test messages are transmitted from them, or the passive (receiving) mode, where Test messages are received through them. For clarity, separate FSMs are defined for the active/passive data links; however, a single set of data link states and events are defined.
データ・リンクFSMはLMP TEリンクの中にデータ・リンクの操作の州と論理を定義します。 データ・リンクの操作はFSM州と出来事に関して説明されます。 データ・リンクが(伝えること)アクティブなモード、または(受信)受け身のモードであることができます。(そこでは、Testメッセージがそれらから送られます)。そこでは、Testメッセージがそれらを通して受け取られます。 明快において、別々のFSMsはアクティブであるか受け身のデータ・リンクと定義されます。 しかしながら、1セットのデータ・リンク州と出来事は定義されます。
Lang Standards Track [Page 34] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[34ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
11.3.1. Data Link States
11.3.1. データ・リンク州
Any data link can be in one of the states described below. Every state corresponds to a certain condition of the data link.
いくらかのデータ・リンクが以下で説明された州の1つにあることができます。 あらゆる状態がデータ・リンクのある状態に対応しています。
Down: The data link has not been put in the resource pool
(i.e., the link is not 'in service')
以下より倒してください。 データ・リンクはリソースプールに入れられていません。(すなわち、リンクは'使用中ではありません')
Test: The data link is being tested. An LMP Test message is
periodically sent through the link.
テスト: データ・リンクはテストされています。 リンクを通して定期的にLMP Testメッセージを送ります。
PasvTest: The data link is being checked for incoming test
messages.
PasvTest: データ・リンクは入って来るテストメッセージがないかどうかチェックされています。
Up/Free: The link has been successfully tested and is now put
in the pool of resources (in-service). The link has
not yet been allocated to data traffic.
上がるか自由: リンクは、(稼働中)で首尾よくテストされて、現在、リソースのプールに入れられます。 リンクはまだデータ通信量に割り当てられていません。
Up/Alloc: The link is up and has been allocated for data
traffic.
/Allocに: リンクを上がって、データ通信量に割り当てました。
11.3.2. Data Link Events
11.3.2. データ・リンク出来事
Data link events are generated by the packet processing routines and by the FSMs of the associated control channel and the TE link.
データ・リンク出来事はパケット処理ルーチンと関連制御チャンネルとTEリンクのFSMsによって発生します。
Every event has its number and a symbolic name. Description of possible data link events is given below:
あらゆる出来事には、番号と英字名があります。 可能なデータ・リンク出来事の記述を以下に与えます:
1 :evCCUp: First active control channel goes up.
1:evCCUp: 最初の活発な制御チャンネルは上がります。
2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between
neighboring nodes.
2:evCCDown: LMP隣人の接続性は無くなっています。 これは、最後のLMP制御チャンネルが隣接しているノードの間で失敗したのを示します。
3 :evStartTst: This is an external event that triggers the
sending of Test messages over the data link.
3:evStartTst: これはデータ・リンクの上でTestメッセージの発信の引き金となる外部のイベントです。
4 :evStartPsv: This is an external event that triggers the
listening for Test messages over the data link.
4:evStartPsv: これはデータ・リンクの上のTestメッセージのための聴取の引き金となる外部のイベントです。
5 :evTestOK: Link verification was successful and the link can
be used for path establishment.
(a) This event indicates the Link Verification
procedure (see Section 5) was successful
for this data link and a TestStatusSuccess
message was received over the control
channel.
5:evTestOK: リンク検証はうまくいきました、そして、経路設立にリンクは使用できます。 (a) このイベントは、Link Verification手順(セクション5を見る)がこのデータ・リンクに成功していて、TestStatusSuccessメッセージが制御チャンネルの上に受け取られたのを示します。
Lang Standards Track [Page 35] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[35ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
(b) This event indicates the link is ready for
path establishment, but the Link
Verification procedure was not used. For
in-band signaling of the control channel,
the control channel establishment may be
sufficient to verify the link.
(b) このイベントは、リンクが経路設立の準備ができているのを示しますが、Link Verification手順は用いられませんでした。 バンドにおける、制御チャンネルのシグナリングでは、コントロールチャンネル設立は、リンクについて確かめるために十分であるかもしれません。
6 :evTestRcv: Test message was received over the data port and a
TestStatusSuccess message is transmitted over the
control channel.
6:evTestRcv: データポートの上にテストメッセージを受け取りました、そして、制御チャンネルの上にTestStatusSuccessメッセージを送ります。
7 :evTestFail: Link verification returned negative results. This
could be because (a) a TestStatusFailure message
was received, or (b) the Verification procedure
has ended without receiving a TestStatusSuccess or
TestStatusFailure message for the data link.
7:evTestFail: リンク検証は否定的結果を返しました。 これは(a) TestStatusFailureメッセージを受け取ったか、または(b) Verification手順がデータ・リンクへのTestStatusSuccessを受けるか、TestStatusFailureメッセージなしで終わったからであるかもしれません。
8 :evPsvTestFail: Link verification returned negative results. This
indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or
(b) the Verification procedure has ended and the
VerifyDeadInterval has not yet expired.
8:evPsvTestFail: リンク検証は否定的結果を返しました。 これは、Testメッセージが検出されなかったのを示します、そして、Verification手順は終わりました、そして、(a) VerifyDeadIntervalが期限が切れたか、または(b) VerifyDeadIntervalはまだ期限が切れていません。
9 :evLnkAlloc: The data link has been allocated.
9:evLnkAlloc: データ・リンクを割り当てました。
10:evLnkDealloc: The data link has been de-allocated.
10 : evLnkDealloc: 反-データ・リンクを割り当てました。
11:evTestRet: A retransmission timer has expired and the Test
message is resent.
11 : evTestRet: 再送信タイマーは期限が切れました、そして、Testメッセージを再送します。
12:evSummaryFail: The LinkSummary did not match for this data port.
12 : evSummaryFail: LinkSummaryはこのデータポートに合っていませんでした。
13:evLocalizeFail: A Failure has been localized to this data link.
13 : evLocalizeFail: Failureはこのデータ・リンクにローカライズされました。
14:evdcDown: The data channel is no longer available.
14 : evdcDown: データ・チャンネルはもう利用可能ではありません。
Lang Standards Track [Page 36] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[36ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
11.3.3. Active Data Link FSM Description
11.3.3. 活発なデータ・リンクFSM記述
Figure 5 illustrates operation of the LMP active data link FSM in a form of FSM state transition diagram.
図5はFSM状態遷移の形のアクティブなデータリンクFSMが図解するLMPの操作を例証します。
+------+
| |<-------+
+--------->| Down | |
| +----| |<-----+ |
| | +------+ | |
| |5b 3| ^ | |
| | | |7 | |
| | v | | |
| | +------+ | |
| | | |<-+ | |
| | | Test | |11 | |
| | | |--+ | |
| | +------+ | |
| | 5a| 3^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +-->| |14 | |
| | Up/Free |----+ |
+---------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |------+
| |
+---------+
+------+ | | <、-、-、-、-、-、--+ +--------->| 下に| | | +----| | <、-、-、-、--+ | | | +------+ | | | |5b3| ^ | | | | | |7 | | | | v| | | | | +------+ | | | | | | <、-+ | | | | | テスト| |11 | | | | | |--+ | | | | +------+ | | | | 5a| 3^ | | | | | | | | | | v| | | |12 | +---------+ | | | +-->| |14 | | | | 上がるか、または自由です。|----+ | +---------| | | +---------+ | 9| ^ | | | | v|10 | +---------+ | | |13 | |/Allocに|------+ | | +---------+
Figure 5: Active LMP Data Link FSM
図5: アクティブなLMPデータ・リンクFSM
Lang Standards Track [Page 37] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[37ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
11.3.4. Passive Data Link FSM Description
11.3.4. 受け身のデータ・リンクFSM記述
Figure 6 illustrates operation of the LMP passive data link FSM in a form of FSM state transition diagram.
図6はFSM状態遷移ダイヤグラムの形における、LMPの受け身のデータ・リンクFSMの操作を例証します。
+------+
| |<------+
+---------->| Down | |
| +-----| |<----+ |
| | +------+ | |
| |5b 4| ^ | |
| | | |8 | |
| | v | | |
| | +----------+ | |
| | | PasvTest | | |
| | +----------+ | |
| | 6| 4^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +--->| Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+
+------+ | | <、-、-、-、-、--+ +---------->| 下に| | | +-----| | <、-、-、--+ | | | +------+ | | | |5b4| ^ | | | | | |8 | | | | v| | | | | +----------+ | | | | | PasvTest| | | | | +----------+ | | | | 6| 4^ | | | | | | | | | | v| | | |12 | +---------+ | | | +--->| 上がるか、または自由です。|14 | | | | |---+ | +----------| | | +---------+ | 9| ^ | | | | v|10 | +---------+ | | |13 | |/Allocに|-----+ | | +---------+
Figure 6: Passive LMP Data Link FSM
図6: 受け身のLMPデータ・リンクFSM
12. LMP Message Formats
12. LMPメッセージ・フォーマット
All LMP messages (except, in some cases, the Test messages, which are limited by the transport mechanism for in-band messaging) are run over UDP with an LMP port number (701).
すべてのLMPメッセージ(いくつかの場合におけるTestメッセージを除いた)はLMPポートナンバー(701)があるUDPの上の走行です。メッセージはバンドにおけるメッセージングのために移送機構によって制限されます。
Lang Standards Track [Page 38] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[38ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.1. Common Header
12.1. 一般的なヘッダー
In addition to the UDP header and standard IP header, all LMP messages (except, in some cases, the Test messages which may be limited by the transport mechanism for in-band messaging) have the following common header:
UDPヘッダーと標準のIPヘッダーに加えて、すべてのLMPメッセージ(いくつかの場合におけるバンドにおけるメッセージングのために移送機構によって制限されるかもしれないTestメッセージを除いた)には、以下の一般的なヘッダーがあります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers| (予約される)です。 | 旗| エムエスジータイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMPの長さ| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Reserved野原は、ゼロとして送られて、領収書の上で無視されるべきです。
All values are defined in network byte order (i.e., big-endian byte order).
すべての値がネットワークバイトオーダー(すなわち、ビッグエンディアンバイトオーダー)で定義されます。
Vers: 4 bits
Vers: 4ビット
Protocol version number. This is version 1.
バージョン番号について議定書の中で述べてください。 これはバージョン1です。
Flags: 8 bits
旗: 8ビット
The following bit-values are defined. All other bits are reserved
and should be sent as zero and ignored on receipt.
以下のビット値は定義されます。 他のすべてのビットが、予約されていて、ゼロとして送られて、領収書の上で無視されるべきです。
0x01: ControlChannelDown
0×01: ControlChannelDown
0x02: LMP Restart
0×02: LMP再開
This bit is set to indicate that a nodal failure has occurred
and the LMP control state has been lost. This flag may be
reset to 0 when a Hello message is received with RcvSeqNum
equal to the local TxSeqNum.
このビットが、こぶのような失敗が起こって、LMPコントロール状態が失われたのを示すように設定されます。 地方のTxSeqNumと等しいRcvSeqNumと共にHelloメッセージを受け取るとき、この旗を0にリセットするかもしれません。
Msg Type: 8 bits
エムエスジーは以下をタイプします。 8ビット
The following values are defined. All other values are reserved
以下の値は定義されます。 他のすべての値が予約されています。
1 = Config
1 =コンフィグ
2 = ConfigAck
2 =ConfigAck
3 = ConfigNack
3 =ConfigNack
Lang Standards Track [Page 39] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[39ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
4 = Hello
4が等しい、こんにちは。
5 = BeginVerify
5 =BeginVerify
6 = BeginVerifyAck
6 =BeginVerifyAck
7 = BeginVerifyNack
7 =BeginVerifyNack
8 = EndVerify
8 =EndVerify
9 = EndVerifyAck
9 =EndVerifyAck
10 = Test
10 =テスト
11 = TestStatusSuccess
11 =TestStatusSuccess
12 = TestStatusFailure
12 =TestStatusFailure
13 = TestStatusAck
13 =TestStatusAck
14 = LinkSummary
14 =LinkSummary
15 = LinkSummaryAck
15 =LinkSummaryAck
16 = LinkSummaryNack
16 =LinkSummaryNack
17 = ChannelStatus
17 =ChannelStatus
18 = ChannelStatusAck
18 =ChannelStatusAck
19 = ChannelStatusRequest
19 =ChannelStatusRequest
20 = ChannelStatusResponse
20 =ChannelStatusResponse
All of the messages are sent over the control channel EXCEPT the
Test message, which is sent over the data link that is being
tested.
Testメッセージを除いて、制御チャンネルの上にメッセージのすべてを送ります。(それは、データ・リンクに上テストされている送られます)。
LMP Length: 16 bits
LMPの長さ: 16ビット
The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow.
一般的なヘッダーと続くどんな可変長のオブジェクトも含むバイトで表現されるこのLMPメッセージの全長。
Lang Standards Track [Page 40] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[40ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.2. LMP Object Format
12.2. LMPオブジェクト形式
LMP messages are built using objects. Each object is identified by its Object Class and Class-type. Each object has a name, which is always capitalized in this document. LMP objects can be either negotiable or non-negotiable (identified by the N bit in the object header). Negotiable objects can be used to let the devices agree on certain values. Non-negotiable objects are used for announcement of specific values that do not need or do not allow negotiation.
オブジェクトを使用するのはLMPメッセージに建てられます。 各オブジェクトはそのObject ClassとClass-タイプによって特定されます。 各オブジェクトには、名前があります。(それは、いつも本書では大文字で書かれます)。 LMPオブジェクトは、交渉可能であるか、または譲渡禁止である場合があります(オブジェクトヘッダーのNビットで、特定されます)。 デバイスをある値に同意させるのに交渉可能なオブジェクトを使用できます。 譲渡禁止のオブジェクトは、特定の必要性ではなく、そうする値の発表に使用されるか、または交渉を許しません。
All values are defined in network byte order (i.e., big-endian byte order).
すべての値がネットワークバイトオーダー(すなわち、ビッグエンディアンバイトオーダー)で定義されます。
The format of the LMP object is as follows:
LMPオブジェクトの形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| C-タイプ| クラス| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(オブジェクトコンテンツ)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
N: 1ビット
The N flag indicates if the object is negotiable (N=1) or non-
negotiable (N=0).
N旗は、オブジェクトが交渉可能な(N=1)か非交渉可能な(N=0)であると示します。
C-Type: 7 bits
C-タイプ: 7ビット
Class-type, unique within an Object Class. Values are defined in
Section 13.
Object Classの中でユニークなクラスタイプ。 値はセクション13で定義されます。
Class: 8 bits
クラス: 8ビット
The Class indicates the object type. Each object has a name,
which is always capitalized in this document.
Classはオブジェクト・タイプを示します。 各オブジェクトには、名前があります。(それは、いつも本書では大文字で書かれます)。
Length: 16 bits
長さ: 16ビット
The Length field indicates the length of the object in bytes,
including the N, C-Type, Class, and Length fields.
Length分野はN、C-タイプ、Class、およびLength分野を含むバイトで表現されるオブジェクトの長さを示します。
Lang Standards Track [Page 41] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[41ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.3. Parameter Negotiation Messages
12.3. パラメタ交渉メッセージ
12.3.1. Config Message (Msg Type = 1)
12.3.1. コンフィグメッセージ(エムエスジータイプ=1)
The Config message is used in the control channel negotiation phase of LMP. The contents of the Config message are built using LMP objects. The format of the Config message is as follows:
ConfigメッセージはLMPのコントロールチャンネル交渉フェーズに使用されます。 LMPオブジェクトを使用するのはConfigメッセージの内容に建てられます。 Configメッセージの形式は以下の通りです:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
<コンフィグメッセージ>:、:= 一般的な地方の<の地方の_ノード_ID><ヘッダー><_CCID><メッセージ_ID><コンフィグ>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
LOCAL_CCIDオブジェクトの範囲の中にMESSAGE_IDオブジェクトがあります。
The Config message MUST be periodically transmitted until (1) it receives a ConfigAck or ConfigNack message, (2) a retry limit has been reached and no ConfigAck or ConfigNack message has been received, or (3) it receives a Config message from the remote node and has lost the contention (e.g., the Node_Id of the remote node is higher than the Node_Id of the local node). Both the retransmission interval and the retry limit are local configuration parameters.
(1) ConfigAckかConfigNackメッセージを受け取って、(2) 再試行限界に達して、どんなConfigAckもConfigNackメッセージも受け取っていないか、(3) 遠隔ノードからConfigメッセージを受け取って、主張を失うまで(例えば、遠隔ノードのNode_IdはローカルのノードのNode_Idより高いです)、Configメッセージを定期的に送らなければなりません。 再送信間隔と再試行限界の両方がローカルの設定パラメータです。
12.3.2. ConfigAck Message (Msg Type = 2)
12.3.2. ConfigAckメッセージ(エムエスジータイプ=2)
The ConfigAck message is used to acknowledge receipt of the Config message and indicate agreement on all parameters.
ConfigAckメッセージは、Configメッセージの領収書を受け取ったことを知らせて、すべてのパラメタの協定を示すのに使用されます。
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
<ConfigAckメッセージ>:、:= 一般的なローカルのローカルのリモート<のID_ACK><リモート_ヘッダー><_CCID><_ノード_ID><_CCID><メッセージ_ノード_ID>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged.
承認されていて、Configメッセージから_REMOTE_CCID、MESSAGE_IDのACK、およびREMOTEのコンテンツを得なければなりません_NODE_IDが、反対する。
12.3.3. ConfigNack Message (Msg Type = 3)
12.3.3. ConfigNackメッセージ(エムエスジータイプ=3)
The ConfigNack message is used to acknowledge receipt of the Config message and indicate disagreement on non-negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Message. The format of the ConfigNack message is as follows:
ConfigNackメッセージは、Configメッセージの領収書を受け取ったことを知らせて、譲渡禁止のパラメタで不一致を示すか、または交渉可能なパラメタのために他の値を提案するのに使用されます。 ConfigNack Messageに合意に達したパラメタを含んではいけません。 ConfigNackメッセージの形式は以下の通りです:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
<ConfigNackメッセージ>:、:= 一般的な地方の地方のリモート<のリモート_ノード_ID><ヘッダー><_CCID><_ノード_ID><_CCID><メッセージ_ID_ACK><コンフィグ>。
Lang Standards Track [Page 42] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[42ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged.
否定的に承認されるConfigメッセージから_REMOTE_CCID、MESSAGE_IDのACK、およびREMOTEのコンテンツを得なければなりません_NODE_IDが、反対する。
It is possible that multiple parameters may be invalid in the Config message.
複数のパラメタがConfigメッセージで無効であることは、可能です。
If a negotiable CONFIG object is included in the ConfigNack message, it MUST include acceptable values for the parameters.
交渉可能なCONFIGオブジェクトがConfigNackメッセージに含まれているなら、それはパラメタのための許容値を含まなければなりません。
If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message.
ConfigNackメッセージが譲渡禁止のパラメタのためのCONFIGオブジェクトを含んでいるなら、Configメッセージに受け取られたCONFIGオブジェクトからそれらをコピーしなければなりません。
If the ConfigNack message is received and only includes CONFIG objects that are negotiable, then a new Config message SHOULD be sent. The values in the CONFIG object of the new Config message SHOULD take into account the acceptable values included in the ConfigNack message.
受け取られたConfigNackメッセージとインクルード次に、交渉可能なCONFIGオブジェクト、aだけ新しいConfigメッセージSHOULDであるなら、送ってください。 新しいConfigメッセージSHOULDのCONFIGオブジェクトの値はConfigNackメッセージに含まれていた許容値を考慮に入れます。
If a node receives a Config message and recognizes the CONFIG object, but does not recognize the C-Type, a ConfigNack message including the unknown CONFIG object MUST be sent.
ノードがConfigメッセージを受け取って、CONFIGオブジェクトを認識しますが、C-タイプを見分けないなら、未知のCONFIGオブジェクトを含むConfigNackメッセージを送らなければなりません。
12.4. Hello Message (Msg Type = 4)
12.4. こんにちは、メッセージ(エムエスジータイプ=4)
The format of the Hello message is as follows:
Helloメッセージの形式は以下の通りです:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
<、こんにちは、メッセージ>:、:= <の一般的なヘッダーの>の<の地方の_CCID><、こんにちは、>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The Hello message MUST be periodically transmitted at least once every HelloInterval msec. If no Hello message is received within the HelloDeadInterval, the control channel is assumed to have failed.
少なくとも一度伝えられて、定期的にHelloメッセージはそうであるに違いありません。あらゆるHelloInterval msec。 HelloDeadIntervalの中にHelloメッセージを全く受け取らないなら、失敗したと制御チャンネルを思います。
12.5. Link Verification Messages
12.5. リンク検証メッセージ
12.5.1. BeginVerify Message (Msg Type = 5)
12.5.1. BeginVerifyメッセージ(エムエスジータイプ=5)
The BeginVerify message is sent over the control channel and is used to initiate the link verification process. The format is as follows:
BeginVerifyメッセージは、制御チャンネルの上に送られて、リンク検証の過程に着手するのに使用されます。 形式は以下の通りです:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
<BeginVerifyメッセージ>:、:= ID>[<のリモート_リンク_ID>]<が_を始めるという一般的な<のローカルの_リンク_ID><ヘッダー><メッセージ_は>について確かめます。
Lang Standards Track [Page 43] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[43ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
To limit the scope of Link Verification to a particular TE Link, the Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. In the special case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that have not yet been assigned to a TE link (see Section 5).
Link Verificationの範囲を特定のTE Link、LOCAL_LINK_ID物のLink_Id分野に制限するのは、非ゼロであるに違いありません。 この分野がゼロであるなら、データ・リンクは複数のTEリンクにかかることができます、そして、それらはまだ構成していてはいけないTEリンクを包括するかもしれません。 地方のLink_Id分野がゼロである特別な場合では、「すべてのリンクスについて確かめてください」というBEGIN_VERIFY物の旗は、複数のその長さTEのデータ・リンクの間でまだTEリンクに割り当てられていないリンクとものを区別するのに使用されます(セクション5を見てください)。
The REMOTE_LINK_ID object may be included if the local/remote Link_Id mapping is known.
地方の、または、リモートなLink_Idマッピングが知られているなら、REMOTE_LINK_ID物は含まれるかもしれません。
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if included.
含まれているなら、REMOTE_LINK_ID物のLink_Id分野は非ゼロであるに違いありません。
The BeginVerify message MUST be periodically transmitted until (1) the node receives either a BeginVerifyAck or BeginVerifyNack message to accept or reject the verify process or (2) a retry limit has been reached and no BeginVerifyAck or BeginVerifyNack message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
(2) BeginVerifyメッセージが(1) ノードが受け入れるBeginVerifyAckかBeginVerifyNackメッセージを受け取るまで定期的に伝えられなければならないか、または検証の過程を拒絶しなければならない、再試行限界に達して、さもなければ、どんなBeginVerifyAckもBeginVerifyNackメッセージも受け取っていません。 再送信間隔と再試行限界の両方がローカルの設定パラメータです。
12.5.2. BeginVerifyAck Message (Msg Type = 6)
12.5.2. BeginVerifyAckメッセージ(エムエスジータイプ=6)
When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted.
BeginVerifyメッセージが受信されていて、Testメッセージが処理される準備ができているとき、BeginVerifyAckメッセージを送らなければなりません。
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
<BeginVerifyAckメッセージ>:、:= ID_ACK><が_を始めるという<コモンヘッダー>[<のローカルの_リンク_ID>]<メッセージ_が_<が確かめるACK>について確かめる、_ID>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The LOCAL_LINK_ID object may be included if the local/remote Link_Id mapping is known or learned through the BeginVerify message.
地方の、または、リモートなLink_IdマッピングがBeginVerifyメッセージを通して知られているか、または学習されるなら、LOCAL_LINK_ID物は含まれるかもしれません。
The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
含まれているなら、LOCAL_LINK_IDのLink_Id分野は非ゼロであるに違いありません。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged.
承認されていて、BeginVerifyメッセージからMESSAGE_ID_ACK物のコンテンツを得なければなりません。
The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. This value is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors.
VERIFY_ID物はBeginVerifyAckメッセージのジェネレータによって割り当てられるノードユニークな値を含んでいます。 この値は、同じLMP隣人の間の複数のLMP隣人、そして/または、平行なTest手順からVerificationの過程を唯一特定するのに使用されます。
Lang Standards Track [Page 44] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[44ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.5.3. BeginVerifyNack Message (Msg Type = 7)
12.5.3. BeginVerifyNackメッセージ(エムエスジータイプ=7)
If a BeginVerify message is received and a node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted.
ノードがBeginVerifyメッセージが受信されていて、不本意であるか、またはVerification手順を始めることができないなら、BeginVerifyNackメッセージを送らなければなりません。
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
<BeginVerifyNackメッセージ>:、:= _<一般的なヘッダー>[<のローカルの_リンク_ID>]<メッセージ_ID ACK><誤り_コード>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged.
否定的に承認されるBeginVerifyメッセージからMESSAGE_ID_ACK物のコンテンツを得なければなりません。
If the Verification process is not supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported".
Verificationの過程が支持されないなら、「リンクVerification Procedureは支持しませんでした。」と、ERROR_CODE MUSTは示します。
If Verification is supported, but the node is unable to begin the procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a BeginVerifyNack message is received with such an ERROR_CODE, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter.
Verificationが支持されますが、ノードが「確かめるために、不本意な」状態で手順、CODE MUSTが示すERROR_を始めることができないなら。 BeginVerifyNackメッセージが受信されているなら、そのようなERROR_CODE、由来したノードでBeginVerify SHOULDはRf秒以降BeginVerify retransmissionの計画をします、Rfが局所的に定義されたパラメタであるところで。
If the Verification Transport mechanism is not supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism".
Verification Transportメカニズムがサポートされないなら、ERROR_CODE MUSTは「サポートされない検証移送機構」を示します。
If remote configuration of the Link_Id is not supported and the content of the REMOTE_LINK_ID object (included in the BeginVerify message) does not match any configured values, the ERROR_CODE MUST indicate "Link_Id configuration error".
Link_Idのリモート構成が支持されないで、またREMOTE_LINK_ID物(BeginVerifyメッセージでは、含まれている)の内容が少しの構成された値にも合っていないなら、ERROR_CODE MUSTは「リンク_Id構成誤り」を示します。
If a node receives a BeginVerify message and recognizes the BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE MUST indicate "Unknown object C-Type".
ノードがBeginVerifyメッセージを受け取って、BEGIN_VERIFY物を認識しますが、C-タイプを見分けないなら、ERROR_CODE MUSTは「未知の物のC-タイプ」を示します。
12.5.4. EndVerify Message (Msg Type = 8)
12.5.4. EndVerifyメッセージ(エムエスジータイプ=8)
The EndVerify message is sent over the control channel and is used to terminate the link verification process. The EndVerify message may be sent any time the initiating node desires to end the Verify procedure. The format is as follows:
EndVerifyメッセージは、制御チャンネルの上に送られて、リンク検証の過程を終えるのに使用されます。 EndVerifyメッセージは送られたいずれかが開始ノードがVerify手順を終わらせることを望んでいる時間であったならそうするかもしれません。 形式は以下の通りです:
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
<EndVerifyメッセージ>:、:=<の一般的なヘッダー><メッセージ_ID><は_ID>について確かめます。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
Lang Standards Track [Page 45] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[45ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The EndVerify message will be periodically transmitted until (1) an EndVerifyAck message has been received or (2) a retry limit has been reached and no EndVerifyAck message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
EndVerifyメッセージは(1) EndVerifyAckメッセージを受け取ったか、再試行限界に達して、または(2) EndVerifyAckメッセージを全く受け取らないまで定期的に送られるでしょう。 再送信間隔と再試行限界の両方がローカルの設定パラメータです。
12.5.5. EndVerifyAck Message (Msg Type =9)
12.5.5. EndVerifyAckメッセージ(エムエスジータイプ=9)
The EndVerifyAck message is sent over the control channel and is used to acknowledge the termination of the link verification process. The format is as follows:
EndVerifyAckメッセージは、制御チャンネルの上に送られて、リンク検証の過程の終了を承諾するのに使用されます。 形式は以下の通りです:
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
<EndVerifyAckメッセージ>:、:= _ID_ACK><が_ID>について確かめるという<の一般的なヘッダー><メッセージ
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged.
承認されていて、EndVerifyメッセージからMESSAGE_ID_ACK物のコンテンツを得なければなりません。
12.5.6. Test Message (Msg Type = 10)
12.5.6. テストメッセージ(エムエスジータイプ=10)
The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated, these messages MUST be transmitted over UDP like all other LMP messages. The format of the Test messages is as follows:
Testメッセージは、データ・リンクの上に送られて、物理的な接続性について確かめるのに使用されます。 明らかに述べられない場合、他のすべてのLMPメッセージのようにこれらのメッセージをUDPの上に送らなければなりません。 Testメッセージの形式は以下の通りです:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
<テストメッセージ>:、:= 一般的な<のヘッダー><ローカルの_インタフェース_ID><は_ID>について確かめます。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
Note that this message is sent over a data link and NOT over the control channel. The transport mechanism for the Test message is negotiated using the Verify Transport Mechanism field of the BEGIN_VERIFY object and the Verify Transport Response field of the BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
このメッセージが制御チャンネルではなく、データ・リンクの上に送られることに注意してください。 Testメッセージのための移送機構は、BEGIN_VERIFY物のVerify Transport Mechanism分野とBEGIN_VERIFY_ACK物のVerify Transport Response分野を使用することで交渉されます(セクション13.8と13.9を見てください)。
The local (transmitting) node sends a given Test message periodically (at least once every VerifyInterval ms) on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node or (2) all active control channels between the two nodes have failed. The remote node will send a given TestStatus message periodically over the control channel until it receives either a correlating TestStatusAck message or an EndVerify message.
(1) コントロールに関するTestStatusSuccessかTestStatusFailureメッセージが(受信)リモートノードからチャネルを開設する関連を受けるか、または(2) 2つのノードの間のすべての活発な制御チャンネルが失敗するまで、(伝えること)ローカルのノードは与えられたTestメッセージを対応するデータ・リンクに定期的(少なくともかつてのあらゆるVerifyInterval ms)に送ります。 それが関連TestStatusAckメッセージかEndVerifyメッセージのどちらかを受け取るまで、遠隔ノードは与えられたTestStatusメッセージを制御チャンネルの上に定期的に送るでしょう。
Lang Standards Track [Page 46] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[46ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.5.7. TestStatusSuccess Message (Msg Type = 11)
12.5.7. TestStatusSuccessメッセージ(エムエスジータイプ=11)
The TestStatusSuccess message is transmitted over the control channel and is used to transmit the mapping between the local Interface_Id and the Interface_Id that was received in the Test message.
TestStatusSuccessメッセージは、制御チャンネルの上に送られて、Testメッセージに受け取られた地方のInterface_IdとInterface_Idの間にマッピングを伝えるのに使用されます。
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
<TestStatusSuccessメッセージ>:、:= 一般的なローカルのローカルの<のインタフェース_ID><リモート_ヘッダー><_リンク_ID><メッセージ_ID><_インタフェース_ID><は_ID>について確かめます。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged.
明確に承認される対応するTestメッセージからREMOTE_INTERFACE_ID物のコンテンツを得なければなりません。
12.5.8. TestStatusFailure Message (Msg Type = 12)
12.5.8. TestStatusFailureメッセージ(エムエスジータイプ=12)
The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received.
TestStatusFailureメッセージは、制御チャンネルの上に送られて、Testメッセージが受け取られなかったのを示すのに使用されます。
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
<TestStatusFailureメッセージ>:、:= <の一般的なヘッダー><メッセージ_ID><は_ID>について確かめます。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
12.5.9. TestStatusAck Message (Msg Type = 13)
12.5.9. TestStatusAckメッセージ(エムエスジータイプ=13)
The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages.
TestStatusAckメッセージは、TestStatusSuccessかTestStatusFailureメッセージの領収書を受け取ったことを知らせるのに使用されます。
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
<TestStatusAckメッセージ>:、:= _ID_ACK><が_ID>について確かめるという<の一般的なヘッダー><メッセージ
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged.
承認されていて、TestStatusSuccessかTestStatusFailureメッセージからMESSAGE_ID_ACK物のコンテンツを得なければなりません。
12.6. Link Summary Messages
12.6. リンク概要メッセージ
12.6.1. LinkSummary Message (Msg Type = 14)
12.6.1. LinkSummaryメッセージ(エムエスジータイプ=14)
The LinkSummary message is used to synchronize the Interface_Ids and correlate the properties of the TE link. The format of the LinkSummary message is as follows:
LinkSummaryメッセージは、Interface_Idsを連動させて、TEリンクの特性を関連させるのに使用されます。 LinkSummaryメッセージの形式は以下の通りです:
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
<LinkSummaryメッセージ>:、:= <の一般的なヘッダー><メッセージ_ID><Te_リンク><データ_リンク>。[<データ_は>をリンクします…]
Lang Standards Track [Page 47] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[47ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The LinkSummary message can be exchanged any time a link is not in the Verification process. The LinkSummary message MUST be periodically transmitted until (1) the node receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has been reached and no LinkSummaryAck or LinkSummaryNack message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
リンクがVerificationの過程にない何時でもLinkSummaryメッセージを交換できます。 (2) (1) ノードがLinkSummaryAckかLinkSummaryNackメッセージを受け取るまでLinkSummaryメッセージを定期的に送らなければならない、再試行限界に達しました、そして、さもなければ、どんなLinkSummaryAckもLinkSummaryNackメッセージも受け取っていません。 再送信間隔と再試行限界の両方がローカルの設定パラメータです。
12.6.2. LinkSummaryAck Message (Msg Type = 15)
12.6.2. LinkSummaryAckメッセージ(エムエスジータイプ=15)
The LinkSummaryAck message is used to indicate agreement on the Interface_Id synchronization and acceptance/agreement on all the link parameters. It is on the reception of this message that the local node makes the Link_Id associations.
LinkSummaryAckメッセージは、Interface_Id同期の協定とすべてのリンクパラメータの承認/協定を示すのに使用されます。 このメッセージのレセプションでは、ローカルのノードはLink_Id協会を作ります。
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<LinkSummaryAckメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
12.6.3. LinkSummaryNack Message (Msg Type = 16)
12.6.3. LinkSummaryNackメッセージ(エムエスジータイプ=16)
The LinkSummaryNack message is used to indicate disagreement on non- negotiated parameters or propose other values for negotiable parameters. Parameters on which agreement was reached MUST NOT be included in the LinkSummaryNack message.
LinkSummaryNackメッセージは、非交渉されたパラメタで不一致を示すか、または交渉可能なパラメタのために他の値を提案するのに使用されます。 LinkSummaryNackメッセージに合意に達したパラメタを含んではいけません。
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
<LinkSummaryNackメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK><誤り_コード>。[<データ_は>をリンクします…]
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The DATA_LINK objects MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes DATA_LINK objects for non-negotiable parameters, they MUST be copied from the DATA_LINK objects received in the LinkSummary message.
DATA_LINK物はすべての交渉可能なパラメタのための許容値を含まなければなりません。 LinkSummaryNackが譲渡禁止のパラメタのためのDATA_LINK物を含んでいるなら、LinkSummaryメッセージに受け取られたDATA_LINK物からそれらをコピーしなければなりません。
If the LinkSummaryNack message is received and only includes negotiable parameters, then a new LinkSummary message SHOULD be sent. The values received in the new LinkSummary message SHOULD take into account the acceptable parameters included in the LinkSummaryNack message.
受け取られたLinkSummaryNackメッセージとインクルード交渉可能なパラメタ、当時のaだけ新しいLinkSummaryメッセージSHOULDであるなら、送ってください。 新しいLinkSummaryメッセージSHOULDに受け取られた値はLinkSummaryNackメッセージに含まれていた許容できるパラメタを考慮に入れます。
If the LinkSummary message is received with unacceptable, non- negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable non-negotiable LINK_SUMMARY parameters."
容認できなくて、非交渉可能なパラメタでLinkSummaryメッセージを受け取るなら、ERROR_CODE MUSTは「容認できない譲渡禁止のLINK_SUMMARYパラメタ」を示します。
Lang Standards Track [Page 48] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[48ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
If the LinkSummary message is received with unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters."
容認できない交渉可能なパラメタでLinkSummaryメッセージを受け取るなら、「LINK_SUMMARYパラメタを再交渉してください。」と、ERROR_CODE MUSTは示します。
If the LinkSummary message is received with an invalid TE_LINK object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
無効のTE_LINK物でLinkSummaryメッセージを受け取るなら、「無効のTE_LINKは反対します。」と、ERROR_CODE MUSTは示します。
If the LinkSummary message is received with an invalid DATA_LINK object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
無効のDATA_LINK物でLinkSummaryメッセージを受け取るなら、「無効のDATA_LINKは反対します。」と、ERROR_CODE MUSTは示します。
If the LinkSummary message is received with a TE_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK object C-Type."
TE_LINK物でLinkSummaryメッセージを受け取りますが、C-タイプが未知であるなら、「未知のTE_LINK物のC-タイプ」と、ERROR_CODE MUSTは示します。
If the LinkSummary message is received with a DATA_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown DATA_LINK object C-Type."
DATA_LINK物でLinkSummaryメッセージを受け取りますが、C-タイプが未知であるなら、「未知のDATA_LINK物のC-タイプ」と、ERROR_CODE MUSTは示します。
12.7. Fault Management Messages
12.7. 障害管理メッセージ
12.7.1. ChannelStatus Message (Msg Type = 17)
12.7.1. ChannelStatusメッセージ(エムエスジータイプ=17)
The ChannelStatus message is sent over the control channel and is used to notify an LMP neighbor of the status of a data link. A node that receives a ChannelStatus message MUST respond with a ChannelStatusAck message. The format is as follows:
ChannelStatusメッセージは、制御チャンネルの上に送られて、データ・リンクの状態についてLMP隣人に通知するのに使用されます。 ChannelStatusメッセージを受け取るノードはChannelStatusAckメッセージで応じなければなりません。 形式は以下の通りです:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
<ChannelStatusメッセージ>:、:= 一般的なローカルの<の><メッセージ_ID><ヘッダー><_リンク_IDチャンネル_状態>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
If the CHANNEL_STATUS object does not include any Interface_Ids, then this indicates the entire TE Link has failed.
CHANNEL_STATUS物が少しのInterface_Idsも含んでいないなら、これは、全体のTE Linkが失敗したのを示します。
12.7.2. ChannelStatusAck Message (Msg Type = 18)
12.7.2. ChannelStatusAckメッセージ(エムエスジータイプ=18)
The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus Message. The format is as follows:
ChannelStatusAckメッセージは、ChannelStatus Messageの領収書を受け取ったことを知らせるのに使用されます。 形式は以下の通りです:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ChannelStatusAckメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged.
承認されていて、ChannelStatusメッセージからMESSAGE_ID_ACK物のコンテンツを得なければなりません。
Lang Standards Track [Page 49] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[49ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
12.7.3. ChannelStatusRequest Message (Msg Type = 19)
12.7.3. ChannelStatusRequestメッセージ(エムエスジータイプ=19)
The ChannelStatusRequest message is sent over the control channel and is used to request the status of one or more data link(s). A node that receives a ChannelStatusRequest message MUST respond with a ChannelStatusResponse message. The format is as follows:
ChannelStatusRequestメッセージは、制御チャンネルの上に送られて、1個以上のデータ・リンクの状態を要求するのに使用されます。 ChannelStatusRequestメッセージを受け取るノードはChannelStatusResponseメッセージで応じなければなりません。 形式は以下の通りです:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
<ChannelStatusRequestメッセージ>:、:= 一般的な<のヘッダー><ローカルの_リンク_ID><メッセージ_ID>。[_<チャンネル_状態要求>]
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
If the CHANNEL_STATUS_REQUEST object is not included, then the ChannelStatusRequest is being used to request the status of ALL of the data link(s) of the TE Link.
CHANNEL_STATUS_REQUESTオブジェクトが含まれていないなら、ChannelStatusRequestは、TE Linkのデータ・リンクのすべての状態を要求するのに使用されています。
12.7.4. ChannelStatusResponse Message (Msg Type = 20)
12.7.4. ChannelStatusResponseメッセージ(エムエスジータイプ=20)
The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest Message and notify the LMP neighbor of the status of the data channel(s). The format is as follows:
ChannelStatusResponseメッセージは、データ・チャンネルの状態についてChannelStatusRequest Messageの領収書を受け取ったことを知らせて、LMP隣人に通知するのに使用されます。 形式は以下の通りです:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>
<ChannelStatusResponseメッセージ>:、:= 一般的な<のメッセージ_ID_ACK><ヘッダー><チャンネル_状態>。
The above transmission order SHOULD be followed.
上のトランスミッションはSHOULDを注文します。続かれています。
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged.
承認されていて、ChannelStatusRequestメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。
13. LMP Object Definitions
13. LMPオブジェクト定義
13.1. CCID (Control Channel ID) Class
13.1. CCID(コントロールチャンネルID)のクラス
Class = 1
クラス=1
o C-Type = 1, LOCAL_CCID
o =1、地方の_CCIDをCでタイプしてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 50] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[50ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
CC_Id: 32 bits
_イドをCCしてください: 32ビット
This MUST be node-wide unique and non-zero. The CC_Id identifies
the control channel of the sender associated with the message.
これはユニーク、そして、非ゼロに合わせてノード全体であるに違いありません。 CC_Idはメッセージに関連している送付者の制御チャンネルを特定します。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
o C-Type = 2, REMOTE_CCID
o =2、リモート_CCIDをCでタイプしてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
_イドをCCしてください: 32ビット
This identifies the remote node's CC_Id and MUST be non-zero.
これは、遠隔ノードのCC_Idを特定して、非ゼロに合わせなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.2. NODE_ID Class
13.2. ノード_IDのクラス
Class = 2
クラス=2
o C-Type = 1, LOCAL_NODE_ID
o C-タイプは1、ローカルの_ノード_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ノード_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
ノード_イド:
This identities the node that originated the LMP packet.
このアイデンティティ、LMPパケットを溯源したノード。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
o C-Type = 2, REMOTE_NODE_ID
o C-タイプは2、リモート_ノード_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ノード_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 51] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[51ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Node_Id:
ノード_イド:
This identities the remote node.
このアイデンティティ、遠隔ノード。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.3. LINK_ID Class
13.3. リンク_IDのクラス
Class = 3
クラス=3
o C-Type = 1, IPv4 LOCAL_LINK_ID
o C-タイプは1、IPv4のローカルの_リンク_IDと等しいです。
o C-Type = 2, IPv4 REMOTE_LINK_ID
o C-タイプは2、IPv4のリモート_リンク_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンク_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_LINK_ID
o C-タイプは3、IPv6のローカルの_リンク_IDと等しいです。
o C-Type = 4, IPv6 REMOTE_LINK_ID
o C-タイプは4、IPv6のリモート_リンク_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + リンク_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_LINK_ID
o C-タイプは5、無数のローカルの_リンク_IDと等しいです。
o C-Type = 6, Unnumbered REMOTE_LINK_ID
o C-タイプは6、無数のリモート_リンク_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンク_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 52] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[52ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Link_Id:
_イドをリンクしてください:
For LOCAL_LINK_ID, this identifies the sender's Link associated
with the message. This value MUST be non-zero.
LOCAL_LINK_IDのために、これは送付者のメッセージに関連しているLinkを特定します。 この値は非ゼロでなければなりません。
For REMOTE_LINK_ID, this identifies the remote node's Link_Id and
MUST be non-zero.
REMOTE_LINK_IDのために、これは、遠隔ノードのLink_Idを特定して、非ゼロに合わせなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.4. INTERFACE_ID Class
13.4. インタフェース_IDのクラス
Class = 4
クラス=4
o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
o C-タイプは1、IPv4のローカルの_インタフェース_IDと等しいです。
o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
o C-タイプは2、IPv4のリモート_インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_INTERFACE_ID
o C-タイプは3、IPv6のローカルの_インタフェース_IDと等しいです。
o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
o C-タイプは4、IPv6のリモート_インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + インタフェース_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
o C-タイプは5、無数のローカルの_インタフェース_IDと等しいです。
o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
o C-タイプは6、無数のリモート_インタフェース_IDと等しいです。
Lang Standards Track [Page 53] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[53ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id:
_イドを連結してください:
For the LOCAL_INTERFACE_ID, this identifies the data link. This
value MUST be node-wide unique and non-zero.
LOCAL_INTERFACE_IDのために、これはデータ・リンクを特定します。 この値はユニーク、そして、非ゼロに合わせてノード全体であるに違いありません。
For the REMOTE_INTERFACE_ID, this identifies the remote node's
data link. The Interface_Id MUST be non-zero.
REMOTE_INTERFACE_IDのために、これは遠隔ノードのデータ・リンクを特定します。 Interface_Idは非ゼロであるに違いありません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.5. MESSAGE_ID Class
13.5. メッセージ_IDのクラス
Class = 5
クラス=5
o C-Type=1, MessageId
o C-タイプは1、MessageIdと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ_イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
メッセージ_イド:
The Message_Id field is used to identify a message. This value is
incremented and only decreases when the value wraps. This is used
for message acknowledgment.
Message_Id分野は、メッセージを特定するのに使用されます。 値の機密であるときにだけ、この値は、増加されていて、減少します。 これはメッセージ承認に使用されます。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
o C-Type = 2, MessageIdAck
o C-タイプは2、MessageIdAckと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ_イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 54] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[54ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Message_Id:
メッセージ_イド:
The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object of
the message being acknowledged.
Message_Id分野は、承認されていて、メッセージを特定するのに使用されます。 承認されていて、この値はメッセージのMESSAGE_IDオブジェクトからコピーされます。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.6. CONFIG Class
13.6. コンフィグのクラス
Class = 6.
クラス=6。
o C-Type = 1, HelloConfig
o C-タイプは1、HelloConfigと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval| HelloDeadInterval| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
HelloInterval: 16ビット。
Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).
Helloパケットがどれくらい頻繁に送られるかを示して、ミリセカンド(ms)で測定されます。
HelloDeadInterval: 16 bits.
HelloDeadInterval: 16ビット。
If no Hello packets are received within the HelloDeadInterval, the
control channel is assumed to have failed. The HelloDeadInterval
is measured in milliseconds (ms). The HelloDeadInterval MUST be
greater than the HelloInterval, and SHOULD be at least 3 times the
value of HelloInterval.
HelloDeadIntervalの中にHelloパケットを全く受け取らないなら、失敗したと制御チャンネルを思います。 ミリセカンド(ms)でHelloDeadIntervalは測定されます。 HelloDeadIntervalはHelloIntervalの値のHelloInterval、およびSHOULDよりすばらしい少なくとも3倍でなければなりません。
If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero.
LMPの速い生きている生活費メカニズムが使用されていないなら、HelloIntervalとHelloDeadIntervalはゼロに用意ができなければなりません。
Lang Standards Track [Page 55] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[55ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
13.7. HELLO Class
13.7. こんにちは、クラス
Class = 7
クラス=7
o C-Type = 1, Hello
o =1をCでタイプしてください、こんにちは
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxSeqNum| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RcvSeqNum| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TxSeqNum: 32 bits
TxSeqNum: 32ビット
This is the current sequence number for this Hello message. This
sequence number will be incremented when the sequence number is
reflected in the RcvSeqNum of a Hello packet that is received over
the control channel.
これはこのHelloメッセージのための現在の一連番号です。 一連番号が制御チャンネルの上に受け取られるHelloパケットのRcvSeqNumに反映されるとき、この一連番号は増加されるでしょう。
TxSeqNum=0 is not allowed. TxSeqNum=1 is used to indicate that
this is the first Hello message sent over the control channel.
TxSeqNum=0は許容されていません。 TxSeqNum=1は、これが制御チャンネルの上に送られた最初のHelloメッセージであることを示すのに使用されます。
RcvSeqNum: 32 bits
RcvSeqNum: 32ビット
This is the sequence number of the last Hello message received
over the control channel. RcvSeqNum=0 is used to indicate that a
Hello message has not yet been received.
これは制御チャンネルの上に受け取られた最後のHelloメッセージの一連番号です。 RcvSeqNum=0は、Helloメッセージがまだ受け取られていないのを示すのに使用されます。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.8. BEGIN_VERIFY Class
13.8. 始まり、_クラスについて確かめてください。
Class = 8
クラス=8
o C-Type = 1
o C-タイプ=1
Lang Standards Track [Page 56] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[56ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| VerifyInterval| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ・リンクの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncType| (予約される)です。 | 移送機構について確かめてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TransmissionRate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 波長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Reserved野原は、ゼロとして送られて、領収書の上で無視されるべきです。
Flags: 16 bits
旗: 16ビット
The following flags are defined:
以下の旗は定義されます:
0x0001 Verify all Links
0×0001はすべてのリンクスについて確かめます。
If this bit is set, the verification process checks all
unallocated links; else it only verifies new ports or
component links that are to be added to this TE link.
このビットが設定されるなら、検証工程監査はすべて、リンクを「非-割り当て」ました。 ほかに、それはこのTEリンクに加えられることになっている新しいポートかコンポーネントリンクについて確かめるだけです。
0x0002 Data Link Type
0×0002 データ・リンクタイプ
If set, the data links to be verified are ports, otherwise
they are component links
設定されるなら、確かめられるべきデータ・リンクがポートである、さもなければ、それらはコンポーネントリンクです。
VerifyInterval: 16 bits
VerifyInterval: 16ビット
This is the interval between successive Test messages and is
measured in milliseconds (ms).
これは、連続したTestメッセージの間隔であり、ミリセカンド(ms)で測定されます。
Number of Data Links: 32 bits
データの数はリンクされます: 32ビット
This is the number of data links that will be verified.
これは確かめられるデータ・リンクの数です。
EncType: 8 bits
EncType: 8ビット
This is the encoding type of the data link. The defined EncType
values are consistent with the LSP Encoding Type values of
[RFC3471].
これはデータのタイプがリンクするコード化です。 定義されたEncType値は[RFC3471]のLSP Encoding Type値と一致しています。
Lang Standards Track [Page 57] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[57ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Verify Transport Mechanism: 16 bits
移送機構について確かめてください: 16ビット
This defines the transport mechanism for the Test Messages. The
scope of this bit mask is restricted to each encoding type. The
local node will set the bits corresponding to the various
mechanisms it can support for transmitting LMP test messages. The
receiver chooses the appropriate mechanism in the BeginVerifyAck
message.
これはTest Messagesのために移送機構を定義します。 この噛み付いているマスクの範囲は、タイプをコード化しながら、それぞれに制限されます。 ローカルのノードはそれがLMPテストメッセージを送るためにサポートできる様々なメカニズムに対応するビットを設定するでしょう。 受信機はBeginVerifyAckメッセージで適切な手段を選びます。
The following flag is defined across all Encoding Types. All
other flags are dependent on the Encoding Type.
以下の旗はすべてのEncoding Typesの向こう側に定義されます。 他のすべての旗がEncoding Typeに依存しています。
0x8000 Payload:Test Message transmitted in the payload
0×8000 有効搭載量: ペイロードで伝えられたテストMessage
Capable of transmitting Test messages in the payload.
The Test message is sent as an IP packet as defined
above.
ペイロードのTestメッセージを送ることができます。 上で定義されるIPパケットとしてTestメッセージを送ります。
TransmissionRate: 32 bits
TransmissionRate: 32ビット
This is the transmission rate of the data link over which the Test
messages will be transmitted. This is expressed in bytes per
second and represented in IEEE floating-point format.
これはTestメッセージが送られるデータ・リンクの通信速度です。 これは、1秒あたりのバイトで言い表されて、IEEEの浮動小数点の形式で表されます。
Wavelength: 32 bits
波長: 32ビット
When a data link is assigned to a port or component link that is
capable of transmitting multiple wavelengths (e.g., a fiber or
waveband-capable port), it is essential to know which wavelength
the test messages will be transmitted over. This value
corresponds to the wavelength at which the Test messages will be
transmitted over and has local significance. If there is no
ambiguity as to the wavelength over which the message will be
sent, then this value SHOULD be set to 0.
データ・リンクが複数の波長(例えば、ファイバーか周波数帯できるポート)を伝えることができるポートかコンポーネントリンクに割り当てられるとき、テストメッセージがどの波長で送られるかを知るのは不可欠です。この値は、Testメッセージに伝えられる波長に対応している、ローカルの意味を持っています。 あいまいさが全くなければ、これが次にメッセージが送られる波長にSHOULDを評価するように、0に設定されてください。
13.9. BEGIN_VERIFY_ACK Class
13.9. 始まり、__ACKのクラスについて確かめてください。
Class = 9
クラス=9
o C-Type = 1
o C-タイプ=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VerifyDeadInterval| _輸送_応答について確かめてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 58] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[58ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
VerifyDeadInterval: 16 bits
VerifyDeadInterval: 16ビット
If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure
message for that data link.
TestメッセージがVerifyDeadIntervalの中に検出されないと、ノードはそのデータ・リンクへのTestStatusFailureメッセージを送るでしょう。
Verify_Transport_Response: 16 bits
_輸送_応答について確かめてください: 16ビット
The recipient of the BeginVerify message (and the future
recipient of the TEST messages) chooses the transport mechanism
from the various types that are offered by the transmitter of
the Test messages. One and only one bit MUST be set in the
verification transport response.
BeginVerifyメッセージ(そして、TESTメッセージの将来の受取人)の受取人はTestメッセージの送信機によって提供される様々なタイプから移送機構を選びます。 検証輸送応答で唯一無二の1ビットを設定しなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.10. VERIFY_ID Class
13.10. _IDのクラスについて確かめてください。
Class = 10
クラス=10
o C-Type = 1
o C-タイプ=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _イドについて確かめてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verify_Id: 32 bits
_イドについて確かめてください: 32ビット
This is used to differentiate Test messages from different TE
links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message.
これは、異なったTEリンク、そして/または、LMP同輩とTestメッセージを区別するのに使用されます。 これはBeginVerifyメッセージの受取人によって割り当てられるノードユニークな値です。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.11. TE_LINK Class
13.11. Te_リンクのクラス
Class = 11
クラス=11
o C-Type = 1, IPv4 TE_LINK
o C-タイプは1、Te_がリンクするIPv4と等しいです。
Lang Standards Track [Page 59] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[59ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地方の_Link_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート_Link_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 TE_LINK
o C-タイプは2、Te_がリンクするIPv6と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 地方の_Link_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + リモート_Link_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered TE_LINK
o C-タイプは3、無数のTe_リンクと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地方の_Link_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート_Link_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Reserved野原は、ゼロとして送られて、領収書の上で無視されるべきです。
Lang Standards Track [Page 60] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[60ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Flags: 8 bits
旗: 8ビット
The following flags are defined. All other bit-values are
reserved and should be sent as zero and ignored on receipt.
以下の旗は定義されます。 他のすべてのビット値が、予約されていて、ゼロとして送られて、領収書の上で無視されるべきです。
0x01 Fault Management Supported.
障害管理がサポートした0×01。
0x02 Link Verification Supported.
0×02はサポートされた検証をリンクします。
Local_Link_Id:
ローカルの_リンク_イド:
This identifies the node's local Link_Id and MUST be non-zero.
これは、ノードの地方のLink_Idを特定して、非ゼロに合わせなければなりません。
Remote_Link_Id:
リモート_リンク_イド:
This identifies the remote node's Link_Id and MUST be non-zero.
これは、遠隔ノードのLink_Idを特定して、非ゼロに合わせなければなりません。
13.12. DATA_LINK Class
13.12. データ_リンクのクラス
Class = 12
クラス=12
o C-Type = 1, IPv4 DATA_LINK
o C-タイプは1、データ_がリンクするIPv4と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地方の_Interface_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート_Interface_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(Subobjects)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 61] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[61ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
o C-Type = 2, IPv6 DATA_LINK
o C-タイプは2、データ_がリンクするIPv6と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 地方の_Interface_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + リモート_Interface_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(Subobjects)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered DATA_LINK
o C-タイプは3、無数のデータ_リンクと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地方の_Interface_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート_Interface_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(Subobjects)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 62] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[62ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The Reserved field should be sent as zero and ignored on receipt.
Reserved野原は、ゼロとして送られて、領収書の上で無視されるべきです。
Flags: 8 bits
旗: 8ビット
The following flags are defined. All other bit-values are
reserved and should be sent as zero and ignored on receipt.
以下の旗は定義されます。 他のすべてのビット値が、予約されていて、ゼロとして送られて、領収書の上で無視されるべきです。
0x01 Interface Type: If set, the data link is a port, otherwise it
is a component link.
0×01 タイプを連結してください: 設定されるなら、データ・リンクがポートである、さもなければ、それはコンポーネントリンクです。
0x02 Allocated Link: If set, the data link is currently allocated
for user traffic. If a single Interface_Id
is used for both the transmit and receive
data links, then this bit only applies to the
transmit interface.
0×02はリンクを割り当てました: 設定するなら、現在、ユーザトラフィックのためにデータ・リンクを割り当てます。 独身のInterface_Idが両方に使用される、データ・リンクを送受信してください、このビットが適用するだけであるその時、インタフェースを伝えてください。
0x04 Failed Link: If set, the data link is failed and not
suitable for user traffic.
0×04の失敗したリンク: 設定されるなら、データ・リンクは、失敗されていてユーザトラフィックに適していません。
Local_Interface_Id:
ローカルの_インタフェース_イド:
This is the local identifier of the data link. This MUST be
node-wide unique and non-zero.
これはデータ・リンクのローカルの識別子です。 これはユニーク、そして、非ゼロに合わせてノード全体であるに違いありません。
Remote_Interface_Id:
リモート_インタフェース_イド:
This is the remote identifier of the data link. This MUST be
non-zero.
これはデータ・リンクのリモート識別子です。 これは非ゼロであるに違いありません。
Subobjects
Subobjects
The contents of the DATA_LINK object consist of a series of
variable-length data items called subobjects. The subobjects are
defined in Section 13.12.1 below.
DATA_LINKオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長のデータ項目から成ります。 「副-オブジェクト」はセクション13.12.1未満で定義されます。
A DATA_LINK object may contain more than one subobject. More than one subobject of the same Type may appear if multiple capabilities are supported over the data link.
DATA_LINKオブジェクトは1個以上の「副-オブジェクト」を含むかもしれません。 複数の能力がデータ・リンクの上でサポートされるなら、同じTypeの1個以上の「副-オブジェクト」が現れるかもしれません。
Lang Standards Track [Page 63] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[63ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
13.12.1. Data Link Subobjects
13.12.1. データ・リンクSubobjects
The contents of the DATA_LINK object include a series of variable- length data items called subobjects. Each subobject has the form:
DATA_LINKオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長さのデータ項目を含んでいます。 各「副-オブジェクト」には、フォームがあります:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ | タイプ| 長さ| (Subobjectコンテンツ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
Type: 8 bits
以下をタイプしてください。 8ビット
The Type indicates the type of contents of the subobject.
Currently defined values are:
Typeは「副-オブジェクト」のコンテンツのタイプを示します。 現在定義された値は以下の通りです。
Type = 1, Interface Switching Type
インタフェース切り換えタイプは=1をタイプしてください。
Type = 2, Wavelength
=2、波長をタイプしてください。
Length: 8 bits
長さ: 8ビット
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 Lengthは少なくとも4歳でなければならなく、4の倍数であるに違いありません。
13.12.1.1. Subobject Type 1: Interface Switching Type
13.12.1.1. Subobjectは1をタイプします: インタフェース切り換えタイプ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 切り換えタイプ| EncType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のReservable帯域幅| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のReservable帯域幅| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Type: 8 bits
切り換えタイプ: 8ビット
This is used to identify the local Interface Switching Type of the
TE link as defined in [RFC3471].
これは、[RFC3471]で定義されるようにTEリンクの地方のInterface Switching Typeを特定するのに使用されます。
EncType: 8 bits
EncType: 8ビット
This is the encoding type of the data link. The defined EncType
values are consistent with the LSP Encoding Type values of
[RFC3471].
これはデータのタイプがリンクするコード化です。 定義されたEncType値は[RFC3471]のLSP Encoding Type値と一致しています。
Lang Standards Track [Page 64] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[64ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Minimum Reservable Bandwidth: 32 bits
最小のReservable帯域幅: 32ビット
This is measured in bytes per second and represented in IEEE
floating point format.
これは、1秒あたりのバイトで測定されて、IEEE浮動小数点形式で表されます。
Maximum Reservable Bandwidth: 32 bits
最大のReservable帯域幅: 32ビット
This is measured in bytes per second and represented in IEEE
floating point format.
これは、1秒あたりのバイトで測定されて、IEEE浮動小数点形式で表されます。
If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value.
インタフェースが定率をサポートするだけであるなら、最小の、そして、最大の帯域幅分野は同じ値に設定されます。
13.12.1.2. Subobject Type 2: Wavelength
13.12.1.2. Subobjectは2をタイプします: 波長
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 波長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Reserved野原は、ゼロとして送られて、領収書の上で無視されるべきです。
Wavelength: 32 bits
波長: 32ビット
This value indicates the wavelength carried over the port. Values
used in this field only have significance between two neighbors.
この値は、波長がポートを引き継いだのを示します。 この分野で使用される値は2人の隣人の間に意味を持っているだけです。
13.13. CHANNEL_STATUS Class
13.13. チャンネル_状態のクラス
Class = 13
クラス=13
Lang Standards Track [Page 65] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[65ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
o C-Type = 1, IPv4 INTERFACE_ID
o C-タイプは1、IPv4インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 INTERFACE_ID
o C-タイプは2、IPv6インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + インタフェース_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + インタフェース_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 66] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[66ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
o C-Type = 3, Unnumbered INTERFACE_ID
o C-タイプは3、無数のインタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel_Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D| チャンネル_状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit
活性ビット: 1ビット
This indicates that the Channel is allocated to user traffic and
the data link should be actively monitored.
これはユーザトラフィックに英仏海峡を割り当てて、活発にデータ・リンクをモニターするべきであるのを示します。
Direction bit: 1 bit
方向ビット: 1ビット
This indicates the direction (transmit/receive) of the data
channel referred to in the CHANNEL_STATUS object. If set, this
indicates the data channel is in the transmit direction.
これはCHANNEL_STATUSオブジェクトで言及されたデータ・チャンネルの方向(伝えるか、または受ける)を示します。 設定されるなら、これが、データ・チャンネルがいるのを示す、方向を伝えてください。
Channel_Status: 30 bits
チャンネル_状態: 30ビット
This indicates the status condition of a data channel. The
following values are defined. All other values are reserved.
これはデータ・チャンネルの状態状態を示します。 以下の値は定義されます。 他のすべての値が予約されています。
1 Signal Okay (OK): Channel is operational
2 Signal Degrade (SD): A soft failure caused by a BER exceeding
a preselected threshold. The specific
BER used to define the threshold is
configured.
3 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of
frame (LOF), or Line AIS.
1 承認(OK)に合図してください: チャンネルは操作上の2Signal Degrade(サウスダコタ)です: 前選択された敷居を超えているBERによって引き起こされた柔らかい失敗。 敷居を定義するのに使用される特定のBERは構成されます。 3信号は(SF)に失敗します: (他)信号の損失(LOS)、フレーム(LOF)の損失、または線AISを含む困難な信号の故障。
This object contains one or more Interface_Ids followed by a Channel_Status field.
このオブジェクトは1Interface_Idsを含んでいます、続いて、Channel_Status分野を含みます。
To indicate the status of the entire TE Link, there MUST be only one Interface_Id, and it MUST be zero.
全体のTE Linkの状態を示すために、1Interface_Idしかないに違いありません、そして、それはゼロであるに違いありません。
Lang Standards Track [Page 67] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[67ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.14. CHANNEL_STATUS_REQUEST Class
13.14. チャンネル_状態_はクラスを要求します。
Class = 14
クラス=14
o C-Type = 1, IPv4 INTERFACE_ID
o C-タイプは1、IPv4インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
このオブジェクトは1Interface_Idsを含んでいます。
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
このオブジェクトのLengthはバイトで表現される4+4Nです。(そこでは、NがInterface_Idsの数です)。
Lang Standards Track [Page 68] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[68ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
o C-Type = 2, IPv6 INTERFACE_ID
o C-タイプは2、IPv6インタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + インタフェース_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + インタフェース_Id(16バイト)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
このオブジェクトは1Interface_Idsを含んでいます。
The Length of this object is 4 + 16N in bytes, where N is the number of Interface_Ids.
このオブジェクトのLengthはバイトで表現される4+16Nです。(そこでは、NがInterface_Idsの数です)。
o C-Type = 3, Unnumbered INTERFACE_ID
o C-タイプは3、無数のインタフェース_IDと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース_Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 69] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[69ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
This object contains one or more Interface_Ids.
このオブジェクトは1Interface_Idsを含んでいます。
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
このオブジェクトのLengthはバイトで表現される4+4Nです。(そこでは、NがInterface_Idsの数です)。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
13.15. ERROR_CODE Class
13.15. 誤り_コードのクラス
Class = 20
クラス=20
o C-Type = 1, BEGIN_VERIFY_ERROR
o =1をCでタイプしてくださいといって、_を始めてください、_誤りについて確かめてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order (i.e.,
big-endian byte order):
以下のビット値はネットワークバイトオーダー(すなわち、ビッグエンディアンバイトオーダー)で定義されます:
0x01 = Link Verification Procedure not supported.
0x02 = Unwilling to verify.
0x04 = Unsupported verification transport mechanism.
0x08 = Link_Id configuration error.
0x10 = Unknown object C-Type.
0×01はVerification Procedureが支えなかったリンクと等しいです。 0×02 確かめたがっていない=。 0×04はサポートされない検証移送機構と等しいです。 0×08はリンク_Id構成誤りと等しいです。 0×10は未知のオブジェクトC-タイプと等しいです。
All other bit-values are reserved and should be sent as zero and
ignored on receipt.
他のすべてのビット値が、予約されていて、ゼロとして送られて、領収書の上で無視されるべきです。
Multiple bits may be set to indicate multiple errors.
複数のビットが複数の誤りを示すように設定されるかもしれません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
If a BeginVerifyNack message is received with Error Code 2, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter.
BeginVerifyNackメッセージが受信されているなら、Error Code2、起因したノードでBeginVerify SHOULDはRf秒以降BeginVerify retransmissionの計画をします、Rfが局所的に定義されたパラメタであるところで。
o C-Type = 2, LINK_SUMMARY_ERROR
o C-タイプは2、リンク_概要_誤りと等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang Standards Track [Page 70] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[70ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The following bit-values are defined in network byte order (i.e.,
big-endian byte order):
以下のビット値はネットワークバイトオーダー(すなわち、ビッグエンディアンバイトオーダー)で定義されます:
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters.
0x02 = Renegotiate LINK_SUMMARY parameters.
0x04 = Invalid TE_LINK Object.
0x08 = Invalid DATA_LINK Object.
0x10 = Unknown TE_LINK object C-Type.
0x20 = Unknown DATA_LINK object C-Type.
0×01は容認できない譲渡禁止のLINK_SUMMARYパラメタと等しいです。 0×02 = LINK_SUMMARYパラメタを再交渉してください。 0×04は無効のTe_リンクオブジェクトと等しいです。 0×08は無効のデータ_リンクオブジェクトと等しいです。 0×10は未知のTE_LINKオブジェクトC-タイプと等しいです。 0×20は未知のDATA_LINKオブジェクトC-タイプと等しいです。
All other bit-values are reserved and should be sent as zero and
ignored on receipt.
他のすべてのビット値が、予約されていて、ゼロとして送られて、領収書の上で無視されるべきです。
Multiple bits may be set to indicate multiple errors.
複数のビットが複数の誤りを示すように設定されるかもしれません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
14. References
14. 参照
14.1. Normative References
14.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月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4201]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] エドKompella、K.、エドY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持して拡大を発送すること」でのRFC4202(2005年10月)。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC2961] バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Lang Standards Track [Page 71] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[71ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
[RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling
Functional Description", RFC 3471, January 2003.
[RFC3471] バーガー、L.、エド、「機能的な記述に合図して、MPLSを一般化した」、RFC3471、1月2003日
14.2. Informative References
14.2. 有益な参照
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3630] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計するトラフィック、RFC3630、2003年9月。」
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3784] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[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月)。
[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月。
Lang Standards Track [Page 72] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[72ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
15. Security Considerations
15. セキュリティ問題
There are number of attacks that an LMP protocol session can potentially experience. Some examples include:
LMPプロトコルセッションが潜在的になることができる攻撃の数があります。 いくつかの例は:
o an adversary may spoof control packets;
o 敵は、コントロールがパケットであると偽造するかもしれません。
o an adversary may modify the control packets in transit;
o 敵はトランジットでコントロールパケットを変更するかもしれません。
o an adversary may replay control packets;
o 敵はコントロールパケットを再演するかもしれません。
o an adversary may study a number of control packets and try to
break the key using cryptographic tools. If the
hash/encryption algorithm used has known weaknesses, then it
becomes easy for the adversary to discover the key using simple
tools.
o 敵は、多くのコントロールパケットを研究して、暗号のツールを使用することでキーを壊そうとするかもしれません。 使用されるハッシュ/暗号化アルゴリズムが弱点を知っていたなら、敵がキーを発見するのは、簡単なツールを使用することで簡単になります。
This section specifies an IPsec-based security mechanism for LMP.
このセクションはIPsecベースのセキュリティー対策をLMPに指定します。
15.1. Security Requirements
15.1. セキュリティ要件
The following requirements are applied to the mechanism described in this section.
以下の要件はこのセクションで説明されたメカニズムに適用されます。
o LMP security MUST be able to provide authentication, integrity,
and replay protection.
o LMPセキュリティは認証、保全、および反復操作による保護を提供できなければなりません。
o For LMP traffic, confidentiality is not needed. Only
authentication is needed to ensure that the control packets
(packets sent along the LMP Control Channel) are originating
from the right place and have not been modified in transit.
LMP Test packets exchanged through the data links do not need
to be protected.
o LMPトラフィックにおいて、秘密性は必要ではありません。 認証だけが、コントロールパケット(パケットはLMP Control Channelを送った)が適当な場所から発していて、トランジットで変更されていないのを保証するのに必要です。 データ・リンクを通して交換されたLMP Testパケットは保護される必要はありません。
o For LMP traffic, protecting the identity of LMP end-points is
not commonly required.
o LMPトラフィックにおいて、LMPエンドポイントのアイデンティティを保護するのは一般的に必要ではありません。
o The security mechanism should provide for well defined key
management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management
schemes should be scalable. In addition, the key management
system should be automatic.
o セキュリティー対策はよく定義されたかぎ管理体系に備えるはずです。 暗号でであるなるように分析された井戸が安全であるなら、かぎ管理体系はそうするでしょうに。 かぎ管理体系はスケーラブルであるべきです。 さらに、かぎ管理システムは自動であるべきです。
o The algorithms used for authentication MUST be
cryptographically sound. Also, the security protocol MUST
allow for negotiating and using different authentication
algorithms.
o 認証に使用されるアルゴリズムは暗号で鳴ることであるに違いありません。 また、セキュリティプロトコルは、異なった認証アルゴリズムを交渉して、使用すると考慮しなければなりません。
Lang Standards Track [Page 73] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[73ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
15.2. Security Mechanisms
15.2. セキュリティー対策
IPsec is a protocol suite that is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management protocol for IP networks, while AH and ESP are used to protect IP traffic. IKE is defined specific to IP domain of interpretation.
IPsecは2人の同輩の間のネットワーク層でコミュニケーションを保証するのに使用されるプロトコル群です。 IPsec AH[RFC2402]、このプロトコルはIKE[RFC2409]、IPから成って、Securityアーキテクチャが[RFC2401]を記録するということであり、IPsecは超能力[RFC2406]です。 IKEはIPネットワークのためのかぎ管理プロトコルですが、AHと超能力は、IPトラフィックを保護するのに使用されます。 IKEは解釈のIPドメインに特定の状態で定義されます。
Considering the requirements described in Section 15.1, it is recommended that, where security is needed for LMP, implementations use IPsec as described below:
要件がセクション15.1で説明した考慮、セキュリティがLMPに必要であるところで実装が以下で説明されるようにIPsecを使用するのは、お勧めです:
1. Implementations of LMP over IPsec protocol SHOULD support manual
keying mode.
1. IPsecプロトコルSHOULDの上のLMPの実装はモードを合わせるマニュアルを支えます。
Manual keying mode provides an easy way to set up and diagnose
IPsec functionality.
モードを合わせるマニュアルがIPsecの機能性をセットアップして、診断する簡単な方法を提供します。
However, note that manual keying mode cannot effectively support
features such as replay protection and automatic re-keying. An
implementer using manual keys must be aware of these limits.
しかしながら、事実上、モードを合わせるマニュアルが反復操作による保護や自動再の合わせることなどの特徴をサポートすることができないことに注意してください。 手動のキーを使用するimplementerはこれらの限界を知っているに違いありません。
It is recommended that an implementer use manual keying only for
diagnostic purposes and use dynamic keying protocol to make use of
features such as replay protection and automatic re-keying.
implementerが反復操作による保護や自動再の合わせることなどの特徴を利用するのに診断目的で手動の合わせることだけを使用して、プロトコルを合わせる動力を使用するのは、お勧めです。
2. IPsec ESP with trailer authentication in tunnel mode MUST be
supported.
2. トンネルモードにおけるトレーラ認証がある超能力をサポートしなければならないIPsec。
3. Implementations MUST support authenticated key exchange protocols.
IKE [RFC2409] MUST be used as the key exchange protocol if keys
are dynamically negotiated between peers.
3. 実装は、認証された主要な交換がプロトコルであるとサポートしなければなりません。 キーが同輩の間でダイナミックに交渉されるなら、主要な交換プロトコルとしてイケ[RFC2409]を使用しなければなりません。
4. Implementation MUST use the IPsec DOI [RFC2407].
4. 実装はIPsec DOI[RFC2407]を使用しなければなりません。
5. For IKE protocol, the identities of the SAs negotiated in Quick
Mode represent the traffic that the peers agree to protect and are
comprised of address space, protocol, and port information.
5. IKEプロトコルのために、クィックModeで交渉されたSAsのアイデンティティは、同輩が保護するのに同意するトラフィックを表して、アドレス空間から成って、議定書を作って、情報を移植します。
For LMP over IPsec, it is recommended that the identity payload
for Quick mode contain the following information:
IPsecの上のLMPに関しては、クィックモードのためのアイデンティティペイロードが以下の情報を含むのは、お勧めです:
The identities MUST be of type IP addresses and the value of the
identities SHOULD be the IP addresses of the communicating peers.
アイデンティティには、IPが演説するタイプとアイデンティティSHOULDの価値が交信のIPアドレスが同輩であったならあるに違いありません。
Lang Standards Track [Page 74] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[74ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The protocol field MUST be UDP. The port field SHOULD be set to
zero to indicate port fields should be ignored. This implies all
UDP traffic between the peers must be sent through the IPsec
tunnel. If an implementation supports port-based selectors, it
can opt for a more finely grained selector by specifying the port
field to the LMP port. If, however, the peer does not use port-
based selectors, the implementation MUST fall back to using a port
selector value of 0.
プロトコル分野はUDPであるに違いありません。 ポートはSHOULDをさばきます。ポート分野が無視されるべきであるのを示すのをゼロに合わせるように用意ができています。 これは、IPsecトンネルを通して同輩の間のすべてのUDPトラフィックを送らなければならないのを含意します。 実装がポートベースのセレクタを支えるなら、それは、LMPポートにポート分野を指定することによって、きめ細かくより粒状のセレクタを選ぶことができます。 しかしながら、同輩がポートのベースのセレクタを使用しないなら、実装は0のポートセレクタ値を使用することへ後ろへ下がらなければなりません。
6. Aggressive mode of IKE negotiation MUST be supported.
6. IKE交渉の攻撃的な方法をサポートしなければなりません。
When IPsec is configured to be used with a peer, all LMP messages
are expected to be sent over the IPsec tunnel (crypto channel).
Similarly, an LMP receiver configured to use Ipsec with a peer
should reject any LMP traffic that does not come through the
crypto channel.
IPsecが同輩と共に使用されるために構成されるとき、すべてのLMPメッセージによってIPsecトンネル(暗号チャンネル)の上に送られると予想されます。 同様に、同輩がいるIpsecを使用するために構成されたLMP受信機は暗号チャンネルを通り抜けないどんなLMPトラフィックも拒絶するはずです。
The crypto channel can be pre-setup with the LMP neighbor, or the
first LMP message sent to the peer can trigger the creation of the
IPsec tunnel.
暗号チャンネルはLMP隣人とのプレセットアップであるかもしれませんか同輩に送られた最初のLMPメッセージがIPsecトンネルの作成の引き金となることができます。
A set of control channels can share the same crypto channel. When
LMP Hellos are used to monitor the status of the control channel,
it is important to keep in mind that the keep-alive failure in a
control channel may also be due to a failure in the crypto
channel. The following method is recommended to ensure that an
LMP communication path between two peers is working properly.
1セットの制御チャンネルは同じ暗号チャンネルを共有できます。 LMPハローズが制御チャンネルの状態をモニターするのに使用されるとき、また、制御チャンネルによる生きている生活費失敗が暗号チャンネルによる失敗のためであるかもしれないことを覚えておくのは重要です。 以下のメソッドが、2人の同輩の間のLMP通信路が適切に働いているのを保証することが勧められます。
o If LMP Hellos detect a failure on a control channel, switch to
an alternate control channel and/or try to establish a new
control channel.
o LMPハローズであるなら、制御チャンネルの上に失敗を検出してください、そして、代替の制御チャンネルに切り替わってください、そして、新しい制御チャンネルを確立するようにしてください。
o Ensure the health of the control channels using LMP Hellos. If
all control channels indicate a failure and it is not possible
to bring up a new control channel, tear down all existing
control channels. Also, tear down the crypto channel (both the
IKE SA and IPsec SAs).
o LMPハローズを使用して、制御チャンネルの健康を確実にしてください。 すべての制御チャンネルが失敗を示して、新しい制御チャンネルを育てるのが可能でないなら、すべての既存の制御チャンネルを取りこわしてください。 また、暗号チャンネル(IKE SAとIPsec SAsの両方)を取りこわしてください。
o Reestablish the crypto channel. Failure to establish a crypto
channel indicates a fatal failure for LMP communication.
o 暗号チャンネルを回復させてください。 暗号チャンネルを確立しない場合、LMPコミュニケーションのために致命的な失敗を示します。
o Bring up the control channel. Failure to bring up the control
channel indicates a fatal failure for LMP communication.
o 制御チャンネルを育ててください。 制御チャンネルを育てない場合、LMPコミュニケーションのために致命的な失敗を示します。
Lang Standards Track [Page 75] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[75ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
When LMP peers are dynamically discovered (particularly the
initiator), the following points should be noted:
LMP同輩がダイナミックに発見されるとき(特に創始者)、以下のポイントは注意されるべきです:
When using pre-shared key authentication in identity protection
mode (main mode), the pre-shared key is required to compute the
value of SKEYID (used for deriving keys to encrypt messages
during key exchange). In main mode of IKE, the pre-shared key
to be used has to be identified before receiving the peer's
identity payload. The pre-shared key is required for
calculating SKEYID. The only information available about the
peer at this point is its IP address from which the negotiation
came from. Keying off the IP address of a peer to get the
pre-shared key is not possible since the addresses are dynamic
and not known beforehand.
アイデンティティ保護モード(主なモード)であらかじめ共有された主要な認証を使用するとき、あらかじめ共有されたキーが、SKEYID(主要な交換の間、メッセージを暗号化するためにキーを引き出すために、使用される)の値を計算するのに必要です。 IKEの主なモードで、同輩のアイデンティティペイロードを受ける前に、使用されるべきあらかじめ共有されたキーは特定されなければなりません。 あらかじめ共有されたキーが計算のSKEYIDに必要です。 ここに同輩に関して利用可能な唯一の情報がIPアドレスです。交渉がどれから来たかから。 アドレスがダイナミックであらかじめ知られないので、あらかじめ共有されたキーを手に入れる同輩のIPアドレスの合わせるのは可能ではありません。
Aggressive mode key exchange can be used since identification
payloads are sent in the first message.
最初のメッセージで識別ペイロードを送るので、攻撃的なモード主要な交換を使用できます。
Note, however, that aggressive mode is prone to passive denial
of service attacks. Using a shared secret (group shared
secret) among a number of peers is strongly discouraged because
this opens up the solution to man-in-the-middle attacks.
しかしながら、攻撃的なモードは受け身のサービス不能攻撃に傾向があることに注意してください。 これが介入者攻撃にソリューションを開けるので、多くの同輩の中で共有秘密キー(共有秘密キーを分類する)を使用するのは強くお勧めできないです。
Digital-signature-based authentication is not prone to such
problems. It is RECOMMENDED that a digital-signature-based
authentication mechanism be used where possible.
デジタル署名ベースの認証はそのような問題の傾向がありません。デジタル署名ベースの認証機構が可能であるところで使用されるのは、RECOMMENDEDです。
If pre-shared-key-based authentication is required, then
aggressive mode SHOULD be used. IKE pre-shared authentication
key values SHOULD be protected in a manner similar to the
user's account password.
あらかじめ共有されたキーベースの認証が必要で、次に、攻撃的なモードSHOULDであるなら、使用されてください。 IKEは保護されたコネがユーザのアカウントパスワードと同様の方法であったなら認証キー値SHOULDをあらかじめ共有しました。
16. IANA Considerations
16. IANA問題
The IANA has assigned port number 701 to LMP.
IANAはポートNo.701をLMPに割り当てました。
In the following, guidelines are given for IANA assignment for each LMP name space. Ranges are specified for Private Use, to be assigned by Expert Review, and to be assigned by Standards Action (as defined in [RFC2434].
以下では、それぞれのLMP名前スペースのためのIANA課題のためにガイドラインを与えます。 Expert Reviewによって割り当てられて、Standards Actionによって割り当てられるように、範囲は兵士のUseに指定されます。([RFC2434]で定義されるように。
Assignments made from LMP number spaces set aside for Private Use (i.e., for proprietary extensions) need not be documented. Independent LMP implementations using the same Private Use code points will in general not interoperate, so care should be exercised in using these code points in a multi-vendor network.
兵士のUse(すなわち、独占拡大のための)のためにかたわらに置かれたLMP数の空間からされた課題は記録される必要はありません。 同じ兵士のUseコード・ポイントを使用する独立しているLMP実装が一般に共同利用しないので、注意はマルチベンダネットワークにこれらのコード・ポイントを使用するのに訓練されるべきです。
Lang Standards Track [Page 76] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[76ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Assignments made from LMP number spaces to be assigned by Expert Review are to be reviewed by an Expert designated by the IESG. The intent in this document is that code points from these ranges are used for Experimental extensions; as such, assignments MUST be accompanied by Experimental RFCs. If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges MUST be assigned.
LMP数の空間からExpert Reviewによって割り当てられるのがされた課題はIESGによって指定されたExpertによって見直されることです。 意図は本書ではこれらの範囲からのコード・ポイントがExperimental拡張子に使用されるということです。 そういうものとして、Experimental RFCsは課題に伴わなければなりません。 展開が、これらの拡大が役に立つと示唆するなら、それらはStandards Track RFCsで説明されるべきです、そして、Standards Action範囲からの新法ポイントを割り当てなければなりません。
Assignments from LMP number spaces to be assigned by Standards Action MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards.
Standards Track RFCはStandards Actionによって割り当てられるLMP数の空間からの課題を記録しなければなりません、IETF作業部会に通常提出しますが、どのような場合でも、Proposed Standardsのために普通のIETF手順に従って。
The Reserved bits of the LMP Common Header should be allocated by Standards Action, pursuant to the policies outlined in [RFC2434].
LMP Common HeaderのReservedビットはStandards Actionによって割り当てられるはずです、[RFC2434]に概説された方針によると。
LMP defines the following name spaces that require management:
LMPは管理を必要とする以下の名前空間を定義します:
- LMP Message Type.
- LMP Object Class.
- LMP Object Class type (C-Type). These are unique within the
Object Class.
- LMP Sub-object Class type (Type). These are unique within the
Object Class.
- LMPメッセージタイプ。 - LMPオブジェクトのクラス。 - LMP Object Classは(C-タイプ)をタイプします。 これらはObject Classの中でユニークです。 - LMP Sub-オブジェクトClassはタイプします(タイプしてください)。 これらはObject Classの中でユニークです。
The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use.
以下の通りスペースというLMP Message Type名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-127の数を割り当てます、そして、Expert Reviewを通して128-240を割り当てます、そして、兵士のUseのために241-255を予約します。
The LMP Object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use.
以下の通りスペースというLMP Object Class名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは0-127の範囲の数を割り当てます、そして、Expert Reviewを通して128-247を割り当てます、そして、兵士のUseのために248-255を予約します。
The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated.
スペースというLMP Object Class名から値を割り当てるための方針は特定のClassインスタンスの定義の一部です。 また、Classが定義されるとき、定義はObject Class名が割り当てられる方針の記述を含まなければなりません。
The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated.
スペースというLMP Sub-オブジェクトClass名から値を割り当てるための方針は特定のClassインスタンスの定義の一部です。 また、Classが定義されるとき、定義はサブオブジェクトが割り当てられる方針の記述を含まなければなりません。
Lang Standards Track [Page 77] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[77ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The following name spaces have been assigned by IANA:
以下の名前空間はIANAによって割り当てられました:
------------------------------------------------------------------ LMP Message Type name space
------------------------------------------------------------------ LMP Message Type名前スペース
o Config message (Message type = 1)
o コンフィグメッセージ(メッセージタイプ=1)
o ConfigAck message (Message type = 2)
o ConfigAckメッセージ(メッセージタイプ=2)
o ConfigNack message (Message type = 3)
o ConfigNackメッセージ(メッセージタイプ=3)
o Hello message (Message type = 4)
o こんにちは、メッセージ(メッセージタイプ=4)
o BeginVerify message (Message type = 5)
o BeginVerifyメッセージ(メッセージタイプ=5)
o BeginVerifyAck message (Message type = 6)
o BeginVerifyAckメッセージ(メッセージタイプ=6)
o BeginVerifyNack message (Message type = 7)
o BeginVerifyNackメッセージ(メッセージタイプ=7)
o EndVerify message (Message type = 8)
o EndVerifyメッセージ(メッセージタイプ=8)
o EndVerifyAck message (Message type = 9)
o EndVerifyAckメッセージ(メッセージタイプ=9)
o Test message (Message type = 10)
o テストメッセージ(メッセージタイプ=10)
o TestStatusSuccess message (Message type = 11)
o TestStatusSuccessメッセージ(メッセージタイプ=11)
o TestStatusFailure message (Message type = 12)
o TestStatusFailureメッセージ(メッセージタイプ=12)
o TestStatusAck message (Message type = 13)
o TestStatusAckメッセージ(メッセージタイプ=13)
o LinkSummary message (Message type = 14)
o LinkSummaryメッセージ(メッセージタイプ=14)
o LinkSummaryAck message (Message type = 15)
o LinkSummaryAckメッセージ(メッセージタイプ=15)
o LinkSummaryNack message (Message type = 16)
o LinkSummaryNackメッセージ(メッセージタイプ=16)
o ChannelStatus message (Message type = 17)
o ChannelStatusメッセージ(メッセージタイプ=17)
o ChannelStatusAck message (Message type = 18)
o ChannelStatusAckメッセージ(メッセージタイプ=18)
o ChannelStatusRequest message (Message type = 19)
o ChannelStatusRequestメッセージ(メッセージタイプ=19)
o ChannelStatusResponse message (Message type = 20)
o ChannelStatusResponseメッセージ(メッセージタイプ=20)
------------------------------------------------------------------
------------------------------------------------------------------
Lang Standards Track [Page 78] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[78ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
LMP Object Class name space and Class type (C-Type)
LMP Object Class名前スペースとClassはタイプします。(C-タイプ)
o CCID Class name (1)
o CCID Class名(1)
The CCID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというCCID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- LOCAL_CCID (C-Type = 1)
- REMOTE_CCID (C-Type = 2)
- 地方の_CCID(C-タイプ=1)--リモート_CCID(C-タイプ=2)
o NODE_ID Class name (2)
o NODE_ID Class名(2)
The NODE ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというNODE ID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- LOCAL_NODE_ID (C-Type = 1)
- REMOTE_NODE_ID (C-Type = 2)
- ローカルの_ノード_ID(C-タイプ=1)--リモート_ノード_ID(C-タイプ=2)
o LINK_ID Class name (3)
o LINK_ID Class名(3)
The LINK_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというLINK_ID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- IPv4 LOCAL_LINK_ID (C-Type = 1)
- IPv4 REMOTE_LINK_ID (C-Type = 2)
- IPv6 LOCAL_LINK_ID (C-Type = 3)
- IPv6 REMOTE_LINK_ID (C-Type = 4)
- Unnumbered LOCAL_LINK_ID (C-Type = 5)
- Unnumbered REMOTE_LINK_ID (C-Type = 6)
- 地方..リンク..ID..タイプ..リモート..リンク..ID..タイプ..地方..リンク..ID..タイプ..リモート..リンク..ID..タイプ..無数..地方..リンク..ID..タイプ..無数..リモート..リンク..ID(C-タイプ=6)
o INTERFACE_ID Class name (4)
o INTERFACE_ID Class名(4)
The INTERFACE_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというINTERFACE_ID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
Lang Standards Track [Page 79] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[79ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
- IPv4 LOCAL_INTERFACE_ID (C-Type = 1)
- IPv4 REMOTE_INTERFACE_ID (C-Type = 2)
- IPv6 LOCAL_INTERFACE_ID (C-Type = 3)
- IPv6 REMOTE_INTERFACE_ID (C-Type = 4)
- Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)
- Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
- IPv4のローカルの_インタフェース_ID(C-タイプ=1)--IPv4のリモート_インタフェース_ID(C-タイプ=2)--IPv6のローカルの_インタフェース_ID(C-タイプ=3)--IPv6のリモート_インタフェース_ID(C-タイプ=4)--無数のローカルの_インタフェース_ID(C-タイプ=5)--無数のリモート_インタフェース_ID(C-タイプ=6)
o MESSAGE_ID Class name (5)
o MESSAGE_ID Class名(5)
The MESSAGE_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというMESSAGE_ID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- MESSAGE_ID (C-Type = 1)
- MESSAGE_ID_ACK (C-Type = 2)
- メッセージ_ID(C-タイプ=1)--_メッセージ_ID ACK(C-タイプ=2)
o CONFIG Class name (6)
o CONFIG Class名(6)
The CONFIG Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというCONFIG Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- HELLO_CONFIG (C-Type = 1)
- こんにちは、_コンフィグ(C-タイプ=1)
o HELLO Class name (7)
o HELLO Class名(7)
The HELLO Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというHELLO Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- HELLO (C-Type = 1)
- こんにちは(C-タイプ=1)
o BEGIN_VERIFY Class name (8)
o BEGIN_VERIFY Class名(8)
The BEGIN_VERIFY Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというBEGIN_VERIFY Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- Type 1 (C-Type = 1)
- 1をタイプしてください。(C-タイプ=1)
Lang Standards Track [Page 80] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[80ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
o BEGIN_VERIFY_ACK Class name (9)
o BEGIN_VERIFY_ACK Class名(9)
The BEGIN_VERIFY_ACK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというBEGIN_VERIFY_ACK Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- Type 1 (C-Type = 1)
- 1をタイプしてください。(C-タイプ=1)
o VERIFY_ID Class name (10)
o VERIFY_ID Class名(10)
The VERIFY_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというVERIFY_ID Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- Type 1 (C-Type = 1)
- 1をタイプしてください。(C-タイプ=1)
o TE_LINK Class name (11)
o TE_LINK Class名(11)
The TE_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというTE_LINK Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- IPv4 TE_LINK (C-Type = 1)
- IPv6 TE_LINK (C-Type = 2)
- Unnumbered TE_LINK (C-Type = 3)
- IPv4Te_は(C-タイプ=1)をリンクします--IPv6Te_は(C-タイプ=2)をリンクします--無数のTe_はリンクします。(C-タイプ=3)
o DATA_LINK Class name (12)
o DATA_LINK Class名(12)
The DATA_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use.
以下の通りスペースというDATA_LINK Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、個人的なUseのために120-127を予約します。
- IPv4 DATA_LINK (C-Type = 1)
- IPv6 DATA_LINK (C-Type = 2)
- Unnumbered DATA_LINK (C-Type = 3)
- IPv4データ_は(C-タイプ=1)をリンクします--IPv6データ_は(C-タイプ=2)をリンクします--無数のデータ_はリンクされます。(C-タイプ=3)
Lang Standards Track [Page 81] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[81ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
The DATA_LINK Sub-object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for private Use.
以下の通りClassがスペースと命名するDATA_LINK Sub-物を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは0-127の範囲の数を割り当てます、そして、Expert Reviewを通して128-247を割り当てます、そして、個人的なUseのために248-255を予約します。
- Interface Switching Type (sub-object Type = 1)
- Wavelength (sub-object Type = 2)
- インタフェース切り換えタイプ(サブオブジェクト・タイプ=1)--波長(サブオブジェクト・タイプ=2)
o CHANNEL_STATUS Class name (13)
o CHANNEL_STATUS Class名(13)
The CHANNEL_STATUS Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというCHANNEL_STATUS Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- IPv4 INTERFACE_ID (C-Type = 1)
- IPv6 INTERFACE_ID (C-Type = 2)
- Unnumbered INTERFACE_ID (C-Type = 3)
- IPv4インタフェース_ID(C-タイプ=1)--IPv6インタフェース_ID(C-タイプ=2)--無数のインタフェース_ID(C-タイプ=3)
o CHANNEL_STATUS_REQUESTClass name (14)
o CHANNEL_STATUS_REQUESTClass名(14)
The CHANNEL_STATUS_REQUEST Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
以下の通りスペースというCHANNEL_STATUS_REQUEST Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、兵士のUseのために120-127を予約します。
- IPv4 INTERFACE_ID (C-Type = 1)
- IPv6 INTERFACE_ID (C-Type = 2)
- Unnumbered INTERFACE_ID (C-Type = 3)
- IPv4インタフェース_ID(C-タイプ=1)--IPv6インタフェース_ID(C-タイプ=2)--無数のインタフェース_ID(C-タイプ=3)
o ERROR_CODE Class name (20)
o ERROR_CODE Class名(20)
The ERROR_CODE Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use.
以下の通りスペースというERROR_CODE Object Class型名を割り当てるべきです: [RFC2434]に概説された方針によると、Standards Actionは範囲0-111の数を割り当てます、そして、Expert Reviewを通して112-119を割り当てます、そして、個人的なUseのために120-127を予約します。
- BEGIN_VERIFY_ERROR (C-Type = 1)
- LINK_SUMMARY_ERROR (C-Type = 2)
- 始まり、__誤り(C-タイプ=1)について確かめてください--_概要_誤りをリンクしてください。(C-タイプ=2)
Lang Standards Track [Page 82] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[82ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
17. Acknowledgements
17. 承認
The authors would like to thank Andre Fredette for his many contributions to this document. We would also like to thank Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability.
作者はこのドキュメントへの彼の多くの貢献についてアンドレFredetteに感謝したがっています。 また、彼らの洞察に満ちたコメントと提案についてアヤンバネルジー、ジョージSwallow、エードリアン・ファレル、ディミトリPapadimitriou、ビナイRavuri、およびデヴィッド・ドライズデールに感謝申し上げます。 また、バンドにおけるコントロールチャンネルの適用性のための彼らの役立つ提案のためのジョン・ユー、Suresh Katukam、およびグレッグ・バーンスタインに感謝申し上げます。
18. Contributors
18. 貢献者
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
サンタバーバラ、ジョナサンP.ラングSonos Inc.223E.De Laグェルラ通りカリフォルニア 93101
EMail: jplang@ieee.org
メール: jplang@ieee.org
Krishna Mitra Independent Consultant
クリシュナ・ミトラから独立しているコンサルタント
EMail: kmitra@earthlink.net
メール: kmitra@earthlink.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョンドレイクCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
EMail: jdrake@calient.net
メール: jdrake@calient.net
Kireeti Kompella Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Kireeti Kompella杜松はInc.1194の北のマチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
ヤコフRekhter JuniperはInc.1194の北のマチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Lang Standards Track [Page 83] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[83ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Lou Berger Movaz Networks
ルウバーガーMovazネットワーク
EMail: lberger@movaz.com
メール: lberger@movaz.com
Debanjan Saha IBM Watson Research Center
DebanjanシャハIBMワトソン研究所
EMail: dsaha@us.ibm.com
メール: dsaha@us.ibm.com
Debashis Basak Accelight Networks 70 Abele Road, Suite 1201 Bridgeville, PA 15017-3470
Debashis Basak Accelightは70ハクヨウ道路、1201Bridgeville、Suite PA15017-3470をネットワークでつなぎます。
EMail: dbasak@accelight.com
メール: dbasak@accelight.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705
ハルSandickシェパードm.s.2401ダコタ通りダラム、NC 27705
EMail: sandick@nc.rr.com
メール: sandick@nc.rr.com
Alex Zinin Alcatel
アレックスジニンアルカテル
EMail: alex.zinin@alcatel.com
メール: alex.zinin@alcatel.com
Bala Rajagopalan Intel Corp. 2111 NE 25th Ave Hillsboro, OR 97123
第25Bala Rajagopalanインテル社2111Ne Aveヒースボロー、または97123
EMail: bala.rajagopalan@intel.com
メール: bala.rajagopalan@intel.com
Sankar Ramamoorthi Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Sankar Ramamoorthi杜松はInc.1194の北のマチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: sankarr@juniper.net
メール: sankarr@juniper.net
Lang Standards Track [Page 84] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[84ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Contact Address
連絡先
Jonathan P. Lang Sonos, Inc. 829 De La Vina, Suite 220 Santa Barbara, CA 93101
ジョナサンP.ラングSonos Inc.829De Laビナ、サンタバーバラ、Suite220カリフォルニア 93101
EMail: jplang@ieee.org
メール: jplang@ieee.org
Lang Standards Track [Page 85] RFC 4204 Link Management Protocol (LMP) October 2005
ラング標準化過程[85ページ]RFC4204は2005年10月に管理プロトコル(LMP)をリンクします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。
Lang Standards Track [Page 86]
ラング標準化過程[86ページ]
一覧
スポンサーリンク
