[要約] RFC 5036は、Label Distribution Protocol（LDP）の仕様を定義しており、MPLSネットワークでラベルの配布と制御を行うためのプロトコルです。このRFCの目的は、LDPの動作とメッセージングの詳細を提供し、MPLSネットワークの効率的なラベル配布を可能にすることです。
Network Working Group L. Andersson, Ed.
Request for Comments: 5036 Acreo AB
Obsoletes: 3036 I. Minei, Ed.
Category: Standards Track Juniper Networks
B. Thomas, Ed.
Cisco Systems, Inc.
October 2007
LDP Specification
LDP仕様
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The architecture for Multiprotocol 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）のアーキテクチャは、RFC 3031で説明されています。MPLSの基本的な概念は、2つのラベルスイッチングルーター（LSR）がそれらの間でトラフィックを転送するために使用されるラベルの意味に同意する必要があることです。この共通の理解は、ラベル分布プロトコルと呼ばれる一連の手順を使用することで達成されます。このドキュメントでは、LSRが通常のルーティングパスに沿ったMPLS転送をサポートするためにLSRがラベルを配布する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 .....................................9
2.2.3. LDP Sessions .......................................10
2.2.4. LDP Transport ......................................10
2.3. LDP Sessions between Non-Directly Connected LSRs ..........10
2.4. LDP Discovery .............................................11
2.4.1. Basic Discovery Mechanism ..........................11
2.4.2. Extended Discovery Mechanism .......................11
2.5. Establishing and Maintaining LDP Sessions .................12
2.5.1. LDP Session Establishment ..........................12
2.5.2. Transport Connection Establishment .................12
2.5.3. Session Initialization .............................14
2.5.4. Initialization State Machine .......................16
2.5.5. Maintaining Hello Adjacencies ......................19
2.5.6. Maintaining LDP Sessions ...........................19
2.6. Label Distribution and Management .........................20
2.6.1. Label Distribution Control Mode ....................20
2.6.1.1. Independent Label Distribution Control ....20
2.6.1.2. Ordered Label Distribution Control ........20
2.6.2. Label Retention Mode ...............................21
2.6.2.1. Conservative Label Retention Mode .........21
2.6.2.2. Liberal Label Retention Mode ..............21
2.6.3. Label Advertisement Mode ...........................22
2.7. LDP Identifiers and Next Hop Addresses ....................22
2.8. Loop Detection ............................................23
2.8.1. Label Request Message ..............................23
2.8.2. Label Mapping Message ..............................25
2.8.3. Discussion .........................................26
2.9. Authenticity and Integrity of LDP Messages ................27
2.9.1. TCP MD5 Signature Option ...........................27
2.9.2. LDP Use of TCP MD5 Signature Option ................29
2.10. Label Distribution for Explicitly Routed LSPs ............29
3. Protocol Specification .........................................30
3.1. LDP PDUs ..................................................30
3.2. LDP Procedures ............................................31
3.3. Type-Length-Value Encoding ................................31
3.4. TLV Encodings for Commonly Used Parameters ................33
3.4.1. FEC TLV ............................................33
3.4.1.1. FEC Procedures ............................35
3.4.2. Label TLVs .........................................35
3.4.2.1. Generic Label TLV .........................36
3.4.2.2. ATM Label TLV .............................36
3.4.2.3. Frame Relay Label TLV .....................37
3.4.3. Address List TLV ...................................38
3.4.4. Hop Count TLV ......................................39
3.4.4.1. Hop Count Procedures ......................39
3.4.5. Path Vector TLV ....................................41
3.4.5.1. Path Vector Procedures ....................41
3.4.5.1.1. Label Request Path Vector ......41
3.4.5.1.2. Label Mapping Path Vector ......42
3.4.6. Status TLV .........................................43
3.5. LDP Messages ..............................................44
3.5.1. Notification Message ...............................46
3.5.1.1. Notification Message Procedures ...........48
3.5.1.2. Events Signaled by Notification Messages ..48
3.5.1.2.1. Malformed PDU or Message .......48
3.5.1.2.2. Unknown or Malformed TLV .......49
3.5.1.2.3. Session KeepAlive Timer
Expiration .....................50
3.5.1.2.4. Unilateral Session Shutdown ....50
3.5.1.2.5. Initialization Message Events ..50
3.5.1.2.6. Events Resulting from
Other Messages .................50
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 ..................53
3.5.3. Initialization Message .............................54
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 ..............................70
3.5.8.1. Label Request Message Procedures ..........71
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 .........................................88
6. Areas for Future Study .........................................89
7. Changes from RFC 3036 ..........................................90
8. Acknowledgments ................................................93
9. References .....................................................93
9.1. Normative References ......................................93
9.2. Informative References ....................................94
Appendix A. LDP Label Distribution Procedures ....................95
A.1. Handling Label Distribution Events .......................97
A.1.1. Receive Label Request .............................98
A.1.2. Receive Label Mapping ...........................101
A.1.3. Receive Label Abort Request .....................107
A.1.4. Receive Label Release ...........................109
A.1.5. Receive Label Withdraw ..........................111
A.1.6. Recognize New FEC ...............................113
A.1.7. Detect Change in FEC Next Hop ...................115
A.1.8. Receive Notification / Label Request Aborted ....118
A.1.9. Receive Notification / No Label Resources .......119
A.1.10. Receive Notification / No Route ................119
A.1.11. Receive Notification / Loop Detected ...........120
A.1.12. Receive Notification / Label Resources Available 121
A.1.13. Detect Local Label Resources Have Become
Available ......................................122
A.1.14. LSR Decides to No Longer Label Switch a FEC ....123
A.1.15. Timeout of Deferred Label Request ..............123
A.2. Common Label Distribution Procedures ....................124
A.2.1. Send_Label ......................................124
A.2.2. Send_Label_Request ..............................125
A.2.3. Send_Label_Withdraw .............................127
A.2.4. Send_Notification ...............................127
A.2.5. Send_Message ....................................128
A.2.6. Check_Received_Attributes .......................128
A.2.7. Prepare_Label_Request_Attributes ................129
A.2.8. Prepare_Label_Mapping_Attributes ................131
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]は、ラベル分布プロトコルを一連の手順として定義します。これにより、1つのラベルを切り替えたルーター（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アーキテクチャは、単一のラベル分布プロトコルを想定していません。実際、多くの異なるラベル分布プロトコルが標準化されています。既存のプロトコルが拡張されているため、ラベル分布をピギーバックすることができます。新しいプロトコルも、ラベルを分散するという明確な目的のために定義されています。MPLSアーキテクチャは、トラフィックエンジニアリング[RFC2702]などの特定のMPLSアプリケーションで使用するためのラベル分布プロトコルを選択する際の考慮事項のいくつかについて説明します。
The Label Distribution Protocol (LDP) is a protocol defined for distributing labels. It was originally published as RFC 3036 in January 2001. It was produced by the MPLS Working Group of the IETF and was jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette, and Bob Thomas.
ラベル分布プロトコル（LDP）は、ラベルの分布用に定義されたプロトコルです。もともと2001年1月にRFC 3036として公開されました。IETFのMPLSワーキンググループによって制作され、Loa Andersson、Paul Doolan、Nancy Feldman、Andre Fredette、およびBob Thomasが共同執筆しました。
LDP is a 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は、転送等価クラス（FEC）[RFC3031]を作成する各LSPと関連付けます。LSPに関連付けられたFECは、そのLSPに「マッピング」されるパケットを指定します。LSPは、与えられたFECの次のホップに割り当てられた発信ラベルにFECのすべてのLSR「スプライス」を着信するラベルを介してネットワークを介して拡張されます。
More information about the applicability of LDP can be found in [RFC3037].
LDPの適用性に関する詳細については、[RFC3037]をご覧ください。
This document assumes (but does not require) 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 that 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 bidirectional.
LDPを使用してラベル/FECマッピング情報を交換する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.
2. LDPピア間のセッションを確立、維持、終了するために使用されるセッションメッセージ。
3. Advertisement messages, used to create, change, and delete label mappings for FECs.
3. FECのラベルマッピングを作成、変更、削除するために使用される広告メッセージ。
4. Notification messages, used to provide advisory information and to signal error information.
4. 通知メッセージ。アドバイザリー情報を提供し、エラー情報を通知するために使用されます。
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がネットワーク内で存在することを示すメカニズムを提供します。これは、「このサブネット」グループマルチキャストアドレスの「すべてのルーター」の「すべてのルーター」のLDPポートにUDPパケットとして送信されます。LSRがHelloメッセージを介して学習した別のLSRとのセッションを確立することを選択すると、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によって行われたローカル決定です。一般に、LSRは、隣接する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の正しい操作には、信頼性の高い注文のメッセージの配信が必要です。これらの要件を満たすために、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）エンコードスキームを使用する共通構造があります。セクション「タイプ長値エンコード」を参照してください。TLVエンコードされたオブジェクトの値、または略してTLV自体には1つ以上のTLVが含まれる場合があります。
LDP errors and other events of interest are signaled to an LDP peer by Notification messages.
LDPエラーやその他の関心のあるイベントは、通知メッセージによって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 on LSR information about the LDP session or the status of some previous message received from the peer.
2. LDPセッションに関するLSR情報またはピアから受信した以前のメッセージのステータスを渡すために使用されるアドバイザリー通知。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 that 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 that 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は、1つ以上のFEC要素のセットとして指定されています。各FEC要素は、対応するLSPにマッピングできるパケットのセットを識別します。LSPが複数のFEC要素で共有される場合、そのLSPは、FEC要素が同じパスを共有できなくなるノードで（またはそれ以前）終了します。
This specification defines a single type of FEC element, the "Address Prefix FEC element". This element is an address prefix of any length from 0 to a full address, inclusive.
この仕様は、単一のタイプのFEC要素である「アドレスプレフィックスFEC要素」を定義します。この要素は、0からフルアドレスまでの任意の長さのアドレスプレフィックスです。
Additional FEC elements may be defined, as needed, by other specifications.
追加のFEC要素は、必要に応じて、他の仕様によって定義される場合があります。
In the remainder of this section, we give the rules to be used for mapping packets to LSPs that have been set up using an Address Prefix FEC element.
このセクションの残りの部分では、アドレスプレフィックスFEC要素を使用してセットアップされたLSPにパケットをマッピングするために使用するルールを提供します。
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 that matches the packet's destination address. With respect to a particular packet and a particular LSP, we refer to any Address Prefix FEC element that matches the packet as the "matching prefix".
特定のアドレスは、そのアドレスがそのプレフィックスで始まる場合にのみ、特定のアドレスのプレフィックスを「一致させる」と言います。また、特定のパケットは、そのLSPにパケットの宛先アドレスに一致するアドレスプレフィックスFEC要素がある場合にのみ、特定のLSPと一致すると言います。特定のパケットと特定の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 a packet matches exactly one LSP, the packet is mapped to that LSP.
- パケットが正確に1つの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 that has an Address Prefix FEC element that is a /32 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.
- パケットが特定の出力ルーターを通過する必要があることがわかっている場合、そのルーターのA /32アドレスであるアドレスプレフィックス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次のホップ属性。）
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 (Virtual Channel Identifiers) as labels, or a Frame Relay interface that uses DLCIs (Data Link Connection Identifiers) as labels.
- インターフェイスラベルスペースごと。インターフェイス固有の着信ラベルは、ラベルにインターフェイスリソースを使用するインターフェイスに使用されます。このようなインターフェイスの例は、VCIS（仮想チャネル識別子）をラベルとして使用するラベル制御ATMインターフェイス、またはラベルとしてDLCIS（データリンク接続識別子）を使用するフレームリレーインターフェイスです。
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>
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がピアに複数のラベルスペースを宣伝し、したがって複数のLDP識別子を使用する必要がある状況は、LSRにピアへの2つのリンクがあり、両方がATMである場合（およびインターフェイスラベルごとに使用）、複数のLDP識別子が発生します。別の状況は、LSRがピアへの2つのリンクを持っていた場所です。1つはイーサネット（およびプラットフォームラベルごとの使用）、もう1つはATMです。
LDP sessions exist between LSRs to support label exchange between them.
LSR間のLDPセッションは、それらの間のラベル交換をサポートするために存在します。
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がLDPを使用して複数のラベルスペースを別のLSRに宣伝する場合、各ラベルスペースに個別のLDPセッションを使用します。
LDP uses TCP as a reliable transport for sessions.
LDPは、セッションの信頼できる輸送としてTCPを使用しています。
When multiple LDP sessions are required between two LSRs, there is one TCP session for each LDP session.
2つのLSRの間に複数のLDPセッションが必要な場合、各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が、通常ルーティングされたパスに沿ってトラフィックを転送するのではなく、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に到着する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.
この状況では、LSRAは2つのラベルを適用してLSPでLSRBに転送します。LSR1から学んだラベルは、LSRAからLSRBへのLSPパスに沿ってトラフィックを転送します。LSRBがLSPに到着するスイッチトラフィックにラベルを付けることができるように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セッションを介して学習したラベルをパケットラベルスタックに追加します（パケットラベルスタックの上部にあるラベルの上にラベルが到着した場合に置き換えるか、パケットが無効になっていない場合はパケットを押します）。次に、LSR1から学んだLSPのラベルをラベルスタックに押し込みます。
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発見は、LSRが潜在的なLDPピアを発見できるようにするメカニズムです。発見により、LSRのラベルスイッチングピアを明示的に構成する必要があります。
There are two variants of the discovery mechanism:
発見メカニズムには2つのバリエーションがあります。
- 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 Basic Discoveryに参加するために、LSRはLDPリンクHellosを定期的にインターフェイスから送信します。LDPリンクHellosは、このサブネットグループマルチキャストアドレスの「すべてのルーター」の有名なLDPディスカバリーポートに宛てられたUDPパケットとして送信されます。
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ピアを備えた「Hello隣接」を識別します。
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は定期的にLDPのターゲットHellosを特定のアドレスに送信します。LDPのターゲットHELLOSは、特定のアドレスの有名なLDPディスカバリーポートに宛てられたUDPパケットとして送信されます。
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.
LSRから送信されたLDPのターゲット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.
- ターゲットを絞ったHelloは、発信インターフェイスの「すべてのルーター」グループマルチキャストアドレスではなく、特定のアドレスに送信されます。
- 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は、ターゲットを絞ったHelloに応答するか無視するかを決定します。応答を選択したターゲットLSRは、定期的にターゲットを絞ったHellosを開始LSRに送信することでそうします。
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のターゲットHelloの受領は、ネットワークレベルで到達可能な潜在的なLDPピアと、ピアが使用しようとするラベルスペースを持つ「Hello隣接」を識別します。
The exchange of LDP Discovery Hellos between two LSRs triggers LDP session establishment. Session establishment is a two step process:
LDP Discovery Hellosの2つのLSRの交換は、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の観点からLSRS LSR1とLSR2の間のLDPセッションの確立について説明しています。ラベルスペースLSR1を指定するHELLOSの交換を想定しています。LSR1およびラベルスペースLSR2：Bの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.
Hellosの交換により、LSR1でHello隣接が作成され、リンク（L）とラベルスペースLSR1：AおよびLSR2：bを結合するのに役立ちます。
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：AおよびLSR2：Bの交換のためのLDPセッションをまだ持っていない場合、LSR2との新しいLDPセッションのTCP接続を開こうとします。
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 Hellos it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;
a. LSR1がLSR2に送信するHellosでTransport Address Optionalオブジェクト（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に送信されるHellosで使用されるソースアドレスです。
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から受け取ったHellosのソースアドレスです。
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 that appears earliest in the message is the most significant byte of the integer and the byte that 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.
- U1をU2と比較します。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が受動的である場合、LSR2がよく知られているLDPポートへのLDP TCP接続を確立するのを待ちます。
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がHelloを送信すると、セッション接続の終了時のトランスポートアドレスを選択し、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は、同じラベルスペースを宣伝するすべてのHellosで同じトランスポートアドレスを宣伝する必要があります。この要件により、同じラベルスペースを使用して複数の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 (Virtual Path Identifier / Virtual Channel Identifier) ranges for label controlled ATM, DLCI (Data Link Connection Identifier) 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.
交渉の成功は、ラベルスペースLSR1：AとLSR2：bの広告について、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の間に複数のリンクがあり、それぞれが宣伝する複数のラベルスペースがある場合、パッシブLSRは、接続のLDP初期化メッセージを受信するまで、新しく確立されたTCP接続を宣伝するラベルスペースを知ることができません。初期化メッセージには、送信者（アクティブLSR）ラベルスペースのLDP識別子と、受信者（パッシブLSR）ラベルスペースの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識別子から決定されたように）。。
1. When LSR1 plays the passive role:
1. LSR1が受動的な役割を果たすとき：
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がhelloの隣接するLDP識別子と一致させようとします。
b. If there is a matching Hello adjacency, the adjacency specifies the local label space for the session.
b. 一致するHelloの隣接がある場合、隣接はセッションのローカルラベルスペースを指定します。
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が一致するHelloの隣接を見つけることができない場合、拒否されたセッション/Hello Error通知メッセージを送信し、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が初期化メッセージに応じてKeepAliveを受信した場合、セッションはLSR1の観点から動作します。
e. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP connection.
e. LSR1がエラー通知メッセージを受信した場合、LSR2は提案されたセッションを拒否し、LSR1はTCP接続を閉じます。
2. When LSR1 plays the active role:
2. LSR1がアクティブな役割を果たすとき：
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がKeepAliveメッセージを受信した場合、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が許容可能な初期化メッセージとKeepaliveメッセージの両方を受け取った場合、セッションはLSR1の観点から動作します。
Until the LDP session is established, no other messages except those listed in the procedures above may be exchanged, and the rules for processing the U-bit in LDP messages are overridden. If a message other than those listed in the procedures above is received, a Shutdown msg MUST be transmitted and the transport connection MUST be closed.
LDPセッションが確立されるまで、上記の手順にリストされているものを除き、他のメッセージが交換される可能性があり、LDPメッセージのUビットを処理するためのルールはオーバーライドされます。上記の手順に記載されているもの以外のメッセージが受信された場合、シャットダウンMSGを送信する必要があり、輸送接続を閉じる必要があります。
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.
エラー通知メッセージで他の初期化メッセージをNAKする際に、セッションパラメーターに同意しない互換性のあるLSRSが無限のメッセージに関与することが可能です。
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'Dになっている状況では、セッションのセットアップ再試行をスロットルする必要があります。また、このような状況を検出する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).
初期化NAKのスロットルシーケンスは、オペレーターの介入がLSRの1つを再構成するまで停止する可能性は低いです。このような構成アクションの後、後続のセッションの確立の試みをスロットルする必要はありません（初期化メッセージがnak'dになるまで）。
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 Message」では、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. Note that a Shutdown message is implemented as a Notification message with a Status TLV indicating a fatal error.
LDPセッションの交渉行動を状態マシンの観点から説明するのは便利です。LDP州のマシンを5つの可能な状態にし、状態遷移表として、および状態遷移図として提示するように定義します。シャットダウンメッセージは、致命的なエラーを示すステータスTLVを備えた通知メッセージとして実装されることに注意してください。
Session Initialization State Transition Table
セッション初期化状態遷移テーブル
STATE EVENT NEW STATE
国家イベント新しい状態
NON EXISTENT Session TCP connection established INITIALIZED established
存在しないセッションTCP接続が確立された初期化された確立
INITIALIZED Transmit Initialization msg OPENSENT (Active Role)
初期化された送信初期化MSGオープンセント（アクティブロール）
Receive acceptable OPENREC Initialization msg (Passive Role) Action: Transmit Initialization msg and KeepAlive msg
許容可能なOpenRec初期化MSG（パッシブロール）アクションを受信：初期化MSGとKeepALIVE MSGを送信
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
他のLDP MSG Non Expect Action：送信エラー通知MSG（NAK）およびClose Transport Connectionを受信する
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
他のLDP MSG Non Expect Action：送信エラー通知MSG（NAK）およびClose Transport Connectionを受信する
OPENSENT Receive acceptable OPENREC Initialization msg Action: Transmit KeepAlive msg
オープンセント受信許容可能なOpenrec初期化MSGアクション：キープライブMSGを送信
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
他のLDP MSG Non Expect Action：送信エラー通知MSG（NAK）およびClose Transport Connectionを受信する
OPERATIONAL Receive Shutdown msg NON EXISTENT Action: Transmit Shutdown msg and close transport connection
運用受信シャットダウンMSG非存在するアクション：シャットダウンMSGと閉鎖輸送接続を送信
Receive other LDP msgs OPERATIONAL
Timeout NON EXISTENT
Action: Transmit Shutdown msg and
close transport connection
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セッションには、1つ以上の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リンク。この状況では、Hellos AN LSRは、そのようなリンクごとに同じLDP識別子を送信します。
LDP includes mechanisms to monitor the necessity of an LDP session and its Hello adjacencies.
LDPには、LDPセッションとそのHelloの隣接の必要性を監視するメカニズムが含まれています。
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 that 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 an LDP session is deleted, the LSR terminates the LDP session by sending a Notification message and closing the transport connection.
LDPは、LDP Discovery Hellosの定期的な領収書を使用して、Helloによって識別されたラベルスペースを使用するピアの意図を示しています。LSRは、隣接に一致するHelloを受け取ったときに再起動するHelloの隣接するたびにホールドタイマーを維持します。ピアからの一致するHelloを受信せずにタイマーが期限切れになった場合、LDPは、ピアがそのリンク（またはターゲットの場合、ターゲットの場合）のラベルスペースを使用してスイッチをラベル付けすることを望まない、またはピアが失敗したと結論付けています。LSRは、Helloの隣接を削除します。LDPセッションの最後のHello隣接が削除されると、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 that 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は、セッショントランスポート接続でLDP PDUの定期的な受領を使用して、セッションの整合性を監視します。LSRは、セッションピアからLDP PDUを受信するたびにリセットする各ピアセッションのキープライブタイマーを維持します。KeepAliveタイマーがピアから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は、ピアが少なくともすべてのキープライブ期間からLDP PDUを受け取って、ピアがセッションのキープライブタイマーを再起動するようにする必要があります。LSRは、この要件を満たすためにプロトコルメッセージを送信する場合があります。LSRがピアと通信する他の情報がない状況では、KeepAliveメッセージを送信します。
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 [RFC3031] 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アーキテクチャ[RFC3031]により、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は、希望するいつでもラベルマッピングを近隣に宣伝する場合があります。たとえば、Down Stream On Demandモードで操作する場合、LSRは、次のホップからのラベルマッピングを待つことなく、すぐにラベルマッピングのリクエストに答えることができます。独立したダウンストリームの未承諾モードで動作する場合、LSRは、FECをラベルスイッチする準備ができている場合はいつでも、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.
LSP順序制御を使用する場合、LSRは、FEC次のホップのラベルマッピング、またはLSRが出口であるFECのみのラベルマッピングの送信を開始できます。LSRが出口ではなくマッピングが存在しない各FECについて、LSRは、FECをマッピングして上流のLSRに対応するラベルを渡す前に、下流のLSRからのラベルを受信するまで待つ必要があります。LSRは、一部のFECの出口であり、他のFECではズロームではない場合があります。
An LSR may act as an egress LSR, with respect to a particular FEC, under any of the following conditions:
LSRは、次の条件のいずれかで、特定のFECに関して、出口LSRとして機能する場合があります。
1. The FEC refers to the LSR itself (including one of its directly attached interfaces).
1. FECは、LSR自体（直接接続されたインターフェイスの1つを含む）を指します。
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] [RFC4271].
3. FEC要素は、OSPFサマリネットワークの別の領域、または外部およびBGPルート[RFC2328] [RFC4271]としてのOSPFの別の自律システムなど、ルーティングドメイン境界を横断することにより到達可能です。
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上の各インターフェイスは、下流の未承諾またはダウンストリームオンデマンド広告モードのいずれかで動作するように構成されています。LSRSは、初期化中に広告モードを交換します。下流の未承諾とダウンストリームオンデマンドモードの主な違いは、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エントリは、プレフィックスのラベルを広告する各ピア用のペアの1つ（LDP識別子、ラベル）のペアのコレクションを関連付けます。
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.
LSRがピアLDP識別子とピアのアドレスの間でマッピングできるようにするために、LSRSは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 that 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:
このメカニズムは、ラベルリクエストとラベルマッピングメッセージによって運ばれるパスベクトルとホップカウント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を含むパスベクトルを使用してメッセージを受信するLSRは、メッセージがループを通過したことを検出します。LDPは、最大許容パスベクトル長の概念をサポートしています。パスベクトルを検出する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には、含まれるメッセージが横断したLSRのカウントが含まれています。LSRがホップカウントTLVを含むメッセージを伝播すると、カウントが増加します。ホップカウントを検出するLSRは、含有メッセージがループを通過したかのように動作する構成された最大値に達しました。慣習により、0のカウントは、ホップ数が不明であることを意味すると解釈されます。不明なホップカウント値を増やすと、不明なホップカウント値が得られます（0）。
The following paragraphs describe 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ループ検出手順について説明します。これらの段落、およびこれらの段落のみの場合、「必須」は、「ループ検出用に構成されている場合」を平均するように再定義されます。段落では、パスベクトルを持ち、ホップカウントTLVを運ぶ必要があるメッセージを指定します。ループ検出が構成されていない状況では、ホップカウントTLVとその手順は、状況でパスベクトルTLVなしで使用されることに注意してください（[RFC3035]および[RFC3034]を参照）。
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.
- 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.
- 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.
rは独自のLSR IDをパスベクトルに追加する必要があり、結果のパスベクトルをラベルリクエストメッセージとともに次のホップに渡す必要があります。ラベル要求にパスベクトルTLVが含まれていない場合、Rは独自のLSR IDを含む長さ1のパスベクトルTLVを含める必要があります。
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 that 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、または最大許容長を超えるパスベクトルTLVを使用して、次のホップからラベル要求メッセージを受信した場合、ラベルリクエストメッセージを検出します。ループで移動しました。
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がループを検出すると、LOOP検出された通知メッセージをラベルリクエストメッセージのソースに送信し、ラベルリクエストメッセージをドロップする必要があります。
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が次のホップからラベルマッピングメッセージを受信すると、侵入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:
- 次のホップから上流のピアに受信したラベルマッピングメッセージを伝播するためにラベルマッピングメッセージが送信されている場合、ホップカウント値は次のように決定する必要があります。
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.
o rがLSRが「TTL分解」（たとえば、ATM LSRドメインまたはフレームリレー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が次のホップからラベルマッピングメッセージを受信していない場合、このホップカウント値は不明になることに注意してください。
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がラベルマッピングメッセージを送信して、次のホップから受信したラベルマッピングメッセージを上流のピアに伝播する場合、次の場合：o rがマージ対応で、Rが以前に上流のピアにラベルマッピングメッセージを送信しなかった場合、パスベクトル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.
o Rが以前に上流のピアにラベルマッピングメッセージを送信した場合、受信したメッセージがLSPホップカウントの増加を報告した場合、パスベクトルTLVを含める必要があります。。
If the above rules require R include a Path Vector TLV in the Label Mapping message, R computes it as follows:
上記のルールにrがラベルマッピングメッセージにパスベクトル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 受信したメッセージにパスベクトルがない場合、上流で送信されるパスベクトルは、RのLSR IDを含む長さ1のパスベクトルでなければなりません。
- 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.
- ラベルマッピングメッセージが送信されていない場合、受信したメッセージを上流に伝播する場合、ラベルマッピングメッセージには、RのLSR IDを含む長さ1のパスベクトルを含める必要があります。
If R receives a Label Mapping message from its next hop with a Hop Count TLV that exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or that exceeds the maximum allowable length, then R detects that the corresponding LSP contains a loop.
Rが次のホップから、構成された最大値を超えるホップカウントTLV、または独自のLSR IDを含むパスベクトルTLVを使用して、または最大許容長を超えるラベルマッピングメッセージを受信した場合、対応する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がループを検出した場合、転送にラベルの使用を停止し、ラベルマッピングメッセージをドロップし、信号ループ検出ステータスをラベルマッピングメッセージのソースに検出する必要があります。
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でオンにする必要があります。Loop検出は適切に動作せず、検出されないループまたは誤って検出されたループになります。
LSRs that 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 that 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 a 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の下流のピアからラベルマッピングメッセージを受信する前に、FECのラベルマッピングメッセージを発信する場合があります。この場合、下流のピアから受信したFECの後続のラベルマッピングメッセージは、LSP属性の更新として扱われ、ラベルマッピングメッセージを上流に伝播する必要があります。したがって、ラベルマッピング更新メッセージの数を最小限に抑えるために、ループ検出を順序付けされたラベル分布と組み合わせて構成することをお勧めします。
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 [RFC4271]. See [RFC1321] for a specification of the MD5 hash function. From a standards maturity point of view, the current document relates to [RFC2385] the same way as [RFC4271] relates to [RFC2385]. This is explained in [RFC4278].
このメカニズムは、BGP [RFC4271]で使用するために[RFC2385]で指定されたTCP MD5署名オプションの使用に基づいています。MD5ハッシュ関数の仕様については、[RFC1321]を参照してください。標準の成熟度の観点から、現在の文書は[RFC2385]に関連して[RFC4271]と同じ方法で[RFC2385]に関連しています。これは[RFC4278]で説明されています。
The following quotes from [RFC2385] outline the security properties achieved by using the TCP MD5 Signature Option and summarize 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拡張を説明しています。TCPセグメントでMD5 [RFC1321]ダイジェストを運ぶための新しい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アルゴリズムは衝突検索攻撃[DOBB]に対して脆弱であることがわかっており、このタイプのアプリケーションに対して不十分に強力であると考えられています。
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.
ただし、このメモは、オプションが既に操作的に展開されており、同じオプション番号を使用してアップグレードを許可するように定義された「アルゴリズムタイプ」フィールドはありませんでした。元のドキュメントは、少なくとも1つのバイトが必要になるため、タイプフィールドを指定しませんでした。完全なオプションのために19バイトを使用して（おそらくTCP実装で20バイトにパディングされる）と感じられました。すでに限られたオプションスペースの無駄があります。
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.
- LSRは、[RFC2385]で指定されたMD5アルゴリズムを適用して、TCPセグメントの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 Hellosを無視します。これにより、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を使用します。これは、宛先ベースのルーティングプロトコルによって決定される通常の（ホップバイホップ）パスに従う必要はありません。CR-LDP [CRLDP]は、LDPを使用してLDPを使用して明示的にルーティングされたLSPを設定するために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ピア間のメッセージの交換を含むシナリオについて説明しています。このセクションでは、メッセージを処理するためのメッセージエンコーディングと手順を指定します。
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は、1つ以上のLDPメッセージを携帯できます。LDP PDUのメッセージは互いに関連する必要はないことに注意してください。たとえば、単一のPDUは、いくつかのFECにFEC-Labelバインディングを広告するメッセージ、他のいくつかのFECのラベルバインディングを要求する別のメッセージ、およびイベントに合図する3番目の通知メッセージを運ぶことができます。
Each LDP PDU is an LDP header followed by one or more LDP messages. The LDP header is:
各LDP PDUはLDPヘッダーに続いて1つ以上の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長2オクテット整数は、バージョンとPDUの長さフィールドを除く、オクテットのこのPDUの全長を指定します。
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識別子6オクテットフィールド。この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:
LDPは、次の領域でメッセージ、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は、タイプ長値（TLV）エンコードスキームを使用して、LDPメッセージに掲載された多くの情報をエンコードします。
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は、14ビットを使用してタイプと2ビットを指定する2オクテットフィールドとしてエンコードされ、LSRがタイプを認識しない場合に動作を指定し、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 MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. The sections following that define TLVs specify a value for the U-bit.
Uビット不明のtlvビット。未知のTLVを受け取ると、Uがクリア（= 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. By setting both the U- and F-bits, a TLV can be propagated as opaque data through nodes that do not recognize the TLV.
Fビットフォワード不明のTLVビット。このビットは、Uビットが設定され、不明なTLVを含むLDPメッセージを転送する場合にのみ適用されます。fがクリア（= 0）の場合、未知のTLVは含むメッセージで転送されません。fが設定されている場合（= 1）、未知のTLVには含まれるメッセージが付いています。TLVを定義するセクションは、Fビットの値を指定します。UビットとFビットの両方を設定することにより、TLVを認識しないノードを介してTLVを不透明データとして伝播できます。
Type Encodes how the Value field is to be interpreted.
タイプは、値フィールドの解釈方法をエンコードします。
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.
型フィールドで指定されていると解釈される情報をエンコードする長さのオクテットの値の標的文字列。
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.
値フィールド自体には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について考えることは可能ですが、この仕様は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は、1つ以上の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要素1からFEC要素n FEC要素にはいくつかのタイプがあります。セクション「FECS」を参照してください。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要素値の表現はタイプ依存性ですが、標準のLDP TLVエンコーディングが使用されないFEC要素自体は使用されていないことに注意してください。
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.
ワイルドカード0x01値なし;つまり、0値オクテット。下記参照。プレフィックス0x02以下を参照してください。
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.
LDPのこのバージョンは、ラベルマッピングメッセージのみにFECあたりの複数のFEC要素の使用をサポートしていることに注意してください。このバージョンでは、他のメッセージで複数のFEC要素を使用することは許可されておらず、将来の研究の主題です。
Wildcard FEC Element
ワイルドカードFEC要素
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.
ラベルでのみ使用するには、リリースメッセージを撤回してラベル付けします。撤退/放出は、次のラベル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 [ASSIGNED_AF] that encodes the address family for the address prefix in the Prefix field.
アドレスファミリー2のアドレスファミリ数からのアドレスファミリ番号からの値を含む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).
PREREN ONE OCTETは、次のアドレスプレフィックスのビットに長さを含む符号なし整数を整理します。ゼロの長さは、すべてのアドレス（デフォルトの宛先）に一致するプレフィックスを示します。この場合、プレフィックス自体はゼロオクテットです）。
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.
プレフィックスアドレスファミリフィールドに従ってエンコードされたアドレスプレフィックスのプレフィックスは、ビットで長さがバイト境界にパッドで埋め込まれています。
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を含むメッセージの処理を中止し、「サポートされていないアドレスファミリ」通知メッセージをLDPに送信する場合ピアシグナリングエラー。
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.
ラベルTLVSエンコードラベル。ラベルTLVは、ラベルマッピングの宣伝、要求、リリース、および引き出しに使用されるメッセージによって運ばれます。
There are several different kinds of Label TLVs that 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 represented as a 20-bit number in a 4 octet field as follows:
ラベルこれは、次のように、4オクテットフィールドの20ビット数として表される20ビットラベル値です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For further information, see [RFC3032].
詳細については、[RFC3032]を参照してください。
An LSR uses ATM Label TLVs to encode labels for use on ATM links.
LSRは、ATMラベルTLVを使用して、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 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ビットの場合、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ビット未満の場合は、フィールドで正当化され、前のビットを0に設定する必要があります。仮想パススイッチングがVビットフィールドに示されている場合、このフィールドはレシーバーによって無視する必要があります。送信者によって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 of DLCI 2 = 23 bits of DLCI
0 = 10ビットのDLCI 2 = 23ビットのDLCI
Len values 1 and 3 are reserved.
LEN値1と3は予約されています。
DLCI The Data Link Connection Identifier For a 10-bit DLCI, the encoding is:
DLCI 10ビットDLCIのデータリンク接続識別子、エンコードは次のとおりです。
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| 0 | 10-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a 23-bit DLCI, the encoding is:
23ビットDLCIの場合、エンコードは次のとおりです。
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| 23-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For further information, see [RFC3034].
詳細については、[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 [ASSIGNED_AF] that encodes the addresses contained in the Addresses field.
アドレスファミリー[アドレス]フィールドに含まれるアドレスをエンコードする[assigned_af]のアドレスファミリ番号からの値を含む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
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 set up.
ホップカウントTLVは、LSPをセットアップするメッセージのオプションフィールドとして表示されます。LSPがセットアップされているため、LSPに沿ってLSRホップの数を計算します。
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およびフレームリレーリンクをトラバースするLSPのセットアップ手順には、ホップカウントTLVの使用が必要であることに注意してください（[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オクテットunsigned Integer Hopカウント値。
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 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:
- メッセージがラベルマッピングメッセージである場合、Rは次のようにホップカウントを決定します。
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.
o rがLSRが「TTL-Decrement」を実行しないLSRドメインのエッジセットのメンバーであり、上流のピアがそのドメイン内にある場合、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（ラベル要求メッセージのイングレス、ラベルマッピングメッセージの出力）は、ホップカウント値を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 an 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に追加されると、LSRSはラベルマッピングメッセージを介して上流のホップカウントアップデートを伝播します。
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が他のLSRよりも出口に近い場合、新しいLSRがLSPに追加されるたびに、上流のホップカウントアップデートを伝播する必要があります。これらの更新は、出口へのホップカウントを反映していないため、オーバーヘッドは役に立たない。
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 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 set up an LSP. Its encoding is:
パスベクトルTLVは、オプションのLDPループ検出メカニズムを実装するために、ラベルリクエストとラベルマッピングメッセージのホップカウントTLVで使用されます。セクション「ループ検出」を参照してください。ラベルリクエストメッセージでの使用は、リクエストが横断したLSRSのパスを記録します。ラベルマッピングメッセージでの使用は、LSRSのパスを記録し、LSPをセットアップするために横断しました。そのエンコードは次のとおりです。
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.
1つ以上のLSR IDは、メッセージが通過したLSRSのパスを示すルーターIDのリストを示しています。各LSR IDは、対応するLSRのLDP識別子の最初の4オクテット（Router-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信号「ループ検出」に送信します。
2. Not propagate the Label Request message further.
2. ラベルリクエストメッセージをさらに伝播しないでください。
Note that a Label Request message with a Path Vector TLV is forwarded until:
パスベクトルTLVを使用したラベル要求メッセージは、以下に転送されることに注意してください。
1. A loop is found,
1. ループが見つかります、
2. The LSP egress is reached, or
2. LSP出力に到達します
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. Status TLVを送信LSRに送信するラベルリリースメッセージを送信して、「検出されたループ」を信号します。
2. Not propagate the message further.
2. メッセージをさらに伝播しないでください。
3. Check whether the Label Mapping message is for an existing LSP. If so, the LSR must unsplice any upstream labels that are spliced to the downstream label for the FEC.
3. ラベルマッピングメッセージが既存のLSP用であるかどうかを確認してください。その場合、LSRは、FECの下流ラベルにスプライスされた上流のラベルを解除する必要があります。
Note that a Label Mapping message with a Path Vector TLV is forwarded until:
パスベクトルTLVを使用したラベルマッピングメッセージは、以下に転送されることに注意してください。
1. A loop is found,
1. ループが見つかります、
2. An LSP ingress is reached, or
2. lsp侵入に到達します
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:
Status Code 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-bit致命的なエラービット。設定（= 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 that 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.
メッセージIDは、ステータスTLVが参照するピアメッセージを識別するゼロ以外の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ビットを1に設定して、受信者が処理する準備ができていない場合はTLVを静かに廃棄する必要があることを示す必要があります。
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.
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には、このメッセージIDを通知メッセージによって伝達されるステータスTLVに含める必要があります。セクション「通知メッセージ」を参照してください。
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 and that there is no padding at the end of a message; that is, parameters can end at odd-byte boundaries.
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" 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"
通知「Hello "Hello" Helloメッセージ「初期化」「初期化メッセージ」「キープライブ」キープライブ「keepAliveメッセージ」アドレス「アドレスメッセージ」撤回 "削除メッセージ" reable "reaver mapping" labelマッピングメッセージ "ラベルリクエスト"ラベルリクエスト "ラベルリクエスト" abort request "ラベル中止要求メッセージ「ラベル引き出し」ラベル撤回メッセージ「ラベルリリース「ラベルリリースメッセージ」
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:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。次のオプションのパラメーターは汎用であり、通知メッセージに表示される場合があります。
Optional Parameter Type Length Value
オプションのパラメータータイプの長さ値
Extended Status 0x0301 4 See below Returned PDU 0x0302 var See below Returned Message 0x0303 var See below
拡張ステータス0x0301 4以下を参照PDU 0x0302 var以下の返されたメッセージ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 octet値は、通知ステータスコードに含まれるステータス情報を補足する追加情報をコードする拡張ステータスコードです。
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 AN LSRは、このパラメーターを使用して、LDP PDUの一部を送信したLSRに戻します。この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セッションを直ちに終了する必要があります。。
The above statement does not apply to the processing of the Shutdown message in the session initialization procedure. When an LSR receives a Shutdown message during session initialization, it SHOULD transmit a Shutdown message and then close the transport connection.
上記のステートメントは、セッションの初期化手順のシャットダウンメッセージの処理には適用されません。セッションの初期化中にLSRがシャットダウンメッセージを受信すると、シャットダウンメッセージを送信してから、輸送接続を閉じる必要があります。
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セッションのTCP接続で受信したLDP PDUは、次の場合に奇形があります。
- 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識別子ではありません。これは、悪いLDP識別子ステータスコードによって示される致命的なエラーです。
- The LDP protocol version is not supported by the receiver, d 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プロトコルバージョンは、レシーバーによってサポートされていません。DまたはITはサポートされていますが、セッションの確立中にセッションのためにネゴシエートされたバージョンではありません。これは、悪いプロトコルバージョンステータスコードによって示される致命的なエラーです。
- 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 Length is too small, that is, smaller than the smallest possible value component. This is a fatal error signaled by the Bad Message Length Status Code.
- メッセージの長さが小さすぎる、つまり、可能な限り最小値コンポーネントよりも小さい。これは、悪いメッセージ長ステータスコードによって示される致命的なエラーです。
- The message is missing one or more Mandatory Parameters. This is a non-fatal error signaled 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は、以下の場合に奇形されます。
- 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.
TLVタイプが> = 0x8000（高次ビット= 1）の場合、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.
これは、KeepAlive Timerの期限切れのステータスコードによって示される致命的なエラーです。
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ハローメッセージは、LDP発見メカニズムの一部として交換されます。セクション「LDP Discovery」を参照してください。
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.
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のペアは、Hellosに使用するHold Timeを互いに交渉します。それぞれが保留時間を提案します。使用される保留時間は、Hellosで提案されている保留時間の最小です。
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の値とは、デフォルトを使用することを意味します。これは、リンクHellosで15秒、ターゲットを絞ったHellosで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、ターゲットを絞ったHello 1の値は、このHelloがターゲットを絞ったHelloであることを指定しています。0の値は、このHelloがリンクHelloであることを指定します。
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、リクエストターゲットのhellosを1つの値を送信します。レシーバーに、このhelloのソースに定期的なターゲットのhellosを送信するようにレシーバーにリクエストします。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.
拡張ディスカバリーを開始するLSRはRを1に設定します。Rが1の場合、受信LSRは、このリクエストでHellosに応答してHello SourceにターゲットHellosを送信するように構成されているかどうかをチェックします。そうでない場合、それはリクエストを無視します。もしそうなら、それはターゲットを絞ったHellosのHello Sourceへの定期的な送信を開始します。
Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定し、受領時に無視する必要があります。
Optional Parameters This variable length field of the Hello message contains 0 or more parameters, each encoded as a TLV. The optional parameters defined by this version of the protocol are
オプションのパラメーターHelloメッセージのこの変数長さフィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれています。このバージョンのプロトコルで定義されるオプションのパラメーターは
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 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トランスポートアドレス0x0401 4以下の構成を参照0x0402 4以下のシーケンス番号IPv6トランスポートアドレス0x0403を参照してください。16以下を参照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 Octet Unsigned構成シーケンス番号を指定します。受信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からHellosを受け取るLSRは、Hellosに対応するHelloの隣接を維持しています。LSRは、Helloの隣接を備えたホールドタイマーを維持します。これは、Helloの隣接に一致するHelloを受け取るたびに再起動します。Helloの隣接官の保留タイマーが期限切れになった場合、LSRはHelloの隣接を破棄します。
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は、Helloが受け入れられるかどうかを確認します。Helloが受け入れられるかどうかを判断するための基準は実装依存です（以下を参照してください。たとえば基準を参照）。
2. If the Hello is not acceptable, the LSR ignores it.
2. こんにちはが受け入れられない場合、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. Helloが受け入れられる場合、LSRはHello SourceのHello隣接があるかどうかをチェックします。もしそうなら、それはHello隣接のホールドタイマーを再起動します。そうでない場合は、Hello SourceのHello隣接を作成し、ホールドタイマーを開始します。
4. If the Hello carries any optional TLVs, the LSR processes them (see below).
4. HelloがオプションのTLVを搭載している場合、LSRはそれらを処理します（以下を参照）。
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".
5. 最後に、LSRに、HelloのPDUヘッダーのLDP識別子によって指定されたラベルスペースのLDPセッションがない場合、セクション「LDPセッション確立」の手順に従います。
The following are examples of acceptability criteria for Link and Targeted Hellos:
以下は、リンクとターゲットを絞ったHellosの受容性基準の例です。
A Link Hello is acceptable if the interface on which it was received has been configured for label switching.
ラベルスイッチング用に、受信したインターフェイスが構成されている場合、リンクHelloは許容されます。
A Targeted Hello from source address A is acceptable if either:
ソースアドレスAからのターゲットを絞ったハローは、次の場合に受け入れられます。
- The LSR has been configured to accept Targeted Hellos, or
- LSRは、ターゲットを絞ったHellosを受け入れるように構成されています。
- The LSR has been configured to send Targeted Hellos to A.
- LSRは、ターゲットを絞ったHellosをAに送信するように構成されています。
The following describes how an LSR processes Hello optional TLVs:
以下は、LSRがHello Optional TLVをどのように処理するかについて説明します。
Transport Address The LSR associates the specified transport address with the Hello adjacency.
輸送住所指定された輸送アドレスをHello隣接するLSR Associates。
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 octet unsigned Integer。仕様のこのバージョンは、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.
Keepalive Time Two Octet Unsigned Non Zero Integerは、送信LSRがKeepalive時間の価値を提案する秒数を示します。受信LSRは、提案されたキープアライブ時間の小さい時間とPDUで受け取ったキープライブ時間を使用して、キープライブタイマーの値を計算する必要があります。KeepAlive時間に選択された値は、セッションTCP接続でのLDPピアからの連続PDUの受領の間に経過する可能性のある最大秒数を示します。PDUが到着するたびに、Keepaliveタイマーはリセットされます。
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.
A、ラベル広告の規律は、ラベル広告のタイプを示します。0の値は、下流の未承諾広告を意味します。1の値は、オンデマンドの下流を意味します。
If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is:
1人のLSRが下流の未承諾を提案し、もう1人がダウン要求の下流を提案する場合、この違いを解決するためのルールは次のとおりです。
- 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 that 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.
Max PDU長2オクテットの署名整合整数整合体セッションのLDP PDUの最大許容長を提案します。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に対して受け入れられない場合、初期化メッセージに応じてセッションを拒否/パラメーターMax 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識別子は、受信機のラベルスペースを識別します。このLDP識別子は、PDUヘッダーの送信者のLDP識別子とともに、受信者が初期化メッセージをHelloの隣接の1つと一致させることができます。セクション「こんにちはメッセージ手順」を参照してください。
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.
一致するHelloの隣接がない場合、LSRは、初期化メッセージに応じて拒否されたセッション/No Hello通知メッセージを送信する必要があり、セッションを確立しません。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。オプションのパラメーターは次のとおりです。
Optional Parameter Type Length Value
オプションのパラメータータイプの長さ値
ATM Session Parameters 0x0501 var See below Frame Relay Session 0x0502 var See below Parameters
ATMセッションパラメーター0x0501 var以下のフレームリレーセッション0x0502 var以下のパラメーターを参照
ATM Session Parameters Used when an LDP session manages label exchange for an ATM link to specify ATM-specific session parameters.
LDPセッションがATMリンクのラベルエクスチェンジを管理して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
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マージ対応スイッチの相互運用性は、将来の研究の対象です。VPマージの使用に関してLSRが異なる場合、セッションは確立されますが、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.
VPマージが使用されている場合、選択したVCIがLSRドメイン内で一意であることを確認することは、イングレスノードの責任であることに注意してください。
N, Number of label range components Specifies the number of ATM Label Range Components included in the TLV.
n、ラベル範囲のコンポーネント数TLVに含まれるATMラベル範囲コンポーネントの数を指定します。
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の値は、双方向VC機能を指定します。つまり、LSRは（特定のVPI内）は、特定のVCIの使用を両方のリンク方向のラベルとして個別にサポートできます。1の値は、一方向のVC機能を指定します。つまり（特定のVPI内）、特定のVCIがリンクのみの1つの方向のラベルマッピングに表示される場合があります。ピアのいずれかまたは両方が一方向の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 that together specify the Label range supported by the transmitting LSR.
1つ以上の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は、範囲の交差点がヌルである隣人とのセッションを確立してはなりません。この場合、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 Channel 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は最小値と最大VPIフィールドを0に設定し、受信LSRは最小および最大VPIフィールドを無視する必要があります。
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
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 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.
D、VC方向0の値は、双方向VC機能を指定します。つまり、LSRは、特定のDLCIの使用を両方のリンク方向のラベルとして独立してサポートできます。1の値は、一方向のVC機能を指定します。つまり、特定のDLCIがリンクのみの1つの方向のラベルマッピングに表示される場合があります。ピアのいずれかまたは両方が一方向のVC機能を指定すると、両方のLSRは次のようにリンクの単方向VCラベル割り当てを使用します。LSRは、LDP識別子を署名のない整数と比較します。LDP識別子が大きいLSRは、範囲内の奇数の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 that together specify the Label range supported by the transmitting LSR.
1つ以上のフレームリレーラベル範囲コンポーネントフレームリレーラベル範囲コンポーネントのリストを合わせて、送信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は、範囲の交差点がヌルである隣人とのセッションを確立してはなりません。この場合、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
len dlciビット
0 10 2 23
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ビットフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCIS）のブロックの下限を指定します。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ビットフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCIS）のブロックの上限を指定します。DLCIはこのフィールドで正当化される必要があり、未使用のビットは0に設定する必要があります。
Note that there is no Generic Session Parameters TLV for sessions that 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セッショントランスポート接続の整合性を監視するメカニズムの一部としてKeepAliveメッセージを送信します。
The encoding for the KeepAlive message is:
KeepAliveメッセージのエンコーディングは次のとおりです。
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.
オプションのパラメーターKeepAliveメッセージに対してオプションのパラメーターは定義されていません。
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.
セッションTCP接続でLDP PDUを受信するたびに、セッション「LDPセッションの維持」で説明されているキープライブタイマーメカニズムは、セッションKeepAliveタイマーをリセットします。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 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は1つ以上のアドレスメッセージでインターフェイスアドレスを宣伝する必要があります。
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 signaling an error and abort processing the message.
LSRがアドレスリストTLVで指定されているアドレスファミリをサポートしていない場合、サポートされていないアドレスファミリ通知をLDPに送信して、エラーをシグナルにし、メッセージの処理を中止する必要があります。
An LSR may re-advertise an address (A) that it has previously advertised without explicitly withdrawing the address. If the receiver already has address binding (LSR, A), it SHOULD take no further action.
LSRは、アドレスを明示的に撤回せずに以前に宣伝したアドレス（a）を再承認する場合があります。受信者がすでにアドレスバインディング（LSR、A）を持っている場合、それ以上のアクションはかかりません。
An LSR may withdraw an address (A) without having previously advertised it. If the receiver has no address binding (LSR, A), it SHOULD take no further action.
LSRは、以前に宣伝することなく（a）住所を撤回する場合があります。受信者にアドレスバインディングがない場合（LSR、A）、それ以上のアクションはかかりません。
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は、LDPピアにラベルマッピングメッセージを送信して、FEC-Labelバインディングをピアに宣伝します。
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 TLVs" for encoding.
FEC TLV宣伝されているFEC-Labelマッピングの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:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。オプションのパラメーターは次のとおりです。
Optional Parameter Length Value
オプションのパラメーターの長さ値
Label Request 4 See below
Message ID TLV
Hop Count TLV 1 See below
Path Vector TLV variable See below
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 Label 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 set up by the Label message. Section "Hop Count Procedures" describes how to handle this TLV.
ホップカウントは、ラベルメッセージによって設定されているLSPに沿ったLSRホップの数の実行数の合計を指定します。セクション「ホップカウント手順」では、このTLVの処理方法について説明します。
Path Vector Specifies the LSRs along the LSP being set up by the Label message. Section "Path Vector Procedures" describes how to handle this TLV.
PATH VECTORラベルメッセージによってセットアップされている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.
マッピングメッセージは、LSRによって使用され、FECのラベルマッピングをLDPピアに配布します。LSRがFECのマッピングを複数のLDPピアに配布する場合、それが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 SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element.
プレフィックスの下流LSRからラベルマッピングメッセージを受信するLSRは、ルーティングテーブルにFEC要素と正確に一致するエントリが含まれていない限り、転送にラベルを使用しないでください。
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ピアに変更され、ループ検出が構成されています。
4. The attributes of a mapping change.
4. マッピングの変更の属性。
5. The receipt of a mapping from the downstream next hop AND
5. 次のホップの下流からのマッピングの受領と
a) no upstream mapping has been created OR b) loop detection is configured OR c) the attributes of the mapping have changed.
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ピアに変更され、ループ検出が構成されています。
4. The attributes of a mapping change.
4. マッピングの変更の属性。
5. The receipt of a mapping from the downstream next hop AND
5. 次のホップの下流からのマッピングの受領と
a) no upstream mapping has been created OR b) Loop Detection is configured OR c) the attributes of the mapping have changed.
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が、すべてが適切に機能しているが、ラベルが配布されていないリヴェロックの状況に陥る可能性があります。たとえば、2つのLSRS RUとRDを考えてみましょう。ここで、RUは上流のLSRであり、RDは特定のFECの下流LSRです。この例では、RUはダウンストリームの未承諾広告モードを使用しており、RDはダウンストリームオンデマンドモードを使用しています。この場合、RDは、RUが1つが必要な場合にラベルマッピングを要求すると想定する場合があり、RUはRDがRUを使用したい場合にラベルを宣伝すると想定する場合があります。RDとRUが提案されているように動作する場合、RDからRUに配布されるラベルはありません。
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がRUの次のホップではないFECのラベルをLSR RUに宣伝する場合、RUはラベルをリリースします。FECの次のホップが後でRDに変更された場合、以前にリリースされたラベルが必要です。
To deal with this situation, either Ru can explicitly request the label when it needs it, or Rd can periodically re-advertise 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に再承認できます。多くの状況では、RuはRdのラベルが必要な時期を知っています。たとえば、FECの次のホップがRDに変化する場合。ただし、RUがそうでない状況がある可能性があります。たとえば、RDは、非標準特性を備えた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 re-advertising the label to Ru.
Ruがラベルが必要であることを知っている状況では、ラベル要求メッセージによってラベルを明示的に要求する責任があります。Ruがラベルを必要としていることを知らない場合がある状況では、RDは定期的にラベルをRUに再版画する責任があります。
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.
このバージョンのLDPの場合、RUがRDのFECに必要なラベルが必要であることを知っている唯一の状況は、RDがFECの次のホップであり、RUにはRDのラベルがなく、FECのLSPは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:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。オプションのパラメーターは次のとおりです。
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 set up by the Label Request message. Section "Hop Count Procedures" describes how to handle this TLV.
ホップカウントは、ラベルリクエストメッセージによって設定されているLSPに沿ったLSRホップの数の実行数の合計を指定します。セクション「ホップカウント手順」では、このTLVの処理方法について説明します。
Path Vector Specifies the LSRs along the LSR being set up by the Label Request message. Section "Path Vector Procedures" describes how to handle this TLV.
PATH VECTORラベル要求メッセージによってセットアップされている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によって使用され、下流のLSRがFECのラベルを割り当てて宣伝することを明示的に要求します。
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が新しいNext Hopの保留中のラベル要求メッセージを既に持っている場合、次のホップ変更に応じて追加のラベル要求を発行しないでください。
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 Next HopはLDPピアであり、LSRは次のホップからのマッピングはまだありません。
Note that since a non-merge LSR must set up 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, the receiving LSR uses its routing table to determine its response. Unless its routing table includes an entry that exactly matches the requested Prefix, the LSR MUST respond with a No Route Notification message.
ラベルが要求されているFECがプレフィックスFEC要素である場合、受信LSRはルーティングテーブルを使用して応答を決定します。ルーティングテーブルには、要求されたプレフィックスと正確に一致するエントリが含まれていない限り、LSRはルートなし通知メッセージで応答する必要があります。
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 that 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がラベルマッピングメッセージで応答する場合、マッピングメッセージには、ラベル要求メッセージのメッセージIDを含むラベルリクエスト/返されたメッセージID TLVオプションパラメーターを含める必要があります。LSRSはラベルリクエストメッセージ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.
ルートは、ラベルに要求された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.
LOOPが検出された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:
ラベルABORTリクエストメッセージのエンコードは次のとおりです。
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.
オプションのパラメーターラベルAbort Reqメッセージに対してオプションのパラメーターは定義されていません。
An LSR Ru may send a Label Abort Request message to abort an outstanding Label Request message for a FEC sent to an LSR Rd in the following circumstances:
LSR RUは、次の状況でLSR RDに送信されたFECの未解決のラベルリクエストメッセージを中止するためにラベル中止要求メッセージを送信する場合があります。
1. Ru's next hop for the FEC has changed from LSR Rd to LSR X; or
1. FECの次のホップがLSR RDからLSR Xに変更されました。また
2. Ru is a non-merge, non-ingress LSR and has received a Label Abort Request for the 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 the FEC from an upstream peer Y and Y is the only (last) upstream LSR requesting a label for the FEC.
3. Ruはマージ、非炎症LSRであり、上流のピアYからFECのラベル中断要求を受け取り、YはFECのラベルを要求する唯一の（最後の）上流のLSRです。
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.
保留中のLSPに関連付けられたリソースを取り戻すために、LSRが未解決のラベル要求メッセージを中止することを選択できる他の状況があるかもしれません。ただし、アボートメカニズムを使用するための一般的な戦略の仕様は、LDPの範囲を超えています。
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が、ラベルマッピングメッセージまたは通知メッセージで問題のラベルリクエストに応答した後にラベル中止要求メッセージを受信した場合、Abortリクエストは無視されます。
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:
ラベル要求メッセージを中止するLSRは、ピアから以下のいずれかを受信するまで、ラベル要求メッセージのメッセージIDを再利用しない場合があります。
- A Label Request Aborted Notification message acknowledging the abort;
- 中止を認めるラベルリクエストが中止された通知メッセージ。
- A Label Mapping message in response to the Label Request message being aborted;
- 中止されるラベル要求メッセージに応じたラベルマッピングメッセージ。
- 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 timeout period should be relatively long (several minutes). If the timeout 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セットアップが中止されるという下流の状態に依存しません。LSPを受信するLSRは、LSPのダウンストリーム状態に関係なく、必要に応じて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は、LSRが以前に宣伝していた特定のFEC-Labelマッピングを使用し続けないことをピアに信号するために、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-Labelマッピングが撤回されているFECを識別します。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。オプションのパラメーターは次のとおりです。
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を指定します。FECに従うラベルTLVがない場合、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は、LDPピアにラベルリリースメッセージを送信して、LSRが以前にピアによって要求および/または宣伝されていた特定のFEC-Labelマッピングがもはや必要ではないことをピアに知らせます。
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-LabelマッピングがリリースされているFECを識別します。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
オプションのパラメーターこの可変長フィールドには、それぞれがTLVとしてエンコードされた0以上のパラメーターが含まれます。オプションのパラメーターは次のとおりです。
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 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 that 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 that is not the next hop for the FEC, and the LSR is configured for conservative operation.
2. LSRは、FECの次のホップではないLSRからラベルマッピングを受信し、LSRは保守的な操作のために構成されています。
3. The LSR receives a Label Withdraw message.
3. 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）の場合、リリースメッセージは決して送信されないことに注意してください。この場合、上流のLSRは各未使用のラベルを保持しているため、下流のピアがFECの次のホップになった場合、すぐに使用できます。
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を指定します。FECに従うラベルTLVがない場合、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 handles 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.
タイプ範囲0x3E00から0x3effは、ベンダープライベート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ビット。未知のTLVを受け取ると、Uがクリア（= 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フィールドに基づいています。
Implementations that support vendor-private TLVs MUST support a user-accessible configuration interface that causes the U-bit to be set on all transmitted vendor-private TLVs; this requirement MAY be satisfied by a user-accessible configuration interface that prevents transmission of all vendor-private TLVs for which the U-bit is clear.
ベンダープライベートTLVをサポートする実装は、すべての送信ベンダープライベートTLVでUビットを設定するユーザーアクセス可能な構成インターフェイスをサポートする必要があります。この要件は、Uビットが明確なすべてのベンダープライベートTLVの送信を防ぐユーザーアクセス可能な構成インターフェイスによって満たされる場合があります。
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 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.
範囲0x3e00から0x3effのタイプタイプ値。一緒に、タイプとベンダー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によって割り当てられたベンダーID 802ベンダーID。
Data The remaining octets after the Vendor ID in the Value field are optional vendor-dependent data.
データ値フィールドのベンダーIDの後の残りのオクテットは、オプションのベンダー依存データです。
The Message Type range 0x3E00 through 0x3EFF is reserved for Vendor-Private messages.
メッセージタイプの範囲0x3E00から0x3effは、ベンダープライベートメッセージ用に予約されています。
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.
ベンダープライベートメッセージが理解されているかどうかの決定は、MSGタイプとベンダーIDパラメーターに基づいています。
Implementations that support Vendor-Private messages MUST support a user-accessible configuration interface that causes the U-bit to be set on all transmitted Vendor-Private messages; this requirement MAY be satisfied by a user-accessible configuration interface that prevents transmission of all Vendor-Private messages for which the U-bit is clear.
ベンダープライベートメッセージをサポートする実装は、すべての送信されたベンダープライベートメッセージでUビットを設定するユーザーアクセス可能な構成インターフェイスをサポートする必要があります。この要件は、Uビットが明確なすべてのベンダープライベートメッセージの送信を防ぐユーザーアクセス可能な構成インターフェイスによって満たされる場合があります。
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.
MSGタイプメッセージタイプ値0x3E00から0x3effの範囲。一緒に、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:
実験のためのLDPサポートは、以下の違いがあるベンダープライベート拡張のサポートに似ています。
- The Type range 0x3F00 through 0x3FFF is reserved for experimental TLVs.
- タイプ範囲0x3F00から0x3FFFは、実験的なTLVに予約されています。
- The Message Type range 0x3F00 through 0x3FFF is reserved for experimental messages.
- メッセージタイプ範囲0x3F00から0x3FFFは、実験メッセージ用に予約されています。
- 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またはメッセージの解釈を指定します。
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"
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
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
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. Note that the setting of the Status Code F-bit is at the discretion of the LSR originating the Status TLV.
「e」列は、ステータスコードeビットの必要な設定です。「ステータスデータ」列は、ステータスコードTLVの30ビットステータスデータフィールドの値です。ステータスコードF-BITの設定は、ステータス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 Abort Request ..."
Missing Message 0 0x00000016 "Events Signaled by ..."
Parameters
Unsupported Address 0 0x00000017 "FEC Procedures" Family "Address Message Proc ..." Session Rejected/ 1 0x00000018 "Session Initialization" Bad KeepAlive Time Internal Error 1 0x00000019 "Events Signaled by ..."
サポートされていないアドレス0 0x00000017 "FECプロシージャ「ファミリ」アドレスメッセージProc ..."セッション拒否/ 1 0x00000018 "セッションの初期化
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 is defined in [RFC3031] as follows:
暗黙のヌルラベルは、次のように[RFC3031]で定義されています。
"The Implicit NULL label is a label with special semantics which an LSR can bind to an address prefix. If LSR Ru, by consulting its ILM (Incoming Label Map) sees that labeled packet P must be forwarded next to Rd, but that Rd has distributed a binding of Implicit NULL to the corresponding address prefix, then instead of replacing the value of the label on top of the label stack, Ru pops the label stack, and then forwards the resulting packet to Rd."
「暗黙のヌルラベルは、LSRがアドレスプレフィックスにバインドできる特別なセマンティクスを備えたラベルです。LSRRUの場合、ILM（着信ラベルマップ）に相談することにより、ラベルのパケットPをRDの隣に転送する必要がありますが、そのRDは暗黙のヌルのバインディングを対応するアドレスプレフィックスに配布し、ラベルスタックの上にラベルの値を置き換える代わりに、RUはラベルスタックをポップし、結果のパケットをRDに転送します。」
The implicit NULL label is represented in LDP as a Generic Label TLV with a Label field value of 3, as defined in [RFC3032].
暗黙のヌルラベルは、[RFC3032]で定義されているように、ラベルフィールド値が3の一般的なラベルTLVとしてLDPで表されます。
LDP defines the following name spaces that require management:
LDPは、管理を必要とする次の名前スペースを定義します。
- 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:
LDPは、メッセージタイプの名前スペースを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.
- メッセージタイプ0x0000-0x3dff。この範囲のメッセージタイプは、LDPベースプロトコルの一部です。[IANA]で概説されているポリシーに従って、この範囲のメッセージタイプは、IETFコンセンサスアクションを通じて割り当てられます。
- 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:
LDPは、TLVタイプの名前スペースを3つの範囲に分割します。以下は、これらの範囲を管理するためのガイドラインです。
- 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タイプ0x0000-0x3dff。この範囲のTLVタイプは、LDPベースプロトコルの一部です。[IANA]で概説されているポリシーに従って、この範囲のTLVタイプは、IETFコンセンサスアクションを通じて割り当てられます。
- 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.
FECタイプの範囲は0〜255です。
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.
[IANA]で概説されているポリシーに続いて、0〜127の範囲のFECタイプはIETFコンセンサスアクションによって割り当てられ、範囲128〜191のタイプは最初に提供されるように割り当てられ、192〜255の範囲のタイプは予約されています私的使用のため。
The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
ステータスコードの範囲は0x00000000-0x3fffffffです。
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コンセンサスアクション、範囲0x20000000-0x3effffffのコードが最初に提供されるように割り当てられ、0x3F0000 -0x3ffffffffの範囲のコードが再登録されています。私的使用のため。
The range for Experiment IDs is 0x00000000 - 0xffffffff.
実験IDの範囲は0x00000000-0xffffffffです。
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.
[IANA]で概説されているポリシーに続いて、範囲0x00000000-0xefffffffの範囲の実験IDは、最初に提供され、範囲0xf000000000-0xffffffffの実験IDが私的使用のために予約されます。
This section identifies threats to which LDP may be vulnerable and discusses means by which those threats might be mitigated.
このセクションでは、LDPが脆弱である可能性がある脅威を特定し、それらの脅威が緩和される可能性のある手段について議論します。
There are two types of LDP communication that could be the target of a spoofing attack.
スプーフィング攻撃のターゲットとなる可能性のあるLDP通信には、2種類のタイプがあります。
1. Discovery exchanges carried by UDP
1. UDPが運ぶディスカバリー交換
LSRs indicate their willingness to establish and maintain LDP sessions by periodically sending Hello messages. Receipt of a Hello serves to create a new "Hello adjacency", if one does not already exist, or to refresh an existing one. Spoofing a Hello packet for an existing adjacency can cause the adjacency to time out and that can result in termination of the associated session. This can occur when the spoofed Hello specifies a small Hold Time, causing the receiver to expect Hellos within this interval, while the true neighbor continues sending Hellos at the lower, previously agreed to, frequency.
LSRは、Helloメッセージを定期的に送信することにより、LDPセッションを確立および維持する意欲を示しています。Helloの受領は、まだ存在していない場合、または既存のものを更新する場合、新しい「隣接」を作成するのに役立ちます。既存の隣接のためにハローパケットをスプーフィングすると、隣接がタイムアウトを引き起こす可能性があり、それにより関連するセッションが終了する可能性があります。これは、スプーフィングされたHelloが小さな保留時間を指定し、受信者がこの間隔内でHellosを期待すると発生する可能性がありますが、真の隣人は以前に同意した頻度にHellosを送信し続けます。
LSRs directly connected at the link level exchange Basic Hello messages over the link. The threat of spoofed Basic Hellos can be reduced by:
LSRSは、リンクレベルで直接接続されています。リンク上の基本的なハローメッセージ。スプーフィングされた基本的なHellosの脅威は、次のように減らすことができます。
o Accepting Basic Hellos only on interfaces to which LSRs that can be trusted are directly connected.
o 信頼できるLSRが直接接続されているインターフェイスでのみ基本的なHellosを受け入れることができます。
o Ignoring Basic Hellos not addressed to the All Routers on this Subnet multicast group.
o このサブネットマルチキャストグループのすべてのルーターに宛てられていない基本的なHellosを無視します。
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セッションを確立する意欲を示す場合があります。LSRは、それらをフィルタリングし、アクセスリストで許可されているソースで発信されたもののみを受け入れることにより、スプーフィングされた拡張されたHellosの脅威を減らすことができます。
2. Session communication carried by TCP
2. TCPが運ぶセッション通信
LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.
LDPは、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認証がこのアプリケーションには弱すぎると考慮されるようになったと主張しています。また、より強いハッシュアルゴリズムを備えた同様のTCPオプション（例としてSHA-1を引用）を展開できることも指摘しています。私たちの知る限り、そのようなTCPオプションは定義および展開されていません。ただし、LDPはTCPメッセージダイジェストテクニックを使用できるものを使用できることに注意してください。MD5よりも強いものが指定および実装されている場合、LDPをアップグレードして使用すると比較的簡単です。
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 that distribute routing information. By providing a mechanism to ensure the authenticity and integrity of its messages, LDP provides a level of security that 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.
ラベル分布プロトコルのセキュリティ要件は、ルーティング情報を配布するプロトコルのセキュリティ要件と本質的に同一です。メッセージの信ity性と整合性を確保するメカニズムを提供することにより、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:
LDPは、サービス拒否（DOS）攻撃のための2つの潜在的なターゲットを提供します。
1. Well-known UDP Port for LDP Discovery
1. LDPディスカバリーの有名なUDPポート
An LSR administrator can address the threat of DoS attacks via Basic Hellos by ensuring that the LSR is directly connected only to peers that can be trusted to not initiate such an attack. 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管理者は、LSRがそのような攻撃を開始しないと信頼できるピアに直接接続されることを保証することにより、基本的なHellosを介してDOS攻撃の脅威に対処できます。インテリアへのインテリアへのインターフェイス管理者のドメインへのインテリアは、インテリアのピアが管理者の管理下にあるため、脅威を表すべきではありません。外部のピアがそうではないため、ドメインの外側のピアへのインターフェイスは潜在的な脅威を表しています。管理者は、基本的なハロー攻撃を開始しないと信頼できる外部ピアに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.
拡張されたHellosを介したDOS攻撃は、より深刻な脅威になる可能性があります。この脅威は、拡張された発見が許可されているアドレスを定義するアクセスリストを使用して、拡張Hellosをフィルタリングすることで対処できます。ただし、フィルタリングを実行するには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クラウドの外側で発生する拡張Hellosを除外し、で発生するもののみを受け入れることにより、拡張Hellosを介してDOS攻撃からインテリアLSRを保護するために使用できます。アクセスリストで許可されているアドレス。このフィルタリングは、クラウドの内部のLSRを保護しますが、エッジでリソースを消費します。
2. Well-known TCP port for LDP Session Establishment
2. LDPセッション設立のための有名なTCPポート
Like other control plane protocols that use TCP, LDP may be the target of DoS attacks, such as SYN attacks. LDP is no more or less vulnerable to such attacks than other control plane protocols that use TCP.
TCPを使用する他のコントロールプレーンプロトコルと同様に、LDPはSyn攻撃などのDOS攻撃のターゲットである可能性があります。LDPは、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 LSRは、LDPセッションの確立のための無差別のTCPリッスンを避ける必要があります。発見された仲間に固有のリッスンのみを使用する必要があります。これにより、既存または進行中の接続と一致する可能性が低いため、処理の早い段階で攻撃パケットをドロップできます。
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.
o MD5オプションの使用は、MD5セグメントチェックサムが有効でない限り、Synが受け入れられないようにするため、多少役立ちます。ただし、受信者は、それ以外の場合は受け入れられる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.
o MPLSクラウドの境界で適用されるアクセスリストメカニズムの使用は、拡張されたHellosについて上記のように示唆された方法と同様の方法で適用されます。
The following topics not addressed in this version of LDP are possible areas for future study:
LDPのこのバージョンでは対処されていない以下のトピックは、将来の研究の可能性のある領域です。
- 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がピアがラベルスタックをポップできるかどうかを判断できるようにします。LDPのこのバージョンは、LSRSがATMおよびフレームリレーを除くすべてのリンクタイプのラベルポップをサポートすることを前提としています。将来のバージョンは、この決定をセッション開始交渉の一部にするための手段を指定する場合があります。
- LDP support for CoS (Class of Service) 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サポートは指定されていません。マルチパスサポートは、将来のバージョンで対処できます。
- LDP support for signaling the maximum transmission unit is not specified in this version. It is discussed in the experimental document [LDP-MTU].
- このバージョンでは、最大透過ユニットを信号するためのLDPサポートは指定されていません。実験文書[LDP-MTU]で説明します。
- The current specification does not address basic peer discovery on Non-Broadcast Multi-Access (NBMA) media. The solution available in the current specification is to use extended peer discovery in such setups. The issue of defining a mechanism semantically similar to Basic Discovery (1 hop limit, bind the hello adjacency to an interface) that uses preconfigured neighbor addresses is left for further study.
- 現在の仕様は、非ブロードキャストマルチアクセス（NBMA）メディアでの基本的なピアディスカバリーに対処していません。現在の仕様で利用可能なソリューションは、このようなセットアップで拡張ピアディスカバリーを使用することです。基本的な発見（1ホップ制限、ハローの隣接をインターフェイスに結合する）と意味的に類似したメカニズムを定義する問題は、事前に構成された隣接アドレスを使用するために残されています。
- The current specification does not support shutting down an adjacency. The motivation for doing it and the mechanisms for achieving it are left for further study.
- 現在の仕様は、隣接のシャットダウンをサポートしていません。それを行う動機とそれを達成するためのメカニズムは、さらなる研究のために残されています。
- The current specification does not include a method for securing Hello messages, to detect spoofing of Hellos. The scenarios where this is necessary, as well as the mechanism for achieving it are left for future study.
- 現在の仕様には、Hellosのスプーフィングを検出するためのHelloメッセージを保護するための方法は含まれていません。これが必要なシナリオと、それを達成するためのメカニズムは、将来の研究のために残されています。
- The current specification does not have the ability to detect a stateless fast control plane restart. The method for achieving this, possibly through an "incarnation/instance" number carried in the Hello message, is left for future study.
- 現在の仕様には、ステートレスの高速制御プレーンの再起動を検出する機能がありません。おそらく、Helloメッセージに掲載された「化身/インスタンス」数を通してこれを達成する方法は、将来の研究のために残されています。
- The current specification does not support an "end of LIB" message, analogous to BGP's "end of RIB" message that an LDP LSR (operating in DU mode) would use following session establishment. The discussion on the need for such a mechanism and its implementation is left for future study.
- 現在の仕様は、LDP LSR（DUモードで動作する）がセッションの確立を使用するというBGPの「エンドオブリブ」メッセージに類似した「LIBの終了」メッセージをサポートしていません。このようなメカニズムとその実装の必要性に関する議論は、将来の研究のために残されています。
- The current specification does not deal with situations where different LSRs advertise the same address. Such situations typically occur as the result of configuration errors, and the goal in this case is to provide the LSRs advertising the same address with enough information to enable operators to take corrective action. The specification of this mechanism is left for a separate document.
- 現在の仕様は、異なるLSRが同じアドレスを宣伝する状況を扱っていません。このような状況は通常、構成エラーの結果として発生します。この場合の目標は、LSRSに同じアドレスを宣伝するLSRに、オペレーターが是正措置を講じるのに十分な情報を提供することです。このメカニズムの仕様は、別のドキュメントに残されています。
Here is a list of changes from RFC 3036
RFC 3036からの変更のリストを次に示します
1. Removed the Host Address FEC and references to it, since it is not used by any implementation.
1. ホストアドレスFECとそれへの参照を削除しました。これは、実装では使用されていないためです。
2. Split the reference list into normative and informative references
2. 参照リストを規範的および有益な参照に分割します
3. Removed "MPLS using ATM VP Switching" from the list of normative references, and references to it.
3. 規範的参照のリストからATM VPスイッチングを使用して「MPLS」を削除し、それを参照しました。
4. Removed reference to RFC 1700 and replaced it with a link to http://www.iana.org/assignments/address-family-numbers.
4. RFC 1700への参照を削除し、http：//www.iana.org/assignments/address-family-numbersへのリンクに置き換えました。
5. Removed reference to RFC 1771 and replaced it with a reference to RFC 4271.
5. RFC 1771への参照を削除し、RFC 4271への参照に置き換えました。
6. Clarified the use of the F-bit.
6. Fビットの使用を明確にしました。
7. Added option to allow split horizon when doing Ordered Control.
7. 順序付けられた制御を行うときにスプリットホライズンを許可するオプションを追加しました。
8. Clarified the processing of messages with the U-bit set during the session initialization procedures
8. セッションの初期化手順中に、Uビットセットでメッセージの処理を明確にしました
9. Clarified the processing of the E-bit during session initialization procedures.
9. セッションの初期化手順中にeビットの処理を明確にしました。
10. Added text explaining that the Shutdown message in the state transition diagram is implemented as a notification message with a Status TLV indicating a fatal error.
10. 状態遷移図のシャットダウンメッセージが致命的なエラーを示すステータスTLVを含む通知メッセージとして実装されていることを説明するテキストが追加されました。
11. Added case for TLV length too short in the specification for handling malformed TLVs.
11. 奇形のTLVを処理するには、仕様に短すぎるTLVの長さのケースを追加しました。
12. Explained the security threat posed by hello spoofing.
12. Hello Spoofingによってもたらされるセキュリティの脅威について説明しました。
13. Added reference to 4271 and 4278 and text for standards maturity variance with regards to the MD5 option.
13. 4271および4278への参照と、MD5オプションに関する標準の成熟度の変動のためのテキストを追加しました。
14. Added text from 3031 explaining the handling of implicit NULL label.
14. 3031からテキストが追加され、暗黙のヌルラベルの取り扱いを説明しました。
15. Included the encoding of DLCIs to remove normative reference to 3034.
15. 3034への規範的参照を削除するためのDLCISのエンコードが含まれています。
16. Moved references to 3031, 3032, and 3034 to informative.
16. 3031、3032、および3034への参照を有益なものに移動しました。
17. In the section describing handling of unknown TLV, removed reference to inexistent section (errata in original document).
17. 未知のTLVの取り扱いを説明するセクションでは、存在するセクション（元のドキュメントのERRATA）への参照を削除しました。
18. Added text clarifying how to achieve interoperability when sending vendor-private TLVs and messages.
18. ベンダープライベートTLVとメッセージを送信する際に相互運用性を実現する方法を明確にするテキストが追加されました。
19. In the "receive label request" procedures, if a loop is detected, changed the procedure to send a notification before aborting the rest of the processing.
19. 「ラベルリクエストの受信」手順では、ループが検出された場合、処理の残りを中止する前に通知を送信する手順を変更しました。
20. In "receive label release" procedures, clarified the behavior for merge-capable LSRs.
20. 「レーベルリリースの受信」手順で、マージ対応LSRの動作を明らかにしました。
21. In "receive label release" procedures, clarified the behavior for receipt of an unknown FEC.
21. 「レーベルリリースの受信」手順で、未知のFECを受信する動作を明確にしました。
22. In note 4 of "Detect Change in FEC Next Hop", modified the text to reference the correct set of conditions for sending a label request procedure (typo in the original document).
22. 「FEC Next Hopの変更を検出」の注4では、テキストを変更して、ラベルリクエスト手順を送信するための正しい一連の条件を参照しました（元のドキュメントのタイプミス）。
23. In the procedures for "LSR decides to no longer label switch a FEC", clarified the fact that the label must not be reused until a label release is received.
23. 「LSRは、FECのラベルスイッチがなくなったことを決定しました」の手順で、ラベルのリリースを受信するまでラベルを再利用してはならないという事実を明らかにしました。
24. In the routine "Prepare_Label_Mapping_Attributes", added a note regarding the treatment of unknown TLVs according to their U and F-bits.
24. ルーチン「prepare_label_mapping_attributes」で、Uおよびfビットに従って未知のTLVの処理に関するメモを追加しました。
25. In the Address message processing procedures, clarified the behavior for the case where an LSR receives re-advertisement of an address previously advertised it, or withdrawal of an address from an LSR that has not previously advertised that address.
25. アドレスメッセージ処理手順で、LSRが以前に宣伝した住所の再承認を受け取った場合の動作、または以前にその住所を宣伝していなかったLSRから住所を撤回する場合の動作を明確にしました。
26. In the routine "Receive Label Mapping", clarified the meaning of PrevAdvLabel when no label advertisement message has been sent previously.
26. ルーチン「レーベルマッピングを受信」では、ラベル広告メッセージが以前に送信されていない場合、prevadvlabelの意味を明確にしました。
27. In the "Receive Label Mapping" procedures, if a loop is detected, modified the procedure to send a notification before aborting the rest of the processing.
27. 「レーベルマッピングの受信」手順では、ループが検出された場合、処理の残りを中止する前に通知を送信する手順を変更しました。
28. In the "Receive Label Mapping" procedures, corrected step LMp.10 to handle label mapping messages for additional (non-merged) LSPs for the FEC.
28. 「レーベルマッピングを受信」手順で、FECの追加（非マージー）LSPのラベルマッピングメッセージを処理するために、ステップLMP.10を修正しました。
29. In the "Receive Label Mapping" procedures, clarified behavior when receiving a duplicate label for the same FEC.
29. 「ラベルマッピングを受信」手順では、同じFECの重複ラベルを受信するときに動作を明確にします。
30. In the routine "Receive Label Abort Request", clarified the behavior for non-merging LSRs.
30. ルーチン「Receive Label Abort Request」で、非マージングLSRの動作を明確にしました。
31. Added the following items to the section discussing areas for future study:
31. 将来の研究のために領域を議論するセクションに次の項目を追加しました。
o extensions for communicating the maximum transmission unit o basic peer discovery on NBMA media o option of shutting down an adjacency o mechanisms for securing Hello messages o detection of a stateless fast control plane restart o support of "end of LIB" message o mechanisms for dealing with the case where different LSRs advertise the same address
o 最大トランスミッションユニットの通信のための拡張o NBMAメディアでの基本的なピアディスカバリーo隣接するメカニズムをシャットダウンするオプションoハローメッセージを保護するためのメカニズム異なるLSRが同じアドレスを宣伝する場合
This document is produced as part of advancing the LDP specification to draft standard status. This document was originally published as RFC 3036 in January 2001. It was produced by the MPLS Working Group of the IETF and was jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette, and Bob Thomas.
このドキュメントは、LDP仕様を標準ステータスをドラフトするために進める一環として作成されます。このドキュメントはもともと2001年1月にRFC 3036として公開されました。IETFのMPLSワーキンググループによって作成され、Loa Andersson、Paul Doolan、Nancy Feldman、Andre Fredette、およびBob Thomasが共同で作成しました。
The ideas and text in RFC 3036 were 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 for their input for RFC 3036.
RFC 3036のアイデアとテキストは、多くのソースから収集されました。リック・ボイヴィー、ロス・カロン、アレックス・コンタ、エリック・グレイ、ヨシヒロ・オバ、エリック・ローゼン、バーナード・スーター、ヤコフ・レクター、およびArun ViswanathanがRFC 3036に入力してくれたことに感謝します。
The editors would like to thank Eric Gray, David Black, and Sam Hartman for their input to and review of the current document.
編集者は、現在の文書への入力とレビューについて、エリック・グレイ、デビッド・ブラック、サム・ハートマンに感謝したいと思います。
In addition, the editors would like to thank the members of the MPLS Working Group for their ideas and the support they have given to this document, and in particular, to Eric Rosen, Luca Martini, Markus Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
さらに、編集者は、MPLSワーキンググループのメンバーのアイデアと、このドキュメント、特にエリックローゼン、ルカマティーニ、マルクスジョーク、マークダフィー、ヴァッハコペラ、キショアへのサポートに感謝したいと思います。Tiruveedhula、Rama Ramakrishnan、Nick Weeds、Adrian Farrel、Andy Malis。
[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月。
[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
[assigned_af] http://www.iana.org/assignments/address-family-numbers
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035] Davie、B.、Lawrence、J.、McCloghrie、K.、Rosen、E.、Swallow、G.、Rekhter、Y.、およびP. Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC 3035、2001年1月。
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001.
[RFC3037] Thomas、B。およびE. Gray、「LDP Applicability」、RFC 3037、2001年1月。
[CRLDP] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[CRLDP] Jamoussi、B.、Ed。、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A。、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[LDP-MTU] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, January 2005.
[LDP-MTU] Black、B。およびK. Kompella、「ラベル分布プロトコルの最大伝送ユニットシグナリング拡張」、RFC 3988、2005年1月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[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.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、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] Conta、A.、Doolan、P。、およびA. Malis、「フレームリレーネットワーク仕様のラベルスイッチングの使用」、RFC 3034、2001年1月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[RFC4278] Bellovin、S。およびA. Zinin、「TCP MD5署名オプション（RFC 2385）およびBGP-4仕様に関する標準成熟度の差異」、RFC 4278、2006年1月。
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.
- ラベルリクエストメッセージを受信します。 - ラベルマッピングメッセージを受信します。 - ラベル中止リクエストメッセージを受信します。 - ラベルのリリースメッセージを受信します。 - ラベルの引き出しメッセージを受信します。 - 新しいFECを認識します。-FEC次のホップの変更を検出します。 - 通知メッセージ /ラベルリクエストを中止します。 - 通知メッセージ /ラベルなしのリソースを受信します。 - 通知メッセージを受信 /ルートなし。 - 検出された通知メッセージ /ループを受信します。 - 利用可能な通知メッセージ /ラベルリソースを受信します。 - ローカルラベルリソースを検出できるようになりました。-LSRは、FECにスイッチをラベル付けしなくなることを決定します。 - 繰延ラベルリクエストのタイムアウト。
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を参照）
3. Algorithm. An algorithm for LSR response to the event.
3. アルゴリズム。イベントに対するLSR応答のアルゴリズム。
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:
- 下流のLSRによって実行されるラベル分布手順は、FECのラベルをLDPピアに配布するタイミングを決定します。アーキテクチャは、4つのラベル分布手順を定義しています。
. Downstream Unsolicited Independent Control, called PushUnconditional in [RFC3031].
。[RFC3031]でPushunConditionalと呼ばれる下流の未承諾独立制御。
. Downstream Unsolicited Ordered Control, called PushConditional in [RFC3031].
。[RFC3031]でプッシュコンディショナルと呼ばれる下流の未承諾の順序制御。
. Downstream On Demand Independent Control, called PulledUnconditional in [RFC3031].
。[RFC3031]でPulleDunConditionalと呼ばれる、ダウンストリームオンデマンド独立制御。
. Downstream On Demand Ordered Control, called PulledConditional in [RFC3031].
。[RFC3031]でuppledConditionalと呼ばれる下流のオンデマンド順序コントロール。
- 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.
- ラベル離脱手順は、下流のLSRによって実行され、以前にLDPピアに配布されていたFECラベルマッピングをいつ撤回するかを判断します。アーキテクチャは、単一のラベル離脱手順を定義します。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によって実行されるラベルリクエスト手順は、下流のLSRがラベルをFECにバインドし、対応するラベルマッピングを送信するタイミングを明示的に要求するタイミングを決定するタイミングを決定します。アーキテクチャは、3つのラベルリクエスト手順を定義します。
. Request Never. The LSR never requests a label.
。決してリクエストしないでください。LSRは決してラベルを要求しません。
. Request When Needed. The LSR requests a label whenever it needs one.
。必要に応じてリクエストします。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の非labelで使用されます。LSRは、必要なときに加えて、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つのラベルリリース手順を定義します。
. Conservative Label retention, called ReleaseOnChange in [RFC3031].
。[RFC3031]のreleaseOnchangeと呼ばれる保守的なラベル保持。
. Liberal Label retention, called NoReleaseOnChange in [RFC3031].
。[RFC3031]のnoreleaseonchangeと呼ばれるリベラルラベル保持。
- 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.
LDPのこのバージョンには、ループ予防メカニズムは含まれていません。したがって、以下の手順は、ループフリー手順の場合に使用を使用しません。
- Label No Route procedure (called the NotAvailable 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:
- ラベルなしのルート手順（[RFC3031]のnotabableプロシージャと呼ばれる）。これは、上流のLSRによって実行され、FECラベルマッピングのリクエストに応じて下流のLSRからのノールート通知に応答する方法を決定する方法を決定する方法を決定します。アーキテクチャの仕様では、2つのラベルなしのルート手順を定義します。
. Request Retry. The LSR should issue the label request at a later time.
。再試行をリクエストします。LSRは、後でラベルリクエストを発行する必要があります。
. No Request Retry. The LSR should assume that 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がラベルマッピングを提供すると想定する必要があり、リクエストを再発行しないでください。
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.
実装では、データ構造を使用して、プロトコルアクティビティに関する情報を保存します。この付録は、アルゴリズムを説明するのに十分な詳細に保存される情報を指定し、必要に応じて情報を取得する能力を想定しています。データ構造の詳細は指定されていません。
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による応答には、次の1つ以上のアクションが含まれる場合があります。
- 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.
- ラットトリビュート。メッセージで受信した属性、例：ホップカウント、パスベクトル。
- SAttributes. Attributes to be included in the Label Request message, if any, propagated to FEC Next Hop.
- attributes。ラベル要求メッセージに含まれる属性（ある場合）は、FEC Next Hopに伝播されます。
- 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.4.
LRQ.1手順CHECK_RECEIVED_ATTRIBUTES（MSGSOURCE、LABLEREQUEST、RATTRIBUTES）を実行します。ループが検出された場合、goto lrq.4。
LRq.2 Is there a Next Hop for FEC? If not, goto LRq.5.
LRQ.2 FECの次のホップはありますか？そうでない場合は、Lrq.5をgotoします。
LRq.3 Is MsgSource the Next Hop? If not, goto LRq.6.
lrq.3 msgsourceは次のホップですか？そうでない場合は、lrq.6をgotoします。
LRq.4 Execute procedure Send_Notification (MsgSource, Loop Detected). Goto LRq.13
LRQ.4は手順を実行しますsend_notification（msgsource、ループが検出）。GOTO LRQ.13
LRq.5 Execute procedure Send_Notification (MsgSource, No Route). Goto LRq.13.
LRQ.5は手順を実行しますsend_notification（msgsource、no route）。GOTO 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をgotoします。（注1を参照してください。）
LRq.7 Is the label request a duplicate request? If so, goto LRq.13. (See Note 2.)
LRQ.7ラベルリクエストは重複リクエストですか？もしそうなら、goto lrq.13。（注2を参照）
LRq.8 Record label request for FEC received from MsgSource and mark it pending.
LRQ.8 MSGSourceから受信したFECのレコードレーベルリクエストと保留中のマーク。
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のラベルマッピングを受け取り、保持していますか？そのため、プロパゲートに伝播するように設定されています。そうでない場合は、伝播しないように設定します。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).
2. 手順prepare_label_mapping_attributes（msgsource、fec、rattributes、attributes、propaging、storedhopcount）を実行します。
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes).
3. procedure send_label（msgsource、fec、stributes）を実行します。
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 Egressはありますか？または、LSRは以前に次のホップからFECのラベルマッピングを受け取って保持しましたか？もしそうなら、Goto lrq.11。そうでない場合は、Lrq.10をgotoします。
For Downstream Unsolicited Ordered Control OR For Downstream On Demand Ordered Control
下流の未承諾の注文制御の場合、またはダウンストリームオンデマンドの注文制御の場合
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 Egressはありますか？または、LSRは以前に次のホップからFECのラベルマッピングを受け取って保持しましたか？（注3を参照）そうでない場合は、lrq.10をご覧ください。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount)
2. 手順を実行するreptare_label_mapping_attributes（msgsource、fec、rattributes、stributes、ispropaging、storedhopcount）
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes). Goto LRq.11.
3. procedure send_label（msgsource、fec、stributes）を実行します。GOTO LRQ.11。
LRq.10 Perform LSR Label Request procedure:
LRQ.10 LSRラベルリクエスト手順を実行：
For Request Never
リクエストのために
1. Goto LRq.13.
1. GOTO LRQ.13。
For Request When Needed OR For Request On Request
必要に応じてリクエストまたはリクエストに応じて
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, RAttributes, SAttributes);
1. prectiour prepare_label_request属性（次のホップ、fec、属性、属性）を実行します。
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto LRq.13.
2. procedure send_label_request（次のホップ、FEC、衛星）を実行します。GOTO 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はFECのラベルをMSGSourceに正常に送信しましたか？そうでない場合は、lrq.13をgotoします。（注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.
1. 転送/切り替えの使用のために、次のホップ（LSRが出口ではない場合）からmsgsourceとラベルに送信されたラベルをインストールします。
LRq.13 DONE.
LRQ.13完了。
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に返される適切な通知があります）。
3. If the LSR is not merge-capable, this test will fail.
3. LSRがマージ対応でない場合、このテストは失敗します。
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はラベルの使用手順を実行してはなりません。
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による応答には、次の1つ以上のアクションが含まれる場合があります。
- 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;
- FECのラベルマッピングメッセージの1つ以上のLDPピアへの送信。
- 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 the FEC, if any, previously advertised to an upstream peer. Assuming no label was previously advertised, this is the same label as the one in the Label Mapping message being processed.
- 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.
- ラットトリビュート。メッセージで受信した属性、例：ホップカウント、パスベクトル。
- SAttributes to be included in the Label Mapping message, if any, propagated to upstream peers.
- 上流のピアに伝播された場合、ラベルマッピングメッセージに含めるための格納。
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の未解決のラベルリクエストと一致していますか？そうでない場合は、goto lmp.3。
LMp.2 Delete record of outstanding FEC label request.
LMP.2未払いのFECラベルリクエストのレコードを削除します。
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）を実行します。ループが検出されない場合、goto 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用の以前に受信されたラベルマッピングがありますか？（注1を参照してください。）そうでない場合は、goto lmp.8。（注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マッチラベル（つまり、メッセージで受け取ったラベル）から以前に受け取ったものですか？（注3を参照）そうでない場合は、goto lmp.8。（注4を参照）
LMp.6 Delete matching label mapping for FEC previously received from MsgSource.
LMP.6 MSGSourceから以前に受信したFECのマッチングラベルマッピングを削除します。
LMp.7 Remove Label from forwarding/switching use. (See Note 5.) LMp.8 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.
LMP.7転送/切り替えからラベルを削除します。（注5を参照）LMP.8は手順を実行しましたsend_message（msgsource、label release、fec、label、loop検出ステータスコード）。GOTO 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の以前に受信されたラベルマッピングがありますか？（注6を参照）そうでない場合は、goto lmp.11。
LMp.10 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) OR Is the received label mapping in response to a previously outstanding label request sent to MsgSource? (See Note 12.) If so, goto LMp.11.
LMP.10 MSGSourceマッチラベル（つまり、メッセージで受け取ったラベル）から以前に受け取ったラベルは？（注3を参照）または、MSGSourceに送信された以前の未払いのラベルリクエストに応じて、受信したラベルマッピングですか？（注12を参照してください。）その場合、goto lmp.11。
LMp.10a Is LSR operating in Downstream Unsolicited mode? If so, delete the label mapping for the label previously received from MsgSource and remove it from forwarding/switching use. Execute procedure Send_Message (MsgSource, Label Release, FEC, label previously received from MsgSource).
LMP.10Aは、LSRが下流の未承諾モードで動作していますか？その場合は、MSGSourceから以前に受信したラベルのラベルマッピングを削除し、転送/切り替えから削除します。procedure send_message（msgsource、label release、fec、以前にmsgsourceから受信したラベル）を実行します。
LMp.11 Determine the Next Hop for FEC.
LMP.11 FECの次のホップを決定します。
LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14.
LMP.12 MSGSourceはFECの次のホップですか？もしそうなら、goto lmp.14。
LMp.13 Perform LSR Label Release procedure:
LMP.13 LSRラベルリリース手順を実行します。
For Conservative Label retention:
保守的なラベル保持の場合：
1. Goto LMp.32.
1. GOTO LMP.32。
For Liberal Label retention:
リベラルなラベル保持のため：
1. Record label mapping for FEC with Label and RAttributes has been received from MsgSource. Goto LMp.33.
1. FECのレコードレーベルマッピングとラベルとラットトリビュートを使用して、MSGSourceから受信しました。GOTO LMP.33。
LMp.14 Is LSR an ingress for FEC? If not, goto LMp.16.
LMP.14 LSRはFECの侵入ですか？そうでない場合は、goto 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.
LMP.16ラベルとラットトリビュートを備えたFEC用のレコードレーベルマッピングは、MSGSourceから受信されました。
LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).
LMP.17ピアごとにLMP.31を反復します。（注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のラベルマッピングを送信しましたか？（注8を参照）その場合は、goto lmp.22。
LMp.19 Is the Downstream Unsolicited Ordered Control Label Distribution procedure being used by LSR? If not, goto LMp.28.
LMP.19下流の未承諾の順序付けられたコントロールラベル分布手順は、LSRによって使用されていますか？そうでない場合は、goto lmp.28。
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMP.20実行手順prepare_label_mapping_attributes（Peer、fec、rattributes、stributes、ispropaging、storedhopcount）。
LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 13.) Goto LMp.28.
LMP.21は手順を実行しますsend_message（ピア、ラベルマッピング、FEC、prevadvlabel、stributes）。（注13を参照してください。）GOTO LMP.28。
LMp.22 Iterate through LMp.27 for each label mapping for FEC previously sent to Peer.
LMP.22は、以前にピアに送信されたFECのラベルマッピングごとにLMP.27を繰り返します。
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は、以前にピアに送られたものと一致する、受信したラベルマッピングのラットトリビュートですか？その場合は、次のラベルマッピングについては、LMP.22からの反復を継続します。（注9を参照してください。）
LMp.24 Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMP.24は手順を実行してください。PREPARE_LABEL_MAPPING_ATTRIBUTES（PEER、FEC、RATTRIBUTES、SATTRIBUTES、ISPROPAGING、SOREDHOPCOUNT）。
LMp.25 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 10.)
LMP.25は手順を実行しますsend_message（ピア、ラベルマッピング、FEC、prevadvlabel、stributes）。（注10を参照）
LMp.26 Update record of label mapping for FEC previously sent to Peer to include the new attributes sent.
LMP.26以前にPEERに送信されたFECのラベルマッピングの更新レコードは、送信された新しい属性を含めます。
LMp.27 End iteration from LMp.22.
LMP.27 LMP.22からの終了反復。
LMp.28 Does LSR have any label requests for FEC from Peer marked as pending? If not, goto LMp.30.
LMP.28 LSRには、保留中としてマークされたピアからのFECのラベル要求がありますか？そうでない場合は、goto 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（Peer、FEC、rattributes、Sattributes、ispropaging、nownownopcount）。
2. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
2. 手順send_label（ピア、FEC、衛星）を実行します。手順が失敗した場合は、LMP.17の次のピアの反復を継続します。
3. If no pending requests exist for Peer, goto LMp.30. (See Note 11.)
3. ピアの保留中のリクエストが存在しない場合は、goto 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.
1. 保留中としてマークされたピアからのFECの保留中のラベル要求ごとにステップ5を繰り返します。
2. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)
2. 手順prepare_label_mapping_attributes（Peer、FEC、rattributes、stributes、ispropaging、nownownowcount）を実行する
3. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
3. 手順send_label（ピア、FEC、衛星）を実行します。手順が失敗した場合は、LMP.17の次のピアの反復を継続します。
4. Delete record of pending request.
4. 保留中のリクエストのレコードを削除します。
5. End iteration from Step 1.
5. ステップ1からの反復を終了します。
6. Goto LMp.30.
6. GOTO LMP.30。
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.
1. 以前にPEERに送信されたFECのラベルマッピングごとにステップ3を繰り返します。
2. Install label received and label sent to Peer for forwarding/switching use.
2. 転送/切り替えの使用のために、受信したラベルとラベルがピアに送信されたラベルをインストールします。
3. End iteration from Step 1.
3. ステップ1からの反復を終了します。
4. Goto LMp.31.
4. GOTO LMP.31。
LMp.31 End iteration from LMp.17. Go to LMp.33.
LMP.31 LMP.17からの終了反復。LMP.33に移動します。
LMp.32 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label).
LMP.32は手順を実行しますsend_message（msgsource、label release、fec、label）。
LMp.33 DONE.
LMP.33完了。
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が統合されている場合、問題のLSPのFECの最大1つの受信マッピングが必要です。非マスターの場合、問題のLSPのFECの複数の受信マッピングがある可能性があります。
2. If the 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. 同じピアとは異なるラベルを使用した未承諾マッピングは、このバージョンのLDPではサポートされていないマルチパスラベルスイッチングを確立する試みになります。
5. If the 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) the 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.
6. 受信したラベルマッピングメッセージがLMP.1の未解決のラベルリクエストと一致した場合、（定義上）LSRは、問題のLSPのFECのラベルマッピングを以前に受け取っていません。LSRが問題のLSPの上流ラベルを統合している場合、最大で1つの受信マッピングが必要です。非マスターの場合、同じFECに複数の受信ラベルマッピングがあり、それぞれの結果として生じるLSPに1つが存在する可能性があります。
7. The LMp.17 iteration includes MsgSource in order to handle the case where the LSR is operating in Downstream Unsolicited Ordered Control mode. Ordered Control prevents the LSR from advertising a label for the FEC until it has received a label mapping from its next hop (MsgSource) for the FEC.
7. LMP.17の反復には、LSRが下流の未承諾順序制御モードで動作している場合を処理するためのMSGSourceが含まれます。順序付けられたコントロールにより、LSRはFECの次のホップ（MSGSource）からラベルマッピングを受信するまで、FECのラベルを宣伝することを防ぎます。
8. If the LSR is merging the LSP, it may have previously sent label mappings for the FEC LSP to one or more peers. If the LSR is not merging, it may have sent a label mapping for the LSP in question to at most one LSR.
8. LSRがLSPを統合している場合、以前にFEC LSPのラベルマッピングを1つ以上のピアに送信した可能性があります。LSRがマージしていない場合、問題のLSPのラベルマッピングを最大1つのLSRに送信した可能性があります。
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. このチェックでは、ループ検出パスベクトル属性が考慮されます。受信したラットにはパスベクトルが含まれており、パスベクトルが以前にピアに送信されていなかった場合、または受信したパスベクトルが以前にピアに送信されたパスベクトルと矛盾している場合、属性は矛盾していると見なされます。マッピングメッセージにパスベクトルを伝播した後、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.
10. LMP.22からLMP.27は、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は、受信するラベル要求メッセージを処理する必要があります。保留中のラベルリクエストがある場合は、保留中のリクエストを満たすために、ダウンストリームオンデマンド手順に陥ります。
12. As determined by step LMp.1.
12. ステップLMP.1によって決定されています。
13. An LSR operating in Ordered Control mode may choose to skip at this stage the peer from which it received the advertisement that caused it to generate the label-map message. Doing so will in effect provide a form of split-horizon.
13. 順序付けられた制御モードで動作するLSRは、この段階でラベルマップメッセージを生成する広告を受け取ったピアをスキップすることを選択できます。そうすることで、実際にはスプリットホリゾンの一形態が提供されます。
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がピアからラベル中止要求メッセージを受信すると、問題のラベルリクエストにすでに応答しているかどうかを確認します。もしそうなら、それは静かにメッセージを無視します。そうでない場合は、ピアAラベルリクエストが中止された通知を送信します。さらに、下流のピアに問題の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からの以前に受信したラベル要求メッセージと一致していますか？（注1を参照してください。）そうでない場合は、goto labr.12。
LAbR.2 Has LSR responded to the previously received label request? If so, goto LAbR.12.
Labr.2 LSRは以前に受け取ったラベル要求に応答しましたか？もしそうなら、goto 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は手順を実行しますsend_message（msgsource、notification、notification、label request aborted、tlv）。ここで、TLVはラベルリクエストメッセージID TLVがラベルABORTリクエストメッセージで受信しました。
LAbR.4 Does LSR have a Label Request message outstanding for FEC? If so, goto LAbR.7.
Labr.4 LSRには、FECの顕著なラベルリクエストメッセージがありますか？もしそうなら、goto labr.7。
LAbR.5 Does LSR have a label mapping for FEC? If not, goto LAbR.11.
Labr.5 LSRにはFECのラベルマッピングがありますか？そうでない場合は、goto labr.11。
LAbR.6 Generate Event: Received Label Release message for FEC from MsgSource. (See Note 2.) Goto LAbR.11.
Labr.6イベントの生成：MSGSourceからFECのラベルリリースメッセージを受信しました。（注2を参照）GOTO Labr.11。
LAbR.7 Is LSR merging the LSP for FEC? If not, goto LAbR.9.
Labr.7 LSRはFECのLSPをマージしていますか？そうでない場合は、goto labr.9。
LAbR.8 Are there outstanding label requests for this FEC? If so, goto LAbR.11.
labr.8このFECには未解決のラベルリクエストはありますか？もしそうなら、goto 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.
labr.9は手順を実行しますsend_message（次のホップ、ラベルAbort request、fec、tlv）。これは、TLVが、未解決のラベルリクエストメッセージでLSRで使用されるメッセージIDを含むラベルリクエストメッセージID TLVです。
LAbR.10 Record that a label abort request for FEC is pending.
Labr.10レーベルがFECのリクエストを中止することが保留中であることを記録します。
LAbR.11 Delete record of label request for FEC from MsgSource.
Labr.11 MSGSourceからFECのラベル要求のレコードを削除します。
LAbR.12 DONE.
labr.12完了。
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を使用して、ラベルABORTリクエストによって運ばれ、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がNexthopからラベルマッピングを受け取った場合、MSGSourceへのラベルマッピングを宣伝し、MSGSourceがリリースしたかのように振る舞うはずです。
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 Next Hopからラベルマッピングを保持している場合、ラベルマッピングをリリースします。
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 Does FEC match a known FEC? If not, goto LRl.14.
LRL.1 FECは既知のFECと一致しますか？そうでない場合は、goto lrl.14。
LRl.2 Remove MsgSource from record of peers that hold Label for FEC. (See Note 1.)
LRL.2 FECのラベルを保持しているピアの記録からMSGSourceを削除します。（注1を参照してください。）
LRl.3 Does message match an outstanding label withdraw for FEC previously sent to MsgSource? If not, goto LRl.5
LRL.3メッセージは、以前にMSGSourceに送信されたFECの未解決のラベル撤回と一致しますか？そうでない場合は、goto lrl.5
LRl.4 Delete record of outstanding label withdraw for FEC previously sent to MsgSource.
lrl.4以前にmsgsourceに送信されたFECの未解決のラベル引き出しのレコードを削除します。
LRl.5 Is LSR merging labels for this FEC? If not, goto LRl.7. (See Note 2.)
LRL.5このFECのLSRはラベルをマージしていますか？そうでない場合は、goto lrl.7。（注2を参照）
LRl.6 Does LSR have outstanding label advertisements for this FEC? If so, goto LRl.11.
LRL.6 LSRには、このFECの優れたラベル広告がありますか？もしそうなら、goto lrl.11。
LRl.7 Is LSR egress for the FEC? If so, goto LRl.11.
LRL.7はFECのLSR出口ですか？もしそうなら、goto lrl.11。
LRl.8 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.11.
LRL.8 FECの次のホップはありますか？また、LSRには、次のホップからFEC用の以前に受信したラベルマッピングがありますか？そうでない場合は、goto lrl.11。
LRl.9 Is LSR configured to propagate releases? If not, goto LRl.11. (See Note 3.)
LRL.9 LSRはリリースを伝播するように構成されていますか？そうでない場合は、goto lrl.11。（注3を参照）
LRl.10 Execute procedure Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).
lrl.10プロシージャsend_message（次のホップ、ラベルリリース、FEC、次のホップからのラベル）を実行します。
LRl.11 Remove Label from forwarding/switching use for traffic from MsgSource.
LRL.11 MSGSourceからのトラフィックの転送/切り替えの使用からラベルを削除します。
LRl.12 Do any peers still hold Label for FEC? If so, goto LRl.14.
LRL.12ピアはまだFECのラベルを保持していますか？もしそうなら、goto lrl.14。
LRl.13 Free the Label.
LRL.13レーベルを無料。
LRl.14 DONE.
LRL.14完了。
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が要求するまでFECのラベルマッピングをMSGSourceに再承認しないでください。
2. LRl.5 through LRl.9 deal with determining whether where the LSR should propagate the Label Release to a downstream peer (LRl.9).
2. LRL.5からLRL.9は、LSRがラベルリリースを下流のピアに伝播する場所を決定することに対処します（LRL.9）。
3. If LRl.9 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.
3. LRL.9に到達した場合、上流のLSRはFECのラベルを保持しておらず、LSRはFEC Next Hopの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, and whether LSP setup is ingress-controlled or egress-controlled in the operating environment.
リリースを伝播するかどうかは、プロトコルの問題ではありません。ラベル分布は、リリースが伝播されるかどうかにかかわらず適切に動作します。伝播するかどうかの決定は、ラベルが動作環境での希少なリソースであるかどうか、必要なシグナリングの量を小さく保つことでLSPセットアップの遅延を低く保つことの重要性、LSPセットアップがイングレス制御であるかどうかなどの要因を考慮する必要があります。または、操作環境で退出した。
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、label release、fec、label）。
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をgotoします。
LWd.4 Delete matching label mapping for FEC previously received from MsgSource.
LWD.4 MSGSourceから以前に受信したFECのマッチングラベルマッピングを削除します。
LWd.5 Is LSR using Ordered Control? If so, goto LWd.8.
LWD.5 LSRは順序付けられたコントロールを使用していますか？もしそうなら、goto lwd.8。
LWd.6 Is MsgSource using Downstream On Demand label advertisement? If not, goto LWd.13.
LWD.6 MSGSourceはダウンストリームオンデマンドラベル広告を使用していますか？そうでない場合は、lwd.13をgotoします。
LWd.7 Generate Event: Recognize New FEC for FEC. Goto LWd.13. (See Note 2.)
LWD.7生成イベント：FECの新しいFECを認識します。GOTO LWD.13。（注2を参照）
LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource.
LWD.8は、MSGSource以外のピアごとにLWD.12を繰り返します。
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.12 LWD.8からの終了反復。
LWd.13 DONE.
LWD.13完了。
Notes:
ノート：
1. If the 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が独立したコントロールを備えた下流のオンデマンドラベル分布を使用している場合を処理します。この状況では、LSRはFECの次のホップにラベルリクエストを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つ以上の着信ラベルが同じ発信ラベルにマッピング）と、ラベルマージなし（発信ラベルへの1つのラベルマップ）ケースの両方を処理します。
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による応答には、次のアクションの1つ以上が含まれる場合があります。
- Transmission of label mappings for the FEC to one or more LDP peers;
- FECのラベルマッピングの1つ以上のLDPピアへの送信。
- Transmission of a label request for the FEC to the FEC next hop;
- FECのFEC Next Hopへのラベル要求の送信。
- Any of the actions that can occur when the LSR receives a label mapping for the FEC from the FEC next hop.
- LSRがFEC Next Hopから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.
- attributes。ラベルマッピングまたはラベルリクエストメッセージに含まれる属性（ある場合）がピアに送信されます。
- 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
下流の未承諾独立制御用
1. Iterate through 5 for each Peer.
1. ピアごとに5を繰り返します。
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のラベルマッピングを受け取り、保持していますか？もしそうなら、プロパゲートに伝播するように設定します。そうでない場合は、伝播しないように設定します。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).
3. prectire frepare_label_mapping_attributes（peer、fec、initattributes、attributes、cropaging、nownowing count（0））を実行します。
4. Execute procedure Send_Label (Peer, FEC, SAttributes).
4. 手順send_label（ピア、FEC、衛星）を実行します。
5. End iteration from 1. Goto FEC.2.
5. 1. goto fec.2からの反復を終了します。
For Downstream Unsolicited Ordered Control
下流の未承諾の順序制御用
1. Iterate through 5 for each Peer.
1. ピアごとに5を繰り返します。
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出口はありますか？または、LSRは以前に次のホップからFECのラベルマッピングを受け取って保持しましたか？そうでない場合は、次のピアの反復を続けます。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
3. 手順を実行することを実行しますdectare_label_mapping_attributes（peer、fec、initattributes、attributes、cropaging、storedhopcount）。
4. Execute procedure Send_Label (Peer, FEC, SAttributes).
4. 手順send_label（ピア、FEC、衛星）を実行します。
5. End iteration from 1. Goto FEC.2.
5. 1. goto fec.2からの反復を終了します。
For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control
ダウンストリームオンデマンドの独立制御またはダウンストリームオンデマンドの注文済みコントロール
1. Goto FEC.2. (See Note 2.)
1. GOTO FEC.2。（注2を参照）
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のラベルマッピングを受け取って保持していますか？もしそうなら、goto fec.5
FEC.3 Is Next Hop an LDP peer? If not, Goto FEC.6
FEC.3次のホップはLDPピアですか？そうでない場合は、goto fec.6
FEC.4 Perform LSR Label Request procedure:
FEC.4 LSRラベルリクエスト手順を実行します。
For Request Never
リクエストのために
1. Goto FEC.6
1. Goto fec.6
For Request When Needed OR For Request On Request
必要に応じてリクエストまたはリクエストに応じて
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, InitAttributes, SAttributes);
1. prectiour prepare_label_request_attributes（次のホップ、fec、initattributes、attributes）を実行します。
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto FEC.6.
2. procedure send_label_request（次のホップ、FEC、衛星）を実行します。Goto fec.6。
FEC.5 Generate Event: Received Label Mapping from Next Hop. (See Note 3.)
FEC.5イベントの生成：次のホップからラベルマッピングを受信しました。（注3を参照）
FEC.6 DONE.
fec.6完了。
Notes:
ノート：
1. An example of an attribute that might be part of InitAttributes is one that 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.)
1. initattributesの一部である可能性のある属性の例は、サービスのクラス（COS）などの望ましいLSP特性を指定するものです。（LDPの現在のバージョンはCOS属性を指定していないが、LDP拡張機能は5月であることに注意してください。）
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は、リクエストLSRにルートなし通知を送信し、ラベルリクエストを破棄することにより、未知のFECのラベル要求に応答するため、そのような保留中の要求はありません。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のラベルを持っている場合、次のホップからラベルを受け取ったばかりのように振る舞うはずです。これは、リベラルなラベル保持モードの場合に発生します。
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による応答には、次のアクションの1つ以上が含まれる場合があります。
- Removal of the label from the FEC's old next hop from forwarding/switching use;
- FECのOld Next Hopから転送/切り替えの使用からのラベルを削除します。
- Transmission of label mapping messages for the FEC to one or more LDP peers;
- FECのラベルマッピングメッセージの1つ以上のLDPピアへの送信。
- Transmission of a label request to the FEC's new next hop;
- FECの新しいNext Hopへのラベルリクエストの送信。
- Any of the actions that can occur when the LSR receives a label mapping from the FEC's new next hop.
- LSRがFECの新しいNext Hopからラベルマッピングを受信したときに発生する可能性のあるアクションのいずれか。
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.
- オールドラベル。以前にOld Next Hopから受け取ったラベルがある場合。
- CurAttributes. The attributes, if any, currently associated with the FEC.
- Curattributes。現在FECに関連付けられている属性。
- SAttributes. Attributes to be included in the Label Request message, if any, sent to New Next Hop.
- attributes。Label Requestメッセージに含まれる属性は、ある場合、新しいNext Hopに送信されます。
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が以前に受信し、Old Next HopからFECのラベルマッピングを保持していますか？そうでない場合は、NH.6をGOTO。
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をgoto。
NH.4 Execute procedure Send_Message (Old Next Hop, Label Release, OldLabel).
NH.4は手順を実行しますsend_message（古い次のホップ、ラベルリリース、オールドラベル）。
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（古い次のホップ、ラベルAbort request、fec、tlv）を実行します。ここで、TLVは保留中のラベルリクエストのメッセージIDを運ぶラベルリクエストメッセージID TLVです。
NH.9 Record that a label abort request is pending for FEC with Old Next Hop.
NH.9は、ラベルがリクエストを中止していることを、古い次のホップでFECに対して保留中であることを記録しています。
NH.10 Is there a New Next Hop for FEC? If not, goto NH.16.
NH.10 FECの新しい次のホップはありますか？そうでない場合は、NH.16をGOTO。
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が以前にNew Next HopからFECのラベルマッピングを受け取って保持していますか？そうでない場合は、NH.13をGOTO。
NH.12 Generate Event: Received Label Mapping from New Next Hop. Goto NH.20. (See Note 2.)
NH.12生成イベント：新しい次のホップからラベルマッピングを受信しました。GOTO 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はダウンストリームオンデマンド広告を使用していますか？または、次のホップはダウンストリームオンデマンド広告を使用していますか？または、LSRは保守的なラベル保持を使用していますか？（注3を参照）その場合、Goto Nh.14。そうでない場合は、NH.20をGOTO。
NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, CurAttributes, SAttributes).
nh.14は手順を実行しますprepare_label_request_attributes（Next Hop、FEC、Curattributes、Sattributes）。
NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC, SAttributes). (See Note 4.) Goto NH.20.
NH.15は手順を実行しますsend_label_request（新しい次のホップ、FEC、衛星）。（注4を参照）goto nh.20。
NH.16 Iterate through NH.19 for each Peer.
NH.16ピアごとにNH.19を繰り返します。
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.19 NH.16からの終了反復。
NH.20 DONE.
nh.20完了。
Notes:
ノート：
1. If the 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.
2. LSRが新しいNext HopのFECのラベルを持っている場合、新しいNext Hopからラベルを受け取ったばかりのように振る舞うはずです。
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 that the FEC next hop had changed.
3. ラベル保持モードのチェックの目的は、保守的なラベル保持モードで動作するLSRが受信したラベルマッピングをリリースした可能性のあるラベルマッピングメッセージを処理する手順の手順LMP.12-LMP.13のレースを回避することです。FEC Next Hopが変更されたことを検出する前の新しい次のホップ。
4. Regardless of the Label Request procedure in use by the LSR, it MUST send a label request if the conditions in NH.13 hold. Therefore, it executes the Send_Label_Request procedure directly rather than perform the LSR Label Request procedure.
4. LSRが使用しているラベル要求手順に関係なく、NH.13の条件が保留されている場合は、ラベルリクエストを送信する必要があります。したがって、LSRラベル要求手順を実行するのではなく、send_label_request手順を直接実行します。
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.2 Record that the label request for FEC has been aborted.
LRQA.2は、FECのラベル要求が中止されたことを記録しています。
LRqA.3 DONE.
lrqa.3完了。
Note:
ノート：
1. The LSR uses the FEC and RequestMessageID to locate its record, if any, of the outstanding label request abort.
1. LSRは、FECとRequestMessageIDを使用して、未解決のラベルリクエストが中止された場合、そのレコードを見つけます。
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 that label mapping for FEC from MsgSource is needed but that no label resources are available.
Nores.2 MSGSourceのFECのラベルマッピングを記録することが必要ですが、ラベルリソースは利用できないことを記録します。
NoRes.3 Set status record indicating it is not OK to send label requests to MsgSource.
nores.3ステータスレコードのセットマスグルセにラベルリクエストを送信することは問題ないことを示す。
NoRes.4 DONE.
Nores.4完了。
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ルート手順はその応答を決定します。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ラベルのルート手順なしを実行します。
For Request No Retry
リクエストの場合は再試行しません
1. Goto NoNH.3.
1. Goto nonh.3。
For Request Retry
リクエストの再試行用
1. Record deferred label request for FEC and Attributes to be sent to MsgSource.
1. MSGSourceに送信されるFECおよび属性の繰延ラベルリクエストを記録します。
2. Start timeout. Goto NoNH.3.
2. タイムアウトを開始します。Goto nonh.3。
NoNH.3 DONE.
非h.3完了。
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ピアからループ検出されたステータスコードを受信すると、ルートなし通知を受け取ったかのように動作します。
Context:
コンテクスト：
See "Receive Notification / No Route".
「通知を受け取る /ルートなし」を参照してください。
Algorithm:
アルゴリズム：
See "Receive Notification / No Route".
「通知を受け取る /ルートなし」を参照してください。
Note:
ノート：
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. Loopが検出された通知がラベル要求メッセージに応じている場合、通知メッセージのステータスコードTLVに到着します。ラベルマッピングメッセージに応じている場合、ラベルリリースメッセージのステータスコードTLVに到着します。
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 the postponed Label Request message.
- attributes。延期されたラベルリクエストメッセージで保存された属性。
Algorithm:
アルゴリズム：
Res.1 Set status record indicating it is OK to send label requests to MsgSource.
res.1ステータスレコードを設定して、msgsourceにラベルリクエストを送信しても構いません。
Res.2 Iterate through Res.6 for each record of a FEC label mapping needed from MsgSource for which no label resources are available.
Res.2は、ラベルリソースが利用できないMSGSourceから必要なFECラベルマッピングの各レコードについてRes.6を介して反復します。
Res.3 Is MsgSource the next hop for FEC? If not, goto Res.5.
Res.3 MSGSourceはFECの次のホップですか？そうでない場合は、goto 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、stributes）。手順が失敗した場合、反復を終了します。
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.6 Res.2からの最終反復。
Res.7 DONE.
Res.7が完了しました。
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 the 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.1は、LSRが以前にラベルリソース通知を送信した各ピアに対してResa.4を繰り返します。
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.4 Resa.1からの終了反復。
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.)
Resa.5 Resa.8を介して繰り返します。PECに必要なラベルマッピングの各レコードについて、ピア用の非ラベルリソース。（注1を参照してください。）
ResA.6 Execute procedure Send_Label (Peer, FEC, Attributes). If the procedure fails, terminate iteration.
Resa.6は手順を実行しますsend_label（PEER、FEC、属性）。手順が失敗した場合、反復を終了します。
ResA.7 Clear record of FEC label mapping needed for peer but no-label-resources.
Resa.7ピアに必要なが非ラベルリソースに必要なFECラベルマッピングの明確な記録。
ResA.8 End iteration from ResA.5
Resa.8 Resa.5からの終了反復
ResA.9 DONE.
Resa.9完了。
Note:
ノート：
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.
1. 反復RESA.5からRESA.8を介して、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にスイッチをラベル付けしなくなることを一方的に決定する場合があります。そうするLSRは、FECのラベル引き出しメッセージをピアに送信する必要があります。
Context:
コンテクスト：
- Peer. The peer.
- ピア。ピア。
- FEC. The FEC.
- FEC。FEC。
- PrevAdvLabel. The label for the FEC previously advertised to the Peer.
- prevadvlabel。以前にピアに宣伝されていたFECのラベル。
Algorithm:
アルゴリズム：
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, PrevAdvLabel). (See Note 1.)
nols.1は手順を実行しますsend_label_withdraw（peer、fec、prevadvlabel）。（注1を参照してください。）
NoLS.2 DONE.
nols.2完了。
Note:
ノート：
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. If the LSR doesn't wait for the Label Release message from the peer, it SHOULD NOT reuse the label until it receives the Label Release.
1. LSRは、このイベントの一部として、またはラベルの引き出しに応じてピアからのラベルリリースの処理の一部として、転送/切り替えの使用からラベルを削除する場合があります。LSRがピアからのラベルリリースメッセージを待たない場合、ラベルリリースを受信するまでラベルを再利用しないでください。
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.
ラベルリクエストは、通知が検出されないルートとループが検出されないことに応じて延期されます。Peer Times Outの延期された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 the 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の次のホップですか？そうでない場合は、gototo.4。
TO.3 Execute procedure Send_Label_Request (Peer, FEC).
to.3手順send_label_request（ピア、FEC）を実行します。
TO.4 DONE.
to.4 done。
This section specifies utility procedures used by the algorithms that handle label distribution events.
このセクションでは、ラベル分布イベントを処理するアルゴリズムで使用されるユーティリティ手順を指定します。
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がラベルを割り当てることができず、ピアからの保留中のラベルリクエストがある場合、LDPピアにラベルなしのリソース通知を送信します。
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. 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には割り当てるラベルがありますか？そうでない場合は、goto 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ラベル要求の記録がありますか？そうでない場合、goto sl.8。
SL.7 Delete record of pending label request for FEC from Peer.
SL.7 PEERからの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のラベルリクエストがありますか？そうでない場合は、goto 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 PEERからのFECの保留中のラベルリクエストのレコードを削除します。
SL.12 Record No Label Resources notification has been sent to Peer. Goto SL.14.
SL.12レコードラベルリソースはピアに送信されていません。GOTO 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障害を返す。
Note:
ノート：
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.
1. SL.13は、LSRがFECをピアに送信するためにラベルを割り当てることができない場合に、下流の未承諾ラベル分布のケースを処理します。
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は、send_label_request手順を使用して、現在許可されている場合は、FECのラベルのリクエストをLDPピアに送信します。
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ステータスレコードは、ラベルリクエストをピアセットに送信しても問題ないことを示していますか？そうでない場合は、goto slrq.6
SLRq.3 Execute procedure Send_Message (Peer, Label Request, FEC, Attributes).
slrq.3プロシージャsend_message（ピア、ラベルリクエスト、FEC、属性）を実行します。
SLRq.4 Record that label request for FEC has been sent to Peer and mark it as outstanding.
SLRQ.4 FECのラベルリクエストがピアに送信され、それを未解決のものとして記録しました。
SLRq.5 Return success.
SLRQ.5の成功を返します。
SLRq.6 Postpone the label request by recording that label mapping for FEC and Attributes from Peer is needed but that no label resources are available.
SLRQ.6 FECのラベルマッピングとピアからの属性のラベルマッピングを記録することにより、ラベル要求を延期する必要がありますが、ラベルリソースは利用できないことです。
SLRq.7 Return failure.
slrq.7復帰障害。
Note:
ノート：
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のラベルリクエストを送信する試みを区別する必要があります。この手順では、重複したラベルリクエストは送信されません。
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は、send_label_withdraw手順を使用して、LDPピアからFECのラベルを引き出します。これを行うために、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 that label withdraw for FEC has been sent to Peer and mark it as outstanding.
SWD.2 FECのラベル撤回は、ピアに送られ、それを未解決のものとしてマークすることを記録しています。
Summary:
まとめ：
An LSR uses the Send_Notification procedure to send an LDP peer a Notification message.
LSRは、send_notificationプロシージャを使用して、LDPピアに通知メッセージを送信します。
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)
snt.1手順を実行するsend_message（ピア、通知、ステータス）
Summary:
まとめ：
An LSR uses the Send_Message procedure to send an LDP peer an LDP message.
LSRは、send_message手順を使用して、LDPピアにLDPメッセージを送信します。
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.
この手順は、指定されたタイプのLDPメッセージを指定されたLDPピアに送信する手段です。
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.
- ラットトリビュート。メッセージの属性。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR ID。このLSRの一意のLSR ID。
- 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ラットトリビューツはホップカウントを含みますか？そうでない場合は、goto cra.5。
CRa.2 Does Hop Count exceed Max allowable hop count? If so, goto CRa.6.
Cra.2ホップカウントは最大許容ホップカウントを超えていますか？もしそうなら、goto cra.6。
CRa.3 Do RAttributes include Path Vector? If not, goto CRa.5.
Cra.3ラットトリビュートにはパスベクトルが含まれていますか？そうでない場合は、goto 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 Path VectorにはLSR IDが含まれていますか？または、パスベクトルの長さは最大許容長を超えていますか？もしそうなら、goto 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ラベルマッピングですか？もしそうなら、goto cra.8。（注1を参照してください。）
CRa.7 Execute procedure Send_Notification (MsgSource, Loop Detected).
Cra.7は手順を実行しますsend_notification（msgsource、ループ検出）。
CRa.8 Return Loop Detected.
Cra.8 Return Loopが検出されました。
CRa.9 DONE.
Cra.9完了。
Note:
ノート：
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でループ検出された通知を送信します。（セクション「レーベルマッピングの受信」を参照してください。）
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.
- ラットトリビュート。このLSRは、FECのLSPに関連付けられています。
- SAttributes. The attributes to be included in the Label Request message.
- attributes。ラベル要求メッセージに含まれる属性。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR ID。このLSRの一意のLSR ID。
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を参照）またはラットトリビュートはホップカウントを含みますか？または、ループ検出はLSRで構成されていますか？そうでない場合は、goto prqa.14。
PRqA.2 Is LSR ingress for FEC? If not, goto PRqA.6.
PRQA.2はFECのLSRイングレスですか？そうでない場合は、goto prqa.6。
PRqA.3 Include Hop Count of 1 in SAttributes.
Prqa.3は、格納に1のホップカウントを含めます。
PRqA.4 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRQA.4ループ検出はLSRで構成されていますか？そうでない場合は、goto prqa.14。
PRqA.5 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRQA.5はLSRマージ対応ですか？もしそうなら、goto prqa.14。そうでない場合は、goto prqa.13。
PRqA.6 Do RAttributes include a Hop Count? If not, goto PRqA.8.
prqa.6 rattributesにはホップカウントが含まれていますか？そうでない場合は、goto prqa.8。
PRqA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. (See Note 2.) Goto PRqA.9.
PRQA.7インクリメントラットトリビュートホップカウントと結果のホップカウントを格付けにコピーします。（注2を参照）GOTO PRQA.9。
PRqA.8 Include Hop Count of unknown (0) in SAttributes.
Prqa.8は、格納に不明（0）のホップ数を含めます。
PRqA.9 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRQA.9ループ検出はLSRで構成されていますか？そうでない場合は、goto prqa.14。
PRqA.10 Do RAttributes have a Path Vector? If so, goto PRqA.12.
prqa.10 rattributesにはパスベクトルがありますか？もしそうなら、goto prqa.12。
PRqA.11 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRQA.11 LSRマージ対応ですか？もしそうなら、goto prqa.14。そうでない場合は、goto 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ラットトリビュートからパスベクトルの開始にLSR IDを追加し、結果のパスベクトルを格付けにコピーします。GOTO PRQA.14。
PRqA.13 Include Path Vector of length 1 containing LSR Id in SAttributes.
PRQA.13には、衛星にLSR IDを含む長さ1のパスベクトルが含まれます。
PRqA.14 DONE.
prqa.14完了。
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]を参照してください。
2. For hop count arithmetic, unknown + 1 = unknown.
2. ホップカウント算術の場合、不明1 =不明。
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.
- ラットトリビュート。このLSRは、FECのLSPに関連付けられています。
- SAttributes. The attributes to be included in the Label Mapping message.
- attributes。ラベルマッピングメッセージに含まれる属性。
- IsPropagating. The LSR is sending the Label Mapping message to propagate one received from the FEC next hop.
- プロパゲート。LSRは、FEC Next Hopから受信したものを伝播するラベルマッピングメッセージを送信しています。
- PrevHopCount. The Hop Count, if any, this LSR associates with the LSP for the FEC.
- 前提条件。ホップカウントがある場合、このLSRはFECのLSPと関連しています。
Additional Context:
追加のコンテキスト：
- LSR Id. The unique LSR Id of this LSR.
- LSR ID。このLSRの一意のLSR ID。
Algorithm:
アルゴリズム：
PMpA.1 Do the RAttributes include any unknown TLVs? If not, goto PMpA.4.
PMPA.1ラットトリビュートには不明なTLVが含まれていますか？そうでない場合は、goto pmpa.4。
PMpA.2 Do the settings of the U- and F-bits require forwarding of these TLVs? If not, goto PMpA.4.
PMPA.2 UおよびFビットの設定には、これらのTLVの転送が必要ですか？そうでない場合は、goto pmpa.4。
PMpA.3 Copy the unknown TLVs in SAttributes.
PMPA.3未知のTLVを格付けでコピーします。
PMpA.4 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.24.
PMPA.4このピアにはホップカウントが必要ですか？（注1を参照）またはラットトリビュートはホップカウントを含みますか？または、ループ検出はLSRで構成されていますか？そうでない場合は、goto pmpa.24。
PMpA.5 Is LSR egress for FEC? If not, goto PMpA.7.
PMPA.5はFECのLSR出口ですか？そうでない場合は、goto pmpa.7。
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.24.
PMPA.6には、サトリビュートに1のホップカウントが含まれています。GOTO PMPA.24。
PMpA.7 Do RAttributes have a Hop Count? If not, goto PMpA.11.
PMPA.7ラットトリビュートにはホップカウントがありますか？そうでない場合は、goto pmpa.11。
PMpA.8 Is LSR a member of the 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.10.
PMPA.8 LSRは、LSRがTTLの減少を実行せず、そのドメインでピアであるLSRドメインのエッジセットのメンバーですか？（注2を参照）そうでない場合は、goto pmpa.10。
PMpA.9 Include Hop Count of 1 in SAttributes. Goto PMpA.12.
PMPA.9には、サトリビュートに1のホップカウントが含まれます。GOTO PMPA.12。
PMpA.10 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. (See Note 2.) Goto PMpA.12.
PMPA.10インクリメントラットトリビュースホップカウントと結果のホップカウントを格付けにコピーします。（注2を参照）goto pmpa.12。
PMpA.11 Include Hop Count of unknown (0) in SAttributes.
PMPA.11は、サトリビュートに不明（0）のホップ数を含めます。
PMpA.12 Is Loop Detection configured on LSR? If not, goto PMpA.24.
PMPA.12ループ検出はLSRで構成されていますか？そうでない場合は、goto pmpa.24。
PMpA.13 Do RAttributes have a Path Vector? If so, goto PMpA.22.
PMPA.13ラットトリビュートにはパスベクトルがありますか？もしそうなら、goto pmpa.22。
PMpA.14 Is LSR propagating a received Label Mapping? If not, goto PMpA.23.
PMPA.14 LSRは受信したラベルマッピングを伝播していますか？そうでない場合は、goto pmpa.23。
PMpA.15 Does LSR support merging? If not, goto PMpA.17.
PMPA.15 LSRは合併をサポートしていますか？そうでない場合は、goto pmpa.17。
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.23.
PMPA.16 LSRは以前にFECのラベルマッピングをピアに送信しましたか？そうでない場合は、goto pmpa.23。
PMpA.17 Do RAttributes include a Hop Count? If not, goto PMpA.24.
PMPA.17ラットトリビュートはホップカウントを含みますか？そうでない場合は、goto pmpa.24。
PMpA.18 Is Hop Count in RAttributes unknown(0)? If so, goto PMpA.23.
PMPA.18は、Rattributesのホップカウント不明（0）ですか？もしそうなら、goto pmpa.23。
PMpA.19 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.24.
PMPA.19 LSRは以前にPEECにFEC用のラベルマッピングを送信しましたか？そうでない場合は、goto pmpa.24。
PMpA.20 Is Hop Count in RAttributes different from PrevHopCount? If not, goto PMpA.24.
PMPA.20は、ラットトリビュートのホップカウントとは異なりますか？そうでない場合は、goto pmpa.24。
PMpA.21 Is the Hop Count in RAttributes > PrevHopCount? OR Is PrevHopCount unknown(0)? If not, goto PMpA.24.
PMPA.21は、ラットトリビュートのホップカウント> prevhopcountですか？または、prevhopcountは不明です（0）？そうでない場合は、goto pmpa.24。
PMpA.22 Add LSR Id to beginning of Path Vector from RAttributes and copy the resulting Path Vector into SAttributes. Goto PMpA.24.
PMPA.22は、rattributesからパスベクトルの開始にLSR IDを追加し、結果のパスベクトルを格付けにコピーします。GOTO PMPA.24。
PMpA.23 Include Path Vector of length 1 containing LSR Id in SAttributes.
PMPA.23には、衛星にLSR IDを含む長さ1のパスベクトルが含まれます。
PMpA.24 DONE.
PMPA.24完了。
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分解を実行しないLSRの雲の端にあり、ラベルマッピングメッセージをクラウドに上流に伝播している場合、クラウド全体のホップカウントが適切に計算されるようにホップカウントを1に設定します。これにより、クラウドを通過するLSPの一部に転送されるパケットの適切なTTL管理が保証されます。
3. For hop count arithmetic, unknown + 1 = unknown.
3. ホップカウント算術の場合、不明1 =不明。
Editors' Addresses
編集者のアドレス
Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden EMail: loa.andersson@acreo.se loa@pi.se
loa andersson acreo ab isafjordsgatan 22キスタ、スウェーデンのメール：loa.andersson@acreo.se loa@pi.se
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net
Ina Misei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089メール：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: rhthomas@cisco.com
Bob Thomas Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719メール：rhthomas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。