Network Working Group L. Andersson
Request for Comments: 3036 Nortel Networks Inc.
Category: Standards Track P. Doolan
Ennovate Networks
N. Feldman
IBM Corp
A. Fredette
PhotonEx Corp
B. Thomas
Cisco Systems, Inc.
January 2001
LDP Specification
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
マルチプロトコルラベルスイッチング（MPLS）のためのアーキテクチャは、MPLSの基本的な考え方は、二つのラベルスイッチングルータ（LSRには）の間およびそれらを介してトラフィックを転送するために使用されるラベルの意味に同意しなければならないということであるRFC 3031に記述されています。この共通の理解は、1 LSRは自身が行ったラベルバインディングの別通知することにより、ラベル配布プロトコルと呼ばれる一連の手順を、使用することによって達成されます。この文書は、のLSRが正常にルーティングパスに沿ってMPLS転送をサポートするためのラベルを配布れる（ラベル配布プロトコルのための）LDPと呼ばれるこのような手順のセットを定義します。
Table of Contents
目次
1 LDP Overview ....................................... 5
1.1 LDP Peers .......................................... 6
1.2 LDP Message Exchange ............................... 6
1.3 LDP Message Structure .............................. 7
1.4 LDP Error Handling ................................. 7
1.5 LDP Extensibility and Future Compatibility ......... 7
1.6 Specification Language ............................. 7
2 LDP Operation ...................................... 8
2.1 FECs ............................................... 8
2.2 Label Spaces, Identifiers, Sessions and Transport .. 9
2.2.1 Label Spaces ....................................... 9
2.2.2 LDP Identifiers .................................... 10
2.2.3 LDP Sessions ....................................... 10
2.2.4 LDP Transport ...................................... 11
2.3 LDP Sessions between non-Directly Connected LSRs ... 11
2.4 LDP Discovery ..................................... 11
2.4.1 Basic Discovery Mechanism .......................... 12
2.4.2 Extended Discovery Mechanism ....................... 12
2.5 Establishing and Maintaining LDP Sessions .......... 13
2.5.1 LDP Session Establishment .......................... 13
2.5.2 Transport Connection Establishment ................. 13
2.5.3 Session Initialization ............................. 14
2.5.4 Initialization State Machine ....................... 17
2.5.5 Maintaining Hello Adjacencies ...................... 20
2.5.6 Maintaining LDP Sessions ........................... 20
2.6 Label Distribution and Management .................. 21
2.6.1 Label Distribution Control Mode .................... 21
2.6.1.1 Independent Label Distribution Control ............. 21
2.6.1.2 Ordered Label Distribution Control ................. 21
2.6.2 Label Retention Mode ............................... 22
2.6.2.1 Conservative Label Retention Mode .................. 22
2.6.2.2 Liberal Label Retention Mode ....................... 22
2.6.3 Label Advertisement Mode ........................... 23
2.7 LDP Identifiers and Next Hop Addresses ............. 23
2.8 Loop Detection ..................................... 24
2.8.1 Label Request Message .............................. 24
2.8.2 Label Mapping Message .............................. 26
2.8.3 Discussion ......................................... 27
2.9 Authenticity and Integrity of LDP Messages ......... 28
2.9.1 TCP MD5 Signature Option ........................... 28
2.9.2 LDP Use of TCP MD5 Signature Option ................ 30
2.10 Label Distribution for Explicitly Routed LSPs ...... 30
3 Protocol Specification ............................. 31
3.1 LDP PDUs ........................................... 31
3.2 LDP Procedures ..................................... 32
3.3 Type-Length-Value Encoding ......................... 32
3.4 TLV Encodings for Commonly Used Parameters ......... 34
3.4.1 FEC TLV ............................................ 34
3.4.1.1 FEC Procedures ..................................... 37
3.4.2 Label TLVs ......................................... 37
3.4.2.1 Generic Label TLV .................................. 37
3.4.2.2 ATM Label TLV ...................................... 38
3.4.2.3 Frame Relay Label TLV .............................. 38
3.4.3 Address List TLV ................................... 39
3.4.4 Hop Count TLV ...................................... 40
3.4.4.1 Hop Count Procedures ............................... 40
3.4.5 Path Vector TLV .................................... 41
3.4.5.1 Path Vector Procedures ............................. 42
3.4.5.1.1 Label Request Path Vector .......................... 42
3.4.5.1.2 Label Mapping Path Vector .......................... 43
3.4.6 Status TLV ......................................... 43
3.5 LDP Messages ....................................... 45
3.5.1 Notification Message ............................... 47
3.5.1.1 Notification Message Procedures .................... 48
3.5.1.2 Events Signaled by Notification Messages ........... 49
3.5.1.2.1 Malformed PDU or Message ........................... 49
3.5.1.2.2 Unknown or Malformed TLV ........................... 50
3.5.1.2.3 Session KeepAlive Timer Expiration ................. 50
3.5.1.2.4 Unilateral Session Shutdown ........................ 51
3.5.1.2.5 Initialization Message Events ...................... 51
3.5.1.2.6 Events Resulting From Other Messages ............... 51
3.5.1.2.7 Internal Errors .................................... 51
3.5.1.2.8 Miscellaneous Events ............................... 51
3.5.2 Hello Message ...................................... 51
3.5.2.1 Hello Message Procedures ........................... 54
3.5.3 Initialization Message ............................. 55
3.5.3.1 Initialization Message Procedures .................. 63
3.5.4 KeepAlive Message .................................. 63
3.5.4.1 KeepAlive Message Procedures ....................... 63
3.5.5 Address Message .................................... 64
3.5.5.1 Address Message Procedures ......................... 64
3.5.6 Address Withdraw Message ........................... 65
3.5.6.1 Address Withdraw Message Procedures ................ 66
3.5.7 Label Mapping Message .............................. 66
3.5.7.1 Label Mapping Message Procedures ................... 67
3.5.7.1.1 Independent Control Mapping ........................ 67
3.5.7.1.2 Ordered Control Mapping ............................ 68
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 68
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 69
3.5.8 Label Request Message .............................. 69
3.5.8.1 Label Request Message Procedures ................... 70
3.5.9 Label Abort Request Message ........................ 72
3.5.9.1 Label Abort Request Message Procedures ............. 73
3.5.10 Label Withdraw Message ............................. 74
3.5.10.1 Label Withdraw Message Procedures .................. 75
3.5.11 Label Release Message .............................. 76
3.5.11.1 Label Release Message Procedures ................... 77
3.6 Messages and TLVs for Extensibility ................ 78
3.6.1 LDP Vendor-private Extensions ...................... 78
3.6.1.1 LDP Vendor-private TLVs ............................ 78
3.6.1.2 LDP Vendor-private Messages ........................ 80
3.6.2 LDP Experimental Extensions ........................ 81
3.7 Message Summary .................................... 81
3.8 TLV Summary ........................................ 82
3.9 Status Code Summary ................................ 83
3.10 Well-known Numbers ................................. 84
3.10.1 UDP and TCP Ports .................................. 84
3.10.2 Implicit NULL Label ................................ 84
4 IANA Considerations ................................ 84
4.1 Message Type Name Space ............................ 84
4.2 TLV Type Name Space ................................ 85
4.3 FEC Type Name Space ................................ 85
4.4 Status Code Name Space ............................. 86
4.5 Experiment ID Name Space ........................... 86
5 Security Considerations ............................ 86
5.1 Spoofing ........................................... 86
5.2 Privacy ............................................ 87
5.3 Denial of Service .................................. 87
6 Areas for Future Study ............................. 89
7 Intellectual Property Considerations ............... 89
8 Acknowledgments .................................... 89
9 References ......................................... 89
10 Authors' Addresses ................................. 92
Appendix A LDP Label Distribution Procedures .................. 93
A.1 Handling Label Distribution Events ................. 95
A.1.1 Receive Label Request .............................. 96
A.1.2 Receive Label Mapping .............................. 99
A.1.3 Receive Label Abort Request ........................ 105
A.1.4 Receive Label Release .............................. 107
A.1.5 Receive Label Withdraw ............................. 109
A.1.6 Recognize New FEC .................................. 110
A.1.7 Detect Change in FEC Next Hop ...................... 113
A.1.8 Receive Notification / Label Request Aborted ....... 116
A.1.9 Receive Notification / No Label Resources .......... 116
A.1.10 Receive Notification / No Route .................... 117
A.1.11 Receive Notification / Loop Detected ............... 118
A.1.12 Receive Notification / Label Resources Available ... 118
A.1.13 Detect local label resources have become available . 119
A.1.14 LSR decides to no longer label switch a FEC ........ 120
A.1.15 Timeout of deferred label request .................. 121
A.2 Common Label Distribution Procedures ............... 121
A.2.1 Send_Label ......................................... 121
A.2.2 Send_Label_Request ................................. 123
A.2.3 Send_Label_Withdraw ................................ 124
A.2.4 Send_Notification .................................. 125
A.2.5 Send_Message ....................................... 125
A.2.6 Check_Received_Attributes .......................... 126
A.2.7 Prepare_Label_Request_Attributes ................... 127
A.2.8 Prepare_Label_Mapping_Attributes ................... 129
Full Copyright Statement ...................................... 132
The MPLS architecture [RFC3031] defines a label distribution protocol as a set of procedures by which one Label Switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them.
MPLSアーキテクチャ[RFC3031]一つのラベルルータ（LSR）を交換れる手順のセットとしてラベル配布プロトコルを定義する間、それらを介してトラフィックを転送するために使用されるラベルの意味の他に通知します。
The MPLS architecture does not assume a single label distribution protocol. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them. New protocols have also been defined for the explicit purpose of distributing labels. The MPLS architecture discusses some of the considerations when choosing a label distribution protocol for use in particular MPLS applications such as Traffic Engineering [RFC2702].
MPLSアーキテクチャは、単一のラベル配布プロトコルを負いません。実際には、異なるラベル配布プロトコルの数は、標準化されています。ラベル配布がそれらの上にピギーバックできるように、既存のプロトコルが拡張されています。新しいプロトコルはまた、ラベルを配布する明示的な目的のために定義されています。こうしたトラフィックエンジニアリング[RFC2702]などの特定のMPLSアプリケーションで使用するためのラベル配布プロトコルを選択する際に、MPLSアーキテクチャは、検討事項のいくつかについて説明します。
The Label Distribution Protocol (LDP) defined in this document is a new protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes.
この文書で定義されたラベル配布プロトコル（LDP）は、ラベルを配布するために定義された新しいプロトコルです。これは、パスを切り替えるラベルはデータリンク層に直接マッピングネットワーク層によって、ネットワークを介してルーティング情報をパス（LSPを）ラベルを確立ルータ（LSRの）のスイッチスイッチれる手順およびメッセージのセットです。これらのLSPは（IPホップバイホップ転送に匹敵する）直接結合ネイバーで終点を有していてもよく、またはすべての中間ノードを介して切り替え可能に、ネットワークの出口ノードにおけるエンドポイントを有することができます。
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with each LSP it creates. The FEC associated with an LSP specifies which packets are "mapped" to that LSP. LSPs are extended through a network as each LSR "splices" incoming labels for a FEC to the outgoing label assigned to the next hop for the given FEC.
LDPは、それが作成し、各LSPで転送等価クラス（FEC）[RFC3031]を関連付けます。 LSPに関連付けられたFECパケットがそのLSPに「マッピング」されるかを指定します。 LSPは、各LSRが所与のFECのための次のホップに割り当てられた出力ラベルにFECの着信ラベルを「スプライス」などのネットワークを介して拡張されます。
More information about the applicability of LDP can be found in [RFC3037].
自民党の適用についての詳細は、[RFC3037]で見つけることができます。
This document assumes familiarity with the MPLS architecture [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminology, such as ingress, label switched path, etc.
この文書では、MPLSアーキテクチャ[RFC3031]に精通している前提としています。 [RFC3031]は、そのような入力としてMPLS用語の用語集を含むことに注意し、ラベルスイッチパス、等
Two LSRs which use LDP to exchange label/FEC mapping information are known as "LDP Peers" with respect to that information and we speak of there being an "LDP Session" between them. A single LDP session allows each peer to learn the other's label mappings; i.e., the protocol is bi-directional.
ラベル/ FECマッピング情報を交換するLDPを使用する2つのLSRは、その情報に対する「LDPピア」として知られており、私たちはそこにそれらの間で「LDPセッション」での話します。単一LDPセッションは、それぞれの他のラベルマッピングを学習するピアことができます。すなわち、プロトコルは双方向です。
There are four categories of LDP messages:
LDPメッセージの4つのカテゴリがあります。
1. Discovery messages, used to announce and maintain the presence of an LSR in a network.
1.ディスカバリーメッセージは、アナウンス及びネットワークにおけるLSRの存在を維持するために使用されます。
2. Session messages, used to establish, maintain, and terminate sessions between LDP peers.
確立、維持、およびLDPピア間のセッションを終了するために使用2.セッションメッセージ、。
3. Advertisement messages, used to create, change, and delete label mappings for FECs.
FECのラベルマッピングを作成、変更、および削除するために使用3.広告メッセージ、。
4. Notification messages, used to provide advisory information and to signal error information.
アドバイザリ情報を提供し、エラー情報を通知するために使用される前記通知メッセージ。
Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending a Hello message periodically. This is transmitted as a UDP packet to the LDP port at the `all routers on this subnet' group multicast address. When an LSR chooses to establish a session with another LSR learned via the Hello message, it uses the LDP initialization procedure over TCP transport. Upon successful completion of the initialization procedure, the two LSRs are LDP peers, and may exchange advertisement messages.
LSRは、定期的にHelloメッセージを送信することにより、ネットワーク内で自分の存在を示すことにより、ディスカバリーメッセージは、メカニズムを提供します。これは `このサブネット上のすべてのルータ」グループのマルチキャストアドレスのLDPポートにUDPパケットとして送信されます。 LSRが別のLSRは、Helloメッセージを通じて学んだとのセッションを確立することを選択した場合は、TCPトランスポート上LDP初期化手順を使用しています。初期化手順が正常に完了すると、2つのLSRは、LDPピアであり、広告メッセージを交換することができます。
When to request a label or advertise a label mapping to a peer is largely a local decision made by an LSR. In general, the LSR requests a label mapping from a neighboring LSR when it needs one, and advertises a label mapping to a neighboring LSR when it wishes the neighbor to use a label.
ラベルを要求するか、ピアへのラベルマッピングを広告する場合には、主にLSRによって作られた地元の決定です。それが1つを必要とするとき、一般的に、LSRは、隣接LSRからラベルマッピングを要求し、それがラベルを使用するために隣人を希望する場合、隣接LSRにラベルマッピングをアドバタイズします。
Correct operation of LDP requires reliable and in order delivery of messages. To satisfy these requirements LDP uses the TCP transport for session, advertisement and notification messages; i.e., for everything but the UDP-based discovery mechanism.
自民党の正しい動作は、信頼性やメッセージの順序の配信に必要です。これらの要件を満たすためにLDPセッション、広告および通知メッセージ用のTCPトランスポートを使用しています。すなわち、UDPベースの検出メカニズムが、すべてのために。
All LDP messages have a common structure that uses a Type-Length-Value (TLV) encoding scheme; see Section "Type-Length-Value" encoding. The Value part of a TLV-encoded object, or TLV for short, may itself contain one or more TLVs.
全てのLDPメッセージは、タイプレングス値（TLV）符号化方式を使用する共通の構造を有しています。セクション "なType-Length-値" エンコーディングを参照してください。略し値TLVでエンコードされたオブジェクトの一部、またはTLVは、それ自体が一つ以上のTLVを含んでいてもよいです。
LDP errors and other events of interest are signaled to an LDP peer by notification messages.
自民党のエラーや関心のある他のイベントは、通知メッセージでLDPピアに通知されます。
There are two kinds of LDP notification messages:
LDP通知メッセージの2種類があります。
1. Error notifications, used to signal fatal errors. If an LSR receives an error notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned via the session.
1.エラー通知は、致命的なエラーを通知するために使用しました。 LSRは、LDPセッションのために、ピアからのエラー通知を受信した場合、それはセッションのためのTCPトランスポート接続をクローズして、セッションを介して学習すべてのラベルマッピングを破棄することにより、LDPセッションを終了します。
2. Advisory notifications, used to pass an LSR information about the LDP session or the status of some previous message received from the peer.
LDPセッションまたはピアから受信したいくつかの以前のメッセージのステータスに関するLSR情報を渡すために使用2.諮問通知、。
Functionality may be added to LDP in the future. It is likely that future functionality will utilize new messages and object types (TLVs). It may be desirable to employ such new messages and TLVs within a network using older implementations that do not recognize them. While it is not possible to make every future enhancement backwards compatible, some prior planning can ease the introduction of new capabilities. This specification defines rules for handling unknown message types and unknown TLVs for this purpose.
機能は、将来的にはLDPに添加することができます。将来の機能は、新しいメッセージおよびオブジェクトタイプ（TLVを）利用する可能性があります。それらを認識していない古い実装を使用して、ネットワーク内のこのような新しいメッセージやTLVを採用することが望ましい場合があります。それは、すべての将来の拡張は下位互換性にすることはできませんが、いくつかの従来の計画は、新機能の導入を容易にすることができます。この仕様では、この目的のために、未知のメッセージタイプと未知のTLVを処理するためのルールを定義します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
It is necessary to precisely specify which packets may be mapped to each LSP. This is done by providing a FEC specification for each LSP. The FEC identifies the set of IP packets which may be mapped to that LSP.
正確に各LSPにマッピングすることができるパケットを指定する必要があります。これは、各LSPのためにFEC仕様を提供することによって行われます。 FECは、そのLSPにマッピングすることができるIPパケットのセットを識別する。
Each FEC is specified as a set of one or more FEC elements. Each FEC element identifies a set of packets which may be mapped to the corresponding LSP. When an LSP is shared by multiple FEC elements, that LSP is terminated at (or before) the node where the FEC elements can no longer share the same path.
各FECは、一つ以上のFEC要素の集合として指定されます。各FEC要素は、対応するLSPにマッピングすることができるパケットのセットを識別する。 LSPは、LSPがで（または前に）終了したことを、複数のFEC要素によってFEC要素はもはや同じ経路を共有することができるノードを共有する場合。
Following are the currently defined types of FEC elements. New element types may be added as needed:
FEC要素の現在定義されているタイプは次のとおりです。必要に応じて新しい要素タイプを追加してもよいです。
1. Address Prefix. This element is an address prefix of any length from 0 to a full address, inclusive.
1.アドレスプレフィックス。この要素は、0以上からの完全なアドレスに任意の長さのアドレスプレフィックス、です。
(We will see below that an Address Prefix FEC element which is a full address has a different effect than a Host Address FEC element which has the same address.)
（私たちは、完全なアドレスが同じアドレスを持つホストアドレスFEC要素とは異なる効果を持っている、そのアドレスプレフィックスFEC要素の下に表示されます。）
We say that a particular address "matches" a particular address prefix if and only if that address begins with that prefix. We also say that a particular packet matches a particular LSP if and only if that LSP has an Address Prefix FEC element which matches the packet's destination address. With respect to a particular packet and a particular LSP, we refer to any Address Prefix FEC element which matches the packet as the "matching prefix".
私たちは、特定のアドレスが「一致する」と言う特定のアドレスプレフィックスであれば、そのアドレスは、その接頭辞で始まる場合にのみ。我々はまた、特定のパケットが特定のLSPと一致していることを言うならば、そのLSPは、パケットの宛先アドレスと一致するアドレスプレフィックスFEC要素を持っている場合のみ。特定のパケットおよび特定のLSPに関しては、私たちは、「一致する接頭辞」としてパケットに一致する任意のアドレスプレフィックスFEC要素を参照してください。
The procedure for mapping a particular packet to a particular LSP uses the following rules. Each rule is applied in turn until the packet can be mapped to an LSP.
特定のLSPに特定のパケットをマッピングするための手順は、以下の規則を使用します。パケットがLSPにマッピングすることが可能になるまで各ルールは順番に適用されます。
- If there is exactly one LSP which has a Host Address FEC element that is identical to the packet's destination address, then the packet is mapped to that LSP.
- パケットの宛先アドレスと同じであるホストアドレスFEC要素を持って正確に一つのLSPがある場合、パケットはそのLSPにマッピングされます。
- If there are multiple LSPs, each containing a Host Address FEC element that is identical to the packet's destination address, then the packet is mapped to one of those LSPs. The procedure for selecting one of those LSPs is beyond the scope of this document.
- 複数のLSPがある場合、パケットの宛先アドレスと同一であるそれぞれ含むホストアドレスFEC要素は、パケットは、それらのLSPのいずれかにマッピングされます。これらのLSPのいずれかを選択するための手順は、このドキュメントの範囲を超えています。
- If a packet matches exactly one LSP, the packet is mapped to that LSP.
- パケットが正確に一つのLSPと一致する場合、パケットはそのLSPにマッピングされます。
- If a packet matches multiple LSPs, it is mapped to the LSP whose matching prefix is the longest. If there is no one LSP whose matching prefix is longest, the packet is mapped to one from the set of LSPs whose matching prefix is longer than the others. The procedure for selecting one of those LSPs is beyond the scope of this document.
- パケットが複数のLSPと一致する場合、それは、そのマッチング接頭最長であるLSPにマッピングされます。そのマッチング接頭辞最長で誰LSPが存在しない場合、パケットはマッチングプレフィックス長他よりあるLSPの集合から1にマッピングされています。これらのLSPのいずれかを選択するための手順は、このドキュメントの範囲を超えています。
- If it is known that a packet must traverse a particular egress router, and there is an LSP which has an Address Prefix FEC element which is an address of that router, then the packet is mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document.
- それは、パケットが特定の出口ルータを横断しなければならないことが知られており、そのルータのアドレスであるアドレスプレフィックスFEC要素を有するLSPが存在している場合、パケットはそのLSPにマッピングされます。この知識を得るための手順は、このドキュメントの範囲を超えています。
The procedure for determining that a packet must traverse a particular egress router is beyond the scope of this document. (As an example, if one is running a link state routing algorithm, it may be possible to obtain this information from the link state data base. As another example, if one is running BGP, it may be possible to obtain this information from the BGP next hop attribute of the packet's route.)
パケットが特定の出口ルータを通過しなければならないことを決定するための手順は、このドキュメントの範囲を超えています。一つはリンク状態ルーティング・アルゴリズムを実行している場合（例として、リンク状態データベースからこの情報を取得することも可能である。一方がBGPを実行している場合、別の例として、それからこの情報を取得することも可能ですパケットのルートのBGPネクストホップ属性。）
It is worth pointing out a few consequences of these rules:
これは、これらの規則のいくつかの影響を指摘する価値があります：
- A packet may be sent on the LSP whose Address Prefix FEC element is the address of the packet's egress router ONLY if there is no LSP matching the packet's destination address.
- パケットは、そのアドレスプレフィックスFEC要素LSPを通じて送信されるパケットの宛先アドレスと一致するLSPが存在しない場合にのみ、パケットの出口ルータのアドレスです。
- A packet may match two LSPs, one with a Host Address FEC element and one with an Address Prefix FEC element. In this case, the packet is always assigned to the former.
- パケットは、二つのLSP、ホストアドレスFEC要素を有するものとアドレスプレフィックスFEC要素を有するものと一致してもよいです。この場合、パケットは常に元に割り当てられます。
- A packet which does not match a particular Host Address FEC element may not be sent on the corresponding LSP, even if the Host Address FEC element identifies the packet's egress router.
- 特定のホストアドレスFEC要素と一致しないパケットは、ホストアドレスFEC要素は、パケットの出口ルータを識別した場合でも、対応するLSP上で送信されなくてもよいです。
The notion of "label space" is useful for discussing the assignment and distribution of labels. There are two types of label spaces:
「ラベルスペース」の概念は、ラベルの割り当てと配布を議論するのに便利です。ラベルスペースの2種類があります。
- Per interface label space. Interface-specific incoming labels are used for interfaces that use interface resources for labels. An example of such an interface is a label-controlled ATM interface that uses VCIs as labels, or a Frame Relay interface that uses DLCIs as labels.
- インターフェイスごとのラベルスペース。インターフェイス固有の着信ラベルは、ラベルのインターフェイスリソースを使用するインターフェイスのために使用されます。そのようなインターフェイスの例は、ラベル、又はラベルとしてのDLCIを使用してフレームリレーインタフェースとしてのVCIを使用してラベル制御ATMインターフェイスです。
Note that the use of a per interface label space only makes sense when the LDP peers are "directly connected" over an interface, and the label is only going to be used for traffic sent over that interface.
LDPピアがインターフェイス上で「直接接続」されている場合、インターフェイスごとのラベルスペースの使用が唯一の理にかなっている、とラベルは唯一そのインターフェイス経由で送信されるトラフィックに使用されようとしていることに注意してください。
- Per platform label space. Platform-wide incoming labels are used for interfaces that can share the same labels.
- プラットフォームごとのラベルスペース。プラットフォーム全体の着信ラベルは同じラベルを共有できるインターフェイスのために使用されます。
An LDP identifier is a six octet quantity used to identify an LSR label space. The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR. The last two octets identify a specific label space within the LSR. The last two octets of LDP Identifiers for platform-wide label spaces are always both zero. This document uses the following print representation for LDP Identifiers:
LDP識別子はLSRラベルスペースを識別するために使用される6つのオクテット量です。最初の4つのオクテットはLSRを識別し、そのようなLSRに割り当てられた32ビットルータIDとしてグローバルに固有の値でなければなりません。最後の2つのオクテットはLSR内の特定のラベルスペースを識別します。プラットフォーム全体のラベルスペースのLDP識別子の最後の2つのオクテットは、常に両方ともゼロです。この文書はLDP識別子のために、次の印刷表現を使用しています。
<LSR Id> : <label space id>
<LSR ID>：<ラベルスペースID>
e.g., lsr171:0, lsr19:2.
例えば、lsr171：0、lsr19：2。
Note that an LSR that manages and advertises multiple label spaces uses a different LDP Identifier for each such label space.
複数のラベルのスペースを管理し、アドバタイズLSRは、このような各ラベル領域に異なるLDP識別子を使用することに留意されたいです。
A situation where an LSR would need to advertise more than one label space to a peer and hence use more than one LDP Identifier occurs when the LSR has two links to the peer and both are ATM (and use per interface labels). Another situation would be where the LSR had two links to the peer, one of which is ethernet (and uses per platform labels) and the other of which is ATM.
LSRがピアへの2つのリンクを有しており、両方がATMである（及びインタフェースラベルごとに使用する）場合LSRがピアに複数のラベルスペースをアドバタイズし、従ってつ以上のLDP識別子よりも使用する必要がある状況が発生します。 LSRがイーサネットであるそのうちの一つのピアへの2つのリンクを、持っていた（とプラットフォームのラベルごとに使用しています）やATMで他のその場所別の状況は次のようになります。
LDP sessions exist between LSRs to support label exchange between them.
LDPセッションは、それらの間のラベル交換をサポートするためのLSR間に存在します。
When an LSR uses LDP to advertise more than one label space to another LSR it uses a separate LDP session for each label space.
LSRが別のLSRに複数のラベルスペースを宣伝するためにLDPを使用する場合には、各ラベルのスペースのための別のLDPセッションを使用しています。
LDP uses TCP as a reliable transport for sessions.
自民党は、セッションのための信頼性の高いトランスポートとしてTCPを使用しています。
When multiple LDP sessions are required between two LSRs there is one TCP session for each LDP session.
複数のLDPセッションが2つのLSRの間に必要とされている場合は、各LDPセッションのための1つのTCPセッションがあります。
LDP sessions between LSRs that are not directly connected at the link level may be desirable in some situations.
直接リンク・レベルで接続されていないのLSR間のLDPセッションは、いくつかの状況では望ましいかもしれません。
For example, consider a "traffic engineering" application where LSRa sends traffic matching some criteria via an LSP to non-directly connected LSRb rather than forwarding the traffic along its normally routed path.
例えば、LSRaトラフィック非直接接続LSRbにLSPを介していくつかの条件に一致するのではなく、その正常にルーティングされた経路に沿ってトラフィックの転送を送信する「トラフィックエンジニアリング」アプリケーションを考えます。
The path between LSRa and LSRb would include one or more intermediate LSRs (LSR1,...LSRn). An LDP session between LSRa and LSRb would enable LSRb to label switch traffic arriving on the LSP from LSRa by providing LSRb means to advertise labels for this purpose to LSRa.
LSRaとLSRb間の経路は、1つまたは複数の中間のLSR（LSR1、... LSRn）を含むであろう。 LSRaとLSRb間のLDPセッションがLSRbを提供することにより、LSRaからLSPに到着スイッチトラフィックにラベルを付けるためにLSRbを可能にするLSRaに、この目的のためにラベルを宣伝することを意味します。
In this situation LSRa would apply two labels to traffic it forwards on the LSP to LSRb: a label learned from LSR1 to forward traffic along the LSP path from LSRa to LSRb; and a label learned from LSRb to enable LSRb to label switch traffic arriving on the LSP.
;ラベルはLSRbへLSRaからのLSPの経路に沿ってトラフィックを転送するためにLSR1から学んだ：このような状況でLSRaは、それがLSRbにLSPに転送するトラフィックに2つのラベルを適用しますラベルは、LSPに到着スイッチトラフィックにラベルを付けるためにLSRbを可能にするためにLSRbから学びました。
LSRa first adds the label learned via its LDP session with LSRb to the packet label stack (either by replacing the label on top of the packet label stack with it if the packet arrives labeled or by pushing it if the packet arrives unlabeled). Next, it pushes the label for the LSP learned from LSR1 onto the label stack.
LSRaは、最初の（どちらかそれパケットが標識に到着した場合のパケットラベルスタックの最上位にあるラベルを置き換えることによって、またはパケットが非標識で到着した場合、それを押して）パケットのラベルスタックにLSRbとのLDPセッションを介して学習ラベルを追加します。次に、LSPのラベルは、ラベルスタックにLSR1から学んだプッシュします。
LDP discovery is a mechanism that enables an LSR to discover potential LDP peers. Discovery makes it unnecessary to explicitly configure an LSR's label switching peers.
LDPディスカバリは、潜在的なLDPピアを発見するためにLSRを可能にするメカニズムです。ディスカバリーは、明示的にLSRのラベルスイッチングピアを設定することが不要になります。
There are two variants of the discovery mechanism:
発見機構の二つの変種があります。
- A basic discovery mechanism used to discover LSR neighbors that are directly connected at the link level.
- 直接リンクレベルで接続されているLSRのネイバーを検出するために使用される基本的な発見メカニズム。
- An extended discovery mechanism used to locate LSRs that are not directly connected at the link level.
- 拡張された検出メカニズムは、直接リンク・レベルで接続されていないのLSRを見つけるために使用しました。
To engage in LDP Basic Discovery on an interface an LSR periodically sends LDP Link Hellos out the interface. LDP Link Hellos are sent as UDP packets addressed to the well-known LDP discovery port for the "all routers on this subnet" group multicast address.
インターフェイス上でLDP基本的な発見に従事するためにLSRは、定期的にインターフェイスからLDPリンクhelloを送信します。 LDPリンクハローズUDPパケットは、「このサブネット上のすべてのルータ」グループマルチキャストアドレスで知らLDPディスカバリポートに宛てて送信されます。
An LDP Link Hello sent by an LSR carries the LDP Identifier for the label space the LSR intends to use for the interface and possibly additional information.
LSRによって送られたLDPリンクこんにちはLSRは、インターフェイスと、おそらく追加情報については、使用しようとするラベルスペースのためのLDP識別子を運びます。
Receipt of an LDP Link Hello on an interface identifies a "Hello adjacency" with a potential LDP peer reachable at the link level on the interface as well as the label space the peer intends to use for the interface.
インターフェイス上でLDPリンクのHelloの領収書は、インターフェイス上のリンクレベルで到達可能な潜在的なLDPピアと「ハロー隣接」だけでなく、ラベルスペースピアがインターフェイスのために使用するつもりが識別されます。
LDP sessions between non-directly connected LSRs are supported by LDP Extended Discovery.
非直接接続のLSR間のLDPセッションがLDP拡張ディスカバリーによってサポートされています。
To engage in LDP Extended Discovery an LSR periodically sends LDP Targeted Hellos to a specific address. LDP Targeted Hellos are sent as UDP packets addressed to the well-known LDP discovery port at the specific address.
LDPに従事するために発見LSRは、定期的に自民党が特定のアドレスにhelloをターゲットに送信し拡張。 UDPパケットが特定のアドレスによく知られたLDPディスカバリポート宛としてLDPターゲットhelloメッセージが送信されます。
An LDP Targeted Hello sent by an LSR carries the LDP Identifier for the label space the LSR intends to use and possibly additional optional information.
LDP LSRによって送信されるhelloターゲットLSRを使用して、おそらく追加のオプション情報を意図ラベルスペースのためのLDP識別子を運びます。
Extended Discovery differs from Basic Discovery in the following ways:
拡張ディスカバリーは、次の点で基本的な発見と異なります。
- A Targeted Hello is sent to a specific address rather than to the "all routers" group multicast address for the outgoing interface.
- ターゲットこんにちはは、特定のアドレスにではなく、発信インターフェイスのために「すべてのルータ」グループマルチキャストアドレスに送信されます。
- Unlike Basic Discovery, which is symmetric, Extended Discovery is asymmetric.
- 対称である基本的な発見とは異なり、拡張ディスカバリーは非対称です。
One LSR initiates Extended Discovery with another targeted LSR, and the targeted LSR decides whether to respond to or ignore the Targeted Hello. A targeted LSR that chooses to respond does so by periodically sending Targeted Hellos to the initiating LSR.
一つのLSRは、別の標的にLSRと拡張検出を開始し、目標とLSRに応答、またはこんにちはターゲットを無視するかどうかを決定します。対応することを選択した対象のLSRは、定期的に開始するLSRにターゲットhelloを送信することによって、そうします。
Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with a potential LDP peer reachable at the network level and the label space the peer intends to use.
LDPターゲットこんにちはの領収書は、ネットワークレベルで到達可能な潜在的なLDPピアとピアが使用しようとするラベルスペースを持つ「ハロー隣接を」識別します。
The exchange of LDP Discovery Hellos between two LSRs triggers LDP session establishment. Session establishment is a two step process:
2つのLSR間のLDPディスカバリhelloメッセージの交換は、LDPセッションの確立をトリガー。セッションの確立は、2段階のプロセスであります：
- Transport connection establishment.
- Session initialization
The following describes establishment of an LDP session between LSRs LSR1 and LSR2 from LSR1's point of view. It assumes the exchange of Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b for LSR2.
以下は、ビューのLSR1の観点からのLSR LSR1とLSR2間のLDPセッションの確立を説明します。 LSR1とラベルスペースLSR2のため：それはラベルスペースLSR1を指定ハローズの交換を前提としていLSR2ため、B。
The exchange of Hellos results in the creation of a Hello adjacency at LSR1 that serves to bind the link (L) and the label spaces LSR1:a and LSR2:b.
AとLSR2：：Bのリンク（L）とラベルスペースLSR1をバインドするのに役立つLSR1でのHello隣接の作成でハローズの結果を交換。
1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2.
1. LSR1がすでにラベルスペースLSR1を交換するためのLDPセッションがない場合：AとLSR2を：それはLSR2で新しいLDPセッションのためのTCP接続を開こうとbを。
LSR1 determines the transport addresses to be used at its end (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 is determined as follows:
LSR1は、LDP TCP接続のトランスポートアドレスの末尾（A1）で使用するとLSR2の終わり（A2）を決定します。次のようにアドレスA1が決定されます。
a. If LSR1 uses the Transport Address optional object (TLV) in Hello's it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;
A。 LSR1は、それがアドレスをアドバタイズするLSR2に送信こんにちは年代にトランスポートアドレスオプションのオブジェクト（TLV）を使用している場合、A1はLSR1はオプションのオブジェクトを経由して広告するアドレスです。
b. If LSR1 does not use the Transport Address optional object, A1 is the source address used in Hellos it sends to LSR2.
B。 LSR1は、トランスポートアドレスオプションのオブジェクトを使用していない場合は、A1は、それがLSR2に送信するhelloメッセージに使用される送信元アドレスです。
Similarly, address A2 is determined as follows:
次のように同様に、アドレスA2が決定されます。
a. If LSR2 uses the Transport Address optional object, A2 is the address LSR2 advertises via the optional object;
A。 LSR2は、トランスポートアドレスオプションのオブジェクトを使用している場合、A2はLSR2は、オプションのオブジェクトを経由して広告するアドレスです。
b. If LSR2 does not use the Transport Address optional object, A2 is the source address in Hellos received from LSR2.
B。 LSR2は、トランスポートアドレスオプションのオブジェクトを使用していない場合は、A2はハローズの送信元アドレスは、LSR2から受信されます。
2. LSR1 determines whether it will play the active or passive role in session establishment by comparing addresses A1 and A2 as unsigned integers. If A1 > A2, LSR1 plays the active role; otherwise it is passive.
2. LSR1は、符号なし整数としてアドレスA1とA2を比較することにより、セッションの確立に積極的または受動的な役割を果たしているかどうかを決定します。 A1> A2場合、LSR1は、積極的な役割を果たしています。それ以外の場合は、受動的です。
The procedure for comparing A1 and A2 as unsigned integers is:
符号なし整数としてA1とA2を比較するための手順は次のとおりです。
- If A1 and A2 are not in the same address family, they are incomparable, and no session can be established.
- A1とA2は同じアドレスファミリに含まれていない場合、彼らは比類のないですし、何のセッションが確立できません。
- Let U1 be the abstract unsigned integer obtained by treating A1 as a sequence of bytes, where the byte which appears earliest in the message is the most significant byte of the integer and the byte which appears latest in the message is the least significant byte of the integer.
- U1はメッセージで最初に表示されるバイトは、整数の最上位バイトとの最下位バイトであるメッセージに最新表示されますバイトであるバイトのシーケンスとしてA1を処理して得られた抽象的符号なし整数とします整数。
Let U2 be the abstract unsigned integer obtained from A2 in a similar manner.
U2は同様にA2から得た抽象符号なし整数とします。
- Compare U1 with U2. If U1 > U2, then A1 > A2; if U1 < U2, then A1 < A2.
- U2とU1を比較してください。 U1> U2、その後、A1> A2であれば、 U1 <U2、その後、A1 <A2の場合。
3. If LSR1 is active, it attempts to establish the LDP TCP connection by connecting to the well-known LDP port at address A2. If LSR1 is passive, it waits for LSR2 to establish the LDP TCP connection to its well-known LDP port.
3. LSR1がアクティブな場合、それはアドレスA2でよく知られたLDPポートに接続することにより、LDP TCP接続を確立しようとします。 LSR1が受動的である場合、それは、そのよく知られたLDPポートへのLDP TCP接続を確立するためにLSR2のを待ちます。
Note that when an LSR sends a Hello it selects the transport address for its end of the session connection and uses the Hello to advertise the address, either explicitly by including it in an optional Transport Address TLV or implicitly by omitting the TLV and using it as the Hello source address.
LSRが送信したときこんにちは、それは明示的にオプションのトランスポートアドレスTLVでそれを含めることによって、または暗黙的にTLVを省略して、それを使用するか、セッション接続の終わりのためのトランスポートアドレスを選択し、アドレスをアドバタイズするのHelloを使用することに注意してくださいこんにちは元アドレス。
An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency.
LSRは同じラベルスペースを広告のすべてのハローズで同じトランスポートアドレスをアドバタイズする必要があります。この要件は、同じラベルのスペースを使用して、複数のHello隣接関係によって連結された2つのLSRがそれぞれ隣接の同じ接続確立の役割を果たしていることを保証します。
After LSR1 and LSR2 establish a transport connection they negotiate session parameters by exchanging LDP Initialization messages. The parameters negotiated include LDP protocol version, label distribution method, timer values, VPI/VCI ranges for label controlled ATM, DLCI ranges for label controlled Frame Relay, etc.
LSR1とLSR2は、トランスポート接続を確立した後、彼らは、LDP初期化メッセージを交換することにより、セッションパラメータをネゴシエートします。ネゴシエートされたパラメータは、LDPプロトコルバージョン、ラベル配布方法、タイマー値を含む、VPI / VCIは、ATM制御ラベルの範囲、DLCI等ラベル制御フレーム・リレーのための範囲
Successful negotiation completes establishment of an LDP session between LSR1 and LSR2 for the advertisement of label spaces LSR1:a and LSR2:b.
AとLSR2：B成功した交渉は、ラベルスペースの広告LSR1ためLSR1とLSR2間のLDPセッションの確立を完了します。
The following describes the session initialization from LSR1's point of view.
以下は、ビューのLSR1の観点からのセッションの初期化について説明します。
After the connection is established, if LSR1 is playing the active role, it initiates negotiation of session parameters by sending an Initialization message to LSR2. If LSR1 is passive, it waits for LSR2 to initiate the parameter negotiation.
接続が確立された後、LSR1が積極的な役割を果たしている場合、それはLSR2に初期化メッセージを送信することにより、セッションパラメータのネゴシエーションを開始します。 LSR1が受動的である場合LSR2は、パラメータのネゴシエーションを開始するのを待ちます。
In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each, the passive LSR cannot know which label space to advertise over a newly established TCP connection until it receives the LDP Initialization message on the connection. The Initialization message carries both the LDP Identifier for the sender's (active LSR's) label space and the LDP Identifier for the receiver's (passive LSR's) label space.
各によってアドバタイズされるLSR1とLSR2と複数のラベル空間の間の複数のリンクがある場合、それは接続でLDP初期化メッセージを受信するまで一般的には、受動的なLSRは、新たに設立されたTCP接続を介して宣伝するためにどのラベルスペースを知ることができません。初期化メッセージは、受信者（受動LSRの）ラベル空間の送信者（アクティブLSRの）ラベルスペースとLDP識別子の両方LDP識別子を運びます。
By waiting for the Initialization message from its peer the passive LSR can match the label space to be advertised by the peer (as determined from the LDP Identifier in the PDU header for the Initialization message) with a Hello adjacency previously created when Hellos were exchanged.
ピアからの初期化メッセージを待つことによって受動LSRはハローズを交換したときに、以前に作成したハロー隣接して（初期化メッセージのPDUヘッダでLDP識別子から決定されるように）ピアによってアドバタイズするラベル領域を一致させることができます。
a. If LSR1 receives an Initialization message it attempts to match the LDP Identifier carried by the message PDU with a Hello adjacency.
A。 LSR1は、初期化メッセージを受信した場合には、ハロー隣接有するメッセージPDUによって運ばLDP識別子と一致することを試みます。
b. If there is a matching Hello adjacency, the adjacency specifies the local label space for the session.
B。こんにちはマッチング隣接関係が存在する場合、隣接関係は、セッションのローカルラベルスペースを指定します。
Next LSR1 checks whether the session parameters proposed in the message are acceptable. If they are, LSR1 replies with an Initialization message of its own to propose the parameters it wishes to use and a KeepAlive message to signal acceptance of LSR2's parameters. If the parameters are not acceptable, LSR1 responds by sending a Session Rejected/Parameters Error Notification message and closing the TCP connection.
次LSR1は、メッセージ内に提案セッションパラメータが許容可能であるかどうかをチェックします。その場合、LSR1はそれを使用したいパラメータとLSR2のパラメータの受け入れを合図にキープアライブメッセージを提案する、独自の初期化メッセージで応答します。パラメータが受け入れられない場合、LSR1は拒否セッション/パラメータエラー通知メッセージを送信し、TCPコネクションを閉じて応答します。
c. If LSR1 cannot find a matching Hello adjacency it sends a Session Rejected/No Hello Error Notification message and closes the TCP connection.
C。 LSR1が一致こんにちは隣接を見つけることができない場合には、セッションの拒否/いいえこんにちはエラー通知メッセージを送信し、TCP接続を閉じます。
d. If LSR1 receives a KeepAlive in response to its Initialization message, the session is operational from LSR1's point of view.
D。 LSR1が初期設定メッセージに応答して、キープアライブを受信した場合、セッションは、ビューのLSR1の観点からの操作です。
e. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP connection.
電子。 LSR1は、エラー通知メッセージを受信した場合、LSR2は、その提案のセッションを拒否したとLSR1は、TCP接続を終了します。
a. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP connection.
A。 LSR1は、エラー通知メッセージを受信した場合、LSR2は、その提案のセッションを拒否したとLSR1は、TCP接続を終了します。
b. If LSR1 receives an Initialization message, it checks whether the session parameters are acceptable. If so, it replies with a KeepAlive message. If the session parameters are unacceptable, LSR1 sends a Session Rejected/Parameters Error Notification message and closes the connection.
B。 LSR1は、初期化メッセージを受信すると、セッションパラメータが許容可能であるかどうかをチェックします。そうだとすれば、それはキープアライブメッセージで応答します。セッションパラメータが受け入れられない場合、LSR1は拒否セッション/パラメータエラー通知メッセージを送信し、接続を閉じます。
c. If LSR1 receives a KeepAlive message, LSR2 has accepted its proposed session parameters.
C。 LSR1は、キープアライブメッセージを受信した場合、LSR2は、その提案セッションパラメータを受け入れました。
d. When LSR1 has received both an acceptable Initialization message and a KeepAlive message the session is operational from LSR1's point of view.
D。 LSR1が許容される初期化メッセージおよびキープアライブメッセージの両方を受信したときに、セッションは、ビューのLSR1の視点からの操作です。
It is possible for a pair of incompatibly configured LSRs that disagree on session parameters to engage in an endless sequence of messages as each NAKs the other's Initialization messages with Error Notification messages.
セッションパラメータに反対し、非互換に構成されたのLSRのペアがエラー通知メッセージでの他の初期化メッセージそれぞれのNAKなどのメッセージの無限のシーケンスに従事することが可能です。
An LSR must throttle its session setup retry attempts with an exponential backoff in situations where Initialization messages are being NAK'd. It is also recommended that an LSR detecting such a situation take action to notify an operator.
LSRは、そのセッションのセットアップが初期化メッセージがNAKされつつある状況で指数バックオフして再試行絞る必要があります。また、このような状況を検出するLSRは、オペレータに通知するために行動を取ることをお勧めします。
The session establishment setup attempt following a NAK'd Initialization message must be delayed no less than 15 seconds, and subsequent delays must grow to a maximum delay of no less than 2 minutes. The specific session establishment action that must be delayed is the attempt to open the session transport connection by the LSR playing the active role.
NAKさ初期化メッセージ、次のセッション確立のセットアップの試みは、劣らず15秒以上を遅延させなければならない、とその後の遅延はありません2以上分の最大遅延に成長しなければなりません。遅延させなければならない特定のセッション確立アクションが積極的な役割を果たしLSRによってセッションのトランスポート接続をオープンしようとする試みです。
The throttled sequence of Initialization NAKs is unlikely to cease until operator intervention reconfigures one of the LSRs. After such a configuration action there is no further need to throttle subsequent session establishment attempts (until their initialization messages are NAK'd).
オペレータの介入がLSRのの1を再構成するまで、初期のNAK絞っシーケンスは中止することはほとんどありません。このような構成の作用後に更なる（それらの初期化メッセージは、NAKさになるまで）、その後のセッション確立の試みを絞るが必要とされません。
Due to the asymmetric nature of session establishment, reconfiguration of the passive LSR will go unnoticed by the active LSR without some further action. Section "Hello Message" describes an optional mechanism an LSR can use to signal potential LDP peers that it has been reconfigured.
セッション確立の非対称性のために、受動的なLSRの再構成は、さらにいくつかのアクションなしでアクティブなLSRによって気付かれないだろう。セクションの「Helloメッセージは」LSRは、それが再構成されたことを潜在的なLDPピアを通知するために使用できるオプションのメカニズムを説明しています。
It is convenient to describe LDP session negotiation behavior in terms of a state machine. We define the LDP state machine to have five possible states and present the behavior as a state transition table and as a state transition diagram.
ステートマシンの面でLDPセッションネゴシエーションの振る舞いを記述するのに便利です。我々は、5つの可能な状態を有し、状態遷移表として、状態遷移図として挙動を提示するLDP状態マシンを定義します。
Session Initialization State Transition Table
セッションの初期化状態遷移表
STATE EVENT NEW STATE
状態イベントNEW STATE
NON EXISTENT Session TCP connection established INITIALIZED established
NON EXISTENTセッションのTCPコネクションが確立INITIALIZED設立します
INITIALIZED Transmit Initialization msg OPENSENT (Active Role)
INITIALIZED送信初期化のMSG OPENSENT（積極的な役割）
Receive acceptable OPENREC
Initialization msg
(Passive Role )
Action: Transmit Initialization
msg and KeepAlive msg
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
その他のLDP MSG NON EXISTENTアクション：受信エラー通知MSG（NAK）と密接なトランスポート接続を送信
OPENREC Receive KeepAlive msg OPERATIONAL
OPENRECは、運用のKeepAlive MSGを受信します
Receive Any other LDP msg NON EXISTENT
Action: Transmit Error Notification msg
(NAK) and close transport connection
OPENSENT Receive acceptable OPENREC Initialization msg Action: Transmit KeepAlive msg
送信キープアライブメッセージ：OPENSENTは許容OPENREC初期化MSGアクションを受け取ります
Receive Any other LDP msg NON EXISTENT
Action: Transmit Error Notification msg
(NAK) and close transport connection
OPERATIONAL Receive Shutdown msg NON EXISTENT Action: Transmit Shutdown msg and close transport connection
オペレーショナル・シャットダウンMSG NON EXISTENTアクションを受信：送信シャットダウンmsgと密接なトランスポート接続
Receive other LDP msgs OPERATIONAL
オペレーショナル他のLDPのMSGの受信
Timeout NON EXISTENT Action: Transmit Shutdown msg and close transport connection
タイムアウトNON EXISTENTアクション：送信シャットダウンmsgと密接なトランスポート接続
Session Initialization State Transition Diagram
セッションの初期化状態遷移図
+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg or Timeout |
| +-----------+ |
Rx Any other | | | |
msg or | |INITIALIZED| |
Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) |
| | Rx Acceptable | Tx Init msg |
| | Init msg / | |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg |
msg | | | |
| | | Rx Acceptable |
| | | Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown msg
All other | ^ or Timeout /
LDP msgs | | Tx Shutdown msg
| |
+---+
An LDP session with a peer has one or more Hello adjacencies.
ピアとのLDPセッションが一個の以上のHello隣接関係を持っています。
An LDP session has multiple Hello adjacencies when a pair of LSRs is connected by multiple links that share the same label space; for example, multiple PPP links between a pair of routers. In this situation the Hellos an LSR sends on each such link carry the same LDP Identifier.
LDPセッションがのLSRのペアが同じラベル空間を共有する複数のリンクで接続された複数のHello隣接関係を持っています。ルータのペア間、例えば、複数のPPPリンク。ハローズLSRは、そのような各リンク上で送信します。このような状況では、同じLDP識別子を運びます。
LDP includes mechanisms to monitor the necessity of an LDP session and its Hello adjacencies.
LDPはLDPセッションの必要性とそのハロー隣接関係を監視するためのメカニズムが含まれています。
LDP uses the regular receipt of LDP Discovery Hellos to indicate a peer's intent to use the label space identified by the Hello. An LSR maintains a hold timer with each Hello adjacency which it restarts when it receives a Hello that matches the adjacency. If the timer expires without receipt of a matching Hello from the peer, LDP concludes that the peer no longer wishes to label switch using that label space for that link (or target, in the case of Targeted Hellos) or that the peer has failed. The LSR then deletes the Hello adjacency. When the last Hello adjacency for a LDP session is deleted, the LSR terminates the LDP session by sending a Notification message and closing the transport connection.
自民党は、こんにちはで識別ラベルスペースを使用するには、ピアの意思を示すために、LDPディスカバリhelloメッセージを定期的に領収書を使用しています。 LSRは、隣接関係に一致するハローを受信したとき、それが再起動し、それぞれのHello隣接してホールドタイマーを維持します。タイマーがピアからこんにちはマッチングの領収書なしで期限が切れるなら、LDPピアは、もはや（ターゲットハローズの場合、またはターゲット）そのラベルをそのリンクのためのスペースを使用してスイッチを標識することを希望するか、ピアが失敗したことと結論付けていません。 LSRは、その後のHello隣接関係を削除します。 LDPセッションの最後のハロー隣接関係が削除されると、LSRは、通知メッセージを送信し、トランスポート接続を閉じることでLDPセッションを終了します。
LDP includes mechanisms to monitor the integrity of the LDP session.
LDPはLDPセッションの整合性を監視するためのメカニズムが含まれています。
LDP uses the regular receipt of LDP PDUs on the session transport connection to monitor the integrity of the session. An LSR maintains a KeepAlive timer for each peer session which it resets whenever it receives an LDP PDU from the session peer. If the KeepAlive timer expires without receipt of an LDP PDU from the peer the LSR concludes that the transport connection is bad or that the peer has failed, and it terminates the LDP session by closing the transport connection.
自民党は、セッションの整合性を監視するために、セッションのトランスポート接続上のLDP PDUの定期的な領収書を使用しています。 LSRは、セッションピアからのLDP PDUを受信するたびに、それがリセット各ピアセッションのためのキープアライブタイマーを維持します。キープアライブタイマーがピアからLDP PDUの領収書なしで期限が切れるならLSRは、トランスポート接続が不良であると結論またはピアが失敗したこと、そしてそれがトランスポート接続を閉じることでLDPセッションを終了します。
After an LDP session has been established, an LSR must arrange that its peer receive an LDP PDU from it at least every KeepAlive time period to ensure the peer restarts the session KeepAlive timer. The LSR may send any protocol message to meet this requirement. In circumstances where an LSR has no other information to communicate to its peer, it sends a KeepAlive message.
LDPセッションが確立された後、LSRは、そのピアがピアがセッションキープアライブタイマーを再起動することを確認するために、それは、少なくとも、すべてのKeepAliveの期間からLDP PDUを受け取ることを手配しなければなりません。 LSRは、この要件を満たすために、任意のプロトコルメッセージを送信することができます。 LSRがそのピアに通信するための他の情報を有していない状況では、キープアライブメッセージを送信します。
An LSR may choose to terminate an LDP session with a peer at any time. Should it choose to do so, it informs the peer with a Shutdown message.
LSRはいつでもピアとのLDPセッションを終了することもできます。それはそうすることを選択する必要があり、それは、シャットダウンメッセージを持つピアに通知します。
The MPLS architecture [RF3031] allows an LSR to distribute a FEC label binding in response to an explicit request from another LSR. This is known as Downstream On Demand label distribution. It also allows an LSR to distribute label bindings to LSRs that have not explicitly requested them. [RFC3031] calls this method of label distribution Unsolicited Downstream; this document uses the term Downstream Unsolicited.
MPLSアーキテクチャ[RF3031]はLSRが別のLSRからの明示的な要求に応じて、結合FECラベルを配布することを可能にします。これは、オンデマンドラベル配布上のダウンストリームとして知られています。また、LSRは明示的に要求していないのLSRにラベルバインディングを配布することができます。 [RFC3031]は下流迷惑ラベル配布のこのメソッドを呼び出します。この文書では、ダウンストリーム迷惑用語を使用しています。
Both of these label distribution techniques may be used in the same network at the same time. However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. See Section "Downstream on Demand label Advertisement".
これらのラベル配布技術の両方が同時に同じネットワークで使用することができます。しかし、任意の所与のLDPセッションのために、各LSRは、下流迷惑ラベル配布を使用して一方のピアは、そのピアもあると想定状況を回避するために、そのピアによって使用されるラベル配布方法を知っていなければなりません。 「オンデマンドラベル広告のダウンストリーム」のセクションを参照してください。
The behavior of the initial setup of LSPs is determined by whether the LSR is operating with independent or ordered LSP control. An LSR may support both types of control as a configurable option.
LSPの初期設定の動作は、LSRが独立したり注文したLSPの制御で動作しているかどうかによって決定されます。 LSRは、設定可能なオプションとして、コントロールの両方のタイプをサポートすることができます。
When using independent LSP control, each LSR may advertise label mappings to its neighbors at any time it desires. For example, when operating in independent Downstream on Demand mode, an LSR may answer requests for label mappings immediately, without waiting for a label mapping from the next hop. When operating in independent Downstream Unsolicited mode, an LSR may advertise a label mapping for a FEC to its neighbors whenever it is prepared to label-switch that FEC.
独立したLSPコントロールを使用する場合は、各LSRは、それが望む任意の時点でその隣にラベルマッピングを広告することがあります。デマンドモードに独立したダウンストリームで動作している場合たとえば、LSRは次のホップからのラベルマッピングを待たずに、すぐにラベルマッピングの要求に答えることがあります。独立したダウンストリーム迷惑モードで動作している場合、FECことをスイッチにラベルを付けるために用意されたときに、LSRは隣人にFECのためのラベルマッピングを広告します。
A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.
独立モードを使用することの結果は、下流のラベルが受信される前に、上流のラベルをアドバタイズすることができることです。
When using LSP ordered control, an LSR may initiate the transmission of a label mapping only for a FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. For each FEC for which the LSR is not the egress and no mapping exists, the LSR MUST wait until a label from a downstream LSR is received before mapping the FEC and passing corresponding labels to upstream LSRs. An LSR may be an egress for some FECs and a non-egress for others. An LSR may act as an egress LSR, with respect to a particular FEC, under any of the following conditions:
LSPは、制御を注文使用する場合、LSRは、それがFECネクストホップのラベルマッピングを有する、またはそのためのLSRが出力されたFECのためのラベルマッピングの送信を開始することができます。下流LSRからラベルをFECをマッピングし、上流のLSRに対応するラベルを渡す前に受信されるまでLSRが出力されず、マッピングが存在しないため、各FECのために、LSR待たなければなりません。 LSRは、他人のためのいくつかのFECおよび非出口用の出口であってもよいです。 LSRは、以下のいずれかの条件の下で、特定のFECに対して、出口LSRとして作用することができます。
1. The FEC refers to the LSR itself (including one of its directly attached interfaces).
1. FECは、（その直接結合インターフェースのいずれかを含む）LSR自体を指します。
2. The next hop router for the FEC is outside of the Label Switching Network.
2. FECのネクストホップルータは、ネットワークのラベルスイッチングの外にあります。
3. FEC elements are reachable by crossing a routing domain boundary, such as another area for OSPF summary networks, or another autonomous system for OSPF AS externals and BGP routes [RFC2328] [RFC1771].
3. FEC要素は、OSPFサマリーネットワークの別の領域、または外観およびBGPルートとしてOSPFのための別の自律システム[RFC2328]、[RFC1771]のように、ルーティングドメインの境界を横断することによって到達可能です。
Note that whether an LSR is an egress for a given FEC may change over time, depending on the state of the network and LSR configuration settings.
LSRであるか否かを与えられたFECのための出口は、ネットワークおよびLSRの構成設定の状態に応じて、時間とともに変化してもよいことに留意されたいです。
The MPLS architecture [RFC3031] introduces the notion of label retention mode which specifies whether an LSR maintains a label binding for a FEC learned from a neighbor that is not its next hop for the FEC.
MPLSアーキテクチャ[RFC3031]はLSRがFECはFECのための次のホップではない隣人から学んに対するラベルバインディングを維持するかどうかを指定するラベル保持モードの概念を導入しています。
In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all peer LSRs. When using conservative label retention, advertised label mappings are retained only if they will be used to forward packets (i.e., if they are received from a valid next hop according to routing). If operating in Downstream on Demand mode, an LSR will request label mappings only from the next hop LSR according to routing. Since Downstream on Demand mode is primarily used when label conservation is desired (e.g., an ATM switch with limited cross connect space), it is typically used with the conservative label retention mode.
下流迷惑広告モードでは、すべてのルートのためのラベルマッピング広告は、すべてのピアのLSRから受信することができます。保守的なラベル保持を使用する場合、彼らはパケットを転送するために使用される場合、アドバタイズされたラベルマッピングは、保持されている（すなわち、それらはルーティングに係る有効な次のホップから受信された場合）。デマンドモードにダウンストリームで動作している場合、LSRは、ルーティングに応じてのみ次のホップLSRからラベルマッピングを要求します。ラベル保護が所望される場合デマンドモードでダウンストリームを主に使用されているので（例えば、限定された交差を有するATMスイッチは空間を接続する）、それは、典型的には保守的なラベル保持モードで使用されています。
The main advantage of the conservative mode is that only the labels that are required for the forwarding of data are allocated and maintained. This is particularly important in LSRs where the label space is inherently limited, such as in an ATM switch. A disadvantage of the conservative mode is that if routing changes the next hop for a given destination, a new label must be obtained from the new next hop before labeled packets can be forwarded.
保守的なモードの主な利点は、データの転送に必要とされるだけのラベルが割り当てられ、維持されることです。これは、ATMスイッチのようにラベルスペースが本質的に限られているのLSR、特に重要です。保守的なモードの欠点は、ルーティングは、与えられた宛先に対する次ホップを変更した場合、標識パケットが転送される前に、新しいラベルが新しいネクストホップから得なければならないことです。
In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using liberal label retention, every label mappings received from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping. When operating in Downstream on Demand mode with liberal label retention, an LSR might choose to request label mappings for all known prefixes from all peer LSRs. Note, however, that Downstream on Demand mode is typically used by devices such as ATM switch-based LSRs for which the conservative approach is recommended.
下流迷惑広告モードでは、すべてのルートのためのラベルマッピング広告は、すべてのLDPピアから受信することができます。リベラルラベル保持を使用する場合は、ピアLSRから受信したすべてのラベルのマッピングは関係なく、LSRが広告を出してマッピングのための次のホップであるかどうかの保持されています。リベラルラベル保持してデマンドモードにダウンストリームで動作している場合、LSRは、すべてのピアのLSRからすべての既知のプレフィクスのラベルマッピングを要求することもできます。デマンドモードのダウンストリームは、典型的には、保守的なアプローチが推奨されるATMスイッチベースのLSRのようなデバイスで使用されていること、しかし、注意してください。
The main advantage of the liberal label retention mode is that reaction to routing changes can be quick because labels already exist. The main disadvantage of the liberal mode is that unneeded label mappings are distributed and maintained.
リベラルラベル保持モードの主な利点は、ラベルがすでに存在しているため、ルーティングの変更への反応は迅速にできることです。リベラルモードの主な欠点は、不要なラベルマッピングが分散して保持されることです。
Each interface on an LSR is configured to operate in either Downstream Unsolicited or Downstream on Demand advertisement mode. LSRs exchange advertisement modes during initialization. The major difference between Downstream Unsolicited and Downstream on Demand modes is in which LSR takes responsibility for initiating mapping requests and mapping advertisements.
LSRの各インターフェイスは、オンデマンド広告モードにダウンストリーム迷惑または下流のいずれかで動作するように設定されています。 LSRは、初期化時に広告モードを交換します。デマンドモードのダウンストリーム迷惑と川下の主な違いは、LSRはマッピング要求とマッピング広告を開始するための責任をとるです。
An LSR maintains learned labels in a Label Information Base (LIB). When operating in Downstream Unsolicited mode, the LIB entry for an address prefix associates a collection of (LDP Identifier, label) pairs with the prefix, one such pair for each peer advertising a label for the prefix.
LSRは、ラベル情報ベース（LIB）で学んだラベルを維持しています。下流迷惑モードで動作しているとき、アドレスプレフィックスのLIBエントリーが（LDP識別子、ラベル）接頭辞と対の集合を関連付け、プレフィックスのラベルを広告各ピアに対して1つのそのようなペア。
When the next hop for a prefix changes the LSR must retrieve the label advertised by the new next hop from the LIB for use in forwarding. To retrieve the label the LSR must be able to map the next hop address for the prefix to an LDP Identifier.
プレフィックスの次のホップが変化したときLSRは、転送用のLIBから新しい次のホップによってアドバタイズラベルを取得する必要があります。ラベルを取得するにはLSRはLDP識別子の接頭辞のためのネクストホップアドレスをマッピングすることができなければなりません。
Similarly, when the LSR learns a label for a prefix from an LDP peer, it must be able to determine whether that peer is currently a next hop for the prefix to determine whether it needs to start using the newly learned label when forwarding packets that match the prefix. To make that decision the LSR must be able to map an LDP Identifier to the peer's addresses to check whether any are a next hop for the prefix.
LSRは、LDPピアからプレフィックスのラベルを学習するとき同様に、そのピアが一致するパケットを転送するときに、新たに学習したラベルを使用して開始する必要があるかどうかを決定するために現在プレフィックスの次のホップであるかどうかを決定することができなければなりません接頭辞。その決定を行うためにLSRは、任意のプレフィックスの次のホップであるかどうかを確認するために、ピアのアドレスにLDP識別子をマッピングすることができなければなりません。
To enable LSRs to map between a peer LDP identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages.
ピアLDP識別子とピアのアドレス間のマッピングするためのLSRを有効にするには、のLSRは、LDPアドレスを使用して、それらのアドレスを宣伝し、アドレスメッセージを撤回します。
An LSR sends an Address message to advertise its addresses to a peer. An LSR sends a Withdraw Address message to withdraw previously advertised addresses from a peer
LSRがピアにそのアドレスをアドバタイズするアドレスメッセージを送信します。 LSRがピアから以前に広告を出してアドレスを撤回する引き出しアドレスメッセージを送信します
Loop detection is a configurable option which provides a mechanism for finding looping LSPs and for preventing Label Request messages from looping in the presence of non-merge capable LSRs.
ループ検出はループLSPを見つけるための非マージ可能なのLSRの存在下で、ループからラベル要求メッセージを防止するための機構を提供する構成可能なオプションです。
The mechanism makes use of Path Vector and Hop Count TLVs carried by Label Request and Label Mapping messages. It builds on the following basic properties of these TLVs:
メカニズムは、Vectorやホップがラベル要求とラベルマッピングメッセージによって運ばTLVをカウントパスを利用します。これは、これらのTLVの次の基本的な性質に基づいています：
- A Path Vector TLV contains a list of the LSRs that its containing message has traversed. An LSR is identified in a Path Vector list by its unique LSR Identifier (Id), which is the first four octets of its LDP Identifier. When an LSR propagates a message containing a Path Vector TLV it adds its LSR Id to the Path Vector list. An LSR that receives a message with a Path Vector that contains its LSR Id detects that the message has traversed a loop. LDP supports the notion of a maximum allowable Path Vector length; an LSR that detects a Path Vector has reached the maximum length behaves as if the containing message has traversed a loop.
- パスベクトルTLVは、その含むメッセージを横断したのLSRのリストが含まれています。 LSRは、そのLDP識別子の最初の4つのオクテットである独自のLSR識別子（ID）によってパスベクトルリストにおいて識別されます。 LSRは、パスベクトルTLVを含むメッセージを伝播するとき、それはパスベクタリストにそのLSR IDを追加します。そのLSR Idはメッセージがループを通過したことを検出含むPath Vectorを使ってメッセージを受け取るLSR。自民党は、最大許容パスベクタ長の概念をサポートしています。パスベクトルを検出するLSRは含むメッセージがループを通過したかのように最大長の動作に達しました。
- A Hop Count TLV contains a count of the LSRS that the containing message has traversed. When an LSR propagates a message containing a Hop Count TLV it increments the count. An LSR that detects a Hop Count has reached a configured maximum value behaves as if the containing message has traversed a loop. By convention a count of 0 is interpreted to mean the hop count is unknown. Incrementing an unknown hop count value results in an unknown hop count value (0).
- ホップカウントTLVは含むメッセージが横断していることをLSRSのカウントが含まれています。 LSRはホップカウントTLVを含むメッセージを伝播するとき、それはカウントをインクリメント。ホップカウントを検出するLSRは含むメッセージがループを通過したかのように設定された最大値の動作に達しました。慣例により0のカウントはホップ数が不明であるという意味に解釈されます。未知のホップカウント値（0）で、未知のホップカウント値の結果をインクリメントします。
The following paragraphs describes LDP loop detection procedures. For these paragraphs, and only these paragraphs, "MUST" is redefined to mean "MUST if configured for loop detection". The paragraphs specify messages that must carry Path Vector and Hop Count TLVs. Note that the Hop Count TLV and its procedures are used without the Path Vector TLV in situations when loop detection is not configured (see [RFC3035] and [RFC3034]).
次の段落では、LDPループ検出手順を説明します。これらの段落、及びこれらのみのパラグラフについては、「ループ検出用に設定されている場合MUST」を意味するように再定義された「MUST」。段落は、TLVをカウントパスベクトルとホップを運ばなければならないメッセージを指定します。ホップ（[RFC3035]及び[RFC3034]を参照）TLVをカウントし、その手順はループ検出が構成されていない状況でパスベクトルTLVなしで使用されることに留意されたいです。
The use of the Path Vector TLV and Hop Count TLV prevent Label Request messages from looping in environments that include non-merge capable LSRs.
パスベクトルTLVとホップの使用は、TLVが非マージできるのLSRを含む環境でのループからラベル要求メッセージが表示されないカウント。
The rules that govern use of the Hop Count TLV in Label Request messages by LSR R when Loop Detection is enabled are the following:
ループ検出が有効になっているときLSR Rによってラベル要求メッセージにTLVをカウントホップの使用を管理する規則は次のとおりです。
- The Label Request message MUST include a Hop Count TLV.
- ラベル要求メッセージは、ホップカウントTLVを含まなければなりません。
- If R is sending the Label Request because it is a FEC ingress, it MUST include a Hop Count TLV with hop count value 1.
- それはFECの入口であるため、Rは、ラベル要求を送信している場合は、ホップカウント値1を持つホップカウントTLVを含まなければなりません。
- If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, and if the received Label Request contains a Hop Count TLV, R MUST increment the received hop count value by 1 and MUST pass the resulting value in a Hop Count TLV to its next hop along with the Label Request message;
- Rは、上流LSRからラベル要求を受信した結果としてのラベル要求を送信し、受信したラベル要求がホップTLVカウント含まれている場合、R 1によって受信されたホップカウント値をインクリメントしなければならないし、得られた値を渡す必要がある場合ホップにラベル要求メッセージと一緒にその次のホップにTLVを数えます。
The rules that govern use of the Path Vector TLV in Label Request messages by LSR R when Loop Detection is enabled are the following:
ループ検出が有効になっているときLSR Rによってラベル要求メッセージ内のパスベクトルTLVの使用を管理する規則は、次のとおりです。
- If R is sending the Label Request because it is a FEC ingress, then if R is non-merge capable, it MUST include a Path Vector TLV of length 1 containing its own LSR Id.
- それはFEC入力であるため、Rは、ラベル要求を送信している場合はRである場合、可能な非マージ、それ自身のLSR IDを含む長さ1のパスベクトルTLVを含まなければなりません。
- If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, then if the received Label Request contains a Path Vector TLV or if R is non-merge capable:
- R上流LSRからラベル要求を受信した結果として、ラベル要求を送信している場合、受信したラベルリクエストパスベクトルTLVが含まれている場合、またはRである場合、可能な非マージ：
R MUST add its own LSR Id to the Path Vector, and MUST pass the
resulting Path Vector to its next hop along with the Label
Request message. If the Label Request contains no Path Vector
TLV, R MUST include a Path Vector TLV of length 1 containing
its own LSR Id.
Note that if R receives a Label Request message for a particular FEC, and R has previously sent a Label Request message for that FEC to its next hop and has not yet received a reply, and if R intends to merge the newly received Label Request with the existing outstanding Label Request, then R does not propagate the Label Request to the next hop.
注R特定のFECのためにラベル要求メッセージを受信し、そしてRは以前に、その次のホップへのFECのためにラベル要求メッセージを送信し、まだ応答を受信しなかった場合、およびそのRが有する新たに受信したラベル要求をマージしようとする場合既存の優れたラベル要求、そしてRは、次のホップにラベル要求を伝播しません。
If R receives a Label Request message from its next hop with a Hop Count TLV which exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or which exceeds the maximum allowable length, then R detects that the Label Request message has traveled in a loop.
Rが設定された最大値を超えている、またはパスベクトルTLVが最大許容長を超えて独自のLSR IDまたは含有するホップカウントTLVとその次のホップからのラベル要求メッセージを受信した場合、次いでRは、ラベル要求メッセージことを検出しますループの中で旅してきました。
When R detects a loop, it MUST send a Loop Detected Notification message to the source of the Label Request message and drop the Label Request message.
Rは、ループを検出すると、ラベル要求メッセージの送信元にループ検出通知メッセージを送信し、ラベル要求メッセージをドロップしなければなりません。
The use of the Path Vector TLV and Hop Count TLV in the Label Mapping message provide a mechanism to find and terminate looping LSPs. When an LSR receives a Label Mapping message from a next hop, the message is propagated upstream as specified below until an ingress LSR is reached or a loop is found.
ベクトルTLVとホップは、ラベルマッピングメッセージにTLVをカウントパスの使用が見つけ、ループLSPを終了させるメカニズムを提供します。 LSRは、次のホップからLabel Mappingメッセージを受信したときに入口LSRに到達するまで、下記に指定またはループが発見されたように、メッセージが上流に伝播されます。
The rules that govern the use of the Hop Count TLV in Label Mapping messages sent by an LSR R when Loop Detection is enabled are the following:
ループ検出が有効になっているときLSR Rによって送られたラベルマッピングメッセージにTLVをカウントホップの使用を管理する規則は次のとおりです。
- R MUST include a Hop Count TLV.
- Rは、ホップカウントTLVを含まなければなりません。
- If R is the egress, the hop count value MUST be 1.
- Rが出ている場合は、ホップカウント値は1でなければなりません。
- If the Label Mapping message is being sent to propagate a Label Mapping message received from the next hop to an upstream peer, the hop count value MUST be determined as follows:
- Label Mappingメッセージが上流のピアに次のホップから受信したLabel Mappingメッセージを伝播するために送信される場合、以下のように、ホップカウント値が決定されなければなりません。
o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame Relay LSR domain) and the upstream peer is within that domain, R MUST reset the hop count to 1 before propagating the message.
Rは、LSRの「TTL-減少」を実行しないLSRドメインの辺集合のメンバである場合、O（例えば、ATM LSRドメインまたはフレームリレーLSRドメイン）、および上流のピアがそのドメイン内では、Rはリセットする必要がありますメッセージを伝播する前に、1へのホップカウント。
o Otherwise, R MUST increment the hop count received from the next hop before propagating the message.
Oそれ以外の場合、Rは、メッセージを伝播する前に、次のホップから受信したホップカウントをインクリメントしなければなりません。
- If the Label Mapping message is not being sent to propagate a Label Mapping message, the hop count value MUST be the result of incrementing R's current knowledge of the hop count learned from previous Label Mapping messages. Note that this hop count value will be unknown if R has not received a Label Mapping message from the next hop.
- ラベルマッピングメッセージがラベルマッピングメッセージを伝播するために送信されていない場合は、ホップカウント値は、前のラベルマッピングメッセージから学んだホップ数のRの現在の知識をインクリメントした結果でなければなりません。 Rは、次のホップからのラベルマッピングメッセージを受信していない場合、このホップカウント値が不明になることに注意してください。
Any Label Mapping message MAY contain a Path Vector TLV. The rules that govern the mandatory use of the Path Vector TLV in Label Mapping messages sent by LSR R when Loop Detection is enabled are the following:
任意のラベルマッピングメッセージは、パスベクトルTLVを含むかもしれません。ループ検出が有効になっているときLSR Rによって送られたラベルマッピングメッセージにパスベクトルTLVの義務的な使用を管理する規則は次のとおりです。
- If R is the egress, the Label Mapping message need not include a Path Vector TLV.
- Rは出口がある場合は、ラベルマッピングメッセージは、パスベクトルTLVを含む必要はありません。
- If R is sending the Label Mapping message to propagate a Label Mapping message received from the next hop to an upstream peer, then: o If R is merge capable and if R has not previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV.
- RがLabel Mappingメッセージを伝播するLabel Mappingメッセージを送信している場合、上流のピアにネクストホップから受信した：Rである場合、Rは先に、次いで、上流のピアにLabel Mappingメッセージを送信していない場合に可能なマージおよびoそれはパスベクトルTLVを含まなければなりません。
o If the received message contains an unknown hop count, then R MUST include a Path Vector TLV.
受信したメッセージが、未知のホップカウントが含まれている場合は、O、そしてRは、パスベクトルTLVを含まなければなりません。
o If R has previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV if the received message reports an LSP hop count increase, a change in hop count from unknown to known, or a change from known to unknown.
Rは以前に上流のピアにラベルマッピングメッセージを送信した場合、受信したメッセージは、LSPホップ数の増加、既知、未知からのホップ数の変化、またはに知られてからの変化を報告した場合、O、それはパスベクトルTLVを含まなければなりません未知の。
If the above rules require R include a Path Vector TLV in the Label Mapping message, R computes it as follows:
上記の規則は、Rは、Label MappingメッセージにパスベクトルTLVを含める必要がある場合、以下のように、Rはそれを計算します。
o If the received Label Mapping message included a Path Vector, the Path Vector sent upstream MUST be the result of adding R's LSR Id to the received Path Vector.
受信したラベルマッピングメッセージは、パスベクトルが含まれている場合、O、ベクターは、上流送信パスが受信パスベクトルにRのLSR IDを付加した結果でなければなりません。
o If the received message had no Path Vector, the Path Vector sent upstream MUST be a path vector of length 1 containing R's LSR Id.
受信したメッセージがないパスベクトルを有していなかった場合は、O、ベクターは、上流送信パス長1を含むRのLSR Idのパスベクトルでなければなりません。
- If the Label Mapping message is not being sent to propagate a received message upstream, the Label Mapping message MUST include a Path Vector of length 1 containing R's LSR Id.
- Label Mappingメッセージを上流の受信したメッセージを伝播するために送信されていない場合、Label Mappingメッセージは、経路長1を含むRのLSR Idのベクトルを含まなければなりません。
If R receives a Label Mapping message from its next hop with a Hop Count TLV which exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or which exceeds the maximum allowable length, then R detects that the corresponding LSP contains a loop.
Rが設定された最大値を超えている、またはパスベクトルTLVが最大許容長を超えて独自のLSR IDまたは含有するホップカウントTLVとその次のホップからLabel Mappingメッセージを受信した場合、次いでRは、対応するLSPが含まれていることを検出しますループ。
When R detects a loop, it MUST stop using the label for forwarding, drop the Label Mapping message, and signal Loop Detected status to the source of the Label Mapping message.
Rがループを検出した場合、それは、転送のためにラベルを使用して停止Label Mappingメッセージをドロップし、Label Mappingメッセージの送信元にループ検出ステータスを通知しなければなりません。
If loop detection is desired in an MPLS domain, then it should be turned on in ALL LSRs within that MPLS domain, else loop detection will not operate properly and may result in undetected loops or in falsely detected loops.
ループ検出がMPLSドメインに所望される場合、それは、そのMPLSドメイン内のすべてのLSRにオンされるべきであり、正常に動作しないであろうと未検出ループまたは誤って生じ得る他のループ検出は、ループを検出しました。
LSRs which are configured for loop detection are NOT expected to store the path vectors as part of the LSP state.
ループ検出のために構成されているのLSRは、LSPの状態の一部として、パスベクトルを格納しないと予想されます。
Note that in a network where only non-merge capable LSRs are present, Path Vectors are passed downstream from ingress to egress, and are not passed upstream. Even when merge is supported, Path Vectors need not be passed upstream along an LSP which is known to reach the egress. When an LSR experiences a change of next hop, it need pass Path Vectors upstream only when it cannot tell from the hop count that the change of next hop does not result in a loop.
唯一の非マージ可能なのLSRが存在するネットワークにおいて、パスベクトルが入口から出口に下流渡され、上流渡されない場合ことに注意してください。マージがサポートされている場合でも、パスのベクターは、出口に到達することが知られているLSPに沿って上流に渡す必要はありません。 LSRは次のホップの変更を経験するとき、それは次のホップの変更がループにならないホップ数から言うことができないときにのみ、それは上流のパスベクトルを渡す必要が。
In the case of ordered label distribution, Label Mapping messages are propagated from egress toward ingress, naturally creating the Path Vector along the way. In the case of independent label distribution, an LSR may originate a Label Mapping message for an FEC before receiving a Label Mapping message from its downstream peer for that FEC. In this case, the subsequent Label Mapping message for the FEC received from the downstream peer is treated as an update to LSP attributes, and the Label Mapping message must be propagated upstream. Thus, it is recommended that loop detection be configured in conjunction with ordered label distribution, to minimize the number of Label Mapping update messages.
注文したラベル配布の場合は、ラベルマッピングメッセージは自然に道に沿ってパスのベクトルを作成し、入口に向かって出口から伝播されています。独立ラベル配布の場合、LSRはそのFECのためにその下流ピアからLabel Mappingメッセージを受信する前にFECのラベルマッピングメッセージを発信することができます。この場合には、FECのための後続のLabel Mappingメッセージは、LSPの更新属性、およびLabel Mappingメッセージが上流に伝播されなければならないとして扱われる下流ピアから受信しました。したがって、ラベルマッピング更新メッセージの数を最小限にするために、ループ検出を命じたラベル配布と併せて構成することをお勧めします。
This section specifies a mechanism to protect against the introduction of spoofed TCP segments into LDP session connection streams. The use of this mechanism MUST be supported as a configurable option.
このセクションでは、LDPセッション接続ストリームに偽装されたTCPセグメントの導入から保護するメカニズムを指定します。このメカニズムを使用すると、設定可能なオプションとしてサポートしなければなりません。
The mechanism is based on use of the TCP MD5 Signature Option specified in [RFC2385] for use by BGP. See [RFC1321] for a specification of the MD5 hash function.
機構は、BGPで使用するために[RFC2385]で指定されたTCP MD5署名オプションの使用に基づいています。 MD5ハッシュ関数の仕様については、[RFC1321]を参照してください。
The following quotes from [RFC2385] outline the security properties achieved by using the TCP MD5 Signature Option and summarizes its operation:
[RFC2385]から以下の引用はTCP MD5署名オプションを使用することによって達成セキュリティのプロパティの概要を説明し、その動作をまとめたものです。
"IESG Note
「IESG注意
This document describes current existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks."
この文書では、特定のシンプルな攻撃からBGPを確保するため、現在の既存の練習を説明しています。協調攻撃に対するセキュリティ上の弱点を持っていると理解されています。」
"Abstract
"抽象
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP."
このメモは、BGPのセキュリティを強化するためにTCPの拡張機能について説明します。これはMD5 [RFC1321] TCPセグメント内ダイジェストを運ぶための新しいTCPオプションを定義します。このダイジェストは、接続エンドポイントにのみ知られている情報を組み込んで、そのセグメントのための署名のように作用します。 BGPは、そのトランスポートとしてTCPを使用しているため、本論文で述べたように、このオプションを使用すると、大幅にBGP上の特定のセキュリティ攻撃からの危険性を低減します。」
"Introduction
"前書き
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
このオプションの主な動機は、BGP接続ストリームに偽装されたTCPセグメントの導入に対して自身を保護できるようにすることです。特に懸念されるのTCPリセットがあります。
To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords).
このホワイトペーパーで説明する手法を使用して接続を偽装するために、攻撃者は、TCPシーケンス番号を推測しなければならないだけでなく、MD5ダイジェストに含まれるパスワードを取得しなければならなかっただろう。このパスワードは、接続ストリームに表示されたことがない、とパスワードの実際の形はアプリケーション次第です。 （再送がパスワードの変更といくつかのTCP実装に問題となることができますが）それも、あまりにも長い間、この変更は、両端に同期されたように、特定の接続の存続期間中に変更することができます。
Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option."
最後に、接続でこのオプションを使用するための交渉が存在しない、むしろそれは、その接続オプションを使用するかどうかにかかわらず、純粋にサイトポリシーの問題です。」
"MD5 as a Hashing Algorithm
「MD5ハッシュアルゴリズムとして
Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application.
このメモは、最初に（別のタイトルの下）が公表されましたので、MD5アルゴリズムは[ドッブ]衝突サーチ攻撃に対して脆弱であることが判明しており、このタイプの用途のために十分に強いと一部で考えられています。
This memo still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original document did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space.
オプションは、すでに運用配備されている、と同じオプション番号を使用してアップグレードを許可するように定義された「アルゴリズムのタイプ」フィールドがなかったので、このメモはまだ、しかし、MD5アルゴリズムを指定します。元の文書には、あまりにもなり、これは、少なくとももう1つのバイトを必要とするので、タイプフィールドを指定していない、それは（おそらく、TCPの実装では20バイトに水増しされます）完全なオプションの19のバイトを取った時点で感じましたすでに限られたオプション空間の廃棄物の多く。
This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field.
これは、（SHA-1のような）別のハッシュアルゴリズムを使用して、他の同様のオプションの展開を防ぐことはできません。とにかく20バイトに定義されている18バイトのオプションほとんどの実装パッド場合にも、それはアルゴリズムタイプフィールドが含まれている新しいオプションを定義するためだけにもなります。
This would need to be addressed in another document, however."
しかし、これは、別の文書に対処する必要があるだろう。」
End of quotes from [RFC2385].
[RFC2385]からの引用の終わり。
LDP uses the TCP MD5 Signature Option as follows:
次のようにLDPはTCP MD5署名オプションを使用しています。
- Use of the MD5 Signature Option for LDP TCP connections is a configurable LSR option.
- LDP TCP接続のためのMD5署名オプションを使用すると、設定LSRオプションです。
- An LSR that uses the MD5 Signature Option is configured with a password (shared secret) for each potential LDP peer.
- MD5署名オプションを使用するLSRは、各電位LDPピアのパスワード（共有秘密）で構成されています。
- The LSR applies the MD5 algorithm as specified in [RFC2385] to compute the MD5 digest for a TCP segment to be sent to a peer. This computation makes use of the peer password as well as the TCP segment.
- [RFC2385]で指定されるようにLSRは、ピアに送信されるTCPセグメントのためのMD5ダイジェストを計算するためにMD5アルゴリズムを適用します。この計算は、ピア・パスワードの使用だけでなく、TCPセグメントになります。
- When the LSR receives a TCP segment with an MD5 digest, it validates the segment by calculating the MD5 digest (using its own record of the password) and compares the computed digest with the received digest. If the comparison fails, the segment is dropped without any response to the sender.
- LSRは、MD5ダイジェストとTCPセグメントを受信すると、（パスワードの独自のレコードを使用して）MD5ダイジェストを計算することによってセグメントを検証し、計算受信したダイジェストとダイジェストとを比較します。比較が失敗した場合、セグメントは、送信者への応答なしに削除されます。
- The LSR ignores LDP Hellos from any LSR for which a password has not been configured. This ensures that the LSR establishes LDP TCP connections only with LSRs for which a password has been configured.
- LSRはパスワードが設定されていない任意のLSRからLDP helloを無視します。これはLSRが唯一のパスワードが設定されたのLSRとのLDP TCP接続を確立することを保証します。
Traffic Engineering [RFC2702] is expected to be an important MPLS application. MPLS support for Traffic Engineering uses explicitly routed LSPs, which need not follow normally-routed (hop-by-hop) paths as determined by destination-based routing protocols. CR-LDP [CRLDP] defines extensions to LDP to use LDP to set up explicitly routed LSPs.
トラフィックエンジニアリング[RFC2702]は、重要なMPLSアプリケーションであることが予想されます。トラフィックエンジニアリングのためのMPLSサポートは、宛先ベースのルーティングプロトコルによって決定される（ホップバイホップ）通常ルーティング経路をたどる必要はなく、明示的にルーティングされたLSPを使用します。 CRLDPは[CRLDP]明示的にルーティングされたLSPを設定するためにLDPを使用するLDPへの拡張を定義します。
Previous sections that describe LDP operation have discussed scenarios that involve the exchange of messages among LDP peers. This section specifies the message encodings and procedures for processing the messages.
自民党の操作を説明する前のセクションでは、LDPピア間のメッセージの交換を伴うシナリオを検討しています。このセクションでは、メッセージを処理するためのメッセージのエンコーディングと手順を指定します。
LDP message exchanges are accomplished by sending LDP protocol data units (PDUs) over LDP session TCP connections.
LDPメッセージ交換は、LDPセッションのTCP接続でLDPプロトコルデータユニット（PDU）を送信することによって達成されます。
Each LDP PDU can carry one or more LDP messages. Note that the messages in an LDP PDU need not be related to one another. For example, a single PDU could carry a message advertising FEC-label bindings for several FECs, another message requesting label bindings for several other FECs, and a third notification message signaling some event.
各LDP PDUは、一つ以上のLDPメッセージを運ぶことができます。 LDP PDU内のメッセージは、互いに関連する必要はないことに注意してください。例えば、単一のPDUは、いくつかのFECのためのFECラベルバインディングを広告メッセージ、他のいくつかのFECのラベルバインディング、およびいくつかのイベントをシグナリングする第三の通知メッセージを要求する別のメッセージを運ぶことができます。
Each LDP PDU is an LDP header followed by one or more LDP messages. The LDP header is:
各LDP PDUは、一つ以上のLDPメッセージが続くLDPヘッダです。 LDPヘッダがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1.
プロトコルのバージョン番号を含むバージョン2つのオクテットの符号なし整数。仕様のこのバージョンは、LDPプロトコルバージョン1を指定します。
PDU Length Two octet integer specifying the total length of this PDU in octets, excluding the Version and PDU Length fields.
バージョンとPDU長さフィールドを除いオクテットでこのPDUの全長を、特定PDU長さ2オクテットの整数。
The maximum allowable PDU Length is negotiable when an LDP session is initialized. Prior to completion of the negotiation the maximum allowable length is 4096 bytes.
LDPセッションが初期化されたときの最大許容PDUの長さは交渉です。事前交渉が完了するまでの最大許容長は4096バイトです。
LDP Identifier Six octet field that uniquely identifies the label space of the sending LSR for which this PDU applies. The first four octets identify the LSR and must be a globally unique value. It should be a 32-bit router Id assigned to the LSR and also used to identify it in loop detection Path Vectors. The last two octets identify a label space within the LSR. For a platform-wide label space, these should both be zero.
LDP識別子六一意にこのPDUが適用される送信LSRのラベルスペースを識別オクテットフィールド。最初の4つのオクテットはLSRを識別し、グローバルに一意の値でなければなりません。これはLSRに割り当てられ、また、ループ検出経路ベクターでそれを識別するために使用される32ビットのルータIDであるべきです。最後の2つのオクテットはLSR内のラベルスペースを識別します。プラットフォーム全体のラベルスペースのために、これらは両方ともゼロである必要があります。
Note that there is no alignment requirement for the first octet of an LDP PDU.
LDP PDUの最初のオクテットのための位置合わせ要件が存在しないことに留意されたいです。
LDP defines messages, TLVs and procedures in the following areas:
自民党は、次の分野でのメッセージ、のTLVと手順を定義しています。
- Peer discovery;
- Session management;
- Label distribution;
- Notification of errors and advisory information.
The sections that follow describe the message and TLV encodings for these areas and the procedures that apply to them.
以下のセクションでは、これらの領域とそれらに適用手続きのためのメッセージとTLVエンコーディングを記述する。
The label distribution procedures are complex and are difficult to describe fully, coherently and unambiguously as a collection of separate message and TLV specifications.
ラベル分配手順が複雑であり、コヒーレントと明確別々のメッセージとTLVの仕様の集合として、完全に記述するのが困難です。
Appendix A, "LDP Label Distribution Procedures", describes the label distribution procedures in terms of label distribution events that may occur at an LSR and how the LSR must respond. Appendix A is the specification of LDP label distribution procedures. If a procedure described elsewhere in this document conflicts with Appendix A, Appendix A specifies LDP behavior.
付録A、「LDPラベル配布手順は、」、LSR、どのようにLSRが応答しなければならない時に発生する可能性があり、ラベル配布イベントの観点からラベル配布手順について説明します。付録Aは、LDPラベル配布手順の仕様です。手順は付録Aで、この文書の競合の他の箇所に記載する場合は、付録Aには、LDPの動作を指定します。
LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages.
LDPは、LDPメッセージで搬送される情報の多くを符号化するタイプレングス値（TLV）符号化方式を使用します。
An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length Field, followed by a variable length Value field.
LDP TLVは、LSRは可変長Valueフィールドに続く2オクテットの長さフィールドに続くタイプを認識しないときの動作を指定するタイプとの2ビットを指定する14ビットを使用する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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist. The sections following that define TLVs specify a value for the U-bit.
Uは不明TLVビットビット。 Uがクリアされている場合、未知のTLVを受信すると、（= 0）、通知メッセージの発信元に戻さなければならず、全体のメッセージが無視されなければなりません。 Uが設定されている場合（= 1）、未知のTLVは無視され、未知のTLVが存在しなかったかのようにメッセージの残りの部分が処理されます。すなわちTLVを定義する以下のセクションでは、Uビットの値を指定します。
F bit Forward unknown TLV bit. This bit applies only when the U bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message. The sections following that define TLVs specify a value for the F-bit.
Fビットフォワード未知のTLVビット。このビットは、Uビットが設定されている場合にのみ適用され、未知のTLVを含むLDPメッセージが転送されます。 Fがクリアされている場合（= 0）、未知のTLVを含むメッセージで転送されません。 Fが設定されている場合（= 1）、未知のTLVを含むメッセージで転送されます。すなわちTLVを定義する以下のセクションでは、Fビットの値を指定します。
Type Encodes how the Value field is to be interpreted.
タイプは、Valueフィールドがどのように解釈されるかエンコードします。
Length Specifies the length of the Value field in octets.
長さはオクテット単位で値フィールドの長さを指定します。
Value Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
Typeフィールドによって指定されるように解釈されるべき情報を符号化長さオクテットの値オクテットストリング。
Note that there is no alignment requirement for the first octet of a TLV.
TLVの最初のオクテットのための位置合わせ要件が存在しないことに留意されたいです。
Note that the Value field itself may contain TLV encodings. That is, TLVs may be nested.
Valueフィールド自体がTLVエンコーディングを含むことができることに注意してください。つまり、TLVが入れ子にすることができます。
The TLV encoding scheme is very general. In principle, everything appearing in an LDP PDU could be encoded as a TLV. This specification does not use the TLV scheme to its full generality. It is not used where its generality is unnecessary and its use would waste space unnecessarily. These are usually places where the type of a value to be encoded is known, for example by its position in a message or an enclosing TLV, and the length of the value is fixed or readily derivable from the value encoding itself.
TLV符号化方式は、非常に一般的です。原則として、LDP PDUに登場するすべてのものは、TLVとして符号化することができます。この仕様は、その完全な一般性にTLVスキームを使用していません。その普遍性は不要であり、その使用が不必要にスペースを無駄にする場所には使用しません。これらは、通常、値の種類は、そのメッセージ内の位置又は封入TLVにより、例えば、知られている符号化する場所であり、値の長さは、固定または容易に値をコード自体から誘導されます。
Some of the TLVs defined for LDP are similar to one another. For example, there is a Generic Label TLV, an ATM Label TLV, and a Frame Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and "Frame Relay TLV".
LDPのために定義されたTLVの一部は、互いに類似しています。例えば、一般的なラベルTLV、ATMラベルTLV、およびフレームリレーTLVがあります。セクション「ジェネリックラベルTLV」、「ATMのラベルTLV」、および「フレームリレーTLV」を参照してください。
While it is possible to think about TLVs related in this way in terms of a TLV type that specifies a TLV class and a TLV subtype that specifies a particular kind of TLV within that class, this specification does not formalize the notion of a TLV subtype.
それはTLVクラスとそのクラス内のTLVの特定の種類を指定するTLVサブタイプを指定するTLVタイプの面で、このように関連するのTLVを考えることは可能ですが、この仕様はTLVサブタイプの概念を形式化しません。
The specification assigns type values for related TLVs, such as the label TLVs, from a contiguous block in the 16-bit TLV type number space.
仕様は、16ビットのTLVタイプ番号空間内の連続したブロックから、そのようなラベルのTLVのような関連のTLVのタイプの値を割り当てます。
Section "TLV Summary" lists the TLVs defined in this version of the protocol and the section in this document that describes each.
セクション「TLVの概要は、」プロトコルのこのバージョンとそれぞれの説明このドキュメントのセクションで定義されたTLVを示しています。
There are several parameters used by more than one LDP message. The TLV encodings for these commonly used parameters are specified in this section.
複数のLDPメッセージで使用されるいくつかのパラメータがあります。これらの一般的に使用されるパラメータのためのTLVエンコーディングは、このセクションで指定されています。
Labels are bound to Forwarding Equivalence Classes (FECs). A FEC is a list of one or more FEC elements. The FEC TLV encodes FEC items.
ラベルは、転送等価クラス（FEC）に結合しています。 FECは、一つ以上のFEC要素のリストです。 FEC TLVはFECの項目を符号化します。
Its encoding is:
そのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element 1 to FEC Element n There are several types of FEC elements; see Section "FECs". The FEC element encoding depends on the type of FEC element.
FEC要素にFEC要素1からn FEC要素のいくつかの種類があります。セクション「のFEC」を参照してください。 FEC要素の符号化は、FEC要素の種類に依存します。
A FEC Element value is encoded as a 1 octet field that specifies the element type, and a variable length field that is the type-dependent element value. Note that while the representation of the FEC element value is type-dependent, the FEC element encoding itself is one where standard LDP TLV encoding is not used.
FEC要素の値は、要素のタイプを指定する1つのオクテットフィールド、及び種類に依存する要素の値である可変長フィールドとして符号化されます。 FEC要素値の表現がタイプ依存であるが、それ自体をコードFEC要素は、標準LDP TLVエンコーディングが使用されていないものであることに留意されたいです。
The FEC Element value encoding is:
FEC要素の値のエンコーディングは以下のとおりです。
FEC Element Type Value type name
FEC要素タイプ値のタイプ名
Wildcard 0x01 No value; i.e., 0 value octets; see below. Prefix 0x02 See below. Host Address 0x03 Full host address; see below.
ノー値0x01のワイルドカード。すなわち、0値オクテット。下記参照。プレフィックスは、以下を参照してください0X02。ホストアドレス0x03の完全なホストアドレス。下記参照。
Note that this version of LDP supports the use of multiple FEC Elements per FEC for the Label Mapping message only. The use of multiple FEC Elements in other messages is not permitted in this version, and is a subject for future study.
自民党のこのバージョンでは唯一のラベルマッピングメッセージのFECごとに複数のFEC要素の使用をサポートしていることに注意してください。他のメッセージ内の複数のFEC要素の使用は、このバージョンでは許可されており、今後の検討課題であるされていません。
Wildcard FEC Element To be used only in the Label Withdraw and Label Release Messages. Indicates the withdraw/release is to be applied to all FECs associated with the label within the following label TLV. Must be the only FEC Element in the FEC TLV.
ワイルドカードFEC要素はラベルのみに使用するリリース・メッセージを撤回し、ラベルを付けます。撤退/リリースでは、次のラベルTLV内のラベルに関連付けられているすべてのFECに適用されることを示します。 FEC TLVで唯一のFEC要素でなければなりません。
Prefix FEC Element value encoding:
プレフィックスFEC要素の値のエンコード：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field.
Prefixフィールドのアドレスプレフィックスのアドレスファミリーをコード化[RFC1700]でアドレスファミリ番号から値を含むファミリー2オクテット量に対応しています。
PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a prefix that matches all addresses (the default destination); in this case the Prefix itself is zero octets).
次のアドレスプレフィックスのビットの長さを含むPreLen 1つのオクテットの符号なし整数。ゼロの長さは、すべてのアドレス（デフォルトの宛先）と一致プレフィクスを示します。この場合にはプレフィックス自体は）ゼロのオクテットです。
Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary.
プレフィックス長さが、ビット単位、バイト境界にパッド入り、PreLenフィールドで指定されたアドレスファミリフィールド、に従って符号化されたアドレスのプレフィックス。
Host Address FEC Element encoding:
住所FEC要素符号化ホスト：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Addr (3) | Address Family | Host Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Host Addr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field.
Prefixフィールドのアドレスプレフィックスのアドレスファミリーをコード化[RFC1700]でアドレスファミリ番号から値を含むファミリー2オクテット量に対応しています。
Host Addr Len Length of the Host address in octets.
オクテット内のホストアドレスのADDRレンの長さをホストします。
Host Addr An address encoded according to the Address Family field.
アドレスファミリフィールドに従ってエンコードされたアドレスADDRホスト。
If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error.
FEC TLVを復号する際にLSRが、それはサポートしていないアドレスファミリでFEC要素に遭遇した場合、それは、FEC TLVを解読停止TLVを含むメッセージを処理中止し、その自民党に「サポートされていないアドレスファミリー」通知メッセージを送信する必要がありますエラーシグナリングピア。
If it encounters a FEC Element type it cannot decode, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
それはデコードできないFEC要素タイプに遭遇した場合、それは、FEC TLVを復号停止TLVを含むメッセージを処理中止し、エラーをシグナリングそのLDPピアに「不明FEC」通知メッセージを送信しなければなりません。
Label TLVs encode labels. Label TLVs are carried by the messages used to advertise, request, release and withdraw label mappings.
ラベルのTLVはラベルを符号化します。ラベルのTLVは、宣伝要求、解放し、ラベルマッピングを引き出すために使用されるメッセージによって運ばれます。
There are several different kinds of Label TLVs which can appear in situations that require a Label TLV.
ラベルTLVを必要とする状況に表示できるラベルのTLVのいくつかの種類があります。
An LSR uses Generic Label TLVs to encode labels for use on links for which label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet.
LSRは、ラベル値は、基礎となるリンク技術の独立しているため、リンク上で使用するラベルをエンコードするために、汎用ラベルTLVを使用しています。このようなリンクの例には、PPPとイーサネットです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label This is a 20-bit label value as specified in [RFC3032] represented as a 20-bit number in a 4 octet field.
[RFC3032]で指定されるようにこれは、20ビットのラベル値でラベル4オクテットフィールドに20ビットの数として表されます。
An LSR uses ATM Label TLVs to encode labels for use on ATM links.
LSRは、ATMリンク上で使用するためのラベルをエンコードするためにATMのラベルTLVを使用しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
RESこのフィールドは予約されています。これは、送信時にゼロに設定されている必要があり、領収書の上で無視しなければなりません。
V-bits Two-bit switching indicator. If V-bits is 00, both the VPI and VCI are significant. If V-bits is 01, only the VPI field is significant. If V-bit is 10, only the VCI is significant.
Vビット、2ビットのスイッチングインジケータ。 Vビットが00である場合、VPI及びVCIの両方が重要です。 V-ビットが01であれば、唯一のVPIフィールドが重要です。 Vビットが10の場合、唯一のVCIは重要です。
VPI Virtual Path Identifier. If VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
VPI仮想パス識別子。 VPI未満、12ビットである場合、このフィールドに右揃えであるべきであり、先行ビットが0に設定されるべきです。
VCI Virtual Channel Identifier. If the VCI is less than 16- bits, it should be right justified in the field and the preceding bits must be set to 0. If Virtual Path switching is indicated in the V-bits field, then this field must be ignored by the receiver and set to 0 by the sender.
VCI仮想チャネル識別子。 VCIが16ビット未満である場合、それはフィールドで右寄せであるべきであり、仮想パス切り替えがVビットフィールドに示されている場合、先行するビットが0に設定する必要があり、このフィールドは受信機によって無視されなければなりません送信者によって0に設定します。
An LSR uses Frame Relay Label TLVs to encode labels for use on Frame Relay links.
LSRは、フレームリレーリンク上で使用するためのラベルをエンコードするために、フレームリレーラベルTLVを使用しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
RESこのフィールドは予約されています。これは、送信時にゼロに設定されている必要があり、領収書の上で無視しなければなりません。
Len This field specifies the number of bits of the DLCI. The following values are supported:
レンは、このフィールドにはDLCIのビット数を指定します。次の値がサポートされています。
0 = 10 bits DLCI
2 = 23 bits DLCI
Len values 1 and 3 are reserved.
LENは、1と3は予約された値。
DLCI The Data Link Connection Identifier. Refer to [RFC3034] for the label values and formats.
DLCI [データリンク接続識別子。ラベル値とフォーマットのために[RFC3034]を参照してください。
The Address List TLV appears in Address and Address Withdraw messages.
アドレスリストTLVは、アドレスとアドレスメッセージを撤回に表示されます。
Its encoding is:
そのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field.
アドレスフィールドに含まれるアドレスをエンコードする[RFC1700]でアドレスファミリ番号の値を含むファミリー2つのオクテット量に対処します。
Addresses A list of addresses from the specified Address Family. The encoding of the individual addresses depends on the Address Family.
指定されたアドレスファミリからのアドレスのリスト。個々のアドレスのエンコードは、アドレスファミリに依存します。
The following address encodings are defined by this version of the protocol:
以下のアドレスエンコーディングは、プロトコルのこのバージョンで定義されています。
Address Family Address Encoding
アドレスファミリアドレスのエンコード
IPv4 4 octet full IPv4 address IPv6 16 octet full IPv6 address
IPv4の4オクテット完全なIPv4アドレスIPv6の16オクテット完全なIPv6アドレス
The Hop Count TLV appears as an optional field in messages that set up LSPs. It calculates the number of LSR hops along an LSP as the LSP is being setup.
ホップカウントTLVは、LSPを設定し、メッセージ内の任意のフィールドとして表示されます。これは、LSPがセットアップされているようにLSRの数がLSPに沿ってホップ算出します。
Note that setup procedures for LSPs that traverse ATM and Frame Relay links require use of the Hop Count TLV (see [RFC3035] and [RFC3034]).
ATMを横断し、フレームリレーリンクはTLVカウントホップの使用を必要とするLSPのためにその設定手順を注意してください（[RFC3035]と[RFC3034]を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+
HC Value 1 octet unsigned integer hop count value.
HC値1つのオクテットの符号なし整数のホップカウント値。
During setup of an LSP an LSR R may receive a Label Mapping or Label Request message for the LSP that contains the Hop Count TLV. If it does, it should record the hop count value.
LSPのセットアップ中にLSR RはホップTLVカウント含まれているLSPのためのラベルマッピングまたはラベル要求メッセージを受信することができます。それがない場合は、ホップカウント値を記録する必要があります。
If LSR R then propagates the Label Mapping message for the LSP to an upstream peer or the Label Request message to a downstream peer to continue the LSP setup, it must must determine a hop count to include in the propagated message as follows:
LSR R次いでLSPセットアップを継続する下流ピア上流ピアまたはラベル要求メッセージにLSPのラベルマッピングメッセージを伝播する場合、それは次のようにホップ数が伝播メッセージに含めるかを決定しなければならない必要があります。
- If the message is a Label Request message, R must increment the received hop count;
- メッセージは、ラベル要求メッセージである場合、Rは受信ホップカウントをインクリメントする必要があります。
- If the message is a Label Mapping message, R determines the hop count as follows: o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' and the upstream peer is within that domain, R must reset the hop count to 1 before propagating the message.
- メッセージがLabel Mappingメッセージである場合、以下のように、Rはホップカウントを決定する：Rは、LSRの「TTL-減少」と上流のピアを行わないLSRドメインの辺集合のメンバである場合、そのドメイン内にはO 、Rは、メッセージを伝播する前に、1にホップカウントをリセットする必要があります。
o Otherwise, R must increment the received hop count.
Oそれ以外の場合、Rは受信ホップカウントをインクリメントする必要があります。
The first LSR in the LSP (ingress for a Label Request message, egress for a Label Mapping message) should set the hop count value to 1.
LSPの最初のLSR（Label Mappingメッセージのためのラベル要求メッセージ、出口用の入口は、1）ホップカウント値を設定しなければなりません。
By convention a value of 0 indicates an unknown hop count. The result of incrementing an unknown hop count is itself an unknown hop count (0).
慣例により0の値は、未知のホップ数を示します。未知のホップカウントをインクリメントした結果は、未知のホップ数（0）そのものです。
Use of the unknown hop count value greatly reduces the signaling overhead when independent control is used. When a new LSP is established, each LSR starts with unknown hop count. Addition of a new LSR whose hop count is also unknown does not cause a hop count update to be propagated upstream since the hop count remains unknown. When the egress is finally added to the LSP, then the LSRs propagate hop count updates upstream via Label Mapping messages.
独立したコントロールを使用する場合、未知のホップカウント値の使用を大幅にシグナリングオーバーヘッドを減少させます。新しいLSPが確立されると、各LSRは、未知のホップカウントを開始します。ホップ数も不明であるホップカウント更新が発生しないため、ホップ数上流に伝播される新しいLSRの追加は不明のまま。出口が最終的にLSPに追加されると、その後のLSRは、ラベルマッピングメッセージを介して上流のホップ数の更新を伝播します。
Without use of the unknown hop count, each time a new LSR is added to the LSP a hop count update would need to be propagated upstream if the new LSR is closer to the egress than any of the other LSRs. These updates are useless overhead since they don't reflect the hop count to the egress.
未知のホップカウントを使用せずに、新しいLSRがLSPに追加されるたびにホップ数の更新は、新しいLSRが他のLSRのいずれよりも出口に近い場合、上流に伝播する必要があります。彼らは出口へのホップ数を反映していないので、これらのアップデートは役に立たないオーバーヘッドです。
From the perspective of the ingress node, the fact that the hop count is unknown implies nothing about whether a packet sent on the LSP will actually make it to the egress. All it implies is that the hop count update from the egress has not yet reached the ingress.
入口ノードの観点から、ホップ数が不明であるという事実は、LSP上で送信されたパケットが実際に出口にそれを作るかどうかについては何も意味しません。それが意味するすべては、出口からのホップ数の更新はまだ侵入に達していないということです。
If an LSR receives a message containing a Hop Count TLV, it must check the hop count value to determine whether the hop count has exceeded its configured maximum allowable value. If so, it must behave as if the containing message has traversed a loop by sending a Notification message signaling Loop Detected in reply to the sender of the message.
LSRはホップカウントTLVを含むメッセージを受信した場合、それは、ホップ数が設定された最大許容値を超えているかどうかを判断するためにホップカウント値を確認する必要があります。もしそうなら、それが含むメッセージは、メッセージの送信者に返信して検出されたループを知らせる通知メッセージを送信することにより、ループを通過したかのように振る舞う必要があります。
If Loop Detection is configured, the LSR must follow the procedures specified in Section "Loop Detection".
ループ検出が設定されている場合、LSRはセクション「ループ検出」で指定された手順に従わなければなりません。
The Path Vector TLV is used with the Hop Count TLV in Label Request and Label Mapping messages to implement the optional LDP loop detection mechanism. See Section "Loop Detection". Its use in the
ベクトルTLVは、ホップで使用されるパスは、オプションのLDPループ検出メカニズムを実装するためにラベル要求とラベルマッピングメッセージにTLVを数えます。セクション「ループ検出」を参照してください。におけるその使用
Label Request message records the path of LSRs the request has traversed. Its use in the Label Mapping message records the path of LSRs a label advertisement has traversed to setup an LSP.
ラベル要求メッセージは、要求が横断したのLSRのパスを記録します。 Label Mappingメッセージにおけるその使用はラベル広告がセットアップLSPに横断したのLSRのパスを記録します。
Its encoding is:
そのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more LSR Ids A list of router-ids indicating the path of LSRs the message has traversed. Each LSR Id is the first four octets (router-id) of the LDP identifier for the corresponding LSR. This ensures it is unique within the LSR network.
一つ以上のLSRは、メッセージが横断したのLSRの経路を示すルータIDのリストをIDS。各LSR Idは、対応するLSRのためのLDP識別子の最初の4つのオクテット（ルータID）です。これは、LSRネットワーク内で一意である保証します。
The Path Vector TLV is carried in Label Mapping and Label Request messages when loop detection is configured.
ループ検出が設定されている場合、パスベクトルTLVはラベルマッピングおよびラベルリクエストメッセージで運ばれます。
Section "Loop Detection" specifies situations when an LSR must include a Path Vector TLV in a Label Request message.
セクション「ループ検出は」LSRは、ラベル要求メッセージでのパスベクトルTLVを含まなければならない状況を指定します。
An LSR that receives a Path Vector in a Label Request message must perform the procedures described in Section "Loop Detection".
ラベル要求メッセージにパスベクトルを受け取るLSRはセクション「ループ検出」に記載されている手順を実行する必要があります。
If the LSR detects a loop, it must reject the Label Request message.
LSRがループを検出した場合は、ラベル要求メッセージを拒絶しなければなりません。
The LSR must:
LSR必要があります：
1. Transmit a Notification message to the sending LSR signaling "Loop Detected".
1.送信LSRシグナル「が検出ループ」に通知メッセージを送信します。
Note that a Label Request message with Path Vector TLV is forwarded until:
パスベクトルTLVとラベル要求メッセージが転送されるまでされていることに注意してください：
3. The maximum Path Vector limit or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
3.最大パスベクタ制限または最大ホップ数の上限に達しています。これは、ループが検出されたかのように扱われます。
Section "Loop Detection" specifies the situations when an LSR must include a Path Vector TLV in a Label Mapping message.
セクション「ループ検出は」LSRは、ラベルマッピングメッセージでのパスベクトルTLVを含まなければならない状況を指定します。
An LSR that receives a Path Vector in a Label Mapping message must perform the procedures described in Section "Loop Detection".
ラベルマッピングメッセージにパスベクトルを受け取るLSRはセクション「ループ検出」に記載されている手順を実行する必要があります。
If the LSR detects a loop, it must reject the Label Mapping message in order to prevent a forwarding loop. The LSR must:
LSRがループを検出した場合は、転送ループを防止するために、ラベルマッピングメッセージを拒否しなければなりません。 LSR必要があります：
1. Transmit a Label Release message carrying a Status TLV to the sending LSR to signal "Loop Detected".
1.「ループが検出された」知らせるために送るLSRにステータスTLVを運ぶラベル解放メッセージを送信します。
3. Check whether the Label Mapping message is for an existing LSP. If so, the LSR must unsplice any upstream labels which are spliced to the downstream label for the FEC.
3.ラベルマッピングメッセージが既存のLSPのためであるかどうかを確認してください。もしそうなら、LSRはFECのために、下流のラベルに接合されているすべてのアップストリームラベルをunsplice必要があります。
Note that a Label Mapping message with a Path Vector TLV is forwarded until:
パスベクトルTLVとラベルマッピングメッセージが転送されるまでされていることに注意してください：
3. The maximum Path Vector or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
3.最大パスベクタまたは最大ホップ数の上限に達しています。これは、ループが検出されたかのように扱われます。
Notification messages carry Status TLVs to specify events being signaled.
通知メッセージが通知されているイベントを指定するには、ステータスTLVを運びます。
The encoding for the Status TLV is:
ステータスTLVのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Should be 0 when the Status TLV is sent in a Notification message. Should be 1 when the Status TLV is sent in some other message.
ステータスTLVは、通知メッセージで送信されたときにUビットは0にしてください。ステータスTLVは、他のいくつかのメッセージで送信されたときに1にする必要があります。
F bit Should be the same as the setting of the F-bit in the Status Code field.
Fビットは、ステータスコードフィールド内のFビットの設定と同じでなければなりません。
Status Code 32-bit unsigned integer encoding the event being signaled. The structure of a Status Code is:
シグナリングされるイベントをコードステータスコード32ビットの符号なし整数。ステータスコードの構造は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E bit Fatal error bit. If set (=1), this is a fatal error notification. If clear (=0), this is an advisory notification.
Eは、致命的なエラービットビット。 （= 1）に設定した場合、これは致命的なエラー通知です。明確な場合（= 0）、これはアドバイザリ通知です。
F bit Forward bit. If set (=1), the notification should be forwarded to the LSR for the next-hop or previous-hop for the LSP, if any, associated with the event being signaled. If clear (=0), the notification should not be forwarded.
Fビットを転送ビット。設定した場合、もしあれば（= 1）、通知が通知されるイベントに関連した、LSPのネクストホップまたは前のホップのためにLSRに転送されなければなりません。明確であれば（= 0）、通知が転送されるべきではありません。
Status Data 30-bit unsigned integer which specifies the status information.
ステータス情報を指定するステータスデータ30ビットの符号なし整数。
This specification defines Status Codes (32-bit unsigned integers with the above encoding).
この仕様は、ステータスコード（上記符号付き32ビットの符号なし整数）を定義します。
A Status Code of 0 signals success.
0信号の成功のステータスコード。
Message ID If non-zero, 32-bit value that identifies the peer message to which the Status TLV refers. If zero, no specific peer message is being identified.
ステータスTLVが参照するピアメッセージを識別するメッセージIDゼロ以外の場合、32ビット値。ゼロの場合は、特定のピアのメッセージが識別されていません。
Message Type If non-zero, the type of the peer message to which the Status TLV refers. If zero, the Status TLV does not refer to any specific message type.
メッセージタイプゼロ以外の場合、ステータスTLVが参照するピアメッセージのタイプ。ゼロの場合は、ステータスTLVは、特定のメッセージタイプを参照していません。
Note that use of the Status TLV is not limited to Notification messages. A message other than a Notification message may carry a Status TLV as an Optional Parameter. When a message other than a Notification carries a Status TLV the U-bit of the Status TLV should be set to 1 to indicate that the receiver should silently discard the TLV if unprepared to handle it.
TLVは、通知メッセージに限定されるものではなく、ステータスの使用に注意してください。通知メッセージ以外のメッセージは、オプションのパラメータとしてステータスTLVを運ぶことができます。通知以外のメッセージステータスTLVを運ぶときにステータスTLVのUビットが不意にそれを処理する場合、受信機は静かにTLVを捨てるべきであることを示すために1に設定されるべきです。
All LDP messages have the following format:
すべてのLDPメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored. The sections following that define messages specify a value for the U-bit.
Uは不明なメッセージビットビット。 Uがクリアされている場合、未知のメッセージを受信すると、（= 0）、通知メッセージの発信者に戻されます。 Uが設定されている場合（= 1）、未知のメッセージは無視されます。その定義メッセージを次のセクションでは、Uビットの値を指定します。
Message Type Identifies the type of message
メッセージタイプは、メッセージの種類を識別します
Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters.
メッセージ長は、メッセージID、必須パラメータ、およびオプションパラメータのオクテットの累積長さを指定します。
Message ID 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message should include this Message Id in the Status TLV carried by the notification message; see Section "Notification Message".
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。このメッセージに適用することができる特定通知メッセージを容易にするために、送信LSRによって使用されます。 LSRは、通知メッセージによって運ばステータスTLVにこのメッセージIDを含める必要があり、このメッセージに応答して、通知メッセージを送信します。セクション「通知メッセージ」を参照してください。
Mandatory Parameters Variable length set of required message parameters. Some messages have no required parameters.
必要なメッセージパラメータの必須パラメータ可変長セット。一部のメッセージには、必要なパラメータを持っていません。
For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications in the sections that follow.
パラメータを必要としていたメッセージの場合、必要なパラメータは、以下のセクションで、個々のメッセージの仕様で指定された順序で表示されなければなりません。
Optional Parameters Variable length set of optional message parameters. Many messages have no optional parameters.
オプションのメッセージパラメータのオプションパラメータ可変長セット。多くのメッセージには、オプションのパラメータを持っていません。
For messages that have optional parameters, the optional parameters may appear in any order.
オプションのパラメータを持っているメッセージについては、オプションのパラメータは任意の順序で表示されることがあります。
Note that there is no alignment requirement for the first octet of an LDP message.
LDPメッセージの最初のオクテットのための位置合わせ要件が存在しないことに留意されたいです。
The following message types are defined in this version of LDP:
次のメッセージタイプは、LDPのこのバージョンで定義されています。
Message Name Section Title
メッセージ名セクションのタイトル
Notification "Notification Message" Hello "Hello Message" Initialization "Initialization Message" KeepAlive "KeepAlive Message"
通知「通知メッセージ」こんにちは「こんにちはメッセージ」初期化「の初期化メッセージ」キープアライブ「のKeepAliveメッセージ」
Address "Address Message" Address Withdraw "Address Withdraw Message" Label Mapping "Label Mapping Message" Label Request "Label Request Message" Label Abort Request "Label Abort Request Message" Label Withdraw "Label Withdraw Message" Label Release "Label Release Message"
アドレス「アドレスメッセージ」のアドレスは撤回「ラベルマッピングメッセージを」ラベルマッピング「のアドレスは、メッセージを撤回」ラベル要求「ラベル要求メッセージ」ラベルは、ラベルウィズドロー「要求メッセージを中止ラベル」のリクエストを中止「ラベルは、メッセージを撤回」ラベルリリース「ラベルリリースメッセージ」
The sections that follow specify the encodings and procedures for these messages.
以下のセクションでは、これらのメッセージのエンコーディングと手順を指定します。
Some of the above messages are related to one another, for example the Label Mapping, Label Request, Label Withdraw, and Label Release messages.
上記のメッセージのいくつかは、例えば互いに、ラベルマッピング、ラベル要求、ラベル撤回、およびラベルリリースメッセージに関連しています。
While it is possible to think about messages related in this way in terms of a message type that specifies a message class and a message subtype that specifies a particular kind of message within that class, this specification does not formalize the notion of a message subtype.
それはメッセージクラスとそのクラス内のメッセージの特定の種類を指定するメッセージのサブタイプを指定するメッセージタイプの面で、このように関連するメッセージを考えることは可能ですが、この仕様は、メッセージのサブタイプの概念を形式化しません。
The specification assigns type values for related messages, such as the label messages, from of a contiguous block in the 16-bit message type number space.
仕様は、16ビットのメッセージタイプ番号空間内の連続ブロックから、そのようなラベルのメッセージのような関連するメッセージのタイプ値を割り当てます。
An LSR sends a Notification message to inform an LDP peer of a significant event. A Notification message signals a fatal error or provides advisory information such as the outcome of processing an LDP message or the state of the LDP session.
LSRは、重要なイベントのLDPピアを通知する通知メッセージを送信します。通知メッセージは、致命的なエラーを通知し、またはそのようなLDPメッセージまたはLDPセッションの状態を処理する結果としてアドバイザリー情報を提供します。
The encoding for the Notification Message is:
通知メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Status TLV Indicates the event being signaled. The encoding for the Status TLV is specified in Section "Status TLV".
ステータスTLVが通知されているイベントを示します。ステータスTLVのエンコーディングは、「ステータスTLV」セクションで指定されています。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The following Optional Parameters are generic and may appear in any Notification Message:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。以下のオプションパラメータは、一般的なものと任意の通知メッセージに表示されることがあります。
Optional Parameter Type Length Value
オプションのパラメータタイプ長さ値
Extended Status 0x0301 4 See below Returned PDU 0x0302 var See below Returned Message 0x0303 var See below
返されるPDUの0x0302のVAR以下の拡張ステータス0x0301 4を参照してくださいは、返送メッセージの0x0303のvarは以下を参照してください、以下を参照してください
Other Optional Parameters, specific to the particular event being signaled by the Notification Messages may appear. These are described elsewhere.
通知メッセージによって通知されている特定のイベントに固有のその他のオプションパラメータは、表示されることがあります。これらは、他の場所に記載されています。
Extended Status The 4 octet value is an Extended Status Code that encodes additional information that supplements the status information contained in the Notification Status Code.
拡張ステータスは4オクテットの値が通知状態コードに含まれる状態情報を補足する追加情報を符号化する拡張ステータスコードです。
Returned PDU An LSR uses this parameter to return part of an LDP PDU to the LSR that sent it. The value of this TLV is the PDU header and as much PDU data following the header as appropriate for the condition being signaled by the Notification message.
返されたPDUアンLSRはそれを送ったLSRにLDP PDUの一部を返すために、このパラメータを使用しています。このTLVの値は、通知メッセージによってシグナリングされる状態に応じて、ヘッダに続くPDUヘッダと同じくらいPDUデータです。
Returned Message An LSR uses this parameter to return part of an LDP message to the LSR that sent it. The value of this TLV is the message type and length fields and as much message data following the type and length fields as appropriate for the condition being signaled by the Notification message.
返されたメッセージアンLSRはそれを送ったLSRにLDPメッセージの一部を返すために、このパラメータを使用しています。このTLVの値は、メッセージタイプと長さフィールドと通知メッセージによってシグナリングされる状態に応じて適切な種類と長さのフィールドを次のように多くのメッセージデータです。
If an LSR encounters a condition requiring it to notify its peer with advisory or error information it sends the peer a Notification message containing a Status TLV that encodes the information and optionally additional TLVs that provide more information about the condition.
LSRは顧問またはエラー情報をピアに通知するために、それを必要とする状態が発生した場合には、ピアに情報及び状態に関する詳細な情報を提供する必要に応じて追加のTLVをコードステータスTLVを含む通知メッセージを送信します。
If the condition is one that is a fatal error the Status Code carried in the notification will indicate that. In this case, after sending the Notification message the LSR should terminate the LDP session by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session.
条件は通知で運ばれたステータスコードは、それを示すだろう致命的なエラーであるものである場合。この場合、通知メッセージを送信した後にLSRはセッションのTCP接続を閉じることにより、LDPセッションを終了し、セッションを介して学習のすべてのラベル-FECバインディングを含め、セッションに関連するすべての状態を破棄しなければなりません。
When an LSR receives a Notification message that carries a Status Code that indicates a fatal error, it should terminate the LDP session immediately by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session.
LSRは、致命的なエラーを示すステータスコードを運ぶ通知メッセージを受信すると、セッションのTCP接続を閉じることで、すぐにLDPセッションを終了し、セッションを介して学習のすべてのラベル-FECバインディングを含むセッションに関連するすべての状態を、捨てるべき。
It is useful for descriptive purpose to classify events signaled by Notification Messages into the following categories.
説明の目的は、以下のカテゴリに通知メッセージによって通知イベントを分類することは有用です。
Malformed LDP PDUs or Messages that are part of the LDP Discovery mechanism are handled by silently discarding them.
不正な形式のLDP PDUのか、LDPディスカバリメカニズムの一部であるメッセージは静かにそれらを捨てることによって処理されます。
An LDP PDU received on a TCP connection for an LDP session is malformed if:
LDP PDUは、LDPセッションのためのTCP接続で受信した場合、不正な形式です。
- The LDP Identifier in the PDU header is unknown to the receiver, or it is known but is not the LDP Identifier associated by the receiver with the LDP peer for this LDP session. This is a fatal error signaled by the Bad LDP Identifier Status Code.
- PDUのヘッダ内のLDP識別子は、受信機に知られていない、またはそれが知られているが、このLDPセッションのLDPピアと受信機によって関連付けLDP識別子はありません。これは悪いLDP識別子のステータスコードによって合図致命的なエラーです。
- The LDP protocol version is not supported by the receiver, or it is supported but is not the version negotiated for the session during session establishment. This is a fatal error signaled by the Bad Protocol Version Status Code.
- LDPプロトコルバージョンは、受信機でサポートされていない、またはそれがサポートされているが、セッション確立時にセッションのために交渉したバージョンではありません。これは悪いプロトコルバージョンステータスコードによって合図致命的なエラーです。
- The PDU Length field is too small (< 14) or too large (> maximum PDU length). This is a fatal error signaled by the Bad PDU Length Status Code. Section "Initialization Message" describes how the maximum PDU length for a session is determined.
- PDUの長さフィールドが小さすぎる（<14）または大きすぎる（>最大PDU長）。これは悪いPDU長ステータスコードによって合図致命的なエラーです。セクション「初期化メッセージは、」セッションの最大PDU長を決定する方法について説明します。
An LDP Message is malformed if:
LDPメッセージがあれば、不正な形式です。
- The Message Type is unknown.
- メッセージの種類は不明です。
If the Message Type is < 0x8000 (high order bit = 0) it is an error signaled by the Unknown Message Type Status Code.
メッセージタイプがある場合<0x8000の（上位ビット= 0）には、未知のメッセージタイプのステータスコードによって合図誤差です。
If the Message Type is >= 0x8000 (high order bit = 1) it is silently discarded.
メッセージタイプが> = 0x8000の（上位ビット= 1）である場合には、黙って破棄されます。
- The Message Length is too large, that is, indicates that the message extends beyond the end of the containing LDP PDU. This is a fatal error signaled by the Bad Message Length Status Code.
- メッセージ長、すなわち、大きすぎるメッセージを含むLDP PDUの端を越えて延びていることを示しています。これは悪いメッセージ長ステータスコードによって合図致命的なエラーです。
- The message is missing one or more Mandatory Parameters. This is a non-fatal error signalled by the Missing Message Parameters Status Code.
- メッセージは、1つまたは複数の必須パラメーターが欠落しています。これは、行方不明のメッセージパラメータステータスコードによって合図非致命的なエラーです。
Malformed TLVs contained in LDP messages that are part of the LDP Discovery mechanism are handled by silently discarding the containing message.
LDPディスカバリメカニズムの一部であるLDPメッセージに含まれる不正な形式のTLVはサイレント含むメッセージを捨てることによって処理されます。
A TLV contained in an LDP message received on a TCP connection of an LDP is malformed if:
LDPのTCP接続で受信したLDPメッセージに含まれるTLVは、IF奇形です。
- The TLV Length is too large, that is, indicates that the TLV extends beyond the end of the containing message. This is a fatal error signaled by the Bad TLV Length Status Code.
- TLVの長さ、すなわち、大きすぎるTLVを含むメッセージの終わりを越えて延びていることを示しています。これは悪いTLV長ステータスコードによって合図致命的なエラーです。
- The TLV type is unknown.
- TLVタイプが不明です。
If the TLV type is < 0x8000 (high order bit 0) it is an error signaled by the Unknown TLV Status Code.
TLVタイプは<0x8000の（上位ビット0）である場合には、未知のTLVステータスコードによって合図誤差です。
If the TLV type is >= 0x8000 (high order bit 1) the TLV is silently dropped. Section "Unknown TLV in Known Message Type" elaborates on this behavior.
TLVタイプは> = 0x8000の（上位のビット1）である場合TLVは静かに滴下します。セクション「既知のメッセージタイプで不明TLVは、」この動作について詳しく説明します。
- The TLV Value is malformed. This occurs when the receiver handles the TLV but cannot decode the TLV Value. This is interpreted as indicative of a bug in either the sending or receiving LSR. It is a fatal error signaled by the Malformed TLV Value Status Code.
- TLV値が不正な形式です。これは、受信機は、TLVを扱うときに発生するが、TLV値をデコードすることはできません。これは、いずれかの送信または受信LSRのバグを示すものとして解釈されます。これは、不正なTLV値ステータスコードによって合図致命的なエラーです。
This is a fatal error signaled by the KeepAlive Timer Expired Status Code.
これは、キープアライブタイマー期限切れステータスコードによって合図致命的なエラーです。
This is a fatal event signaled by the Shutdown Status Code. The Notification Message may optionally include an Extended Status TLV to provide a reason for the Shutdown. The sending LSR terminates the session immediately after sending the Notification.
これは、シャットダウンステータスコードによって合図致命的なイベントです。通知メッセージは、必要に応じてシャットダウンの理由を提供する拡張ステータスTLVを含んでいてもよいです。送信LSRはすぐに通知を送信した後、セッションを終了します。
The session initialization negotiation (see Section "Session Initialization") may fail if the session parameters received in the Initialization Message are unacceptable. This is a fatal error. The specific Status Code depends on the parameter deemed unacceptable, and is defined in Sections "Initialization Message".
初期化メッセージで受信したセッションパラメータが受け入れられない場合はセッション初期化交渉（セクション「セッション初期化」を参照）が失敗することがあります。これは致命的なエラーです。特定のステータスコード許容できないとみなされ、セクション「初期メッセージ」で定義されたパラメータに依存します。
Messages other than the Initialization message may result in events that must be signaled to LDP peers via Notification Messages. These events and the Status Codes used in the Notification Messages to signal them are described in the sections that describe these messages.
初期化メッセージ以外のメッセージは、通知メッセージを介して、LDPピアに通知しなければならないイベントをもたらすことができます。それらを知らせるために通知メッセージに使用されるこれらのイベントとステータスコードは、これらのメッセージを記述するセクションで説明されています。
An LDP implementation may be capable of detecting problem conditions specific to its implementation. When such a condition prevents an implementation from interacting correctly with a peer, the implementation should, when capable of doing so, use the Internal Error Status Code to signal the peer. This is a fatal error.
LDP実装は、その実装に固有の問題の状態を検出することが可能です。このような状態は、ピアと正しく相互作用からの実施を妨げた場合、実装は、そうすることのできる、ピアに信号を送るために、内部エラーステータスコードを使用する必要があるとき。これは致命的なエラーです。
These are events that fall into none of the categories above. There are no miscellaneous events defined in this version of the protocol.
これらは、上記のカテゴリのどれに分類されたイベントです。プロトコルのこのバージョンで定義されたその他のイベントはありません。
LDP Hello Messages are exchanged as part of the LDP Discovery Mechanism; see Section "LDP Discovery".
LDP helloメッセージをLDPディスカバリメカニズムの一部として交換されています。セクション「LDPディスカバリ」を参照してください。
The encoding for the Hello Message is:
こんにちは、メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Hello (0x0100) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Hello Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Common Hello Parameters TLV Specifies parameters common to all Hello messages. The encoding for the Common Hello Parameters TLV is:
共通こんにちはパラメータTLVは、すべてのHelloメッセージに共通のパラメータを指定します。共通こんにちはパラメータTLVのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time, Hello hold time in seconds. An LSR maintains a record of Hellos received from potential peers (see Section "Hello Message Procedures"). Hello Hold Time specifies the time the sending LSR will maintain its record of Hellos from the receiving LSR without receipt of another Hello.
ホールド時間、こんにちは秒の時間を保持します。 LSRはハローズの記録が潜在的なピア（セクションの「Helloメッセージの手順」を参照）から受信し保持しています。ハロータイムホールド送信LSRが別のHelloの領収書なしで受信LSRからハローズのその記録を維持する時間を指定します。
A pair of LSRs negotiates the hold times they use for Hellos from each other. Each proposes a hold time. The hold time used is the minimum of the hold times proposed in their Hellos.
LSRのペアは、彼らがお互いからハローズのために使用し、ホールド時間を交渉します。それぞれのホールド時間を提案しています。使用ホールド時間は、彼らのハローズで提案されたホールド時間の最小値です。
A value of 0 means use the default, which is 15 seconds for Link Hellos and 45 seconds for Targeted Hellos. A value of 0xffff means infinite.
0手段の値は、リンクハローズのための15秒とターゲットハローズのための45秒で、デフォルトを使用します。値0xffffは無限を意味します。
T, Targeted Hello A value of 1 specifies that this Hello is a Targeted Hello. A value of 0 specifies that this Hello is a Link Hello.
Tは、ターゲットこんにちは1の値は、このこんにちはこんにちは対象であることを指定します。 0の値は、このこんにちはリンクこんにちはであることを指定します。
R, Request Send Targeted Hellos A value of 1 requests the receiver to send periodic Targeted Hellos to the source of this Hello. A value of 0 makes no request.
Rは、ターゲットハローズ1つのリクエストこのハローの元に定期的にターゲットhelloを送信するために受信機の値を送信要求します。 0の値は、要求を行うものではありません。
An LSR initiating Extended Discovery sets R to 1. If R is 1, the receiving LSR checks whether it has been configured to send Targeted Hellos to the Hello source in response to Hellos with this request. If not, it ignores the request. If so, it initiates periodic transmission of Targeted Hellos to the Hello source.
Rが1である場合、拡張ディスカバリーを開始するLSRは、1に、この要求にハローズに応答して、ハロー源にターゲットhelloを送信するように構成されているかどうかを受信LSRチェックをRを設定します。そうでない場合、それは要求を無視します。そうだとすれば、それはハロー源を標的ハローズの周期的な送信を開始します。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters defined by this version of the protocol are
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。プロトコルのこのバージョンで定義されたオプションのパラメータであります
Optional Parameter Type Length Value
オプションのパラメータタイプ長さ値
IPv4 Transport Address 0x0401 4 See below Configuration 0x0402 4 See below Sequence Number IPv6 Transport Address 0x0403 16 See below
IPv4の交通は0x0403 16は、以下を参照してくださいアドレスシーケンス番号のIPv6交通下記参照設定0x0402 4の下を参照してください0x0401 4住所
IPv4 Transport Address Specifies the IPv4 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv4 source address for the UDP packet carrying the Hello should be used.
IPv4のトランスポートアドレスは、LDPセッションのTCP接続を開くときに送信LSRに使用するIPv4アドレスを指定します。このオプションのTLVが存在しない場合のHelloを運ぶUDPパケットのIPv4送信元アドレスを使用する必要があります。
Configuration Sequence Number Specifies a 4 octet unsigned configuration sequence number that identifies the configuration state of the sending LSR. Used by the receiving LSR to detect configuration changes on the sending LSR.
コンフィギュレーション・シーケンス番号は、送信LSRの構成状態を特定する4オクテット符号なしの設定シーケンス番号を指定します。送信LSRに設定変更を検出するために、受信側LSRによって使用されます。
IPv6 Transport Address Specifies the IPv6 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv6 source address for the UDP packet carrying the Hello should be used.
IPv6のトランスポートアドレスは、LDPセッションのTCP接続を開くときに送信LSRに使用するIPv6アドレスを指定します。このオプションのTLVが存在しない場合のHelloを運ぶUDPパケットのIPv6送信元アドレスを使用する必要があります。
An LSR receiving Hellos from another LSR maintains a Hello adjacency corresponding to the Hellos. The LSR maintains a hold timer with the Hello adjacency which it restarts whenever it receives a Hello that matches the Hello adjacency. If the hold timer for a Hello adjacency expires the LSR discards the Hello adjacency: see sections "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".
別のLSRからhelloを受け取るLSRはハローズに対応するのHello隣接関係を維持しています。 LSRは、ハロー隣接を一致するハローを受信するたびに、再起動のHello隣接してホールドタイマーを維持します。 「こんにちは、隣接関係の維持」と「LDPセッションを維持する」の項を参照してください。ハロー隣接のホールドタイマーが満了した場合LSRは、ハロー隣接を破棄します。
We recommend that the interval between Hello transmissions be at most one third of the Hello hold time.
私たちは、ハロー送信間隔はこんにちはの高々3分の1の時間を保持することをお勧めします。
An LSR processes a received LDP Hello as follows:
次のようにLSRは受信LDPこんにちはを処理します。
1. The LSR checks whether the Hello is acceptable. The criteria for determining whether a Hello is acceptable are implementation dependent (see below for example criteria).
1. LSRは、こんにちはが許容できるかどうかチェックします。ハローが許容可能であるか否かを決定するための基準は、（例えば基準については以下を参照）実装依存です。
3. If the Hello is acceptable, the LSR checks whether it has a Hello adjacency for the Hello source. If so, it restarts the hold timer for the Hello adjacency. If not it creates a Hello adjacency for the Hello source and starts its hold timer.
3.ハローが許容可能である場合、LSRは、ハロー・ソースのハロー隣接を持っているかどうかをチェックします。もしそうなら、それは、ハロー隣接のホールドタイマーを再起動します。そうでない場合には、ハローソース用のHello隣接を作成し、そのホールドタイマーを開始します。
4. If the Hello carries any optional TLVs the LSR processes them (see below).
こんにちはLSRがそれらを処理任意のオプションのTLVを運ぶ場合4.（下記参照）。
5. Finally, if the LSR has no LDP session for the label space specified by the LDP identifier in the PDU header for the Hello, it follows the procedures of Section "LDP Session Establishment".
LSRはこんにちはPDUヘッダにLDP識別子によって指定されたラベル領域のためのLDPセッションを持っていない場合5.最後に、それは「LDPセッションの確立」のセクションの手順に従います。
The following are examples of acceptability criteria for Link and Targeted Hellos:
以下は、リンクやターゲットハローズの許容基準の例です：
A Link Hello is acceptable if the interface on which it was received has been configured for label switching.
リンクこんにちは、それが受信したインターフェイスは、ラベルスイッチング用に設定されている場合に許容可能です。
A Targeted Hello from source address A is acceptable if either:
いずれかの場合には送信元アドレスAからターゲットこんにちは可能です：
- The LSR has been configured to accept Targeted Hellos, or
- LSRは、ターゲットhelloを受け入れるように構成されている、または
- The LSR has been configured to send Targeted Hellos to A.
- LSRはA.にターゲットhelloを送信するように設定されています
The following describes how an LSR processes Hello optional TLVs:
以下は、LSRこんにちは、オプションのTLVを処理する方法について説明します。
Transport Address The LSR associates the specified transport address with the Hello adjacency.
トランスポートアドレスLSRこんにちは隣接して指定されたトランスポートアドレスを関連付けます。
Configuration Sequence Number The Configuration Sequence Number optional parameter is used by the sending LSR to signal configuration changes to the receiving LSR. When a receiving LSR playing the active role in LDP session establishment detects a change in the sending LSR configuration, it may clear the session setup backoff delay, if any, associated with the sending LSR (see Section "Session Initialization").
コンフィギュレーションシーケンスナンバー構成シーケンス番号オプションのパラメータは、受信LSRに設定変更を通知するために送信LSRによって使用されます。 LDPセッションの確立に積極的な役割を果たして受信側LSRが送信LSR構成の変更を検出すると、送信LSRに関連付けられている（セクション「セッション初期化」を参照）があれば、それは、セッションセットアップバックオフ遅延をクリアすることがあります。
A sending LSR using this optional parameter is responsible for maintaining the configuration sequence number it transmits in Hello messages. Whenever there is a configuration change on the sending LSR, it increments the configuration sequence number.
このオプションパラメータを使用して送信するLSRは、Helloメッセージで送信コンフィギュレーション・シーケンス番号を維持する責任があります。送信LSR上の設定変更があるたびに、コンフィギュレーション・シーケンス番号をインクリメントします。
The LDP Initialization Message is exchanged as part of the LDP session establishment procedure; see Section "LDP Session Establishment".
LDP初期化メッセージは、LDPセッション確立手順の一部として交換されます。セクション「LDPセッションの確立」を参照してください。
The encoding for the Initialization Message is:
初期化メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Common Session Parameters TLV Specifies values proposed by the sending LSR for parameters that must be negotiated for every LDP session.
一般的なセッションパラメータTLVは、すべてのLDPセッションのために交渉しなければならないパラメータに対して送信するLSRによって提案された値を指定します。
The encoding for the Common Session Parameters TLV is:
一般的なセッションパラメータTLVのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | KeepAlive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Protocol Version Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1.
プロトコルバージョンプロトコルのバージョン番号を含む2つのオクテットの符号なし整数。仕様のこのバージョンは、LDPプロトコルバージョン1を指定します。
KeepAlive Time Two octet unsigned non zero integer that indicates the number of seconds that the sending LSR proposes for the value of the KeepAlive Time. The receiving LSR MUST calculate the value of the KeepAlive Timer by using the smaller of its proposed KeepAlive Time and the KeepAlive Time received in the PDU. The value chosen for KeepAlive Time indicates the maximum number of seconds that may elapse between the receipt of successive PDUs from the LDP peer on the session TCP connection. The KeepAlive Timer is reset each time a PDU arrives.
キープアライブ時間送信LSRは、キープアライブ時間の値を提案している秒数を示す2つのオクテット符号なしのゼロ以外の整数。受信LSRは、その提案されたキープアライブ時間の小さい、キープアライブ時間がPDUで受信を使用して、キープアライブタイマーの値を計算しなければなりません。キープアライブ時間のために選択された値は、セッションのTCP接続上LDPピアからの連続するPDUの受信間で経過することができる最大秒数を示しています。キープアライブタイマーは、PDUが到着するたびにリセットされます。
A, Label Advertisement Discipline Indicates the type of Label advertisement. A value of 0 means Downstream Unsolicited advertisement; a value of 1 means Downstream On Demand.
、ラベル広告規律ラベル広告の種類を示します。 0の値は、ダウンストリーム迷惑広告を意味します。 1の値は、オンデマンドダウンストリームを意味します。
If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is:
1 LSRは川下迷惑提案し、他方はオンデマンド川下提案している場合は、この違いを解決するための規則は次のとおりです。
- If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand must be used.
- セッションがラベル制御ATMリンクまたはラベル制御フレームリレーリンクのためであれば、オンデマンドその後、下流には、使用する必要があります。
- Otherwise, Downstream Unsolicited must be used.
- それ以外の場合は、ダウンストリーム迷惑を使用する必要があります。
If the label advertisement discipline determined in this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Advertisement Mode Notification message in response to the Initialization message and not establish the session.
このようにして決定ラベル広告の規律がLSRに受け入れられない場合は、初期設定メッセージに応答して、セッション拒否/パラメータ広告モード通知メッセージを送信し、セッションを確立してはなりません。
D, Loop Detection Indicates whether loop detection based on path vectors is enabled. A value of 0 means loop detection is disabled; a value of 1 means that loop detection is enabled.
Dは、ループ検出は、パスベクトルに基づいて、ループ検出が有効になっているかどうかを示します。 0の値は、ループ検出が無効であることを意味します。 1の値は、ループ検出が有効であることを意味します。
PVLim, Path Vector Limit The configured maximum path vector length. Must be 0 if loop detection is disabled (D = 0). If the loop detection procedures would require the LSR to send a path vector that exceeds this limit, the LSR will behave as if a loop had been detected for the FEC in question.
PVLim、パスベクトル制限ザパスの最大ベクトル長を構成。ループ検出が無効になっている場合は0でなければならない（D = 0）。ループ検出手順は、この制限を超えるパスベクトルを送信するためにLSRを必要とする場合、LSRはループが問題のFECのために検出されていたかのように動作します。
When Loop Detection is enabled in a portion of a network, it is recommended that all LSRs in that portion of the network be configured with the same path vector limit. Although knowledge of a peer's path vector limit will not change an LSR's behavior, it does enable the LSR to alert an operator to a possible misconfiguration.
ループ検出は、ネットワークの部分で有効になっている場合には、ネットワークのその部分の全てのLSRが同じパスベクトル限界で設定することが推奨されます。ピアのパスベクトル制限の知識がLSRの動作を変更しませんが、それは可能な設定ミスにオペレータに警告するLSRを有効にしません。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
Max PDU Length Two octet unsigned integer that proposes the maximum allowable length for LDP PDUs for the session. A value of 255 or less specifies the default maximum length of 4096 octets.
最大PDU長セッションのLDPのPDUの最大許容長さを提案している2つのオクテットの符号なし整数。 255以下の値が4096オクテットのデフォルトの最大長を指定します。
The receiving LSR MUST calculate the maximum PDU length for the session by using the smaller of its and its peer's proposals for Max PDU Length. The default maximum PDU length applies before session initialization completes.
受信LSRは、最大PDU長のために、そのピアの提案の小さい方を使用して、セッションの最大PDU長を計算しなければなりません。セッションの初期化が完了する前に、デフォルトの最大PDU長が適用されます。
If the maximum PDU length determined this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Max PDU Length Notification message in response to the Initialization message and not establish the session.
このように決定した最大PDU長はLSRに受け入れられない場合は、初期設定メッセージに応答して、セッション拒否/パラメータの最大PDU長通知メッセージを送信し、セッションを確立してはなりません。
Receiver LDP Identifier Identifies the receiver's label space. This LDP Identifier, together with the sender's LDP Identifier in the PDU header enables the receiver to match the Initialization message with one of its Hello adjacencies; see Section "Hello Message Procedures".
レシーバLDP識別子は、受信者のラベルスペースを識別します。一緒にPDUヘッダ内の送信者のLDP識別子にこのLDP識別子は、そのハロー隣接の一つと初期化メッセージと一致するように受信機を可能。セクションの「Helloメッセージの手順」を参照してください。
If there is no matching Hello adjacency, the LSR must send a Session Rejected/No Hello Notification message in response to the Initialization message and not establish the session.
一致こんにちは隣接関係が存在しない場合、LSRは、初期設定メッセージに応答して、セッション拒否/いいえこんにちは通知メッセージを送信し、セッションを確立してはなりません。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。オプションのパラメータは以下のとおりです。
Optional Parameter Type Length Value
オプションのパラメータタイプ長さ値
ATM Session Parameters 0x0501 var See below Frame Relay Session 0x0502 var See below Parameters
ATMセッションパラメータは、VARて0x0501パラメータ下記参照フレームリレーセッション0x0502のVARの下を参照してください。
ATM Session Parameters Used when an LDP session manages label exchange for an ATM link to specify ATM-specific session parameters.
ATMセッションパラメータは、LDPセッションがATM固有のセッションパラメータを指定するには、ATMリンクのラベル交換を管理するときに使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| ATM Sess Parms (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, ATM Merge Capabilities Specifies the merge capabilities of an ATM switch. The following values are supported in this version of the specification:
M、ATMマージ機能は、ATMスイッチのマージ機能を指定します。次の値は、仕様のこのバージョンでサポートされています。
Value Meaning
値意味
0 Merge not supported 1 VP Merge supported 2 VC Merge supported 3 VP & VC Merge supported
0は1 VPが2 VCマージは3 VP＆VCマージはサポートサポートサポートマージはサポートされていませんマージ
If the merge capabilities of the LSRs differ, then:
LSRのマージ機能は、その後、異なる場合：
- Non-merge and VC-merge LSRs may freely interoperate.
- 非マージおよびVC-マージのLSRは自由に相互運用可能。
- The interoperability of VP-merge-capable switches with non-VP-merge-capable switches is a subject for future study. When the LSRs differ on the use of VP-merge, the session is established, but VP merge is not used.
- 非VP-マージ対応スイッチとVP-マージ対応スイッチの相互運用性は、今後の検討課題です。 LSRは、VP-マージの使用に異なる場合、セッションが確立されていますが、VPマージは使用されません。
Note that if VP merge is used, it is the responsibility of the ingress node to ensure that the chosen VCI is unique within the LSR domain (see [ATM-VP]).
VPが使用されてマージした場合、選択されたVCIがLSRドメイン内で一意であることを保証するために、入口ノードの責任であることに留意されたい（参照[ATM-VP]）。
N, Number of label range components Specifies the number of ATM Label Range Components included in the TLV.
N、ラベル範囲コンポーネントの数は、ATMラベル範囲コンポーネントの数はTLVに含まれて指定します。
D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can (within a given VPI) support the use of a given VCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning (within a given VPI) a given VCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered VCIs in the VPI/VCI range as labels. The system with the smaller LDP Identifier may assign only even-numbered VCIs in the VPI/VCI range as labels.
D、VC方向性0の値は、LSRが（所定のVPI内で）独立に両方のリンク方向のラベルとして指定されたVCIの使用をサポートすることができることを意味し、双方向VC能力を指定します。 1の値は、（与えられたVPI内）与えられたVCIはリンクだけで一つの方向のためのラベルマッピングに表示されることを意味し、単方向のVC機能を指定します。ピアのいずれかまたは両方が単方向のVC能力を指定すると、以下のように、両方のLSRは、リンクのための単方向のVCラベルの割り当てを使用しています。 LSRは、符号なし整数としてのLDP識別子を比較します。大きなLDP識別子にLSRがラベルとしてVPI / VCIの範囲でのみ奇数のVCIを割り当てることができます。小さいLDP識別子を持つシステムは、ラベルとしてVPI / VCIの範囲でのみ、偶数のVCIを割り当てることができます。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
One or more ATM Label Range Components A list of ATM Label Range Components which together specify the Label range supported by the transmitting LSR.
一つ以上のATMラベル範囲コンポーネント一緒に送信LSRでサポートされているラベルの範囲を指定するATMラベル範囲コンポーネントのリスト。
A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session.
受信LSRは、受信された範囲と、自身のサポートラベル範囲との交点を計算しなければなりません。交点LSRが割り当てるラベルを受け入れることができる範囲です。 LSRは、範囲の交点がNULLであるために隣人とのセッションを確立してはなりません。この場合、LSRは、初期設定のメッセージへの応答でのセッション拒否/パラメータラベル範囲通知メッセージを送信し、セッションを確立してはなりません。
The encoding for an ATM Label Range Component is:
ATMラベル範囲コンポーネントのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
RESこのフィールドは予約されています。これは、送信時にゼロに設定されている必要があり、領収書の上で無視しなければなりません。
Minimum VPI (12 bits) This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
最小VPI（12ビット）この12ビットのフィールドは、発信スイッチに支持されている仮想パス識別子のブロックの下限を指定します。 VPI未満、12ビットである場合、このフィールドに右揃えであるべきであり、先行ビットが0に設定されるべきです。
Minimum VCI (16 bits) This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it should be right justified in this field and preceding bits should be set to 0.
最小VCI（16ビット）この16ビットのフィールドは、発信スイッチに支持されている仮想接続識別子のブロックの下限を指定します。 VCI未満、16ビットである場合、このフィールドに右揃えであるべきであり、先行ビットが0に設定されるべきです。
Maximum VPI (12 bits) This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
最大VPI（12ビット）この12ビットのフィールドは、発信スイッチに支持されている仮想パス識別子のブロックの上限を指定します。 VPI未満、12ビットである場合、このフィールドに右揃えであるべきであり、先行ビットが0に設定されるべきです。
Maximum VCI (16 bits) This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it should be right justified in this field and preceding bits should be set to 0.
最大VCI（16ビット）この16ビットのフィールドは、発信スイッチに支持されている仮想接続識別子のブロックの上限を指定します。 VCI未満、16ビットである場合、このフィールドに右揃えであるべきであり、先行ビットが0に設定されるべきです。
When peer LSRs are connected indirectly by means of an ATM VP, the sending LSR should set the Minimum and Maximum VPI fields to 0, and the receiving LSR must ignore the Minimum and Maximum VPI fields.
ピアのLSRは、ATM VPによって間接的に接続されている場合、送信LSRは0に最小値と最大VPIフィールドを設定する必要があり、受信LSR最小および最大VPIフィールドを無視しなければなりません。
See [ATM-VP] for specification of the fields for ATM Label Range Components to be used with VP merge LSRs.
LSRをマージVPで使用するATMラベル範囲コンポーネントのフィールドの仕様のために[ATM-VP]を参照してください。
Frame Relay Session Parameters Used when an LDP session manages label exchange for a Frame Relay link to specify Frame Relay-specific session parameters.
フレームリレーセッションパラメータは、LDPセッションがフレームリレー固有のセッションパラメータを指定するには、フレームリレーリンクのラベル交換を管理するときに使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FR Sess Parms (0x0502) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, Frame Relay Merge Capabilities Specifies the merge capabilities of a Frame Relay switch. The following values are supported in this version of the specification:
Mは、リレー機能をマージフレームは、フレームリレースイッチのマージ機能を指定します。次の値は、仕様のこのバージョンでサポートされています。
Value Meaning
値意味
0 Merge not supported 1 Merge supported
0マージ1つのマージはサポートされサポートされていません
Non-merge and merge Frame Relay LSRs may freely interoperate.
非マージおよびマージフレームリレーのLSRは自由に相互運用可能。
N, Number of label range components Specifies the number of Frame Relay Label Range Components included in the TLV.
N、ラベル範囲コンポーネントの数は、範囲のコンポーネントは、TLVに含まフレームリレーラベルの数を指定します。
D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can support the use of a given DLCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning a given DLCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP
D、VC方向性0の値は、LSRが独立して、両方のリンク方向のためのラベルとして与えられたDLCIの使用をサポートすることができることを意味し、双方向のVC機能を指定します。 1の値が与えられたDLCIはリンクだけで一つの方向のためのラベルマッピングに表示されることを意味し、単方向のVC機能を指定します。ピアのいずれかまたは両方が単方向のVC能力を指定すると、以下のように、両方のLSRは、リンクのための単方向のVCラベルの割り当てを使用しています。 LSRは、符号なし整数としてのLDP識別子を比較します。大きな自民党とのLSR
Identifier may assign only odd-numbered DLCIs in the range as labels. The system with the smaller LDP Identifier may assign only even-numbered DLCIs in the range as labels.
識別子は、ラベルとして範囲でのみ奇数のDLCIを割り当てることができます。小さいLDP識別子を持つシステムは、ラベルとして範囲でのみ、偶数のDLCIを割り当てることができます。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
One or more Frame Relay Label Range Components A list of Frame Relay Label Range Components which together specify the Label range supported by the transmitting LSR.
一つ以上のフレーム・リレーラベル範囲コンポーネント一緒に送信LSRでサポートされているラベルの範囲を指定するフレーム・リレーラベル範囲コンポーネントのリスト。
A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session.
受信LSRは、受信された範囲と、自身のサポートラベル範囲との交点を計算しなければなりません。交点LSRが割り当てるラベルを受け入れることができる範囲です。 LSRは、範囲の交点がNULLであるために隣人とのセッションを確立してはなりません。この場合、LSRは、初期設定のメッセージへの応答でのセッション拒否/パラメータラベル範囲通知メッセージを送信し、セッションを確立してはなりません。
The encoding for a Frame Relay Label Range Component is:
フレームリレーラベル範囲コンポーネントのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
Len This field specifies the number of bits of the DLCI. The following values are supported:
レンは、このフィールドにはDLCIのビット数を指定します。次の値がサポートされています。
Len DLCI bits
レンDLCIビット
0 10 2 23
０ １０ ２ ２３
Len values 1 and 3 are reserved.
LENは、1と3は予約された値。
Minimum DLCI This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI should be right justified in this field and unused bits should be set to 0.
最小DLCIは、この23ビットのフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCI）のブロックの下限を指定します。 DLCIは、この分野で右揃えであるべきであり、未使用ビットが0に設定されるべきです。
Maximum DLCI This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI should be right justified in this field and unused bits should be set to 0.
最大DLCIは、この23ビットのフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCI）のブロックの上限を指定します。 DLCIは、この分野で右揃えであるべきであり、未使用ビットが0に設定されるべきです。
Note that there is no Generic Session Parameters TLV for sessions which advertise Generic Labels.
一般的なラベルを宣伝セッションのための一般的なセッションパラメータTLVが存在しないことに注意してください。
See Section "LDP Session Establishment" and particularly Section "Session Initialization" for general procedures for handling the Initialization Message.
初期化メッセージを処理するための一般的な手順については、「LDPセッションの確立」と特にセクション「セッション初期化」を参照してください。
An LSR sends KeepAlive Messages as part of a mechanism that monitors the integrity of the LDP session transport connection.
LSRは、LDPセッションのトランスポート接続の健全性を監視する機構の一部として、キープアライブメッセージを送信します。
The encoding for the KeepAlive Message is:
キープアライブメッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| KeepAlive (0x0201) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Optional Parameters No optional parameters are defined for the KeepAlive message.
オプションのパラメータはオプションパラメータは、キープアライブメッセージのために定義されていません。
The KeepAlive Timer mechanism described in Section "Maintaining LDP Sessions" resets a session KeepAlive timer every time an LDP PDU is received on the session TCP connection. The KeepAlive Message is provided to allow reset of the KeepAlive Timer in circumstances where an LSR has no other information to communicate to an LDP peer.
「LDPセッションを維持する」セクションで説明したキープアライブタイマーメカニズムは、セッションキープアライブタイマーにLDP PDUは、セッションのTCP接続で受信されるたびにリセットされます。 KEEPALIVEメッセージは、LSRは、LDPピアに通信するための他の情報を有していない状況でキープアライブタイマーのリセットを可能にするために設けられています。
An LSR must arrange that its peer receive an LDP Message from it at least every KeepAlive Time period. Any LDP protocol message will do but, in circumstances where no other LDP protocol messages have been sent within the period, a KeepAlive message must be sent.
LSRは、そのピアが、それは、少なくともすべてのキープアライブ時間帯からLDPメッセージを受け取ることを手配しなければなりません。任意のLDPプロトコルメッセージは、他のLDPプロトコルメッセージは、期間内に送信されていない状況では、キープアライブメッセージを送信しなければならない、やるけどます。
An LSR sends the Address Message to an LDP peer to advertise its interface addresses.
LSRは、そのインタフェースのアドレスを通知するLDPピアにアドレスメッセージを送信します。
The encoding for the Address Message is:
アドレスメッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address (0x0300) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Address List TLV The list of interface addresses being advertised by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV".
一覧TLVを送信するLSRによってアドバタイズされたインタフェースアドレスのリストをアドレス。アドレス一覧TLVのエンコーディングは、「リストTLVアドレス」セクションで指定されています。
Optional Parameters No optional parameters are defined for the Address message.
オプションのパラメータはオプションパラメータは、アドレスメッセージのために定義されていません。
An LSR that receives an Address Message message uses the addresses it learns to maintain a database for mapping between peer LDP Identifiers and next hop addresses; see Section "LDP Identifiers and Next Hop Addresses".
アドレスメッセージのメッセージを受信したLSRは、それがピアLDP識別子と次ホップアドレスの間のマッピングのためのデータベースを維持するために、学習アドレスを使用します。セクション「LDP識別子と次ホップアドレス」を参照してください。
When a new LDP session is initialized and before sending Label Mapping or Label Request messages an LSR should advertise its interface addresses with one or more Address messages.
新しいLDPセッションが初期化され、ラベルマッピングまたはラベル要求メッセージを送信する前に、LSRは、一つ以上のアドレスメッセージでそのインターフェイスアドレスをアドバタイズする必要があるとき。
Whenever an LSR "activates" a new interface address, it should advertise the new address with an Address message.
LSRは新しいインターフェイスアドレスを「アクティブ化」するたびに、アドレスメッセージで新しいアドレスを宣伝する必要があります。
Whenever an LSR "de-activates" a previously advertised address, it should withdraw the address with an Address Withdraw message; see Section "Address Withdraw Message".
LSRが以前に広告を出したアドレスを「デアクティブ」ときはいつでも、それはメッセージを撤回アドレスとアドレスを撤回すべきです。セクション「アドレスがメッセージを撤回する」を参照してください。
If an LSR does not support the Address Family specified in the Address List TLV, it should send an "Unsupported Address Family" Notification to its LDP signalling an error and abort processing the message.
LSRがアドレス一覧TLVで指定されたアドレスファミリをサポートしていない場合は、エラーを知らせるそのLDPに「サポートされていないアドレスファミリー」の通知を送信し、メッセージの処理を中止すべきです。
An LSR sends the Address Withdraw Message to an LDP peer to withdraw previously advertised interface addresses.
LSRは、住所は、以前に広告を出しインターフェイスアドレスを撤回するLDPピアへのメッセージを撤回送信します。
The encoding for the Address Withdraw Message is:
メッセージを撤回アドレスのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address Withdraw (0x0301) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
Address list TLV The list of interface addresses being withdrawn by the sending LSR. The encoding for the Address list TLV is specified in Section "Address List TLV".
インターフェイスアドレスのアドレスリストTLVリストを送信するLSRによって引き出されます。アドレスリストTLVのエンコーディングは、セクション「アドレスリストTLV」に指定されています。
Optional Parameters No optional parameters are defined for the Address Withdraw message.
オプションのパラメータはオプションパラメータは、メッセージを撤回アドレスのために定義されていません。
See Section "Address Message Procedures"
セクション「アドレスメッセージ手順」を参照してください。
An LSR sends a Label Mapping message to an LDP peer to advertise FEC-label bindings to the peer.
LSRは、ピアにFEC-ラベルバインディングをアドバタイズするLDPピアへのラベルマッピングメッセージを送信します。
The encoding for the Label Mapping Message is:
ラベルマッピングメッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
FEC TLV Specifies the FEC component of the FEC-Label mapping being advertised. See Section "FEC TLV" for encoding.
FEC TLVは、公示されているFECラベルマッピングのFECコンポーネントを指定します。エンコーディングについては、「FEC TLV」を参照してください。
Label TLV Specifies the Label component of the FEC-Label mapping. See Section "Label TLV" for encoding.
ラベルTLVはFECラベルマッピングのLabelコンポーネントを指定します。エンコーディングについては、「ラベルTLV」を参照してください。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。オプションのパラメータは以下のとおりです。
Optional Parameter Length Value
オプションのパラメータ長さ値
Label Request 4 See below Message ID TLV Hop Count TLV 1 See below Path Vector TLV variable See below
メッセージID TLVホップ以下のラベル要求4を参照してくださいパス以下のベクトルTLV変数は、以下を参照してくださいTLV 1参照カウント
The encodings for the Hop Count, and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters".
ホップカウント、およびパスベクトルTLVのためのエンコーディングは、「一般的に使用されるパラメータのためのTLVエンコーディング」のセクションに記載されています。
Label Request Message ID If this Label Mapping message is a response to a Label Request message it must include the Request Message Id optional parameter. The value of this optional parameter is the Message Id of the corresponding Label Request Message.
ラベル要求メッセージIDこのラベルマッピングメッセージをラベル要求メッセージへの応答である場合には、要求メッセージIDオプションのパラメータを含める必要があります。このオプションパラメータの値は、対応するラベル要求メッセージのメッセージIDです。
Hop Count Specifies the running total of the number of LSR hops along the LSP being setup by the Label Message. Section "Hop Count Procedures" describes how to handle this TLV.
ホップカウントは、LSRの数の累計がラベルメッセージによってLSPという設定に沿ってホップ指定します。セクション「カウント手順をホップは」このTLVを処理する方法について説明します。
Path Vector Specifies the LSRs along the LSP being setup by the Label Message. Section "Path Vector Procedures" describes how to handle this TLV.
パスベクトルは、LSPはラベルメッセージによって設定さに沿ってのLSRを指定します。セクション「パスベクトル手順」このTLVを処理する方法について説明します。
The Mapping message is used by an LSR to distribute a label mapping for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC to multiple LDP peers, it is a local matter whether it maps a single label to the FEC, and distributes that mapping to all its peers, or whether it uses a different mapping for each of its peers.
マッピングメッセージは、LDPピアにFECのためのラベルマッピングを配布するためにLSRによって使用されます。 LSRが複数のLDPピアへのFECのためのマッピングを配布する場合、それはFECへの単一のラベルをマップするかどうかローカルの問題である、とそのすべてのピアにそのマッピングを配布、またはそれは、そのピアごとに異なるマッピングを使用するかどうか。
An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings.
LSRは、それが配布したラベルのマッピングの一貫性のために責任がある、とその仲間は、これらのマッピングを持っていること。
An LSR receiving a Label Mapping message from a downstream LSR for a Prefix or Host Address FEC Element should not use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element.
そのルーティングテーブルが正確にFEC要素と一致するエントリが含まれていない限り、プレフィックスまたはホストアドレスFEC要素のための川下のLSRからラベルマッピングメッセージを受信したLSRは、転送のためのラベルを使用しないでください。
See Appendix A "LDP Label Distribution Procedures" for more details.
詳細は、付録A「LDPラベル配布手順」を参照してください。
If an LSR is configured for independent control, a mapping message is transmitted by the LSR upon any of the following conditions:
LSRが独立制御用に設定されている場合、マッピングメッセージは、次の条件のいずれかの際にLSRによって送信されます。
1. The LSR recognizes a new FEC via the forwarding table, and the label advertisement mode is Downstream Unsolicited advertisement.
1. LSRは、フォワーディングテーブルを経由して新しいFECを認識し、ラベル広告モードは、ダウンストリーム迷惑な広告です。
2. The LSR receives a Request message from an upstream peer for a FEC present in the LSR's forwarding table.
2. LSRはLSRの転送テーブルにFEC存在のために上流のピアから要求メッセージを受信します。
3. The next hop for a FEC changes to another LDP peer, and loop detection is configured.
3. FEC別のLDPピアへの変更、およびループ検出用のネクストホップが設定されています。
5. The receipt of a mapping from the downstream next hop AND a) no upstream mapping has been created OR b) loop detection is configured OR c) the attributes of the mapping have changed.
5.下流の次のホップからのマッピングを受信するAND a）は上流のマッピングが作成されていないまたはb）ループ検出が設定されている、またはc）マッピングの属性が変更されています。
If an LSR is doing ordered control, a Mapping message is transmitted by downstream LSRs upon any of the following conditions:
LSRが注文した制御を行っている場合は、マッピングメッセージは、次の条件のいずれかの時に下流のLSRによって送信されます。
1. The LSR recognizes a new FEC via the forwarding table, and is the egress for that FEC.
1. LSRは、フォワーディングテーブルを介して新しいFECを認識し、そのFECのための出口です。
2. The LSR receives a Request message from an upstream peer for a FEC present in the LSR's forwarding table, and the LSR is the egress for that FEC OR has a downstream mapping for that FEC.
2. LSRはLSRの転送テーブルにFEC存在するため、上流側のピアからの要求メッセージを受信し、LSRはそのFECのための出口であるか、そのFECのためのダウンストリームマッピングを有しています。
3. The next hop for a FEC changes to another LDP peer, and loop detection is configured.
3. FEC別のLDPピアへの変更、およびループ検出用のネクストホップが設定されています。
5. The receipt of a mapping from the downstream next hop AND a) no upstream mapping has been created OR b) loop detection is configured OR c) the attributes of the mapping have changed.
5.下流の次のホップからのマッピングを受信するAND a）は上流のマッピングが作成されていないまたはb）ループ検出が設定されている、またはc）マッピングの属性が変更されています。
In general, the upstream LSR is responsible for requesting label mappings when operating in Downstream on Demand mode. However, unless some rules are followed, it is possible for neighboring LSRs with different advertisement modes to get into a livelock situation where everything is functioning properly, but no labels are distributed. For example, consider two LSRs Ru and Rd where Ru is the upstream LSR and Rd is the downstream LSR for a particular FEC. In this example, Ru is using Downstream Unsolicited advertisement mode and Rd is using Downstream on Demand mode. In this case, Rd may assume that Ru will request a label mapping when it wants one and Ru may assume that Rd will advertise a label if it wants Ru to use one. If Rd and Ru operate as suggested, no labels will be distributed from Rd to Ru.
一般的には、上流のLSRは、オンデマンドモードにダウンストリームで動作しているときに、ラベルマッピングを要求する責任があります。いくつかのルールが守られていない限りしかし、それはすべてが正常に機能しているライブロック状況に入るために異なる広告モードでのLSR隣接可能ですが、何のラベルが配布されていません。例えば、二つのLSR Ru及びRuが上流のLSRであり、Rdは特定のFECのために下流LSRであるRDは考えます。この例では、Ruはダウンストリーム迷惑広告モードを使用しているとRdがオンデマンドモードでダウンストリームを使用しています。この場合、Rdがそれが1を望んでいるとRuはそれがRuはいずれかを使用したい場合Rdはラベルを宣伝することを仮定してもよいときRuがラベルマッピングを要求することを仮定してもよいです。提案されているようRdとRuが作動した場合は、何のラベルがRuにRdのから配布されません。
This livelock situation can be avoided if the following rule is observed: an LSR operating in Downstream on Demand mode should not be expected to send unsolicited mapping advertisements. Therefore, if the downstream LSR is operating in Downstream on Demand mode, the upstream LSR is responsible for requesting label mappings as needed.
以下のルールが観測されている場合は、このライブロック状況を回避することができる：需要モードにダウンストリームで動作しているLSRは、未承諾のマッピング通知を送信すると期待すべきではありません。下流のLSRは、オンデマンドモードにダウンストリームで動作している場合そのため、上流のLSRは、必要に応じてラベルマッピングを要求するための責任があります。
In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires.
一般的には、下流のLSRは、ラベルを使用するために上流のLSRを望んでいるとき、ラベルマッピングを広告するための責任があります。それがそう望むならば、上流LSRはマッピング要求を発行することができます。
The combination of Downstream Unsolicited mode and conservative label retention can lead to a situation where an LSR releases the label for a FEC that it later needs. For example, if LSR Rd advertises to LSR Ru the label for a FEC for which it is not Ru's next hop, Ru will release the label. If Ru's next hop for the FEC later changes to Rd, it needs the previously released label.
ダウンストリーム迷惑モードと保守的なラベル保持の組み合わせは、LSRが、それは後で必要があるとFECのラベルを解放するような状況につながることができます。 LSR RdがLSR Ruに、それは、RuのネクストホップされていないFECのためのラベルをアドバタイズした場合、Ruはラベルを解放します。 FECのためのRuの次のホップが後でRDに変更された場合、それは、以前にリリースされたラベルを必要とします。
To deal with this situation either Ru can explicitly request the label when it needs it, or Rd can periodically readvertise it to Ru. In many situations Ru will know when it needs the label from Rd. For example, when its next hop for the FEC changes to Rd. However, there could be situations when Ru does not. For example, Rd may be attempting to establish an LSP with non-standard properties. Forcing Ru to explicitly request the label in this situation would require it to maintain state about a potential LSP with non-standard properties.
このような状況に対処するために、それはそれを必要とするときRuは、明示的にラベルを要求することができ、またはRdが定期的にRuにそれをreadvertiseことができます。それはRdのからラベルを必要とするとき、多くの状況ではRuを知ることができます。例えば、RDにFEC変更のためにその次のホップ。 Ruがないときしかし、状況があるかもしれません。例えば、R dは非標準特性を有するLSPを確立しようとすることができます。明示的にこのような状況でラベルを要求するためのRuを強制すると、非標準のプロパティを持つ可能性のあるLSPについての状態を維持するためにそれを必要とします。
In situations where Ru knows it needs the label, it is responsible for explicitly requesting the label by means of a Label Request message. In situations where Ru may not know that it needs the label, Rd is responsible for periodically readvertising the label to Ru.
Ruが、それはラベルを必要と知っている状況では、明示的にラベル要求メッセージによってラベルを要求する責任があります。 Ruが、それはラベルを必要としていることを知らないかもしれない状況では、Rdが定期的にRuにラベルをreadvertisingする責任があります。
For this version of LDP, the only situation where Ru knows it needs a label for a FEC from Rd is when Rd is its next hop for the FEC, Ru does not have a label from Rd, and the LSP for the FEC is one that can be established with TLVs defined in this document.
自民党のこのバージョンでは、RdがFECのための次のホップであるとき、Ruは、それはRdのからのFECのラベルを必要と知っている唯一の状況は、RuがRdのからラベルを持っていないされ、およびFECのためのLSPはその一つですこの文書で定義されたTLVを確立することができます。
An LSR sends the Label Request Message to an LDP peer to request a binding (mapping) for a FEC.
LSRは、FECのバインディング（マッピング）を要求するLDPピアにラベル要求メッセージを送信します。
The encoding for the Label Request Message is:
ラベル要求メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
FEC TLV The FEC for which a label is being requested. See Section "FEC TLV" for encoding.
FEC TLVラベルが要求されているFEC。エンコーディングについては、「FEC TLV」を参照してください。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。オプションのパラメータは以下のとおりです。
Optional Parameter Length Value
オプションのパラメータ長さ値
Hop Count TLV 1 See below Path Vector TLV variable See below
ホップは、下記を参照してくださいパスベクトルTLV変数の下1参照TLVを数えます
The encodings for the Hop Count, and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters".
ホップカウント、およびパスベクトルTLVのためのエンコーディングは、「一般的に使用されるパラメータのためのTLVエンコーディング」のセクションに記載されています。
Hop Count Specifies the running total of the number of LSR hops along the LSP being setup by the Label Request Message. Section "Hop Count Procedures" describes how to handle this TLV.
ホップカウントは、LSRの数の累計がラベル要求メッセージによってLSPという設定に沿ってホップ指定します。セクション「カウント手順をホップは」このTLVを処理する方法について説明します。
Path Vector Specifies the LSRs along the LSR being setup by the Label Request Message. Section "Path Vector Procedures" describes how to handle this TLV.
パスベクトルは、ラベル要求メッセージによってLSRという設定に沿ってのLSRを指定します。セクション「パスベクトル手順」このTLVを処理する方法について説明します。
The Request message is used by an upstream LSR to explicitly request that the downstream LSR assign and advertise a label for a FEC.
要求メッセージは、明示的に下流LSRがFECのためにラベルを割り当て、宣伝することを要求するために、上流のLSRによって使用されます。
An LSR may transmit a Request message under any of the following conditions:
LSRは、以下のいずれかの条件の下で要求メッセージを送信することができます。
1. The LSR recognizes a new FEC via the forwarding table, and the next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop for the given FEC.
1. LSRは、フォワーディングテーブルを介して新しいFECを認識し、次のホップは、LDPピアであり、LSRは、既に与えられたFECのための次のホップからのマッピングを持っていません。
2. The next hop to the FEC changes, and the LSR doesn't already have a mapping from that next hop for the given FEC.
2. FEC変化へのネクストホップ、およびLSRは、すでに与えられたFECのためにその次のホップからのマッピングを持っていません。
Note that if the LSR already has a pending Label Request message for the new next hop it should not issue an additional Label Request in response to the next hop change.
LSRは、すでに新しいのために保留中のラベル要求メッセージを持っている場合は、次のことが次のホップの変化に応じて追加のラベル要求を発行してはならないホップことに注意してください。
3. The LSR receives a Label Request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop.
3. LSRが上流のLDPピアからのFECのラベルリクエストを受信し、FEC次ホップはLDPピアであり、LSRは、既に次のホップからのマッピングを持っていません。
Note that since a non-merge LSR must setup a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages for a given FEC outstanding at the same time.
ラベルを要求する各上流ピアの非マージLSRの必須の設定独立したLSPいるので、それは、そのような各ピアに別々のラベル要求を送信しなければならないことに注意してください。この結果、非マージLSRが同時に優れた特定のFECのために複数のラベル要求メッセージを持っているかもしれないということです。
The receiving LSR should respond to a Label Request message with a Label Mapping for the requested label or with a Notification message indicating why it cannot satisfy the request.
受信LSRは、要求されたラベルのか、それは要求を満たすことができない理由を示す通知メッセージとラベルマッピングとラベル要求メッセージに応答する必要があります。
When the FEC for which a label is requested is a Prefix FEC Element or a Host Address FEC Element, the receiving LSR uses its routing table to determine its response. Unless its routing table includes an entry that exactly matches the requested Prefix or Host Address, the LSR must respond with a No Route Notification message.
ラベルが要求されたFECは、プレフィックスFEC要素またはホストアドレスFEC要素である場合、受信LSRは、その応答を決定するために、自身のルーティングテーブルを使用します。そのルーティングテーブルが正確に要求されたプレフィックスまたはホストアドレスと一致するエントリが含まれていない限り、LSRはNOルート通知メッセージで応答しなければなりません。
The message ID of the Label Request message serves as an identifier for the Label Request transaction. When the receiving LSR responds with a Label Mapping message, the mapping message must include a Label Request/Returned Message ID TLV optional parameter which includes the message ID of the Label Request message. Note that since LSRs use Label Request message IDs as transaction identifiers an LSR should not reuse the message ID of a Label Request message until the corresponding transaction completes.
ラベル要求メッセージのメッセージIDは、ラベル要求トランザクションの識別子として機能します。受信LSRはLabel Mappingメッセージで応答する場合、マッピングメッセージは、ラベル要求/ラベル要求メッセージのメッセージIDを含む返されるメッセージID TLVオプションのパラメータを含める必要があります。トランザクションは、識別子としてのLSRがラベル要求メッセージIDを使用しているため、対応するトランザクションが完了するまでLSRは、ラベル要求メッセージのメッセージIDを再利用してはならないことに注意してください。
This version of the protocol defines the following Status Codes for the Notification message that signals a request cannot be satisfied:
プロトコルのこのバージョンでは、要求を満たすことができない信号通知メッセージのための次のステータスコードを定義します。
No Route The FEC for which a label was requested includes a FEC Element for which the LSR does not have a route.
ラベルが要求されたNOルートザ・FECは、LSRはルートを持たないためにFEC要素が含まれていません。
No Label Resources The LSR cannot provide a label because of resource limitations. When resources become available the LSR must notify the requesting LSR by sending a Notification message with the Label Resources Available Status Code.
いいえラベルリソースLSRがあるため、リソース制限のラベルを提供することはできません。リソースが利用可能になったときLSRは、ラベルのリソース利用可能なステータスコードで通知メッセージを送信することにより、要求するLSRに通知しなければなりません。
An LSR that receives a No Label Resources response to a Label Request message must not issue further Label Request messages until it receives a Notification message with the Label Resources Available Status code.
それはラベルのリソース利用可能なステータスコードで通知メッセージを受信するまで、さらにラベル要求メッセージを発行してはならないラベル要求メッセージにないラベルリソース応答を受け取るLSR。
Loop Detected The LSR has detected a looping Label Request message.
ループは、LSRがループラベル要求メッセージを検出した検出しました。
See Appendix A "LDP Label Distribution Procedures" for more details.
詳細は、付録A「LDPラベル配布手順」を参照してください。
The Label Abort Request message may be used to abort an outstanding Label Request message.
ラベル中止要求メッセージは、優れたラベル要求メッセージを中止するために使用することができます。
The encoding for the Label Abort Request Message is:
ラベル中止要求メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Abort Req (0x0404) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
FEC TLV Identifies the FEC for which the Label Request is being aborted.
FEC TLVはラベル要求が中止されているFECを識別します。
Label Request Message ID TLV Specifies the message ID of the Label Request message to be aborted.
ラベル要求メッセージID TLVは中止するラベル要求メッセージのメッセージIDを指定します。
Optional Parameters No optional parameters are defined for the Label Abort Req message.
オプションのパラメータはオプションパラメータは、ラベル中止Reqメッセージ用に定義されていません。
An LSR Ru may send a Label Abort Request message to abort an outstanding Label Request message for FEC sent to LSR Rd in the following circumstances:
LSR Ruは以下の状況ではLSR RDに送らFECのための優れたラベル要求メッセージを中止するラベル中止要求メッセージを送信することができます。
2. Ru is a non-merge, non-ingress LSR and has received a Label Abort Request for FEC from an upstream peer Y.
2. Ruは非マージ、非入口LSRであり、上流のピアY.からFECのラベルアボート要求を受信しました
3. Ru is a merge, non-ingress LSR and has received a Label Abort Request for FEC from an upstream peer Y and Y is the only (last) upstream LSR requesting a label for FEC.
3. Ruがマージ、非入口LSRであり、上流のピアYからFECのラベルアボート要求を受信したとYはLSRがFECのためのラベルを要求上流（最後）のみです。
There may be other situations where an LSR may choose to abort an outstanding Label Request message in order to reclaim resource associated with the pending LSP. However, specification of general strategies for using the abort mechanism is beyond the scope of LDP.
LSRは、保留中のLSPに関連付けられたリソースを再利用するためには、優れたラベル要求メッセージを中止することを選択することが他の状況があるかもしれません。しかし、アボートメカニズムを使用するための一般的な戦略の仕様は、自民党の範囲を超えています。
When an LSR receives a Label Abort Request message, if it has not previously responded to the Label Request being aborted with a Label Mapping message or some other Notification message, it must acknowledge the abort by responding with a Label Request Aborted Notification message. The Notification must include a Label Request Message ID TLV that carries the message ID of the aborted Label Request message.
LSRは、ラベル中止要求メッセージを受信すると、それは以前にラベルマッピングメッセージまたは他の通知メッセージで中止されているラベル要求に応答しなかった場合、それは、通知メッセージを中止ラベル要求に応答することによって、アボートを承認しなければなりません。通知は中止されたラベル要求メッセージのメッセージIDを運ぶラベル要求メッセージID TLVを含まなければなりません。
If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping message or a Notification message, it ignores the abort request.
LSRは、ラベル中止要求メッセージを受信した場合、それはラベルマッピングメッセージや通知メッセージで問題のラベル要求に応答した後に、それは中止要求を無視します。
If an LSR receives a Label Mapping message in response to a Label Request message after it has sent a Label Abort Request message to abort the Label Request, the label in the Label Mapping message is valid. The LSR may choose to use the label or to release it with a Label Release message.
LSRは、ラベル要求メッセージに応じて、ラベルマッピングメッセージを受信した場合、それはラベル要求を中止するラベル中止要求メッセージを送信した後、ラベルマッピングメッセージにラベルが有効です。 LSRは、ラベルを使用するか、ラベル解放メッセージでそれを解放することもできます。
An LSR aborting a Label Request message may not reuse the Message ID for the Label Request message until it receives one of the following from its peer:
それはそのピアから次のいずれかを受信するまで、ラベル要求メッセージのメッセージIDを再利用しないことがありラベル要求メッセージを中止LSR：
- A Label Request Aborted Notification message acknowledging the abort;
- ラベル要求中止通知メッセージには、アボートを認めます。
- A Label Mapping message in response to the Label Request message being aborted;
- 中止されるラベル要求メッセージに応答して、Label Mappingメッセージ。
- A Notification message in response to the Label Request message being aborted (e.g., Loop Detected, No Label Resources, etc.).
- 中止されるラベル要求メッセージ（例えば、ループ検出、なしラベル資源、等）に応答して通知メッセージ。
To protect itself against tardy peers or faulty peer implementations an LSR may choose to time out receipt of the above. The time out period should be relatively long (several minutes). If the time out period elapses with no reply from the peer the LSR may reuse the Message Id of the Label Request message; if it does so, it should also discard any record of the outstanding Label Request and Label Abort messages.
遅刻ピアまたはピア故障実装に対してそれ自体を保護するために、LSRは、上記のタイムアウト受信することを選択することができます。タイムアウト期間が比較的長い（数分）でなければなりません。もし時間が経過LSRがラベル要求メッセージのメッセージIDを再利用することができるピアから応答なしとのタイムアウト期間。それがそうならば、それはまた、優れたラベル要求の任意のレコードを破棄し、中止メッセージにラベルを付ける必要があります。
Note that the response to a Label Abort Request message is never "ordered". That is, the response does not depend on the downstream state of the LSP setup being aborted. An LSR receiving a Label Abort Request message must process it immediately, regardless of the downstream state of the LSP, responding with a Label Request Aborted Notification or ignoring it, as appropriate.
ラベル中止要求メッセージに対する応答が「注文していない」んことに注意してください。つまり、応答が中止されたLSP設定の下流状態に依存しません。 LSRは、必要に応じて、ラベル要求中止通知で応答するか、またはそれを無視して、関係なく、LSPの下流状態の、すぐにそれを処理しなければならないラベルアボート要求メッセージを受信します。
An LSR sends a Label Withdraw Message to an LDP peer to signal the peer that the peer may not continue to use specific FEC-label mappings the LSR had previously advertised. This breaks the mapping between the FECs and the labels.
LSRは、ラベルは、ピアは、特定のFEC-ラベルはLSRが以前に広告を出していたマッピングを使用し続けないかもしれないピアに信号を送るためにLDPピアへのメッセージを撤回送信します。これは、FECをとラベルの間のマッピングを破ります。
The encoding for the Label Withdraw Message is:
メッセージを撤回ラベルのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
FEC TLV Identifies the FEC for which the FEC-label mapping is being withdrawn.
FEC TLVはFECラベルマッピングが撤回されているFECを識別します。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。オプションのパラメータは以下のとおりです。
Optional Parameter Length Value
オプションのパラメータ長さ値
Label TLV variable See below
ラベルTLV変数は、以下を参照してください
The encoding for Label TLVs are found in Section "Label TLVs".
ラベルのTLVのエンコーディングは、セクション「ラベルのTLV」に記載されています。
Label If present, specifies the label being withdrawn (see procedures below).
ラベルは、存在する場合、（下記の手順を参照してください）引き出されるラベルを指定します。
An LSR transmits a Label Withdraw message under the following conditions:
LSRは、ラベルには以下の条件でメッセージを撤回送信します：
1. The LSR no longer recognizes a previously known FEC for which it has advertised a label.
1. LSRは、もはやそれはラベルを広告しているため、以前に知られているFECを認識しません。
2. The LSR has decided unilaterally (e.g., via configuration) to no longer label switch a FEC (or FECs) with the label mapping being withdrawn.
2. LSRは、ラベルマッピングが引き出されるとFEC（またはのFEC）を切り替えるもはやラベルに（コンフィギュレーションを介して、例えば）一方的に決定しました。
The FEC TLV specifies the FEC for which labels are to be withdrawn. If no Label TLV follows the FEC, all labels associated with the FEC are to be withdrawn; otherwise only the label specified in the optional Label TLV is to be withdrawn.
FEC TLVはラベルが撤回されるべきためにFECを指定します。何のラベルTLVはFECを次のない場合は、FECに関連したすべてのラベルが撤回されることになります。そうでない場合は、オプションのラベルTLVで指定されたラベルだけは撤回されます。
The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Withdraw message contains an optional Label TLV, then the label is to be withdrawn from all FECs to which it is bound. If there is not an optional Label TLV in the Label Withdraw message, then the sending LSR is withdrawing all label mappings previously advertised to the receiving LSR.
FEC TLVは、ワイルドカードFEC要素が含まれていてもよいです。もしそうなら、それは他のFEC要素を含まなくてもよいです。この場合、ラベルは、メッセージを撤回場合は、オプションのラベルTLVが含まれている、そしてラベルは、それがバインドされている全てのFECから撤退することがあります。ラベル撤回メッセージ内の任意のラベルTLVが存在しない場合、送信LSRが撤退されたすべてのラベルマッピングは、以前に受信LSRに宣伝しました。
An LSR that receives a Label Withdraw message must respond with a Label Release message.
ラベルは、メッセージを撤回受け取るLSRは、ラベル解放メッセージで応答する必要があります。
See Appendix A "LDP Label Distribution Procedures" for more details.
詳細は、付録A「LDPラベル配布手順」を参照してください。
An LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC-label mappings previously requested of and/or advertised by the peer.
LSRはLSRは、もはや以前の要求および/またはピアによってアドバタイズ特定のFECラベルマッピングを必要とするピアに信号を送るためにLDPピアにラベル解放メッセージを送信します。
The encoding for the Label Release Message is:
ラベル解放メッセージのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
メッセージIDの32ビット値は、このメッセージを識別するために使用されます。
FEC TLV Identifies the FEC for which the FEC-label mapping is being released.
FEC TLVはFECラベルマッピングがリリースされているFECを識別します。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメータはこの可変長フィールドは0以上のパラメータ、TLVとして符号化それぞれを含んでいます。オプションのパラメータは以下のとおりです。
Optional Parameter Length Value
オプションのパラメータ長さ値
Label TLV variable See below
ラベルTLV変数は、以下を参照してください
The encodings for Label TLVs are found in Section "Label TLVs".
ラベルのTLVのための符号化方式は、セクション「ラベルのTLV」に記載されています。
Label If present, the label being released (see procedures below).
ラベルが存在する場合、ラベルは（下記の手順を参照してください）にリリースされています。
An LSR transmits a Label Release message to a peer when it is no longer needs a label previously received from or requested of that peer.
LSRは、それはもはや以前から受信したか、そのピアの要求されたラベルを必要としているピアにラベル解放メッセージを送信します。
An LSR must transmit a Label Release message under any of the following conditions:
LSRは、次のいずれかの条件の下でラベル解放メッセージを送信する必要があります。
1. The LSR which sent the label mapping is no longer the next hop for the mapped FEC, and the LSR is configured for conservative operation.
1.ラベルマッピングを送信したLSRはもはやマッピングされたFECのための次のホップがなく、LSRは保守操作のために構成されています。
2. The LSR receives a label mapping from an LSR which is not the next hop for the FEC, and the LSR is configured for conservative operation.
2. LSRはFECのための次のホップでないLSRからラベルマッピングを受け取り、そしてLSRは保守操作のために構成されています。
Note that if an LSR is configured for "liberal mode", a release message will never be transmitted in the case of conditions (1) and (2) as specified above. In this case, the upstream LSR keeps each unused label, so that it can immediately be used later if the downstream peer becomes the next hop for the FEC.
LSRが「リベラルモード」に設定されている場合、解放メッセージが条件の場合に送信されることはないことに注意してください（1）及び（2）上記指定されるように。下流ピアがFECのための次のホップになった場合、それはすぐに後で使用することができるように、この場合には、上流のLSRは、各未使用のラベルを保持します。
The FEC TLV specifies the FEC for which labels are to be released. If no Label TLV follows the FEC, all labels associated with the FEC are to be released; otherwise only the label specified in the optional Label TLV is to be released.
FEC TLVはラベルが解放されるべきためにFECを指定します。ラベルなしTLVはFECを以下の場合は、FECに関連したすべてのラベルが解放されることになります。そうでない場合は、オプションのラベルTLVで指定された唯一のラベルが解放されます。
The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Release message contains an optional Label TLV, then the label is to be released for all FECs to which it is bound. If there is not an optional Label TLV in the Label Release message, then the sending LSR is releasing all label mappings previously learned from the receiving LSR.
FEC TLVは、ワイルドカードFEC要素が含まれていてもよいです。もしそうなら、それは他のFEC要素を含まなくてもよいです。ラベル解放メッセージは、オプションのラベルTLVが含まれている場合、この場合は、その後、ラベルは、それがバインドされている全てのFECのためにリリースされます。オプションのラベルTLVはラベル解放メッセージに存在しない場合、送信LSRは、以前に受信LSRから学んだすべてのラベルマッピングを解放しています。
See Appendix A "LDP Label Distribution Procedures" for more details.
詳細は、付録A「LDPラベル配布手順」を参照してください。
Support for LDP extensibility includes the rules for the U and F bits that specify how an LSR should handle unknown TLVs and messages.
LDPの拡張のサポートは、LSRが未知のTLVとメッセージをどのように処理するかを指定UとFビットのためのルールが含まれています。
This section specifies TLVs and messages for vendor-private and experimental use.
このセクションでは、ベンダープライベートと実験的な使用のためのTLVとメッセージを指定します。
Vendor-private TLVs and messages are used to convey vendor-private information between LSRs.
ベンダーのプライベートのTLVとのメッセージがLSRの間でベンダーのプライベートな情報を伝えるために使用されています。
The Type range 0x3E00 through 0x3EFF is reserved for vendor-private TLVs.
0x3EFFスルー型範囲0x3E00は、ベンダー・プライベートTLVのために予約されています。
The encoding for a vendor-private TLV is:
ベンダー・プライベートTLVのエンコーディングは以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x3E00-0x3EFF) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data.... |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist.
Uは不明TLVビットビット。 Uがクリアされている場合、未知のTLVを受信すると、（= 0）、通知メッセージの発信元に戻さなければならず、全体のメッセージが無視されなければなりません。 Uが設定されている場合（= 1）、未知のTLVは無視され、未知のTLVが存在しなかったかのようにメッセージの残りの部分が処理されます。
The determination as to whether a vendor-private message is understood is based on the Type and the mandatory Vendor ID field.
ベンダープライベートメッセージが理解されているか否かの決意は、タイプおよび必須のベンダーIDフィールドに基づいています。
F bit Forward unknown TLV bit. This bit only applies when the U bit is set and the LDP message containing the unknown TLV is is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message.
Fビットフォワード未知のTLVビット。 Uビットが設定され、未知のTLVを含むLDPメッセージが転送される場合、このビットにのみ適用されます。 Fがクリアされている場合（= 0）、未知のTLVを含むメッセージで転送されません。 Fが設定されている場合（= 1）、未知のTLVを含むメッセージで転送されます。
Type Type value in the range 0x3E00 through 0x3EFF. Together, the Type and Vendor Id field specify how the Data field is to be interpreted.
0x3EFFまでの範囲0x3E00でType値を入力します。一緒に、タイプとベンダーIDフィールドは、データフィールドがどのように解釈されるかを指定します。
Length Specifies the cumulative length in octets of the Vendor ID and Data fields.
長さは、ベンダーIDおよびデータフィールドのオクテットの累積長さを指定します。
Vendor Id 802 Vendor ID as assigned by the IEEE.
IEEEによって割り当てられたベンダーイド802ベンダID。
Data The remaining octets after the Vendor ID in the Value field are optional vendor-dependent data.
データは、ValueフィールドのベンダーIDの後に残りのオクテットは、オプションのベンダーに依存したデータです。
The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-private Messages.
0x3EFFによるメッセージタイプの範囲0x3E00は、ベンダーのプライベートメッセージのために予約されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Msg Type (0x3E00-0x3EFF) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Remaining Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored.
Uは不明なメッセージビットビット。 Uがクリアされている場合、未知のメッセージを受信すると、（= 0）、通知メッセージの発信者に戻されます。 Uが設定されている場合（= 1）、未知のメッセージは無視されます。
The determination as to whether a vendor-private message is understood is based on the Msg Type and the Vendor ID parameter.
ベンダープライベートメッセージが理解されているか否かの決意は、メッセージタイプとベンダIDパラメータに基づいています。
Msg Type Message type value in the range 0x3E00 through 0x3EFF. Together, the Msg Type and the Vendor ID specify how the message is to be interpreted.
0x3EFFスルー範囲0x3E00でMSGタイプメッセージタイプ値。一緒に、メッセージタイプとベンダIDは、メッセージを解釈する方法を指定します。
Message Length Specifies the cumulative length in octets of the Message ID, Vendor ID, Remaining Mandatory Parameters and Optional Parameters.
メッセージの長さは、必須パラメータとオプションパラメータを残り、メッセージID、ベンダーIDのオクテットの累積長さを指定します。
Message ID 32-bit integer used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message will include this Message Id in the notification message; see Section "Notification Message".
このメッセージを識別するために使用されるメッセージIDの32ビット整数。このメッセージに適用することができる特定通知メッセージを容易にするために、送信LSRによって使用されます。このメッセージに応答して、通知メッセージを送信するLSRは、通知メッセージにこのメッセージIDが含まれます。セクション「通知メッセージ」を参照してください。
Vendor ID 802 Vendor ID as assigned by the IEEE.
IEEEによって割り当てられたベンダーID 802ベンダID。
Remaining Mandatory Parameters Variable length set of remaining required message parameters.
残りの必須パラメータ残りの必要なメッセージパラメータの可変長セット。
Optional Parameters Variable length set of optional message parameters.
オプションのメッセージパラメータのオプションパラメータ可変長セット。
LDP support for experimentation is similar to support for vendor-private extensions with the following differences:
実験のため自民党のサポートは、次のような違いを持つベンダプライベート拡張をサポートするために似ています。
- The Type range 0x3F00 through 0x3FFF is reserved for experimental TLVs.
- 0x3FFFのスルー型範囲0x3F00は、実験のTLVのために予約されています。
- The Message Type range 0x3F00 through 0x3FFF is reserved for experimental messages.
- 0x3FFFの通じメッセージタイプの範囲0x3F00は、実験的なメッセージのために予約されています。
- The encodings for experimental TLVs and messages are similar to the vendor-private encodings with the following difference.
- 実験のTLVとのメッセージのエンコーディングは、以下の違いがベンダーのプライベートエンコーディングに似ています。
Experimental TLVs and messages use an Experiment ID field in place of a Vendor ID field. The Experiment ID field is used with the Type or Message Type field to specify the interpretation of the experimental TLV or Message.
実験のTLVとメッセージは、ベンダーIDフィールドの代わりに実験IDフィールドを使用します。実験IDフィールドは、実験TLVやメッセージの解釈を指定するタイプまたはMessage Typeフィールドで使用されています。
Administration of Experiment IDs is the responsibility of the experimenters.
実験IDの管理は、実験者の責任です。
The following are the LDP messages defined in this version of the protocol.
次のプロトコルのこのバージョンで定義されたLDPメッセージです。
Message Name Type Section Title
メッセージ名を入力セクションのタイトル
Notification 0x0001 "Notification Message" Hello 0x0100 "Hello Message" Initialization 0x0200 "Initialization Message"
通知は0x0001「通知メッセージ」こんにちはは0x0100「ハローメッセージ」初期化0x0200「の初期化メッセージ」
KeepAlive 0x0201 "KeepAlive Message" Address 0x0300 "Address Message" Address Withdraw 0x0301 "Address Withdraw Message" Label Mapping 0x0400 "Label Mapping Message" Label Request 0x0401 "Label Request Message" Label Withdraw 0x0402 "Label Withdraw Message" Label Release 0x0403 "Label Release Message" Label Abort Request 0x0404 "Label Abort Request Message" Vendor-Private 0x3E00- "LDP Vendor-private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF
キープアライブ0x0201「キープアライブメッセージ」アドレス0x0300「アドレスメッセージ」アドレスは0x0301「アドレスが取り消しメッセージを」引き出しラベルマッピング0x0400「ラベルマッピングメッセージ」ラベル要求0x0401「ラベル要求メッセージ」ラベルは、0x0402を撤回「ラベルは、メッセージを撤回」ラベル解放0x0403「ラベルリリースメッセージ」ラベル中止要求0x0404 『ラベル中止要求メッセージ』ベンダープライベート0x3E00- 『LDPベンダープライベート拡張機能』 0x3EFF実験0x3F00- 『LDP実験拡張機能』 0x3FFFの
The following are the TLVs defined in this version of the protocol.
以下は、プロトコルのこのバージョンで定義されたTLVです。
TLV Type Section Title
TLVタイプセクションのタイトル
FEC 0x0100 "FEC TLV" Address List 0x0101 "Address List TLV" Hop Count 0x0103 "Hop Count TLV" Path Vector 0x0104 "Path Vector TLV" Generic Label 0x0200 "Generic Label TLV" ATM Label 0x0201 "ATM Label TLV" Frame Relay Label 0x0202 "Frame Relay Label TLV" Status 0x0300 "Status TLV" Extended Status 0x0301 "Notification Message" Returned PDU 0x0302 "Notification Message" Returned Message 0x0303 "Notification Message" Common Hello 0x0400 "Hello Message" Parameters IPv4 Transport Address 0x0401 "Hello Message" Configuration 0x0402 "Hello Message" Sequence Number IPv6 Transport Address 0x0403 "Hello Message" Common Session 0x0500 "Initialization Message" Parameters ATM Session Parameters 0x0501 "Initialization Message" Frame Relay Session 0x0502 "Initialization Message" Parameters Label Request 0x0600 "Label Mapping Message" Message ID Vendor-Private 0x3E00- "LDP Vendor-private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF
FECは0x0100「FEC TLV」アドレス一覧0x0101ホップ「リストTLVアドレス」0x0103「ホップTLVカウント」パスベクトル0x0104「パスベクトルTLV」総称ラベル0x0200「ジェネリックラベルTLV」ATMラベル0x0201カウント「ATMラベルTLV」フレームリレーラベル0x0202 「フレームリレーラベルTLV」ステータス0x0300「ステータスTLV」拡張ステータス0x0301「通知メッセージ」が返さPDUの0x0302「通知メッセージ」返送メッセージの0x0303「通知メッセージ」共通こんにちは0x0400「ハローメッセージ」パラメータのIPv4トランスポートアドレス0x0401の「Helloメッセージ」の設定0x0402「ハローメッセージ」シーケンス番号のIPv6トランスポートアドレス0x0403の「Helloメッセージ」共通セッション0x0500「初期化メッセージ」パラメータATMセッションパラメータて0x0501「初期メッセージ」フレームリレーセッション0x0502「初期化メッセージ」パラメータラベル要求0x0600「ラベルマッピングメッセージ」メッセージIDベンダープライベート0x3E00-「LDPベンダープライベート拡張機能」0x3EFF実験0x3F00-「LDP実験拡張機能」0x3FFFの
The following are the Status Codes defined in this version of the protocol.
以下は、プロトコルのこのバージョンで定義されたステータスコードです。
The "E" column is the required setting of the Status Code E-bit; the "Status Data" column is the value of the 30-bit Status Data field in the Status Code TLV.
「E」の欄には、ステータスコードE-ビットの必要な設定です。 「ステータスデータ」欄には、ステータスコードTLVで30ビットのステータスデータフィールドの値です。
Note that the setting of the Status Code F-bit is at the discretion of the LSR originating the Status TLV.
ステータスコードFビットの設定はステータスTLVを発信するLSRの裁量であることに注意してください。
Status Code E Status Data Section Title
ステータスコードEステータスデータセクションタイトル
Success 0 0x00000000 "Status TLV" Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." Bad Protocol Version 1 0x00000002 "Events Signaled by ..." Bad PDU Length 1 0x00000003 "Events Signaled by ..." Unknown Message Type 0 0x00000004 "Events Signaled by ..." Bad Message Length 1 0x00000005 "Events Signaled by ..." Unknown TLV 0 0x00000006 "Events Signaled by ..." Bad TLV length 1 0x00000007 "Events Signaled by ..." Malformed TLV Value 1 0x00000008 "Events Signaled by ..." Hold Timer Expired 1 0x00000009 "Events Signaled by ..." Shutdown 1 0x0000000A "Events Signaled by ..." Loop Detected 0 0x0000000B "Loop Detection" Unknown FEC 0 0x0000000C "FEC Procedures" No Route 0 0x0000000D "Label Request Mess ..." No Label Resources 0 0x0000000E "Label Request Mess ..." Label Resources / 0 0x0000000F "Label Request Mess ..." Available Session Rejected/ 1 0x00000010 "Session Initialization" No Hello Session Rejected/ 1 0x00000011 "Session Initialization" Parameters Advertisement Mode Session Rejected/ 1 0x00000012 "Session Initialization" Parameters Max PDU Length Session Rejected/ 1 0x00000013 "Session Initialization" Parameters Label Range KeepAlive Timer 1 0x00000014 "Events Signaled by ..." Expired Label Request Aborted 0 0x00000015 "Label Request Abort ..." Missing Message 0 0x00000016 "Events Signaled by ..." Parameters Unsupported Address 0 0x00000017 "FEC Procedures" Family "Address Message Proc ..."
不明なメッセージタイプ0悪いPDU長さ1 0x00000003「...によって知らされるイベント」不正なプロトコルバージョン1 0x00000002「...によって知らされるイベント」成功0 0x00000000の「ステータスTLV」悪いLDP識別子1は0x00000001「...によって通知されるイベント」不正なTLV値悪いTLVの長さ1 0x00000007「...によって知らされるイベント」不明TLV 0 0x00000006「...によって知らされるイベント」不正なメッセージ長さ1 0x00000005「...によって知らされるイベント」0x00000004「...によって通知されるイベント」 1 0x00000008「で...合図イベントは、」タイマーがループ0 0x0000000B「ループ検出」不明FEC 0 0x0000000C「FEC手順を」検出「によって知らされるイベント...」1 0x00000009「によって知らされるイベント...」シャットダウン1 0x0000000Aが期限切れホールドNOルート0 0x0000000D「ラベル要求混乱しない...」いいえラベルリソース0 0x0000000E「ラベル要求混乱...」ラベルリソース/ 0 0x0000000F「ラベル要求混乱...」利用可能なセッション拒否/ 1 0x00000010「セッション初期化」こんにちはませんセッション拒否/ 1 0x00000011「セッション初期化」パラメータ広告モードセッションR 「ラベル要求が中止...」0 0x00000015を中止期限切れのラベル要求「セッション初期化」パラメータの最大PDU長のセッションは「セッションの初期化」パラメータ/ 1 0x00000013を拒否されたラベル範囲キープアライブタイマー1 0x00000014「...によって知らされるイベント」/ 1 0x00000012を排出メッセージ0 0x00000016「によって知らされるイベント...」パラメータサポートされていない住所にファミリー0 0x00000017「FEC手順」欠落「アドレスメッセージPROCを...」
Session Rejected/ 1 0x00000018 "Session Initialization" Bad KeepAlive Time Internal Error 1 0x00000019 "Events Signaled by ..."
セッション拒否/ 1 0x00000018「セッション初期化」悪いキープアライブ時間内部エラー1 0x00000019「によって知らされるイベント...」
The UDP port for LDP Hello messages is 646.
LDP HelloメッセージのためのUDPポートは646です。
The TCP port for establishing LDP session connections is 646.
LDPセッションの接続を確立するためのTCPポートは646です。
The Implicit NULL label (see [RFC3031]) is represented as a Generic Label TLV with a Label field value as specified by [RFC3032].
暗黙のNULLラベル（[RFC3031]を参照）[RFC3032]で指定されたラベルフィールド値と総称ラベルTLVとして表されます。
LDP defines the following name spaces which require management:
自民党は、管理を必要とする以下の名前空間を定義します。
- Message Type Name Space. - TLV Type Name Space. - FEC Type Name Space. - Status Code Name Space. - Experiment ID Name Space.
- メッセージタイプネームスペース。 - TLVタイプ名スペース。 - FECタイプ名スペース。 - ステータスコードネームスペース。 - 実験IDネームスペース。
The following sections provide guidelines for managing these name spaces.
次のセクションでは、これらの名前空間を管理するためのガイドラインを提供しています。
LDP divides the name space for message types into three ranges. The following are the guidelines for managing these ranges:
自民党は3つの範囲にメッセージタイプのネームスペースを分割します。以下は、これらの範囲を管理するためのガイドラインを次に示します。
- Message Types 0x0000 - 0x3DFF. Message types in this range are part of the LDP base protocol. Following the policies outlined in [IANA], Message types in this range are allocated through an IETF Consensus action.
- メッセージタイプ0000 - 0x3DFF。この範囲のメッセージタイプは、LDPベースプロトコルの一部です。 [IANA]に概説された方針に続いて、この範囲内のメッセージタイプは、IETF Consensus動作を通じて割り当てられます。
- Message Types 0x3E00 - 0x3EFF. Message types in this range are reserved for Vendor Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-private Messages"). IANA management of this range of the Message Type Name Space is unnecessary.
- メッセージタイプ0x3E00 - 0x3EFF。この範囲のメッセージタイプは、ベンダーのプライベート拡張のために予約し、個々のベンダーの責任とされている（セクション「LDPベンダープライベートメッセージ」を参照してください）。メッセージタイプネームスペースのこの範囲のIANA管理は不要です。
- Message Types 0x3F00 - 0x3FFF. Message types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the Message Type Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below).
- メッセージタイプ0x3F00 - 0x3FFFの。この範囲のメッセージタイプは、実験的拡張のために予約し、個々の実験者の責任とされている（セクション「LDP実験拡張機能」と「実験IDネームスペース」を参照）。メッセージタイプネームスペースのこの範囲のIANA管理は不要です。しかし、IANAは、実験IDネームスペース（下記参照）の一部を管理する責任があります。
LDP divides the name space for TLV types into three ranges. The following are the guidelines for managing these ranges:
自民党は3つの範囲にTLVタイプのネームスペースを分割します。以下は、これらの範囲を管理するためのガイドラインを次に示します。
- TLV Types 0x0000 - 0x3DFF. TLV types in this range are part of the LDP base protocol. Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
- TLVタイプ0000 - 0x3DFF。この範囲のTLVタイプは、LDPベースプロトコルの一部です。 [IANA]に概説された方針以下、この範囲のTLVタイプは、IETF Consensus動作を通じて割り当てられます。
- TLV Types 0x3E00 - 0x3EFF. TLV types in this range are reserved for Vendor Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-private TLVs"). IANA management of this range of the TLV Type Name Space is unnecessary.
- TLVタイプ0x3E00 - 0x3EFF。この範囲のTLVタイプはベンダープライベート拡張のために予約し、個々のベンダーの責任とされている（セクション「LDPベンダープライベートのTLV」を参照）。 TLVタイプ名前空間のこの範囲のIANA管理は不要です。
- TLV Types 0x3F00 - 0x3FFF. TLV types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the TLV Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below).
- TLVタイプ0x3F00 - 0x3FFFの。この範囲のTLVタイプは実験的拡張のために予約し、個々の実験者の責任とされている（セクション「LDP実験拡張機能」と「実験IDネームスペース」を参照）。 TLV名前空間のこの範囲のIANA管理は不要です。しかし、IANAは、実験IDネームスペース（下記参照）の一部を管理する責任があります。
The range for FEC types is 0 - 255.
255 - FECタイプの範囲は0です。
Following the policies outlined in [IANA], FEC types in the range 0 - 127 are allocated through an IETF Consensus action, types in the range 128 - 191 are allocated as First Come First Served, and types in the range 192 - 255 are reserved for Private Use.
範囲192内に最初に配信来て、タイプ191として最初に割り当てられている - - 128の範囲内の127 IETFコンセンサス作用によって割り当てられ、タイプ - [IANA]に概説された方針、FECタイプの範囲内の0次255は予約されていますプライベート使用のために。
The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
0x3FFFFFFF - ステータスコードの範囲は0x00000000のです。
Following the policies outlined in [IANA], Status Codes in the range 0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as First Come First Served, and codes in the range 0x3F000000 - 0x3FFFFFFF are reserved for Private Use.
[IANA]に概説された方針以下、範囲0x00000000の中にステータスコード - 0x1FFFFFFFは、IETF Consensus動作を通じて割り当てられ、範囲0x20000000でコード - 最初の配信最初に来るよう0x3EFFFFFFが割り当てられ、範囲0x3F000000にコード - 0x3FFFFFFFが予約されていますプライベート使用のために。
The range for Experiment Ids is 0x00000000 - 0xffffffff.
0xffffffffの - 実験IDの範囲は0x00000000のです。
Following the policies outlined in [IANA], Experiment Ids in the range 0x00000000 - 0xefffffff are allocated as First Come First Served and Experiment Ids in the range 0xf0000000 - 0xffffffff are reserved for Private Use.
実験Idsは範囲0x00000000の中で、[IANA]に概説された方針に続いて - 最初にお召し上がり最初に来ると範囲は、0xf0000000内のIDを実験として0xefffffffが割り当てられている - 0xffffffffのは、私的使用のために予約されています。
This section identifies threats to which LDP may be vulnerable and discusses means by which those threats might be mitigated.
このセクションでは、自民党が脆弱である可能性がある先の脅威を識別し、それらの脅威が軽減されるかもしれない手段を説明します。
There are two types of LDP communication that could be the target of a spoofing attack.
スプーフィング攻撃の標的となりうるLDP通信の2種類があります。
LSRs directly connected at the link level exchange Basic Hello messages over the link. The threat of spoofed Basic Hellos can be reduced by:
直接リンク上のリンクレベルの交流の基本的なHelloメッセージで接続のLSR。偽装された基本ハローズの脅威を減らすことができます。
o Accepting Basic Hellos only on interfaces to which LSRs that can be trusted are directly connected.
唯一の信頼できるのLSRが直接接続されたインターフェイス上で基本的なhelloを受け入れ、O。
o Ignoring Basic Hellos not addressed to the All Routers on this Subnet multicast group.
基本ハローズを無視oをこのサブネットマルチキャストグループ上のすべてのルータ宛ではありません。
LSRs not directly connected at the link level may use Extended Hello messages to indicate willingness to establish an LDP session. An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting only those originating at sources permitted by an access list.
直接リンクレベルで接続されていないのLSRは、LDPセッションを確立する意欲を示すために、拡張Helloメッセージを使用することができます。 LSRは、それらをフィルタリングして、アクセスリストで許可されてソースに起因するものだけを受け入れることによって、偽装された拡張ハローズの脅威を減らすことができます。
LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.
自民党はセッションメッセージの信憑性と整合性を提供するためにTCP MD5署名オプションを使用することを指定します。
[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application. It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed. To our knowledge no such TCP option has been defined and deployed. However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward.
[RFC2385]はMD5認証が今、このアプリケーションには弱すぎると一部で考えられていると主張しています。それはまた、より強力なハッシュアルゴリズム（それは、一例としてSHA-1を引用）と同様のTCPオプションが展開できることを指摘しています。我々の知る限り、そのようなTCPオプションが定義されておらず、配備されています。しかし、私たちは、自民党は技術が利用可能であり、MD5よりも1強いが指定され、実装されている場合、それを使用するLDPをアップグレードすることは比較的簡単になりダイジェストどんなTCPメッセージを使用できることに注意してください。
LDP provides no mechanism for protecting the privacy of label distribution.
LDPは、ラベル配布のプライバシーを保護するためのメカニズムを提供していません。
The security requirements of label distribution protocols are essentially identical to those of the protocols which distribute routing information. By providing a mechanism to ensure the authenticity and integrity of its messages LDP provides a level of security which is at least as good as, though no better than, that which can be provided by the routing protocols themselves. The more general issue of whether privacy should be required for routing protocols is beyond the scope of this document.
ラベル配布プロトコルのセキュリティ要件は、ルーティング情報を配信プロトコルのものと本質的に同一です。 LDPは、少なくともルーティングプロトコル自体によって提供することができるもの、よりは良いものの、同様に良好なセキュリティのレベルを提供し、そのメッセージの真正性および完全性を保証するためのメカニズムを提供することによって。プライバシーはルーティングプロトコルのために必要とされるべきかどうかのより一般的な問題は、このドキュメントの範囲を超えています。
One might argue that label distribution requires privacy to address the threat of label spoofing. However, that privacy would not protect against label spoofing attacks since data packets carry labels in the clear. Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label.
一つは、ラベル配布がラベルなりすましの脅威に対処するため、プライバシーが必要であることを主張するかもしれません。データパケットが明確にラベルを運ぶので、そのプライバシーがラベルスプーフィング攻撃から保護しません。さらに、ラベルスプーフィング攻撃は、ラベルに結合されたFECの知識がなくても行うことができます。
To avoid label spoofing attacks, it is necessary to ensure that labeled data packets are labeled by trusted LSRs and that the labels placed on the packets are properly learned by the labeling LSRs.
ラベルスプーフィング攻撃を回避するためには、データパケットが信頼のLSRによって標識し、パケットに配置されたラベルが正しくラベリングのLSRによって学習されていることをされているラベルされたことを保証する必要があります。
LDP provides two potential targets for denial of service (DoS) attacks:
自民党はサービス拒否（DoS）攻撃の拒否のための2つの潜在的な標的を提供しています。
An LSR administrator can address the threat of DoS attacks via Basic Hellos by ensuring that the LSR is directly connected only to peers which can be trusted to not initiate such an attack.
LSRの管理者は、LSRが直接のみ、このような攻撃を開始しないために信頼できるピアに接続されていることを確実にすることによって、基本的なハローズを経由して、DoS攻撃の脅威に対処することができます。
Interfaces to peers interior to the administrator's domain should not represent a threat since interior peers are under the administrator's control. Interfaces to peers exterior to the domain represent a potential threat since exterior peers are not. An administrator can reduce that threat by connecting the LSR only to exterior peers that can be trusted to not initiate a Basic Hello attack.
内部ピアは、管理者の制御下にあるため、管理者のドメインに内部をピアにインタフェースは、脅威とはなりません。外部ピアではないため、ドメインへの外部ピアへのインタフェースは、潜在的な脅威を表しています。管理者は、基本こんにちは攻撃を開始しないために信頼できる外部ピアにLSRを接続することにより、その脅威を減らすことができます。
DoS attacks via Extended Hellos are potentially a more serious threat. This threat can be addressed by filtering Extended Hellos using access lists that define addresses with which extended discovery is permitted. However, performing the filtering requires LSR resource.
拡張ハローズを介したDoS攻撃は、潜在的に深刻な脅威です。この脅威は発見が許可され、拡張されてアドレスを定義するアクセスリストを使用して拡張ハローズをフィルタリングすることによって対処することができます。しかし、フィルタリングを実行することはLSRのリソースを必要とします。
In an environment where a trusted MPLS cloud can be identified, LSRs at the edge of the cloud can be used to protect interior LSRs against DoS attacks via Extended Hellos by filtering out Extended Hellos originating outside of the trusted MPLS cloud, accepting only those originating at addresses permitted by access lists. This filtering protects LSRs in the interior of the cloud but consumes resources at the edges.
信頼MPLSクラウドを特定することができる環境では、クラウドのエッジでのLSRは、で発生のみを受け入れ、信頼MPLSクラウドの外部発信拡張helloをフィルタリングすることによって拡張ハローズを介して、DoS攻撃に対して内部のLSRを保護するために使用することができますアクセスリストで許可されたアドレス。このフィルタリングは、雲の内部でのLSRを保護しますが縁でリソースを消費します。
Like other control plane protocols that use TCP, LDP may be the target of DoS attacks, such a SYN attacks. LDP is no more or less vulnerable to such attacks than other control plane protocols that use TCP.
TCPを使用する他の制御プレーンプロトコルように、LDPは、DoS攻撃、例えば、SYN攻撃の標的とすることができます。自民党には、多かれ少なかれ、TCPを使用する他のコントロールプレーンプロトコルよりも、このような攻撃に対して脆弱ではありません。
The threat of such attacks can be mitigated somewhat by the following:
このような攻撃の脅威は、以下により多少緩和することができます。
o An LSR should avoid promiscuous TCP listens for LDP session establishment. It should use only listens that are specific to discovered peers. This enables it to drop attack packets early in their processing since they are less likely to match existing or in-progress connections.
O無差別TCPを避けるべきであるLSRは、LDPセッションの確立を待機します。これは、発見されたピアに固有のもののみリッスンを使用する必要があります。これは、彼らが既存または進行中の接続が一致する可能性が低いので、それは彼らの処理の初期攻撃パケットをドロップすることができます。
o The use of the MD5 option helps somewhat since it prevents a SYN from being accepted unless the MD5 segment checksum is valid. However, the receiver must compute the checksum before it can decide to discard an otherwise acceptable SYN segment.
それはMD5セグメントのチェックサムが有効でない限り、受け入れられているからSYNを防ぐため、O MD5オプションを使用すると、多少のに役立ちます。それはそうでなければ許容されるSYNセグメントを廃棄することを決定することができる前に、しかし、受信機は、チェックサムを計算しなければなりません。
o The use of access list mechanisms applied at the boundary of the MPLS cloud in a manner similar to that suggested above for Extended Hellos can protect the interior against attacks originating from outside the cloud.
拡張ハローズクラウド外部から発信攻撃から内部を保護することができるために上記で示唆したのと同様の方法でMPLSクラウドの境界に適用されるアクセスリスト機構の使用、O。
The following topics not addressed in this version of LDP are possible areas for future study:
自民党のこのバージョンで扱われていない次のトピックでは、今後の研究のための可能なエリアです。
- Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation.
- MPLSアーキテクチャ[RFC3031]のセクション2.16は、ピアのLSR間の初期ラベル配布プロトコルのネゴシエーションは、そのピアがラベルスタックをポップすることが可能であるかどうかを決定するために各LSRを有効にすることを必要とします。自民党のこのバージョンでは、LSRのサポートラベルは、ATMやフレームリレーを除くすべてのリンクタイプのために飛び出ることを前提としています。将来のバージョンでは、セッション開始交渉のこの決意部分を作るための手段を指定することもできます。
- LDP support for CoS is not specified in this version. CoS support may be addressed in a future version.
- CoSのためのLDPのサポートは、このバージョンで指定されていません。 CoSのサポートは、将来のバージョンで対処することができます。
- LDP support for multicast is not specified in this version. Multicast support may be addressed in a future version.
- マルチキャストのためのLDPのサポートは、このバージョンで指定されていません。マルチキャストサポートは、将来のバージョンで対処することができます。
- LDP support for multipath label switching is not specified in this version. Multipath support may be addressed in a future version.
- マルチラベル・スイッチングのためのLDPのサポートは、このバージョンで指定されていません。マルチパスのサポートは、将来のバージョンで対処することができます。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
The ideas and text in this document have been collected from a number of sources. We would like to thank Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, and Arun Viswanathan.
この文書のアイデアやテキストは、多数のソースから集めてきました。私たちはリック・Boivie、ロスCallon、アレックスコンタ、エリックグレー、義弘大場、エリック・ローゼン、バーナード・スーター、ヤコフ・レックター、およびアルンViswanathanのを感謝したいと思います。
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T Worster, "MPLS using ATM VP Switching", Work in Progress.
[ATM-VP] N.フェルドマン、B. Jamoussi、S. Komandur、A、Viswanathanの、T Worster、 "スイッチングATM VPを使用してMPLS"、ProgressのWork。
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. G. Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R. Dantu, "Constraint-Based LSP Setup using LDP", Work in Progress.
[CRLDP] L.アンダーソン、A. Fredette、B. Jamoussi、R. Callon、P. Doolan、N.フェルドマン、E.グレー、J.アルペルン、J. Heinanen TE Kilty、AG Malis、M. Girish、K. Sundell、P. Vaananen、T. Worster、L.呉、R. Dantu、 "制約ベースのLSPセットアップLDPを使用して" が進行中で働いています。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DIFFSERV]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム、" RFC 1321、1992年4月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J.、RFC 1483、1993年7月 "ATMアダプテーションレイヤ5の上にマルチプロトコルカプセル化"。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当てられた番号"、STD 2、RFC 1700、1994年10月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "MPLSのトラフィックエンジニアリングのための要件"、RFC 2702、1999年9月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、Rekhter、Y.、タッパン、D.、ファリナッチ、D.、Fedorkow、G.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[RFC3034]コンタ、A.、Doolan、P.およびA. Malis、RFC 3034、2001年1月 "フレームリレーネットワークの仕様上のラベルスイッチングの使用"。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]デイビー、B.、ローレンス、J.、McCloghrie、K.、Rekhter、Y.、ローゼン、E.、ツバメ、G.およびP. Doolan、 "MPLSスイッチングLDPおよびATM VCを使用して"、RFC 3035、 2001年1月。
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001.
[RFC3037]トーマス、B.及びE.グレー、 "LDP適用"、RFC 3037、2001年1月。
Loa Andersson Nortel Networks Inc St Eriksgatan 115, PO Box 6701 113 85 Stockholm Sweden
ロア・アンダーソンノーテルネットワークス株式会社Eriksgatan 115、私書箱6701 113 85ストックホルムスウェーデン
Phone: +46 8 5088 36 34 Mobile: +46 70 522 78 34 EMail: loa.andersson@nortelnetworks.com
電話：+46 8 5088 36 34携帯電話：+46 70 522 78 34 Eメール：loa.andersson@nortelnetworks.com
Paul Doolan Ennovate Networks 60 Codman Hill Rd Marlborough MA 01719
ポールDoolan Ennovateネットワーク60 CodmanヒルRdのマールボロMA 01719
Phone: 978-263-2002 EMail: pdoolan@ennovatenetworks.com
電話：978-263-2002 Eメール：pdoolan@ennovatenetworks.com
Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne, NY 10532
ナンシーフェルドマンIBMリサーチ30ミルリバーロードホーソーン、NY 10532を見ました
Phone: 914-784-3254 EMail: nkf@us.ibm.com
電話：914-784-3254 Eメール：nkf@us.ibm.com
Andre Fredette PhotonEx Corporation 8C Preston Court Bedford, MA 01730
アンドレFredette PhotonEx株式会社8Cプレストン裁判所ベッドフォード、MA 01730
Phone: 781-301-4655 EMail: fredette@photonex.com
電話：781-301-4655 Eメール：fredette@photonex.com
Bob Thomas Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824
ボブトーマスシスコシステムズ社250アポロ博士チェルムズフォード、MA 01824
Phone: 978-244-8078 EMail: rhthomas@cisco.com
電話：978-244-8078 Eメール：rhthomas@cisco.com
Appendix A. LDP Label Distribution Procedures
付録A. LDPラベル配布手順
This section specifies label distribution behavior in terms of LSR response to the following events:
このセクションでは、次のイベントにLSR応答の観点でラベル配布動作を指定します：
- Receive Label Request Message;
- Receive Label Mapping Message;
- Receive Label Abort Request Message;
- Receive Label Release Message;
- Receive Label Withdraw Message;
- Recognize new FEC;
- Detect change in FEC next hop;
- Receive Notification Message / Label Request Aborted;
- Receive Notification Message / No Label Resources;
- Receive Notification Message / No Route;
- Receive Notification Message / Loop Detected;
- Receive Notification Message / Label Resources Available;
- Detect local label resources have become available;
- LSR decides to no longer label switch a FEC;
- Timeout of deferred label request.
The specification of LSR behavior in response to an event has three parts:
イベントに応答して、LSRの振舞いの仕様は3つの部分があります。
1. Summary. Prose that describes LSR response to the event in overview.
1.概要。概要のイベントにLSR応答を説明し散文。
2. Context. A list of elements referred to by the Algorithm part of the specification. (See 3.)
2.コンテキスト。指定のアルゴリズムの一部で参照要素のリスト。 （3を参照）
The Summary may omit details of the LSR response, such as bookkeeping action or behavior dependent on the LSR label advertisement mode, control mode, or label retention mode in use. The intent is that the Algorithm fully and unambiguously specify the LSR response.
概要は、簿記のアクションやLSRのラベル広告モード、制御モード、または使用中のラベル保持モードに依存行動としてLSR応答の詳細は、省略することができます。その意図は、アルゴリズムが完全かつ明確LSR応答を指定することです。
The algorithms in this section use procedures defined in the MPLS architecture specification [RFC3031] for hop-by-hop routed traffic. These procedures are:
ホップバイホップのためのMPLSアーキテクチャ仕様[RFC3031]で定義され、このセクションの使用手順におけるアルゴリズムは、トラフィックをルーティング。これらの手順は以下のとおりです。
- Label Distribution procedure, which is performed by a downstream LSR to determine when to distribute a label for a FEC to LDP peers. The architecture defines four Label Distribution procedures:
- FEC LDPピアへのラベルを配布する際に下流LSRによって実行されるラベル配布手順は、決定しました。アーキテクチャは、4つのラベル配布手順を定義しています。
. Downstream Unsolicited Independent Control, called PushUnconditional in [RFC3031].
。下流迷惑独立したコントロールは、[RFC3031]でPushUnconditionalと呼ばれます。
. Downstream Unsolicited Ordered Control, called PushConditional in [RFC3031].
。下流の迷惑は、[RFC3031]でPushConditionalのと呼ばれる、コントロールを命じました。
. Downstream On Demand Independent Control, called PulledUnconditional in [RFC3031].
。デマンド独立したコントロールで下流には、[RFC3031]でPulledUnconditionalと呼ばれます。
. Downstream On Demand Ordered Control, called PulledConditional in [RFC3031].
。コントロールを発注オンデマンド下流には、[RFC3031]でPulledConditionalと呼ばれます。
- Label Withdrawal procedure, which is performed by a downstream LSR to determine when to withdraw a FEC label mapping previously distributed to LDP peers. The architecture defines a single Label Withdrawal procedure. Whenever an LSR breaks the binding between a label and a FEC, it must withdraw the FEC label mapping from all LDP peers to which it has previously sent the mapping.
- 以前はLDPピアに分配FECラベルマッピングを撤回するとき下流LSRによって実行されるラベル離脱手順は、決定しました。このアーキテクチャは、単一のラベル出金手続きを定義します。 LSRは、ラベルとFECの間の結合を切断するたびに、それは以前にマッピングを送信した先のすべてのLDPピアからFECラベルマッピングを撤回しなければなりません。
- Label Request procedure, which is performed by an upstream LSR to determine when to explicitly request that a downstream LSR bind a label to a FEC and send it the corresponding label mapping. The architecture defines three Label Request procedures:
- 明示的に下流LSRがFECにラベルを結合し、それに対応するラベルマッピングを送信することを要求するときを決定するために上流のLSRによって実行されるラベル要求手順。アーキテクチャは、3つのラベル要求手順を定義しています。
. Request Never. The LSR never requests a label.
。要求決して。 LSRは、ラベルを要求することはありません。
. Request When Needed. The LSR requests a label whenever it needs one.
。必要なときに要求します。それは1が必要な時はいつでもLSRはラベルを要求します。
. Request On Request. This procedure is used by non-label merging LSRs. The LSR requests a label when it receives a request for one, in addition to whenever it needs one.
。リクエストに応じて要求。この手順は、非ラベル合併のLSRによって使用されます。 LSRは、それが1を必要とするたびに加えて、1つの要求を受けたラベルを要求します。
- Label Release procedure, which is performed by an upstream LSR to determine when to release a previously received label mapping for a FEC. The architecture defines two Label Release procedures:
- 上流のLSRによって実行されるラベル解放手順は、FECのために以前に受信したラベルマッピングを解放するときを決定します。アーキテクチャは、2つのLabelリリース手順を定義しています。
. Conservative label retention, called Release On Change in [RFC3031].
。 [RFC3031]の変化にリリースと呼ばれる保守ラベル保持、。
. Liberal label retention, called No Release On Change in [RFC3031].
。リベラルラベル保持、[RFC3031]の変更にはリリースと呼ばれていません。
- Label Use procedure, which is performed by an LSR to determine when to start using a FEC label for forwarding/switching. The architecture defines three Label Use procedures:
- LSRによって実行されるラベルを使用する手順は、転送/スイッチングするためのFECラベルの使用を開始する時を決定します。アーキテクチャは、3つのラベルの使用手順を定義しています。
. Use Immediate. The LSR immediately uses a label received from a FEC next hop for forwarding/switching.
。即時を使用してください。 LSRはすぐにラベルが転送/スイッチング用FEC次ホップから受信した使用します。
. Use If Loop Free. The LSR uses a FEC label received from a FEC next hop for forwarding/switching only if it has determined that by doing so it will not cause a forwarding loop.
。ループのない場合に使用します。 LSRは、FECラベルは、それがそうすることによって、それはフォワーディングループが発生しないことを決定した場合にのみ、スイッチング/転送するためのFECの次のホップから受け取った使用しています。
. Use If Loop Not Detected. This procedure is the same as Use Immediate unless the LSR has detected a loop in the FEC LSP. Use of the FEC label for forwarding/switching will continue until the next hop for the FEC changes or the loop is no longer detected.
。ループが検出されない場合に使用します。 LSRはFEC LSPのループを検出していない限り、この手順は、使用即時同じです。 FEC変更またはループの次のホップがもはや検出されるまでの転送/スイッチングのためのFECのラベルの使用は継続しません。
This version of LDP does not include a loop prevention mechanism; therefore, the procedures below do not make use of the Use If Loop Free procedure.
自民党のこのバージョンは、ループ防止メカニズムが含まれていません。そのため、以下の手順は、使用する場合、ループフリーの手順を使用しません。
- Label No Route procedure (called Label Not Available procedure in [RFC3031]), which is performed by an upstream LSR to determine how to respond to a No Route notification from a downstream LSR in response to a request for a FEC label mapping. The architecture specification defines two Label No Route procedures:
- ラベルNOルート手順FECラベルマッピングの要求に応じて、下流LSRのNOルート通知に応答する方法を決定するために上流のLSRによって実行される、（[RFC3031]でご利用いただけません手順ラベルと呼ばれます）。アーキテクチャの仕様では、2つのLabel Noルート手順を定義しています。
. Request Retry. The LSR should issue the label request at a later time.
。再試行を要求します。 LSRは、後でラベル要求を発行する必要があります。
. No Request Retry. The LSR should assume the downstream LSR will provide a label mapping when the downstream LSR has a next hop and it should not reissue the request.
。要求なしリトライません。 LSRは川下のLSRは次のホップを持っている場合、下流LSRは、ラベルマッピングを提供すると仮定しなければならないし、それは要求を再発行するべきではありません。
A.1. Handling Label Distribution Events
A.1。ラベル配布イベントの処理
This section defines LDP label distribution procedures by specifying an algorithm for each label distribution event. The requirement on an LDP implementation is that its event handling must have the effect specified by the algorithms. That is, an implementation need not follow exactly the steps specified by the algorithms as long as the effect is identical.
このセクションでは、各ラベル配布イベントのアルゴリズムを指定することによって、LDPラベル配布手順を定義します。 LDPの実装上の要件は、そのイベント処理は、アルゴリズムによって指定された効果を持っていなければならないということです。それは、実装は正確に限り、効果は同じであるようなアルゴリズムで指定された手順に従ってくださいする必要はない、です。
The algorithms for handling label distribution events share common actions. The specifications below package these common actions into procedure units. Specifications for these common procedures are in their own section "Common Label Distribution Procedures", which follows this.
ラベル配布イベントを処理するためのアルゴリズムは、一般的なアクションを共有しています。パッケージ以下の仕様手順単位にこれらの一般的なアクション。これらの一般的な手順の仕様は、これを次の自分のセクション「共通ラベル配布手順」、です。
An implementation would use data structures to store information about protocol activity. This appendix specifies the information to be stored in sufficient detail to describe the algorithms, and assumes the ability to retrieve the information as needed. It does not specify the details of the data structures.
実装は、プロトコルの活動に関する情報を格納するためのデータ構造を使用します。この付録では、アルゴリズムを記述するために十分詳細に格納する情報を指定し、必要に応じて情報を取得する機能を前提としています。これは、データ構造の詳細を指定しません。
A.1.1. Receive Label Request
A.1.1。ラベル要求を受け取ります
Summary:
概要：
The response by an LSR to receipt of a FEC label request from an LDP peer may involve one or more of the following actions:
LDPピアからFECラベル要求の受信にLSRによる応答は、次のアクションの一つ以上を含むことができます。
- Transmission of a notification message to the requesting LSR indicating why a label mapping for the FEC cannot be provided;
- FECのためのラベルマッピングを提供することができない理由を示す要求LSRへの通知メッセージの送信。
- Transmission of a FEC label mapping to the requesting LSR;
- 要求するLSRへのFECラベルマッピングの伝送;
- Transmission of a FEC label request to the FEC next hop;
- FEC次のホップにFECラベル要求の送信。
- Installation of labels for forwarding/switching use by the LSR.
- LSRによって転送/スイッチング用のラベルのインストール。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- FEC. The FEC specified in the message.
- FEC。 FECは、メッセージに指定されています。
- RAttributes. Attributes received with the message. E.g., Hop Count, Path Vector.
- RAttributes。属性は、メッセージで受信しました。例えば、ホップ、パスベクトルを数えます。
- SAttributes. Attributes to be included in Label Request message, if any, propagated to FEC Next Hop.
- SAttributes。 FEC次ホップに伝播し、もしあれば、ラベル要求メッセージに含まれる属性。
- StoredHopCount. The hop count, if any, previously recorded for the FEC.
- StoredHopCount。ホップ数は、もしあれば、以前にFECのために記録します。
Algorithm:
アルゴリズム：
LRq.1 Execute procedure Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). If Loop Detected, goto LRq.13.
LRq.1手続きCheck_Received_Attributes（MsgSource、LabelRequest、RAttributes）を実行します。ループが検出された場合は、後藤LRq.13。
LRq.2 Is there a Next Hop for FEC? If not, goto LRq.5.
LRq.2 FECのためのネクストホップはありますか？そうでない場合は、後藤LRq.5。
LRq.3 Is MsgSource the Next Hop? Ifnot, goto LRq.6.
LRq.3はMsgSourceネクストホップですか？ IFNOT、後藤LRq.6。
LRq.4 Execute procedure Send_Notification (MsgSource, Loop Detected). Goto LRq.13
LRq.4手順Send_Notification（MsgSource、ループが検出された）を実行します。後藤LRq.13
LRq.5 Execute procedure Send_Notification (MsgSource, No Route). Goto LRq.13.
手順Send_Notification（MsgSource、NOルート）を実行しLRq.5。後藤LRq.13。
LRq.6 Has LSR previously received a label request for FEC from MsgSource? If not, goto LRq.8. (See Note 1.)
LRq.6はLSRが以前にMsgSourceからFECのためのラベル要求を受けていますか？そうでない場合は、後藤LRq.8。 （注1を参照）。
LRq.7 Is the label request a duplicate request? If so, Goto LRq.13. (See Note 2.)
LRq.7は、ラベル要求重複要求ですか？もしそうなら、後藤LRq.13。 （注2を参照してください）
LRq.8 Record label request for FEC received from MsgSource and mark it pending.
FECのためのLRq.8レコードレーベル要求がMsgSourceから受信し、保留中のそれをマーク。
LRq.9 Perform LSR Label Distribution procedure:
LRq.9はLSRラベル配布手順を実行します。
For Downstream Unsolicited Independent Control OR
For Downstream On Demand Independent Control
1. Has LSR previously received and retained a label mapping for FEC from Next Hop?. Is so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating.
1. LSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していました？。そう、IsPropagatingに伝播設定されています。ない場合は、NotPropagatingに伝播する設定。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).
2.手順Prepare_Label_Mapping_Attributesを実行し（MsgSource、FEC、RAttributes、SAttributes、伝播、StoredHopCount）。
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes).
3.実行手順Send_Label（MsgSource、FEC、SAttributes）。
4. Is LSR egress for FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, goto LRq.11. If not, goto LRq.10.
4. FECのためのLSR出口ですか？ OR LSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していますか？もしそうなら、後藤LRq.11。そうでない場合は、後藤LRq.10。
For Downstream Unsolicited Ordered Control OR For Downstream On Demand Ordered Control
ダウンストリーム迷惑順序制御用ORデマンド順序制御のダウンストリームのために
1. Is LSR egress for FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? (See Note 3.) If not, goto LRq.10.
1.はFECのためのLSR出口ですか？ OR LSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していますか？後藤LRq.10、そうでない場合（注3を参照）。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount)
2.手順Prepare_Label_Mapping_Attributes（MsgSource、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）を実行
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes). Goto LRq.11.
3.実行手順Send_Label（MsgSource、FEC、SAttributes）。後藤LRq.11。
LRq.10 Perform LSR Label Request procedure:
LRq.10はLSRのラベル要求の手順を実行します。
For Request Never
決して要求について
For Request When Needed OR For Request On Request
要求のための要求に必要または要求に対するとき
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, RAttributes, SAttributes);
1.（ネクストホップ、FEC、属性、属性）属性Prepare_Label_Request手順を実行し、
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto LRq.13.
2.手順Send_Label_Request（ネクストホップ、FEC、SAttributes）を実行します。後藤LRq.13。
LRq.11 Has LSR successfully sent a label for FEC to MsgSource? If not, goto LRq.13. (See Note 4.)
LRq.11は、LSRが正常MsgSourceにFECのためのラベルを送っていますか？そうでない場合は、後藤LRq.13。 （注4を参照してください）
LRq.12 Perform LSR Label Use procedure.
LRq.12はLSRラベルの使用手順を実行します。
For Use Immediate OR
For Use If Loop Not Detected
1. Install label sent to MsgSource and label from Next Hop (if LSR is not egress) for forwarding/switching use.
（LSRが出ない場合）1.使用を切り替える/転送するためのネクストホップからMsgSourceに送信ラベルとラベルをインストールします。
LRq.13 DONE
LRq.13 DONE
Notes:
ノート：
1. In the case where MsgSource is a non-label merging LSR it will send a label request for each upstream LDP peer that has requested a label for FEC from it. The LSR must be able to distinguish such requests from a non-label merging MsgSource from duplicate label requests.
1. MsgSource非ラベルマージLSRである場合にはそれからFECのためのラベルを要求した各上流LDPピアのラベル要求を送信します。 LSRは、重複したラベル要求からMsgSourceをマージする非ラベルからそのような要求を区別できなければなりません。
The LSR uses the message ID of received Label Request messages to detect duplicate requests. This means that an LSR (the upstream peer) may not reuse the message ID used for a Label Request until the Label Request transaction has completed.
LSRは、重複した要求を検出するために、受信したラベル要求メッセージのメッセージIDを使用しています。これは、ラベル要求トランザクションが完了するまでLSR（上流ピア）はラベル要求に使用されるメッセージIDを再利用しないことを意味します。
2. When an LSR sends a label request to a peer it records that the request has been sent and marks it as outstanding. As long as the request is marked outstanding the LSR should not send another request for the same label to the peer. Such a second request would be a duplicate. The Send_Label_Request procedure described below obeys this rule.
2. LSRが、それは、要求が送信されたことを記録し、優れたとして、それをマークするピアにラベル要求を送信します。限り要求が未処理マークされているようLSRは、ピアに同じラベルのための別の要求を送信することはできません。このような2番目の要求は重複になります。下記のSend_Label_Request手順は、このルールに従います。
A duplicate label request is considered a protocol error and should be dropped by the receiving LSR (perhaps with a suitable notification returned to MsgSource).
重複ラベル要求はプロトコルエラーとみなされ、受信LSRによってドロップされるべきである（おそらく適切な通知とMsgSourceに戻します）。
4. The Send_Label procedure may fail due to lack of label resources, in which case the LSR should not perform the Label Use procedure.
4. Send_Label手順が原因LSRは、ラベルの使用手順を実行してはいけません、その場合にはラベルリソースの不足のために失敗することがあります。
A.1.2. Receive Label Mapping
A.1.2。ラベルマッピングを受け取ります
Summary:
概要：
The response by an LSR to receipt of a FEC label mapping from an LDP peer may involve one or more of the following actions:
LDPピアからFECラベルマッピングの受信にLSRによる応答は、次のアクションの一つ以上を含むことができます。
- Transmission of a label release message for the FEC label to the LDP peer;
- LDPピアへFECラベルのラベル解放メッセージを送信します。
- Transmission of label mapping messages for the FEC to one or more LDP peers,
- 一つ以上のLDPピアへのFECのためのラベルマッピングメッセージの送信、
- Installation of the newly learned label for forwarding/switching use by the LSR.
- LSRによって転送/スイッチング用の新たに学習ラベルのインストール。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- FEC. The FEC specified in the message.
- FEC。 FECは、メッセージに指定されています。
- Label. The label specified in the message.
- ラベル。メッセージで指定されたラベル。
- PrevAdvLabel. The label for FEC, if any, previously advertised to an upstream peer.
- PrevAdvLabel。 FECのためのラベルは、もしあれば、以前に上流のピアにアドバタイズ。
- StoredHopCount. The hop count previously recorded for the FEC.
- StoredHopCount。以前にFECのために記録ホップ数。
- RAttributes. Attributes received with the message. E.g., Hop Count, Path Vector.
- RAttributes。属性は、メッセージで受信しました。例えば、ホップ、パスベクトルを数えます。
- SAttributes to be included in Label Mapping message, if any, propagated to upstream peers.
- SAttributesは、上流のピアに伝播し、もしあれば、ラベルマッピングメッセージに含まれます。
Algorithm:
アルゴリズム：
LMp.1 Does the received label mapping match an outstanding label request for FEC previously sent to MsgSource. If not, goto LMp.3.
LMp.1は、受信したラベルマッピングは、以前MsgSourceに送信されたFECのための優れたラベル要求に合っています。そうでない場合は、後藤LMp.3。
LMp.2 Delete record of outstanding FEC label request.
優れたFECラベル要求のレコードを削除しますLMp.2。
LMp.3 Execute procedure Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). If No Loop Detected, goto LMp.9.
LMp.3手続きCheck_Received_Attributes（MsgSource、LabelMapping、RAttributes）を実行します。ノーループが検出された場合は、後藤LMp.9。
LMp.4 Does the LSR have a previously received label mapping for FEC from MsgSource? (See Note 1.) If not, goto LMp.8. (See Note 2.)
LMp.4はLSRがMsgSourceからFECのために以前に受信したラベルマッピングを持っていますか？後藤LMp.8、そうでない場合（注1を参照）。 （注2を参照してください）
LMp.5 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) If not, goto LMp.8. (See Note 4.)
LMp.5は、ラベルは以前に（すなわち、ラベルはメッセージで受信）MsgSourceマッチラベルから受信していますか？後藤LMp.8、そうでない場合（注3を参照）。 （注4を参照してください）
LMp.6 Delete matching label mapping for FEC previously received from MsgSource.
以前MsgSourceから受信したFECのためのラベルマッピングに一致する削除LMp.6。
LMp.7 Remove Label from forwarding/switching use. (See Note 5.) Goto LMp.33.
転送/スイッチング使用からラベルを削除しLMp.7。後藤LMp.33（注5を参照）。
LMp.8 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.
手順SEND_MESSAGE（MsgSource、ラベルリリース、FEC、ラベル、ループ検出ステータスコード）を実行しLMp.8。後藤LMp.33。
LMp.9 Does LSR have a previously received label mapping for FEC from MsgSource for the LSP in question? (See Note 6.) If not, goto LMp.11.
LMp.9はLSRは、問題のLSPのためMsgSourceからのFECのための以前に受信したラベルマッピングを持っていますか？後藤LMp.11、そうでない場合（注6を参照）。
LMp.10 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) If not, goto LMp.32. (See Note 4.)
LMp.10は、ラベルは以前に（すなわち、ラベルはメッセージで受信）MsgSourceマッチラベルから受信していますか？後藤LMp.32、そうでない場合（注3を参照）。 （注4を参照してください）
LMp.11 Determine the Next Hop for FEC.
FECのための次のホップを決定LMp.11。
LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14.
LMp.12はMsgSource FECのネクストホップですか？もしそうなら、後藤LMp.14。
LMp.13 Perform LSR Label Release procedure:
LMp.13はLSRラベル解放手順を実行します。
For Conservative Label retention:
保守ラベル保持のために：
For Liberal Label retention:
リベラルラベル保持のために：
1. Record label mapping for FEC with Label and RAttributes has been received from MsgSource. Goto LMp.33.
ラベルとRAttributesとFECのための1レコードレーベルマッピングはMsgSourceから受信されています。後藤LMp.33。
LMp.14 Is LSR an ingress for FEC? If not, goto LMp.16.
LMp.14はLSRはFECのための進入ですか？そうでない場合は、後藤LMp.16。
LMp.15 Install Label for forwarding/switching use.
LMp.15使用を切り替え/転送するためのラベルをインストールします。
LMp.16 Record label mapping for FEC with Label and RAttributes has been received from MsgSource.
ラベルとRAttributesとFECのためのLMp.16レコードレーベルマッピングはMsgSourceから受信されています。
LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).
各ピアのLMp.31てLMp.17反復。 （注7を参照してください）。
LMp.18 Has LSR previously sent a label mapping for FEC to Peer for the LSP in question? (See Note 8.) If so, goto LMp.22.
LMp.18はLSRは以前に問題のLSPのためにピアするFECのためのラベルマッピングを送っていますか？後藤LMp.22、その場合（注8を参照してください）。
LMp.19 Is the Downstream Unsolicited Ordered Control Label Distribution procedure being used by LSR? If not, goto LMp.28.
LMp.19はLSRによって使用されているダウンストリーム迷惑順序コントロールラベル配布手順ですか？そうでない場合は、後藤LMp.28。
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.20プロシージャPrepare_Label_Mapping_Attributes（ピア、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）を実行します。
LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). Goto LMp.28
LMp.21は、手順SEND_MESSAGE（ピア、ラベルマッピング、FEC、PrevAdvLabel、SAttributes）を実行します。後藤LMp.28
LMp.22 Iterate through LMp.27 for each label mapping for FEC previously sent to Peer.
以前にピアに送信されたFECのための各ラベルマッピングのためのLMp.27てLMp.22反復。
LMp.23 Are RAttributes in the received label mapping consistent with those previously sent to Peer? If so, continue iteration from LMp.22 for next label mapping. (See Note 9.)
LMp.23受信したラベルマッピングでRAttributesは以前にピアに送信されたものと一致していますか？その場合は、次のラベルマッピングのLMp.22からの反復を続けます。 （注9を参照してください）
LMp.24 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.24プロシージャPrepare_Label_Mapping_Attributes（ピア、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）を実行します。
LMp.25 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 10.)
LMp.25は、手順SEND_MESSAGE（ピア、ラベルマッピング、FEC、PrevAdvLabel、SAttributes）を実行します。 （注10を参照してください）
LMp.26 Update record of label mapping for FEC previously sent to Peer to include the new attributes sent.
FECのためのラベルマッピングのLMp.26更新レコードが以前に送信された新しい属性が含まれるようにピアに送信します。
LMp.27 End iteration from LMp.22.
LMp.22からLMp.27終了反復。
LMp.28 Does LSR have any label requests for FEC from Peer marked as pending? If not, goto LMp.30.
LMp.28 LSRは保留中としてマークされ、ピアからのFECのための任意のラベル要求を持っていますか？そうでない場合は、後藤LMp.30。
LMp.29 Perform LSR Label Distribution procedure:
LMp.29はLSRラベル配布手順を実行します。
For Downstream Unsolicited Independent Control OR
For Downstream Unsolicited Ordered Control
1. Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).
1.手順Prepare_Label_Mapping_Attributesを実行し（ピア、FEC、RAttributes、SAttributes、IsPropagating、UnknownHopCount）。
2. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
2.手順Send_Label（ピア、FEC、SAttributes）を実行します。手順が失敗した場合、LMp.17で次のピアのための繰り返しを続けます。
3. If no pending requests exist for Peer goto LMp.30. (See Note 11.)
3.保留中の要求が、ピア後藤LMp.30のために存在しない場合。 （注11を参照してください）
For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control
デマンド順序制御上のダウンストリームの需要独立コントロールまたは上のダウンストリームのために
1. Iterate through Step 5 for each pending label request for FEC from Peer marked as pending.
保留中としてマークされたピアからのFECのために保留中の各ラベル要求のためのステップ5を1反復。
2. Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)
2.実行手順Prepare_Label_Mapping_Attributes（ピア、FEC、RAttributes、SAttributes、IsPropagating、UnknownHopCount）
3. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
3.手順Send_Label（ピア、FEC、SAttributes）を実行します。手順が失敗した場合、LMp.17で次のピアのための繰り返しを続けます。
LMp.30 Perform LSR Label Use procedure:
LMp.30はLSRラベルの使用手順を実行します。
For Use Immediate OR
For Use If Loop Not Detected
1. Iterate through Step 3 for each label mapping for FEC previously sent to Peer.
以前にピアに送信されたFECのための各ラベルマッピングのステップ3を1反復。
2. Install label received and label sent to Peer for forwarding/switching use.
2.ラベルをインストールして受信し、ラベルが使用を切り替え/転送のためにピアに送信。
LMp.31 End iteration from LMp.17. Go to LMp.33.
LMp.17からLMp.31終了反復。 LMp.33に移動します。
LMp.32 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label).
手順SEND_MESSAGE（MsgSource、ラベルリリース、FEC、ラベル）を実行しLMp.32。
LMp.33 DONE.
LMp.33はDONE。
Notes:
ノート：
1. If the LSR is merging there should be at most 1 received mapping for the FEC for the LSP in question. In the non-merging case there could be multiple received mappings for the FEC for the LSP in question.
1. LSRは、せいぜい1がなければならないマージされた場合は、問題のLSPのためのFECのためのマッピングを受けました。非合併の場合には、当該LSPのためのFECのために複数の受信のマッピングがあるかもしれません。
2. If LSR has detected a loop and it has not previously received a label mapping from MsgSource for the FEC, it simply releases the label.
2. LSRがループを検出し、それが以前にFECのためMsgSourceからラベルマッピングを受信していない場合、それは単にラベルを解放します。
3. Does the Label received in the message match any of the 1 or more label mappings identified in the previous step (LMp.4 or LMp.9)?
3.ラベルはメッセージで受信し、前のステップ（LMp.4またはLMp.9）で識別さ1つの以上のラベルのマッピングのいずれかに一致していますか？
4. An unsolicited mapping with a different label from the same peer would be an attempt to establish multipath label switching, which is not supported in this version of LDP.
4.同じピアと異なるラベルを持つ迷惑マッピングは自民党のこのバージョンではサポートされていないマルチラベルスイッチングを確立しようとする試みになります。
5. If Label is not in forwarding/switching use, LMp.7 has no effect.
ラベルは、転送/スイッチング使用されていない場合5.は、LMp.7は効果がありません。
6. If the received label mapping message matched an outstanding label request in LMp.1, then (by definition) LSR has not previously received a label mapping for FEC for the LSP in question. If the LSR is merging upstream labels for the LSP in question, there should be at most 1 received mapping. In the non-merging case, there could be multiple received label mappings for the same FEC, one for each resulting LSP.
前記受信されたラベルマッピングメッセージは、LSRが以前に当該LSPのためのFECのラベルマッピングを受信していない（定義により）、次いで、LMp.1で優れたラベル要求と一致した場合。 LSRは、問題のLSPのためのアップストリームラベルをマージされている場合は、高々1があるはずマッピングを受けました。非マージする場合に、同一のFEC、得られた各LSPのための1つのための複数の受信したラベルマッピングがあってもよいです。
7. The LMp.17 iteration includes MsgSource in order to handle the case where LSR is operating in Downstream Unsolicited ordered control mode. Ordered control prevents LSR from advertising a label for FEC until it has received a label mapping from its next hop (MsgSource) for FEC.
7. LMp.17反復は、LSRは、制御モードを注文下流迷惑で動作している場合を処理するためにMsgSourceを含みます。注文したコントロールは、その次のホップFEC用（MsgSource）からラベルマッピングを受け取るまでFECのためのラベルを広告するからLSRを防ぐことができます。
8. If LSR is merging the LSP it may have previously sent label mappings for the FEC LSP to one or more peers. If LSR is not merging, it may have sent a label mapping for the LSP in question to at most one LSR.
8. LSRが以前一の以上のピアにFEC LSPのためのラベルマッピングを送ったかもしれないLSPをマージしている場合。 LSRがマージされていない場合、それはせいぜい1つのLSRに問題のLSPのためのラベルマッピングを送信している可能性があります。
9. The loop detection Path Vector attribute is considered in this check. If the received RAttributes include a Path Vector and no Path Vector had been previously sent to the Peer, or if the received Path Vector is inconsistent with the Path Vector previously sent to the Peer, then the attributes are considered to be inconsistent. Note that an LSR is not required to store a received Path Vector after it propagates the Path Vector in a mapping message. If an LSR does not store the Path Vector, it has no way to check the consistency of a newly received Path Vector. This means that whenever such an LSR receives a mapping message carrying a Path Vector it must always propagate the Path Vector.
9.ループ検出パスベクタ属性は、このチェックで考慮されます。受信RAttributesはパスベクタなしのパスが含まれている場合のベクトルが以前にピアに送信されていた、または受信したPath Vectorがパス以前にピアに送信されたベクトルと矛盾している場合は、その属性が矛盾すると考えられています。 LSRは、それがマッピング・メッセージ内のパスベクトルを伝播した後に受信したパスベクトルを格納するために必要とされないことに留意されたいです。 LSRは、パスベクトルが格納されていない場合は、新たに受信したパスベクトルの整合性をチェックする方法がありません。これは、このようなLSRはパスベクタを運ぶマッピングメッセージを受信したときはいつでも、それは常にパスベクタを伝搬しなければならないことを意味します。
10. LMp.22 through LMp.27 deal with a situation that can arise when the LSR is using independent control and it receives a mapping from the downstream peer after it has sent a mapping to an upstream peer. In this situation the LSR needs to propagate any changed attributes, such as Hop Count, upstream. If Loop Detection is configured on, the propagated attributes must include the Path Vector
LMp.27スルー10. LMp.22はLSRが独立制御を使用して、それが上流のピアにマッピングを送信した後に、下流ピアからのマッピングを受信したときに発生する可能性がある状況に対処します。このような状況ではLSRは、ホップなどの任意の変更された属性、上流、カウントを伝播する必要があります。ループ検出がオンに設定されている場合は、伝播属性はパスベクタを含める必要があります
11. An LSR operating in Downstream Unsolicited mode must process any Label Request messages it receives. If there are pending label requests, fall through into the Downstream on Demand procedures in order to satisfy the pending requests.
【請求項11】LSRは、受信した任意のラベル要求メッセージを処理しなければならないダウンストリーム迷惑モードで動作しています。保留中のラベルの要求がある場合は、保留中の要求を満たすために需要手続き上のダウンストリームに通じ落ちます。
A.1.3. Receive Label Abort Request
A.1.3。ラベル中止要求を受信
Summary:
概要：
When an LSR receives a label abort request message from a peer, it checks whether it has already responded to the label request in question. If it has, it silently ignores the message. If it has not, it sends the peer a Label Request Aborted Notification. In addition, if it has a label request outstanding for the LSP in question to a downstream peer, it sends a Label Abort Request to the downstream peer to abort the LSP.
LSRがピアからラベルアボート要求メッセージを受信すると、それはすでに問題のラベル要求に応答したかどうかをチェックします。それが持っている場合、それは静かにメッセージを無視します。それはしていない場合は、ピアラベル要求中止の通知送信します。それは下流のピアへの質問にLSPのための優れたラベル要求がある場合に加えて、それはLSPを中止する下流のピアにラベル中止要求を送信します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- FEC. The FEC specified in the message.
- FEC。 FECは、メッセージに指定されています。
- RequestMessageID. The message ID of the label request message to be aborted.
- RequestMessageID。ラベル要求メッセージのメッセージIDは中止されます。
- Next Hop. The next hop for the FEC.
- ネクストホップ。 FECのネクストホップ。
Algorithm:
アルゴリズム：
LAbR.1 Does the message match a previously received label request message from MsgSource? (See Note 1.) If not, goto LAbR.12.
LAbR.1メッセージがMsgSourceから以前に受信したラベル要求メッセージに一致していますか？後藤LAbR.12、そうでない場合（注1を参照）。
LAbR.2 Has LSR responded to the previously received label request? If so, goto LAbR.12.
LAbR.2はLSRは以前に受信したラベル要求に応えていますか？もしそうなら、後藤LAbR.12。
LAbR.3 Execute procedure Send_Message(MsgSource, Notification, Label Request Aborted, TLV), where TLV is the Label Request Message ID TLV received in the label abort request message.
LAbR.3 TLVはID TLVがリクエストメッセージをアボートラベルで受信したラベル要求メッセージである手順SEND_MESSAGE（MsgSource、通知、中止ラベル要求、TLV）を実行します。
LAbR.4 Does LSR have a label request message outstanding for FEC? If so, goto LAbR.7
LAbR.4 LSRはFECのための優れたラベル要求メッセージを持っていますか？もしそうなら、後藤LAbR.7
LAbR.5 Does LSR have a label mapping for FEC? If not, goto LAbR.11
LAbR.5 LSRはFECのためのラベルマッピングを持っていますか？そうでない場合は、後藤LAbR.11
LAbR.6 Generate Event: Received Label Release Message for FEC from MsgSource. (See Note 2.) Goto LAbR.11.
LAbR.6イベントを生成：MsgSourceからFECのためのラベルリリースメッセージを受信しました。後藤LAbR.11（注2を参照してください）。
LAbR.7 Is LSR merging the LSP for FEC? If not, goto LAbR.9.
LAbR.7はLSRがFECのためのLSPをマージしますか？そうでない場合は、後藤LAbR.9。
LAbR.8 Are there upstream peers other than MsgSource that have requested a label for FEC? If so, goto LAbR.11.
FECのためのラベルを要求したMsgSource以外が上流ピアはLAbR.8ていますか？もしそうなら、後藤LAbR.11。
LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV containing the Message ID used by the LSR in the outstanding Label Request message.
TLVが未ラベル要求メッセージにLSRによって使用されるメッセージIDを含むラベル要求メッセージID TLVである手順SEND_MESSAGE（ネクストホップ、ラベル中止要求、FEC、TLV）を、実行LAbR.9。
LAbR.10 Record that a label abort request for FEC is pending.
FECのラベルアボート要求が保留されていることをLAbR.10録音。
LAbR.11 Delete record of label request for FEC from MsgSource.
MsgSourceからのFECのためのラベル要求のレコードを削除しますLAbR.11。
LAbR.12 DONE
LAbR.12 DONE
Notes:
ノート：
1. LSR uses FEC and the Label Request Message ID TLV carried by the label abort request to locate its record (if any) for the previously received label request from MsgSource.
1. LSRはFEC使用し、ラベルによって運ばれるラベル要求メッセージID TLVはMsgSourceから以前に受信したラベル要求に対して（もしあれば）そのレコードを検索するための要求を中止します。
2. If LSR has received a label mapping from NextHop, it should behave as if it had advertised a label mapping to MsgSource and MsgSource has released it.
2. LSRはネクストホップからのラベルマッピングを受け取った場合、それはMsgSourceとMsgSourceそれをリリースしているにラベルマッピングを広告していたかのように、それが振る舞うべき。
A.1.4. Receive Label Release
A.1.4。ラベルのリリースを受け取ります
Summary:
概要：
When an LSR receives a label release message for a FEC from a peer, it checks whether other peers hold the released label. If none do, the LSR removes the label from forwarding/switching use, if it has not already done so, and if the LSR holds a label mapping from the FEC next hop, it releases the label mapping.
LSRがピアからのFECのラベル解放メッセージを受信すると、他のピアが放出された標識を保持するかどうかをチェックします。何も行わない場合、それはまだ行っていない場合、LSRは、転送/スイッチング使用からラベルを削除し、LSRはFEC次のホップからのラベルマッピングを保持している場合、それはラベルマッピングを解放します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- Label. The label specified in the message.
- ラベル。メッセージで指定されたラベル。
- FEC. The FEC specified in the message.
- FEC。 FECは、メッセージに指定されています。
Algorithm:
アルゴリズム：
LRl.1 Remove MsgSource from record of peers that hold Label for FEC. (See Note 1.)
FECのためのラベルを保持するピアのレコードからMsgSourceを削除LRl.1。 （注1を参照）。
LRl.2 Does message match an outstanding label withdraw for FEC previously sent to MsgSource? If not, goto LRl.4
LRl.2は、優れたラベルが以前MsgSourceに送られたFECのために撤回するメッセージと一致していますか？そうでない場合は、後藤LRl.4
LRl.3 Delete record of outstanding label withdraw for FEC previously sent to MsgSource.
優れたラベルのレコードを削除しますLRl.3以前MsgSourceに送られたFECのために撤退。
LRl.4 Is LSR merging labels for this FEC? If not, goto LRl.6. (See Note 2.)
LRl.4はこのFECのためのラベルをマージLSRですか？そうでない場合は、後藤LRl.6。 （注2を参照してください）
LRl.5 Has LSR previously advertised a label for this FEC to other peers? If so, goto LRl.10.
LRl.5はLSRは以前に他のピアにこのFECのためのラベルを広告していますか？もしそうなら、後藤LRl.10。
LRl.6 Is LSR egress for the FEC? If so, goto LRl.10
LRl.6はFECのためのLSR出口ですか？もしそうなら、後藤LRl.10
LRl.7 Is there a Next Hop for FEC? AND Does LSR have a previously received label mapping for FEC from Next Hop? If not, goto LRl.10.
LRl.7 FECのためのネクストホップはありますか？そして、LSRは次のホップからのFECのために、以前に受信したラベルマッピングを持っていますか？そうでない場合は、後藤LRl.10。
LRl.8 Is LSR configured to propagate releases? If not, goto LRl.10. (See Note 3.)
LRl.8はLSRは、リリースを伝播するように構成されていますか？そうでない場合は、後藤LRl.10。 （注3を参照してください）
LRl.9 Execute procedure Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).
LRl.9手順SEND_MESSAGE（ネクストホップ、次ホップからのラベルリリース、FEC、ラベル）を実行します。
LRl.10 Remove Label from forwarding/switching use for traffic from MsgSource.
MsgSourceからのトラフィックの転送/スイッチング使用からラベルを削除しLRl.10。
LRl.11 Do any peers still hold Label for FEC? If so, goto LRl.13.
すべてのピアがまだFECのためのラベルを保持していますLRl.11？もしそうなら、後藤LRl.13。
LRl.12 Free the Label.
ラベルを解放LRl.12。
LRl.13 DONE.
LRl.13はDONE。
Notes:
ノート：
1. If LSR is using Downstream Unsolicited label distribution, it should not re-advertise a label mapping for FEC to MsgSource until MsgSource requests it.
1. LSRは川下迷惑ラベル配布を使用している場合MsgSourceが要求するまで、それはMsgSourceにFECのためのラベルマッピングを再広告してはいけません。
2. LRl.4 through LRl.8 deal with determining whether where the LSR should propagate the label release to a downstream peer (LRl.9).
LSRは、下流ピア（LRl.9）にラベル放出を伝播するべき場所かどうかを決定するとともにLRl.8契約を介して2 LRl.4。
3. If LRl.8 is reached, no upstream LSR holds a label for the FEC, and the LSR holds a label for the FEC from the FEC Next Hop. The LSR could propagate the Label Release to the Next Hop. By propagating the Label Release the LSR releases a potentially scarce label resource. In doing so, it also increases the latency for re-establishing the LSP should MsgSource or some other upstream LSR send it a new Label Request for FEC.
LRl.8に達した場合3.、何の上流のLSRはFECのラベルを保持していない、とLSRはFECのネクストホップからのFECのラベルを保持しています。 LSRは、次のホップにラベル解放を伝播することができます。ラベルのリリースを伝播することにより、LSRは潜在的に希少なラベルリソースを解放します。そうすることで、それはまた、MsgSourceまたはいくつかの他の上流のLSRがそれにFECのための新しいラベル要求を送るべきLSPを再確立するための待ち時間が増加します。
Whether or not to propagate the release is not a protocol issue. Label distribution will operate properly whether or not the release is propagated. The decision to propagate or not should take into consideration factors such as: whether labels are a scarce resource in the operating environment; the importance of keeping LSP setup latency low by keeping the amount of signaling required small; whether LSP setup is ingress-controlled or egress-controlled in the operating environment.
リリースを伝播するかどうかは、プロトコルの問題ではありません。ラベルの分布はリリースが伝播されるかどうか、正しく動作します。伝播したりしないように意思決定は、以下のような考慮要因を考慮する必要があります。ラベルは、経営環境の希少な資源であるかどうか。小さな必要なシグナリングの量を維持することによって、低LSPセットアップ待ち時間を維持することの重要性。 LSP設定するかどうかは、進入制御または出力制御の動作環境です。
A.1.5. Receive Label Withdraw
A.1.5。ラベルを受信撤回
Summary:
概要：
When an LSR receives a label withdraw message for a FEC from an LDP peer, it responds with a label release message and it removes the label from any forwarding/switching use. If ordered control is in use, the LSR sends a label withdraw message to each LDP peer to which it had previously sent a label mapping for the FEC. If the LSR is using Downstream on Demand label advertisement with independent control, it then acts as if it had just recognized the FEC.
LSRがラベルはLDPピアからFECのためのメッセージを引き出す受信すると、ラベル解放メッセージで応答し、これは、任意の転送/スイッチング使用からラベルを除去します。注文したコントロールを使用している場合、LSRは、ラベルは、それが以前にFECのためのラベルマッピングを送っていたために、各LDPピアにメッセージを撤回送信します。 LSRが独立制御とデマンド・ラベル広告の川下使用している場合はそれだけでFECを認識していたかのように、それは、動作します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- Label. The label specified in the message.
- ラベル。メッセージで指定されたラベル。
- FEC. The FEC specified in the message.
- FEC。 FECは、メッセージに指定されています。
Algorithm:
アルゴリズム：
LWd.1 Remove Label from forwarding/switching use. (See Note 1.)
転送/スイッチング使用からラベルを削除しLWd.1。 （注1を参照）。
LWd.2 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label)
プロシージャを実行しLWd.2 SEND_MESSAGE（MsgSource、ラベル解放、FEC、ラベル）
LWd.3 Has LSR previously received and retained a matching label mapping for FEC from MsgSource? If not, goto LWd.13.
LWd.3はLSRは以前に受信し、MsgSourceからFECのために一致するラベルマッピングを保持していますか？そうでない場合は、後藤LWd.13。
LWd.4 Delete matching label mapping for FEC previously received from MsgSource.
以前MsgSourceから受信したFECのためのラベルマッピングに一致する削除LWd.4。
LWd.5 Is LSR using ordered control? If so, goto LWd.8.
LWd.5は、注文したコントロールを使用してLSRですか？もしそうなら、後藤LWd.8。
LWd.6 Is MsgSource using Downstream On Demand label advertisement? If not, goto LWd.13.
LWd.6は、オンデマンドラベル広告のダウンストリームを使用してMsgSourceですか？そうでない場合は、後藤LWd.13。
LWd.7 Generate Event: Recognize New FEC for FEC. Goto LWd.13. (See Note 2.)
イベントを生成LWd.7：FECのための新しいFECを認識します。後藤LWd.13。 （注2を参照してください）
LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource.
各ピアのLWd.12てLWd.8反復、MsgSource以外。
LWd.9 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at LWd.8.
LWd.9はLSRが以前にピアするFECのためのラベルマッピングを送っていますか？ない場合は、LWd.8で次のピアのための繰り返しを続けます。
LWd.10 Does the label previously sent to Peer "map" to the withdrawn Label? If not, continue iteration for next Peer at LWd.8. (See Note 3.)
ラベルは、以前に撤回ラベルに「マップ」ピアツーLWd.10を送っていますか？ない場合は、LWd.8で次のピアのための繰り返しを続けます。 （注3を参照してください）
LWd.11 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).
LWd.11手順Send_Label_Withdraw（ピア、FEC、以前にピアに送信ラベル）を実行します。
LWd.12 End iteration from LWd.8.
LWd.8からLWd.12終了反復。
LWd.13 DONE
LWd.13完了
Notes:
ノート：
1. If Label is not in forwarding/switching use, LWd.1 has no effect.
1.ラベルを使用し、スイッチング/転送にない場合、LWd.1は効果がありません。
2. LWd.7 handles the case where the LSR is using Downstream On Demand label distribution with independent control. In this situation the LSR should send a label request to the FEC next hop as if it had just recognized the FEC.
2. LWd.7はLSRが独立制御を備えたオンデマンドラベル配布のダウンストリームを使用している場合を扱います。それだけでFECを認識していたかのように、このような状況ではLSRはFECの次のホップにラベル要求を送信する必要があります。
3. LWd.10 handles both label merging (one or more incoming labels map to the same outgoing label) and no label merging (one label maps to the outgoing label) cases.
3. LWd.10両方のラベルマージ（一枚の以上の着信ラベルが同じ出ラベルにマップ）とラベルなしマージ場合（発信ラベル1つのラベルマップ）を扱います。
A.1.6. Recognize New FEC
A.1.6。新しいFECを認識
Summary:
概要：
The response by an LSR to learning a new FEC via the routing table may involve one or more of the following actions:
ルーティングテーブルを経由して新しいFECを学習するLSRによる応答は、次のアクションの一つ以上を含むことができます。
- Transmission of label mappings for the FEC to one or more LDP peers;
- 一つ以上のLDPピアへのFECのラベルマッピングの伝送;
- Transmission of a label request for the FEC to the FEC next hop;
- FEC次のホップにFEC用のラベル要求の送信。
- Any of the actions that can occur when the LSR receives a label mapping for the FEC from the FEC next hop.
- LSRはFEC次のホップからFECのためのラベルマッピングを受け取ったときに発生する可能性がありますアクションのいずれか。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The newly recognized FEC.
- FEC。新しく認識されたFEC。
- Next Hop. The next hop for the FEC.
- ネクストホップ。 FECのネクストホップ。
- InitAttributes. Attributes to be associated with the new FEC. (See Note 1.)
- InitAttributes。新しいFECに関連付けられる属性。 （注1を参照）。
- SAttributes. Attributes to be included in Label Mapping or Label Request messages, if any, sent to peers.
- SAttributes。ラベルマッピングまたはラベル要求メッセージに含まれる属性があれば、ピアに送信されます。
- StoredHopCount. Hop count associated with FEC label mapping, if any, previously received from Next Hop.
- StoredHopCount。 、以前にネクストホップから受信した場合のホップ数は、FECラベルマッピングに関連付けられています。
Algorithm:
アルゴリズム：
FEC.1 Perform LSR Label Distribution procedure:
FEC.1はLSRラベル配布手順を実行します。
For Downstream Unsolicited Independent Control
ダウンストリーム迷惑独立制御のため
2. Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating.
2. LSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していますか？もしそうなら、IsPropagatingに伝播する設定。ない場合は、NotPropagatingに伝播する設定。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).
3.手続きPrepare_Label_Mapping_Attributes（ピア、FEC、InitAttributes、SAttributes、伝播、未知のホップ数（0））を実行します。
5. End iteration from 1. Goto FEC.2.
1.後藤FEC.2から5.終了反復。
For Downstream Unsolicited Ordered Control
ダウンストリーム迷惑順序制御のため
2. Is LSR egress for the FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? If not, continue iteration for next Peer.
2. FECのためのLSR出口ですか？ OR LSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していますか？ない場合は、次のピアのための繰り返しを続けます。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
3.手順Prepare_Label_Mapping_Attributesを実行し（ピア、FEC、InitAttributes、SAttributes、伝播、StoredHopCount）。
5. End iteration from 1. Goto FEC.2.
1.後藤FEC.2から5.終了反復。
For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control
デマンド順序制御上のダウンストリームの需要独立コントロールまたは上のダウンストリームのために
FEC.2 Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, goto FEC.5
FEC.2はLSRは以前に受信し、ネクストホップからFECのためのラベルマッピングを保持していますか？もしそうなら、後藤FEC.5
FEC.3 Is Next Hop an LDP peer? If not, Goto FEC.6
FEC.3は、ネクストホップはLDPピアですか？そうでない場合は、後藤FEC.6
FEC.4 Perform LSR Label Request procedure:
FEC.4はLSRのラベル要求の手順を実行します。
For Request Never
決して要求について
For Request When Needed OR For Request On Request
要求のための要求に必要または要求に対するとき
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, InitAttributes, SAttributes);
1.手順Prepare_Label_Request_Attributes（ネクストホップ、FEC、InitAttributes、SAttributes）を実行します。
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto FEC.6.
2.手順Send_Label_Request（ネクストホップ、FEC、SAttributes）を実行します。後藤FEC.6。
FEC.5 Generate Event: Received Label Mapping from Next Hop. (See Note 3.)
ネクストホップから受信したラベルマッピング：イベントを生成しますFEC.5。 （注3を参照してください）
FEC.6 DONE.
FEC.6はDONE。
Notes:
ノート：
1. An example of an attribute that might be part of InitAttributes is one which specifies desired LSP characteristics, such as class of service (CoS). (Note that while the current version of LDP does not specify a CoS attribute, LDP extensions may.)
InitAttributesの一部かもしれない属性の1例は、サービス（COS）のクラスとして所望のLSPの特性を指定するものです。 （LDPの拡張は、自民党の現在のバージョンは、CoSの属性を指定していない間ことにも注意してください。）
The means by which FEC InitAttributes, if any, are specified is beyond the scope of LDP. Note that the InitAttributes will not include a known Hop Count or a Path Vector.
FEC InitAttributes手段、存在する場合は、指定されたLDPの範囲を超えています。 InitAttributesが知られているホップカウントまたはパスベクトルが含まれないことに注意してください。
2. An LSR using Downstream On Demand label distribution would send a label only if it had a previously received label request marked as pending. The LSR would have no such pending requests because it responds to any label request for an unknown FEC by sending the requesting LSR a No Route notification and discarding the label request; see LRq.3
オンデマンドラベル配布のダウンストリームを使用して2. LSRは、それが以前に受信したラベル要求が保留中としてマークされていた場合にのみ、ラベルを送信します。それは要求LSRにNOルート通知を送信し、ラベル要求を破棄することにより、未知のFECのための任意のラベル要求に応答するためLSRはそのような保留中の要求を持っていないだろう。 LRq.3を参照してください
3. If the LSR has a label for the FEC from the Next Hop, it should behave as if it had just received the label from the Next Hop. This occurs in the case of Liberal label retention mode.
3. LSRは次のホップからのFECのためのラベルを持っている場合、それは単にネクストホップからラベルを受け取ったかのように、それが振る舞うべき。これは、リベラルラベル保持モードの場合に発生します。
A.1.7. Detect Change in FEC Next Hop
A.1.7。 FEC次ホップの変化を検出
Summary:
概要：
The response by an LSR to a change in the next hop for a FEC may involve one or more of the following actions:
FECのための次のホップの変化にLSRによる応答は、次のアクションの一つ以上を含むことができます。
- Removal of the label from the FEC's old next hop from forwarding/switching use;
- 転送/スイッチングの使用からFECの古いネクストホップからのラベルの除去;
- Transmission of label mapping messages for the FEC to one or more LDP peers;
- 一つ以上のLDPピアへのFECのためのラベルマッピングメッセージの送信。
- Transmission of a label request to the FEC's new next hop;
- FECの新しい次のホップにラベル要求の送信。
- Any of the actions that can occur when the LSR receives a label mapping from the FEC's new next hop.
- LSRはFECの新しい次のホップからのラベルマッピングを受け取ったときに発生する可能性がありますアクションのいずれか。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The FEC whose next hop changed.
- FEC。その次のホップFECが変更されました。
- New Next Hop. The current next hop for the FEC.
- 新しいネクストホップ。 FECのための現在のネクストホップ。
- Old Next Hop. The previous next hop for the FEC.
- 旧ネクストホップ。 FECの前の次のホップ。
- OldLabel. Label, if any, previously received from Old Next Hop.
- OldLabel。ラベルは、もしあれば、以前に旧ネクストホップから受け取りました。
- CurAttributes. The attributes, if any, currently associated with the FEC.
- CurAttributes。属性は、もしあれば、現在FECに関連付けられています。
- SAttributes. Attributes to be included in Label Label Request message, if any, sent to New Next Hop.
- SAttributes。もしあればラベルのラベル要求メッセージに含まれる属性、新しい次のホップに送られます。
Algorithm:
アルゴリズム：
NH.1 Has LSR previously received and retained a label mapping for FEC from Old Next Hop? If not, goto NH.6.
NH.1はLSRは以前に受信し、旧ネクストホップからFECのためのラベルマッピングを保持していますか？そうでない場合は、後藤NH.6。
NH.2 Remove label from forwarding/switching use. (See Note 1.)
NH.2は使用を切り替え/フォワーディングからラベルを削除します。 （注1を参照）。
NH.3 Is LSR using Liberal label retention? If so, goto NH.6.
NH.3は、リベラルラベル保持を使用してLSRですか？もしそうなら、後藤NH.6。
NH.4 Execute procedure Send_Message (Old Next Hop, Label Release, OldLabel).
NH.4は、手順SEND_MESSAGE（旧ネクストホップ、ラベルリリース、OldLabel）を実行します。
NH.5 Delete label mapping for FEC previously received from Old Next Hop.
NH.5は、以前に旧ネクストホップから受信したFECのためのラベルマッピングを削除します。
NH.6 Does LSR have a label request pending with Old Next Hop? If not, goto NH.10.
NH.6はLSRは古いネクストホップで保留中のラベル要求を持っていますか？そうでない場合は、後藤NH.10。
NH.7 Is LSR using Conservative label retention? If not, goto NH.10.
NH.7はLSRは保守的なラベル保持を使用しますか？そうでない場合は、後藤NH.10。
NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV that carries the message ID of the pending label request.
NH.8プロシージャSEND_MESSAGE（古いネクストホップ、ラベル中止要求、FEC、TLV）TLVが保留ラベル要求のメッセージIDを搬送するラベル要求メッセージID TLVで、実行します。
NH.9 Record a label abort request is pending for FEC with Old Next Hop.
NH.9のレコードは、ラベルアボート要求は古いネクストホップとFECのために保留されています。
NH.10 Is there a New Next Hop for the FEC? If not, goto NH.16.
NH.10は、新しい次のホップがFECのためにありますか？そうでない場合は、後藤NH.16。
NH.11 Has LSR previously received and retained a label mapping for FEC from New Next Hop? If not, goto NH.13.
NH.11はLSRは以前に受信し、新しい次のホップからFECのためのラベルマッピングを保持していますか？そうでない場合は、後藤NH.13。
NH.12 Generate Event: Received Label Mapping from New Next Hop. Goto NH.20. (See Note 2.)
新しいネクストホップから受信したラベルマッピング：NH.12は、イベントを生成します。後藤NH.20。 （注2を参照してください）
NH.13 Is LSR using Downstream on Demand advertisement? OR Is Next Hop using Downstream on Demand advertisement? OR Is LSR using Conservative label retention? (See Note 3.) If so, goto NH.14. If not, goto NH.20.
NH.13は、オンデマンド広告を川下使用してLSRですか？または次のホップは、オンデマンド広告をダウンストリームを使ってますか？ ORは、LSRは保守的なラベル保持を使用しますか？もしそうなら、後藤NH.14（注3を参照）。そうでない場合は、後藤NH.20。
NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, CurAttributes, SAttributes)
NH.14は（ネクストホップ、FEC属性、属性）属性Prepare_Label_Requestプロシージャを実行します
NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC, SAttributes). (See Note 4.) Goto NH.20.
NH.15は、手順Send_Label_Request（新ネクストホップ、FEC、SAttributes）を実行します。後藤NH.20（注4を参照してください）。
NH.16 Iterate through NH.19 for each Peer.
各ピアのNH.19てNH.16反復。
NH.17 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at NH.16.
NH.17はLSRが以前にピアするFECのためのラベルマッピングを送っていますか？ない場合は、NH.16で次のピアのための繰り返しを続けます。
NH.18 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).
NH.18は、手順Send_Label_Withdraw（以前にピアに送信されたピア、FEC、ラベル）を実行します。
NH.19 End iteration from NH.16.
NH.16からNH.19終了反復。
NH.20 DONE.
NH.20はDONE。
Notes:
ノート：
1. If Label is not in forwarding/switching use, NH.2 has no effect.
1.ラベルを使用し、スイッチング/転送にない場合、NH.2は効果がありません。
2. If the LSR has a label for the FEC from the New Next Hop, it should behave as if it had just received the label from the New Next Hop.
LSRが新しいネクストホップからのFECのためのラベルを持っている場合、それは単に新しいネクストホップからラベルを受け取ったかのように2.、それが振る舞うべき。
3. The purpose of the check on label retention mode is to avoid a race with steps LMp.12-LMp.13 of the procedure for handling a Label Mapping message where the LSR operating in Conservative Label retention mode may have released a label mapping received from the New Next Hop before it detected the FEC next hop had changed.
3.ラベル保持モードのチェックの目的は、保守的なラベル保持モードで動作しているLSRは、受信したラベルマッピングをリリースしている可能性がラベルマッピングメッセージを処理するための手順のステップLMp.12-LMp.13との競合を避けるためです新しいネクストホップからそれはFECのネクストホップが変更された検出の前に。
4. Regardless of the Label Request procedure in use by the LSR, it must send a label request if the conditions in NH.8 hold. Therefore it executes the Send_Label_Request procedure directly rather than perform LSR Label Request procedure.
4. NH.8の条件は保持している場合に関係なく、LSRによって使用されているラベル要求手順の、それはラベル要求を送信する必要があります。従って、Send_Label_Requestの手順を実行し、直接ではなく、LSRラベル要求の手順を実行します。
A.1.8. Receive Notification / Label Request Aborted
A.1.8。中止の通知/ラベル要求を受け取ります
Summary:
概要：
When an LSR receives a Label Request Aborted notification from an LDP peer it records that the corresponding label request transaction, if any, has completed.
LSRは、LDPからラベル要求中止通知を受信した場合には、対応するラベル要求トランザクションは、もしあれば、完了したことを記録ピア。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The FEC for which a label was requested.
- FEC。ラベルが要求されたFEC。
- RequestMessageID. The message ID of the label request message to be aborted.
- RequestMessageID。ラベル要求メッセージのメッセージIDは中止されます。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。通知メッセージを送信したLDPピア。
Algorithm:
アルゴリズム：
LRqA.1 Does the notification correspond to an outstanding label request abort for FEC? (See Note 1). If not, goto LRqA.3.
LRqA.1はFECのため中止優れたラベル要求への通知に対応していますか？ （注1を参照）。そうでない場合は、後藤LRqA.3。
LRqA.2 Record that the label request for FEC has been aborted.
FECのためのラベル要求が中止されましたLRqA.2録音。
LRqA.3 DONE
LRqA.3 DONE
Notes:
ノート：
1. The LSR uses the FEC and RequestMessageID to locate its record, if any, of the outstanding label request abort.
1. LSRは、優れたラベルリクエストアボートのその記録を、もしあれば、見つけFECとRequestMessageIDを使用しています。
A.1.9. Receive Notification / No Label Resources
A.1.9。通知/ラベルなしリソースを受信しません
Summary:
概要：
When an LSR receives a No Label Resources notification from an LDP peer, it stops sending label request messages to the peer until it receives a Label Resources Available Notification from the peer.
LSRは、LDPピアからのラベルリソースの通知を受信すると、それは、ピアからのラベルのリソース利用可能な通知を受信するまでピアにラベル要求メッセージの送信を停止します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The FEC for which a label was requested.
- FEC。ラベルが要求されたFEC。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。通知メッセージを送信したLDPピア。
Algorithm:
アルゴリズム：
NoRes.1 Delete record of outstanding label request for FEC sent to MsgSource.
NoRes.1 MsgSourceに送られたFECのための優れたラベル要求のレコードを削除します。
NoRes.2 Record label mapping for FEC from MsgSource is needed but that no label resources are available.
MsgSourceからのFECのためのNoRes.2レコードレーベルのマッピングが必要とされているが、何のラベルリソースが用意されていないこと。
NoRes.3 Set status record indicating it is not OK to send label requests to MsgSource.
それを示すNoRes.3設定ステータスレコードがMsgSourceにラベル要求を送信するためにOKではありません。
NoRes.4 DONE.
NoRes.4はDONE。
A.1.10. Receive Notification / No Route
A.1.10。受信通知/いいえルート
Summary:
概要：
When an LSR receives a No Route notification from an LDP peer in response to a Label Request message, the Label No Route procedure in use dictates its response. The LSR either will take no further action, or it will defer the label request by starting a timer and send another Label Request message to the peer when the timer later expires.
LSRがラベル要求メッセージに応答して、LDPピアからのNOルート通知を受信した場合、使用中のラベルのNOルートの手順は、その応答を決定します。 LSRはどちらかそれ以上の措置を講じていないか、またはそれは、タイマーを開始することにより、ラベル要求を延期し、タイマーが満了したときに、後にピアに別のラベル要求メッセージを送信します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The FEC for which a label was requested.
- FEC。ラベルが要求されたFEC。
- Attributes. The attributes associated with the label request.
- 属性。ラベル要求に関連付けられた属性。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。通知メッセージを送信したLDPピア。
Algorithm:
アルゴリズム：
NoNH.1 Delete record of outstanding label request for FEC sent to MsgSource.
NoNH.1 MsgSourceに送られたFECのための優れたラベル要求のレコードを削除します。
NoNH.2 Perform LSR Label No Route procedure.
NoNH.2はLSRラベルNOルートの手順を実行します。
For Request No Retry
リクエストはありません再試行のために
For Request Retry
要求の再試行のために
1. Record deferred label request for FEC and Attributes to be sent to MsgSource.
1.録音はFECのためのラベル要求を延期し、MsgSourceに送信される属性。
NoNH.3 DONE.
NoNH.3はDONE。
A.1.11. Receive Notification / Loop Detected
A.1.11。通知を受信/ループが検出されました
Summary:
概要：
When an LSR receives a Loop Detected Status Code from an LDP peer in response to a Label Request message or a Label Mapping message, it behaves as if it had received a No Route notification.
LSRは、ラベル要求メッセージまたはラベルマッピングメッセージに応答して、LDPピアからのループ検出ステータスコードを受信すると、それはNOルート通知を受けたかのように、それが動作します。
Context:
状況：
See "Receive Notification / No Route".
「通知/ NOルートを受け取る」を参照してください。
Algorithm:
アルゴリズム：
See "Receive Notification / No Route"
「通知/ NOルートを受け取る」を参照してください。
Notes:
ノート：
1. When the Loop Detected notification is in response to a Label Request message, it arrives in a Status Code TLV in a Notification message. When it is in response to a Label Mapping message, it arrives in a Status Code TLV in a Label Release message.
ループ検出通知がラベル要求メッセージに対応している場合は1、それは通知メッセージにステータスコードTLVに到着します。それはラベルマッピングメッセージに対応している場合は、ラベル解放メッセージでステータスコードTLVに到着します。
A.1.12. Receive Notification / Label Resources Available
A.1.12。通知/ラベルリソースが利用可能受信
Summary:
概要：
When an LSR receives a Label Resources Available notification from an LDP peer, it resumes sending label requests to the peer.
LSRは、LDPピアからラベルリソースの利用可能通知を受信すると、ピアにラベル要求の送信を再開します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。通知メッセージを送信したLDPピア。
- SAttributes. Attributes stored with postponed Label Request message.
- SAttributes。属性は延期ラベル要求メッセージに格納されています。
Algorithm:
アルゴリズム：
Res.1 Set status record indicating it is OK to send label requests to MsgSource.
それを示すRes.1設定ステータスレコードがMsgSourceにラベルリクエストを送信するためにOKです。
Res.2 Iterate through Res.6 for each record of a FEC label mapping needed from MsgSource for which no label resources are available.
ラベルなしリソースが用意されていないいるMsgSourceから必要なFECラベルマッピングの各レコードのRes.6てRes.2反復。
Res.3 Is MsgSource the next hop for FEC? If not, goto Res.5.
Res.3あるMsgSource FECのネクストホップ？そうでない場合は、後藤Res.5。
Res.4 Execute procedure Send_Label_Request (MsgSource, FEC, SAttributes). If the procedure fails, terminate iteration.
Res.4は、手順Send_Label_Request（MsgSource、FEC、SAttributes）を実行します。手順が失敗した場合は、反復を終了します。
Res.5 Delete record that no resources are available for a label mapping for FEC needed from MsgSource.
Res.5にはリソースがMsgSourceから必要なFECのためのラベルマッピングのために用意されていないことをレコードを削除します。
Res.6 End iteration from Res.2
Res.2からRes.6エンド反復
Res.7 DONE.
Res.7はDONE。
A.1.13. Detect local label resources have become available
A.1.13。検出ローカルラベルリソースが利用可能となっています
Summary:
概要：
After an LSR has sent a No Label Resources notification to an LDP peer, when label resources later become available it sends a Label Resources Available notification to each such peer.
ラベルリソースが、後に使用可能になったときLSRは、LDPピアにないラベルリソースの通知を送信した後、それは、そのような各ピアにラベルリソースの利用可能通知を送信します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- Attributes. Attributes stored with postponed Label Mapping message.
- 属性。延期ラベルマッピングメッセージで保存された属性。
Algorithm:
アルゴリズム：
ResA.1 Iterate through ResA.4 for each Peer to which LSR has previously sent a No Label Resources notification.
それぞれのResA.4通じResA.1反復は、LSRが以前ありませんラベルリソースの通知を送信したためにピア。
ResA.2 Execute procedure Send_Notification (Peer, Label Resources Available)
ResA.2手順Send_Notification（利用可能なピア、ラベルリソース）を実行
ResA.3 Delete record that No Label Resources notification was previously sent to Peer.
ResA.3ませラベルリソース通知が以前にピアに送信されなかったこと、レコードを削除します。
ResA.4 End iteration from ResA.1
ResA.1からResA.4エンド反復
ResA.5 Iterate through ResA.8 for each record of a label mapping needed for FEC for Peer but no-label-resources. (See Note 1.)
ピアのためのFECのために必要なラベルマッピングの各レコードが、無ラベルリソースのためのResA.8てResA.5反復。 （注1を参照）。
ResA.6 Execute procedure Send_Label (Peer, FEC, Attributes). If the procedure fails, terminate iteration.
ResA.6手順Send_Label（ピア、FEC、属性）を実行します。手順が失敗した場合は、反復を終了します。
ResA.7 Clear record of FEC label mapping needed for peer but no-label-resources.
ピアのために必要なFECラベルマッピングのResA.7クリアレコードが、無ラベルリソース。
ResA.8 End iteration from ResA.5
ResA.5からResA.8エンド反復
ResA.9 DONE.
ResA.9はDONE。
Notes:
ノート：
1. Iteration ResA.5 through ResA.8 handles the situation where the LSR is using Downstream Unsolicited label distribution and was previously unable to allocate a label for a FEC.
ResA.8スルー1.反復ResA.5はLSRが下流迷惑ラベル分配を使用し、FECのラベルを割り当てることが以前にできなかったれる状況を取り扱います。
A.1.14. LSR decides to no longer label switch a FEC
A.1.14。 LSRは、もはやラベルはFECを切り替えることを決定します
Summary:
概要：
An LSR may unilaterally decide to no longer label switch a FEC for an LDP peer. An LSR that does so must send a label withdraw message for the FEC to the peer.
LSRは、一方的にLDPピアのためのFECを切り替えるもはやラベルに決めることができます。そのラベルは、ピアにFECのためのメッセージを撤回送信しなければならないんLSR。
Context:
状況：
- Peer. The peer.
- ピア。ピア。
- FEC. The FEC.
- FEC。 FEC。
- PrevAdvLabel. The label for FEC previously advertised to Peer.
- PrevAdvLabel。 FECのためのラベルは、以前にピアにアドバタイズ。
Algorithm:
アルゴリズム：
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, PrevAdvLabel). (See Note 1.)
手順Send_Label_Withdraw（ピア、FEC、PrevAdvLabel）を実行しNoLS.1。 （注1を参照）。
NoLS.2 DONE.
NoLS.2女性。
Notes:
ノート：
1. The LSR may remove the label from forwarding/switching use as part of this event or as part of processing the label release from the peer in response to the label withdraw.
1. LSRは、このイベントの一部として、または撤回ラベルに応じてピアからラベル解放処理の一部として使用切替/転送からラベルを除去することができます。
A.1.15. Timeout of deferred label request
A.1.15。繰延ラベル要求のタイムアウト
Summary:
概要：
Label requests are deferred in response to No Route and Loop Detected notifications. When a deferred FEC label request for a peer times out, the LSR sends the label request.
ラベルの要求はNOルート及びループ検出通知に応じて延期されています。ピア回繰延FECラベル要求が出て、LSRは、ラベル要求を送信します。
Context:
状況：
- LSR. The LSR handling the event.
- LSR。 LSRは、イベントを処理します。
- FEC. The FEC associated with the timeout event.
- FEC。 FECは、タイムアウトイベントに関連付けられています。
- Peer. The LDP peer associated with the timeout event.
- ピア。タイムアウトイベントに関連付けられたLDPピア。
- Attributes. Attributes stored with deferred Label Request message.
- 属性。繰延ラベル要求メッセージに保存された属性。
Algorithm:
アルゴリズム：
TO.1 Retrieve the record of the deferred label request.
TO.1は、繰延ラベル要求のレコードを取得します。
TO.2 Is Peer the next hop for FEC? If not, goto TO.4.
TO.2はFECのネクストホップピアですか？ 、後藤TO.4ない場合。
TO.3 Execute procedure Send_Label_Request (Peer, FEC).
TO.3は、手順Send_Label_Request（ピア、FEC）を実行します。
TO.4 DONE.
TO.4はDONE。
A.2. Common Label Distribution Procedures
A.2。共通のラベル配布手順
This section specifies utility procedures used by the algorithms
that handle label distribution events.
A.2.1. Send_Label
A.2.1。 Send_Label
Summary:
概要：
The Send_Label procedure allocates a label for a FEC for an LDP peer, if possible, and sends a label mapping for the FEC to the peer. If the LSR is unable to allocate the label and if it has a pending label request from the peer, it sends the LDP peer a No Label Resources notification.
Send_Label手順は、可能な場合は、LDPピアのためのFECのラベルを割り当てて、ピアにFECのためのラベルマッピングを送信します。 LSRは、ラベルを割り当てることができない、それは、ピアからの保留中のラベル要求を持っている場合、それは自民党がありませんラベルリソースの通知をピア送信します。場合
Parameters:
パラメーター：
- Peer. The LDP peer to which the label mapping is to be sent.
- ピア。ラベルマッピングが送られるべきLDPピア。
- FEC. The FEC for which a label mapping is to be sent.
- FEC。ラベルマッピングのためのFECが送られます。
- Attributes. The attributes to be included with the label mapping.
- 属性。属性は、ラベルマッピングに含まれます。
Additional Context:
追加のコンテキスト：
- LSR. The LSR executing the procedure.
- LSR。 LSRは、手順を実行します。
- Label. The label allocated and sent to Peer.
- ラベル。ラベルが割り当てられ、ピアに送信します。
Algorithm:
アルゴリズム：
SL.1 Does LSR have a label to allocate? If not, goto SL.9.
SL.1 LSRは割り当てるラベルを持っていますか？ 、後藤SL.9ない場合。
SL.2 Allocate Label and bind it to the FEC.
SL.2は、ラベルを割り当て、FECにバインドします。
SL.3 Install Label for forwarding/switching use.
SL.3は使用を切り替え/転送するためのラベルをインストールします。
SL.4 Execute procedure Send_Message (Peer, Label Mapping, FEC, Label, Attributes).
SL.4は、手順SEND_MESSAGE（ピア、ラベルマッピング、FEC、ラベル、属性）を実行します。
SL.5 Record label mapping for FEC with Label and Attributes has been sent to Peer.
ラベルや属性を持つFECのためのSL.5レコードレーベルマッピングがピアに送信されてきました。
SL.6 Does LSR have a record of a FEC label request from Peer marked as pending? If not, goto SL.8.
SL.6 LSRは、保留中としてマークされたピアからFECラベル要求の記録を持っていますか？ 、後藤SL.8ない場合。
SL.7 Delete record of pending label request for FEC from Peer.
SL.7は、ピアからのFECのために保留中のラベル要求のレコードを削除します。
SL.8 Return success.
成功を返しSL.8。
SL.9 Does LSR have a label request for FEC from Peer marked as pending? If not, goto SL.13.
SL.9 LSRは保留中としてマークされ、ピアからのFECのためのラベル要求を持っていますか？そうでない場合は、後藤SL.13。
SL.10 Execute procedure Send_Notification (Peer, No Label Resources).
SL.10は、手順Send_Notification（ピア、ラベルなしリソース）を実行します。
SL.11 Delete record of pending label request for FEC from Peer.
SL.11は、ピアからのFECのために保留中のラベル要求のレコードを削除します。
SL.12 Record No Label Resources notification has been sent to Peer. Goto SL.14.
SL.12レコード番号ラベルリソース通知がピアに送信されてきました。後藤SL.14。
SL.13 Record label mapping needed for FEC and Attributes for Peer, but no-label-resources. (See Note 1.)
SL.13レコードラベルマッピングFECのために必要とピアの属性が、無ラベルリソース。 （注1を参照）。
SL.14 Return failure.
失敗を返しSL.14。
Notes:
ノート：
1. SL.13 handles the case of Downstream Unsolicited label distribution when the LSR is unable to allocate a label for a FEC to send to a Peer.
LSRがピアに送信するFECのラベルを割り当てることができない場合1 SL.13は下流迷惑ラベル配布の場合を扱います。
A.2.2. Send_Label_Request
A.2.2。 Send_Label_Request
Summary:
概要：
An LSR uses the Send_Label_Request procedure to send a request for a label for a FEC to an LDP peer if currently permitted to do so.
LSRは現在、これを行うに許可されている場合LDPピアにFECのためのラベルのための要求を送信するためにSend_Label_Request手順を使用しています。
Parameters:
パラメーター：
- Peer. The LDP peer to which the label request is to be sent.
- ピア。ラベル要求が送られるべきLDPピア。
- FEC. The FEC for which a label request is to be sent.
- FEC。ラベル要求のためのFECが送られます。
- Attributes. Attributes to be included in the label request. E.g., Hop Count, Path Vector.
- 属性。ラベル要求に含まれる属性。例えば、ホップ、パスベクトルを数えます。
Additional Context:
追加のコンテキスト：
- LSR. The LSR executing the procedure.
- LSR。 LSRは、手順を実行します。
Algorithm:
アルゴリズム：
SLRq.1 Has a label request for FEC previously been sent to Peer and is it marked as outstanding? If so, Return success. (See Note 1.)
SLRq.1はFECのためのラベル要求が以前にピアに送信され、それが残高マークされていますか？もしそうなら、成功を返します。 （注1を参照）。
SLRq.2 Is status record indicating it is OK to send label requests to Peer set? If not, goto SLRq.6
SLRq.2は、設定ピアにラベル要求を送信するためにOKであることを示すステータスレコードですか？そうでない場合は、後藤SLRq.6
SLRq.3 Execute procedure Send_Message (Peer, Label Request, FEC, Attributes).
SLRq.3手順SEND_MESSAGE（ピア、ラベル要求、FEC、属性）を実行します。
SLRq.4 Record label request for FEC has been sent to Peer and mark it as outstanding.
FECのためのSLRq.4レコードレーベル要求は優れたとして、それをピアとマークするために送信されてきました。
SLRq.5 Return success.
成功を返しSLRq.5。
SLRq.6 Postpone the label request by recording label mapping for FEC and Attributes from Peer is needed but that no label resources are available.
FECのためのラベルマッピングを記録することにより、ラベル要求を延期し、ピアが必要とされているから属性が、ラベルなしのリソースが利用できないことSLRq.6。
SLRq.7 Return failure.
失敗を返しSLRq.7。
Notes:
ノート：
1. If the LSR is a non-merging LSR it must distinguish between attempts to send label requests for a FEC triggered by different upstream LDP peers from duplicate requests. This procedure will not send a duplicate label request.
1. LSRは非合併LSRであれば、それは重複したリクエストは異なる上流のLDPピアによってトリガFECのラベル要求を送信しようとする試みとを区別しなければなりません。この手順は、重複したラベル要求を送信しません。
A.2.3. Send_Label_Withdraw
A.2.3。 Send_Label_Withdraw
Summary:
概要：
An LSR uses the Send_Label_Withdraw procedure to withdraw a label for a FEC from an LDP peer. To do this the LSR sends a Label Withdraw message to the peer.
LSRは、LDPピアからFECのためのラベルを撤回するSend_Label_Withdrawの手順を使用しています。これを行うためにLSRはラベルがピアにメッセージを撤回送信します。
Parameters:
パラメーター：
- Peer. The LDP peer to which the label withdraw is to be sent.
- ピア。ラベルが撤退れたLDPピアが送信されます。
- FEC. The FEC for which a label is being withdrawn.
- FEC。ラベルが撤回されているFEC。
- Label. The label being withdrawn
- ラベル。ラベルが引き出されます
Additional Context:
追加のコンテキスト：
- LSR. The LSR executing the procedure.
- LSR。 LSRは、手順を実行します。
Algorithm:
アルゴリズム：
SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC, Label)
プロシージャを実行しSWd.1 SEND_MESSAGE（ピア、ラベル撤回、FEC、ラベル）
SWd.2 Record label withdraw for FEC has been sent to Peer and mark it as outstanding.
FECは、優れたとして、それをピアとマークするために送信されてきたためSWd.2レコードレーベルは撤退します。
A.2.4. Send_Notification
A.2.4。 Send_Notification
Summary:
概要：
An LSR uses the Send_Notification procedure to send an LDP peer a notification message.
LSRは、LDPピアに通知メッセージを送信するSend_Notification手順を使用します。
Parameters:
パラメーター：
- Peer. The LDP peer to which the Notification message is to be sent.
- ピア。通知メッセージが送信されるべきLDPピア。
- Status. Status code to be included in the Notification message.
- 状態。通知メッセージに含まれるステータスコード。
Additional Context:
追加のコンテキスト：
None.
無し。
Algorithm:
アルゴリズム：
SNt.1 Execute procedure Send_Message (Peer, Notification, Status)
手順SEND_MESSAGE（ピア、通知、ステータス）を実行しSNt.1
A.2.5. Send_Message
A.2.5。メッセージを送る
Summary:
概要：
An LSR uses the Send_Message procedure to send an LDP peer an LDP message.
LSRは、LDPは、LDPメッセージをピアに送信するSEND_MESSAGEプロシージャを使用しています。
Parameters:
パラメーター：
- Peer. The LDP peer to which the message is to be sent.
- ピア。メッセージが送信されるべきLDPピア。
- Message Type. The type of message to be sent.
- メッセージタイプ。送信するメッセージの種類。
- Additional message contents . . . .
- 追加のメッセージの内容。 。 。 。
Additional Context:
追加のコンテキスト：
None.
無し。
Algorithm:
アルゴリズム：
This procedure is the means by which an LSR sends an LDP message of the specified type to the specified LDP peer.
この手順では、LSRは、指定されたLDPピアに指定されたタイプのLDPメッセージを送信する手段です。
A.2.6. Check_Received_Attributes
A.2.6。 Check_Received_Attributes
Summary:
概要：
Check the attributes received in a Label Mapping or Label Request message. If the attributes include a Hop Count or Path Vector, perform a loop detection check. If a loop is detected, cause a Loop Detected Notification message to be sent to MsgSource.
ラベルマッピングまたはラベル要求メッセージで受信した属性を確認してください。属性はホップカウントまたはパスベクトルが含まれている場合、ループ検知チェックを行います。ループが検出された場合、ループ検出通知メッセージがMsgSourceに送られます。
Parameters:
パラメーター：
- MsgSource. The LDP peer that sent the message.
- MsgSource。メッセージを送ったLDPピア。
- MsgType. The type of message received.
- のMsgType。メッセージの種類は、受信されました。
- RAttributes. The attributes in the message.
- RAttributes。メッセージの属性。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR同上。このLSRのユニークなLSR同上。
- Hop Count. The Hop Count, if any, in the received attributes.
- ホップカウント。受け取った属性でのホップカウント、もしあれば、。
- Path Vector. The Path Vector, if any in the received attributes.
- パスベクトル。パスベクトル、受信属性であれば。
Algorithm:
アルゴリズム：
CRa.1 Do RAttributes include Hop Count? If not, goto CRa.5.
CRa.1は、ホップカウントのRAttributes含まれていますか？そうでない場合は、後藤CRa.5。
CRa.2 Does Hop Count exceed Max allowable hop count? If so, goto CRa.6.
CRa.2は、ホップの最大許容ホップ数を超えてカウントしていますか？もしそうなら、後藤CRa.6。
CRa.3 Do RAttributes include Path Vector? If not, goto CRa.5.
CRa.3はパスベクタをRAttributes含まれていますか？そうでない場合は、後藤CRa.5。
CRa.4 Does Path Vector Include LSR Id? OR Does length of Path Vector exceed Max allowable length? If so, goto CRa.6
CRa.4はパスベクトルはLSR IDが含まれていますか？ ORは、パスのベクトルの長さが最大許容長を超えていますか？もしそうなら、後藤CRa.6
CRa.5 Return No Loop Detected.
CRa.5リターン・ノーループが検出されました。
CRa.6 Is MsgType LabelMapping? If so, goto CRa.8. (See Note 1.)
CRa.6はのMsgType LabelMappingですか？もしそうなら、後藤CRa.8。 （注1を参照）。
CRa.7 Execute procedure Send_Notification (MsgSource, Loop Detected)
CRa.7手順Send_Notification（検出MsgSource、ループ）を実行します
CRa.8 Return Loop Detected.
CRa.8戻りループが検出されました。
CRa.9 DONE
CRa.9はDONE
Notes:
ノート：
1. When the attributes being checked were received in a Label Mapping message, the LSR sends the Loop Detected notification in a Status Code TLV in a Label Release message. (See Section "Receive Label Mapping").
1.チェックされている属性は、ラベルマッピングメッセージで受信した、LSRはループラベル解放メッセージでステータスコードTLVで通知が検出され送信されます。 （「ラベルマッピングを受け取る」セクションを参照してください）。
A.2.7. Prepare_Label_Request_Attributes
A.2.7。 Prepare_Label_Request_Attributes
Summary:
概要：
This procedure is used whenever a Label Request is to be sent to a Peer to compute the Hop Count and Path Vector, if any, to include in the message.
この手順は、ラベル要求メッセージに含める、もしあれば、ホップカウントとパスベクトルを計算するためにピアに送信されるたびに使用されます。
Parameters:
パラメーター：
- Peer. The LDP peer to which the message is to be sent.
- ピア。メッセージが送信されるべきLDPピア。
- FEC. The FEC for which a label request is to be sent.
- FEC。ラベル要求のためのFECが送られます。
- RAttributes. The attributes this LSR associates with the LSP for FEC.
- RAttributes。 FECのためのLSPと属性このLSRの仲間。
- SAttributes. The attributes to be included in the Label Request message.
- SAttributes。属性は、ラベル要求メッセージに含まれます。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR同上。このLSRのユニークなLSR同上。
Algorithm:
アルゴリズム：
PRqA.1 Is Hop Count required for this Peer (see Note 1.) ? OR Do RAttributes include a Hop Count? OR Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.1あるホップ（注1を参照）、このピアのために必要なカウント？ OR RAttributesはホップカウントが含まれていますか？またはループ検出はLSRで構成されていますか？そうでない場合は、後藤PRqA.14。
PRqA.2 Is LSR ingress for FEC? If not, goto PRqA.6.
PRqA.2はFECのためのLSRの進入ですか？そうでない場合は、後藤PRqA.6。
PRqA.3 Include Hop Count of 1 in SAttributes.
PRqA.3はSAttributes中1のホップカウントを含めます。
PRqA.4 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.4ループ検出はLSRで構成されていますか？そうでない場合は、後藤PRqA.14。
PRqA.5 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRqA.5はLSRのマージ可能ですか？もしそうなら、後藤PRqA.14。そうでない場合は、後藤PRqA.13。
PRqA.6 Do RAttributes include a Hop Count? If not, goto PRqA.8.
PRqA.6は、ホップカウントのRAttributes含まれていますか？そうでない場合は、後藤PRqA.8。
PRqA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. (See Note 2.) Goto PRqA.9.
PRqA.7インクリメントRAttributesホップ数とSAttributesに結果のホップカウントをコピーします。後藤PRqA.9（注2を参照してください）。
PRqA.8 Include Hop Count of unknown (0) in SAttributes.
PRqA.8は不明（0）でSAttributesのホップカウントを含めます。
PRqA.9 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.9ループ検出はLSRで構成されていますか？そうでない場合は、後藤PRqA.14。
PRqA.10 Do RAttributes have a Path Vector? If so, goto PRqA.12.
PRqA.10ドゥRAttributesはパスベクトルを持っていますか？もしそうなら、後藤PRqA.12。
PRqA.11 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRqA.11はLSRのマージ可能ですか？もしそうなら、後藤PRqA.14。そうでない場合は、後藤PRqA.13。
PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes and copy the resulting Path Vector into SAttributes. Goto PRqA.14.
PRqA.12はRAttributesからパスベクトルの先頭にLSR Idを追加し、SAttributesに結果のパスベクトルをコピーします。後藤PRqA.14。
PRqA.13 Include Path Vector of length 1 containing LSR Id in SAttributes.
PRqA.13はSAttributesにLSR IDを含む長さ1のパスベクタを含めます。
PRqA.14 DONE.
PRqA.14はDONE。
Notes:
ノート：
1. The link with Peer may require that Hop Count be included in Label Request messages; for example, see [RFC3035] and [RFC3034].
1.ピアとのリンクは、ホップカウントラベル要求メッセージに含まれることを必要とするかもしれません。例えば、[RFC3035]及び[RFC3034]を参照。
A.2.8. Prepare_Label_Mapping_Attributes
A.2.8。 Prepare_Label_Mapping_Attributes
Summary:
概要：
This procedure is used whenever a Label Mapping is to be sent to a Peer to compute the Hop Count and Path Vector, if any, to include in the message.
この手順は、ラベルマッピングメッセージに含める、もしあれば、ホップカウントとパスベクトルを計算するためにピアに送信されるたびに使用されます。
Parameters:
パラメーター：
- Peer. The LDP peer to which the message is to be sent.
- ピア。メッセージが送信されるべきLDPピア。
- FEC. The FEC for which a label request is to be sent.
- FEC。ラベル要求のためのFECが送られます。
- RAttributes. The attributes this LSR associates with the LSP for FEC.
- RAttributes。 FECのためのLSPと属性このLSRの仲間。
- SAttributes. The attributes to be included in the Label Mapping message.
- SAttributes。属性は、ラベルマッピングメッセージに含まれます。
- IsPropagating. The LSR is sending the Label Mapping message to propagate one received from the FEC next hop.
- IsPropagating。 LSRはFECのネクストホップから受信した1つを伝播するラベルマッピングメッセージを送信しています。
- PrevHopCount. The Hop Count, if any, this LSR associates with the LSP for the FEC.
- PrevHopCount。ホップカウント、もしあれば、FECのためのLSPと、このLSRの仲間。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR同上。このLSRのユニークなLSR同上。
Algorithm:
アルゴリズム：
PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR Do RAttributes include a Hop Count? OR Is Loop Detection configured on LSR? If not, goto PMpA.21.
PMpA.1あるホップ（注1を参照）、このピアのために必要なカウント？ OR RAttributesはホップカウントが含まれていますか？またはループ検出はLSRで構成されていますか？そうでない場合は、後藤PMpA.21。
PMpA.2 Is LSR egress for FEC? If not, goto PMpA.4.
PMpA.2はFECのためのLSR出口ですか？そうでない場合は、後藤PMpA.4。
PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.21.
PMpA.3はSAttributes中1のホップカウントを含めます。後藤PMpA.21。
PMpA.4 Do RAttributes have a Hop Count? If not, goto PMpA.8.
PMpA.4はRAttributesはホップカウントはありますか？そうでない場合は、後藤PMpA.8。
PMpA.5 Is LSR member of edge set for an LSR domain whose LSRs do not perform TTL decrement AND Is Peer in that domain (See Note 2.). If not, goto PMpA.7.
PMpA.5はLSRのTTLの減算を実行し、そのドメイン内のピアであるしていないLSRドメインのエッジセットのLSRメンバー（参照注2）です。そうでない場合は、後藤PMpA.7。
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.9.
PMpA.6はSAttributes中1のホップカウントを含めます。後藤PMpA.9。
PMpA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. See Note 2. Goto PMpA.9.
PMpA.7インクリメントRAttributesホップ数とSAttributesに結果のホップカウントをコピーします。 2.後藤PMpA.9に注意してくださいを参照してください。
PMpA.8 Include Hop Count of unknown (0) in SAttributes.
PMpA.8は不明（0）でSAttributesのホップカウントを含めます。
PMpA.9 Is Loop Detection configured on LSR? If not, goto PMpA.21.
PMpA.9ループ検出はLSRで構成されていますか？そうでない場合は、後藤PMpA.21。
PMpA.10 Do RAttributes have a Path Vector? If so, goto PMpA.19.
PMpA.10ドゥRAttributesはパスベクトルを持っていますか？もしそうなら、後藤PMpA.19。
PMpA.11 Is LSR propagating a received Label Mapping? If not, goto PMpA.20.
PMpA.11は、受け取ったラベルマッピングを伝播するLSRですか？そうでない場合は、後藤PMpA.20。
PMpA.12 Does LSR support merging? If not, goto PMpA.14.
PMpA.12はLSRのサポートがマージしていますか？そうでない場合は、後藤PMpA.14。
PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.20.
PMpA.13はLSRが以前にピアするFECのためのラベルマッピングを送っていますか？そうでない場合は、後藤PMpA.20。
PMpA.14 Do RAttributes include a Hop Count? If not, goto PMpA.21.
PMpA.14のDo RAttributesは、ホップカウントが含まれていますか？そうでない場合は、後藤PMpA.21。
PMpA.15 Is Hop Count in Rattributes unknown(0)? If so, goto PMpA.20.
PMpA.15されるホップRattributes不明（0）にカウント？もしそうなら、後藤PMpA.20。
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer? If not goto PMpA.21.
PMpA.16はLSRが以前にピアするFECのためのラベルマッピングを送っていますか？後藤PMpA.21ない場合。
PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ? If not goto PMpA.21.
PMpA.17はPrevHopCount異なるRAttributesにおけるホップカウントですか？後藤PMpA.21ない場合。
PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR Is PrevHopCount unknown(0) If not, goto PMpA.21.
PMpA.18はRAttributes> PrevHopCountにおけるホップカウントですか？ OR PrevHopCount不明（0）、後藤PMpA.21ない場合です。
PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and copy the resulting Path Vector into SAttributes. Goto PMpA.21.
PMpA.19はRAttributesからパスベクトルの先頭にLSR Idを追加し、SAttributesに結果のパスベクトルをコピーします。後藤PMpA.21。
PMpA.20 Include Path Vector of length 1 containing LSR Id in SAttributes.
PMpA.20はSAttributesにLSR IDを含む長さ1のパスベクタを含めます。
PMpA.21 DONE.
PMpA.21はDONE。
Notes:
ノート：
1. The link with Peer may require that Hop Count be included in Label Mapping messages; for example, see [RFC3035] and [RFC3034].
1.ピアとのリンクは、ホップカウントラベルマッピングメッセージに含まれることを必要とするかもしれません。例えば、[RFC3035]及び[RFC3034]を参照。
2. If the LSR is at the edge of a cloud of LSRs that do not perform TTL-decrement and it is propagating the Label Mapping message upstream into the cloud, it sets the Hop Count to 1 so that Hop Count across the cloud is calculated properly. This ensures proper TTL management for packets forwarded across the part of the LSP that passes through the cloud.
2. LSRはTTLデクリメントを行わないと、それがクラウドに上流のLabel Mappingメッセージを伝播するのLSRの雲の縁にある場合、それは雲が計算さを横切ってホップカウントするようにホップ1にカウント設定正しく。これは、雲を通過するLSPの一部を横切って転送されるパケットのための適切なTTL管理を確実にします。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。