RFC4379 日本語訳
4379 Detecting Multi-Protocol Label Switched (MPLS) Data PlaneFailures. K. Kompella, G. Swallow. February 2006. (Format: TXT=116872 bytes) (Updates RFC1122) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Kompella
Request for Comments: 4379 Juniper Networks, Inc.
Updates: 1122 G. Swallow
Category: Standards Track Cisco Systems, Inc.
February 2006
Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4379年の杜松はInc.アップデートをネットワークでつなぎます: 1122年のG.ツバメカテゴリ: 標準化過程シスコシステムズInc.2006年2月
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出します。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply.
このドキュメントはMulti-プロトコルLabel Switching(MPLS)ラベルSwitched Paths(LSPs)にデータ飛行機の故障を検出するのに使用できる簡単で効率的なメカニズムについて説明します。 このドキュメントへの2つの部品があります: 情報はMPLS「エコー要求」、欠点検出と分離の目的のための「エコー・リプライ」、およびエコー・リプライを確かに送るためのメカニズムによって運ばれました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions ................................................3
1.2. Structure of This Document .................................3
1.3. Contributors ...............................................3
2. Motivation ......................................................4
2.1. Use of Address Range 127/8 .................................4
3. Packet Format ...................................................6
3.1. Return Codes ..............................................10
3.2. Target FEC Stack ..........................................11
3.2.1. LDP IPv4 Prefix ....................................12
3.2.2. LDP IPv6 Prefix ....................................13
3.2.3. RSVP IPv4 LSP ......................................13
3.2.4. RSVP IPv6 LSP ......................................14
3.2.5. VPN IPv4 Prefix ....................................14
3.2.6. VPN IPv6 Prefix ....................................15
3.2.7. L2 VPN Endpoint ....................................16
1. 序論…2 1.1. コンベンション…3 1.2. このドキュメントの構造…3 1.3. 貢献者…3 2. 動機…4 2.1. アドレスの範囲127/8の使用…4 3. パケット形式…6 3.1. 復帰コード…10 3.2. 目標FECは積み重ねます…11 3.2.1. 自由民主党IPv4接頭語…12 3.2.2. 自由民主党IPv6接頭語…13 3.2.3. RSVP IPv4 LSP…13 3.2.4. RSVP IPv6 LSP…14 3.2.5. VPN IPv4接頭語…14 3.2.6. VPN IPv6接頭語…15 3.2.7. L2 VPN終点…16
Kompella & Swallow Standards Track [Page 1] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[1ページ]RFC4379
3.2.8. FEC 128 Pseudowire (Deprecated) ....................16
3.2.9. FEC 128 Pseudowire (Current) .......................17
3.2.10. FEC 129 Pseudowire ................................18
3.2.11. BGP Labeled IPv4 Prefix ...........................19
3.2.12. BGP Labeled IPv6 Prefix ...........................20
3.2.13. Generic IPv4 Prefix ...............................20
3.2.14. Generic IPv6 Prefix ...............................21
3.2.15. Nil FEC ...........................................21
3.3. Downstream Mapping ........................................22
3.3.1. Multipath Information Encoding .....................26
3.3.2. Downstream Router and Interface ....................28
3.4. Pad TLV ...................................................29
3.5. Vendor Enterprise Number ..................................29
3.6. Interface and Label Stack .................................29
3.7. Errored TLVs ..............................................31
3.8. Reply TOS Byte TLV ........................................31
4. Theory of Operation ............................................32
4.1. Dealing with Equal-Cost Multi-Path (ECMP) .................32
4.2. Testing LSPs That Are Used to Carry MPLS Payloads .........33
4.3. Sending an MPLS Echo Request ..............................33
4.4. Receiving an MPLS Echo Request ............................34
4.4.1. FEC Validation .....................................40
4.5. Sending an MPLS Echo Reply ................................41
4.6. Receiving an MPLS Echo Reply ..............................42
4.7. Issue with VPN IPv4 and IPv6 Prefixes .....................42
4.8. Non-compliant Routers .....................................43
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................44
6. Security Considerations ........................................44
7. IANA Considerations ............................................46
7.1. Message Types, Reply Modes, Return Codes ..................46
7.2. TLVs ......................................................47
8. Acknowledgements ...............................................48
3.2.8. FEC128Pseudowire(推奨しない)…16 3.2.9. FEC128Pseudowire(現在の)…17 3.2.10. FEC129Pseudowire…18 3.2.11. BGPは接頭語とIPv4をラベルしました…19 3.2.12. BGPは接頭語とIPv6をラベルしました…20 3.2.13. ジェネリックIPv4接頭語…20 3.2.14. ジェネリックIPv6接頭語…21 3.2.15. 無いFEC…21 3.3. 川下のマッピング…22 3.3.1. 多重通路情報コード化…26 3.3.2. 川下のルータとインタフェース…28 3.4. TLVを水増ししてください…29 3.5. ベンダーエンタープライズ番号…29 3.6. スタックを連結して、ラベルしてください…29 3.7. Errored TLVs…31 3.8. TOSバイトTLVは返答します…31 4. 操作の理論…32 4.1. 等しい費用マルチ経路(ECMP)に対処します…32 4.2. MPLS有効搭載量を運ぶのに使用されるLSPsをテストします…33 4.3. MPLSを送って、要求を反映してください…33 4.4. MPLSを受けて、要求を反映してください…34 4.4.1. FEC合法化…40 4.5. MPLSエコーを送って、返答してください…41 4.6. MPLSエコーを受けて、返答してください…42 4.7. VPN IPv4とIPv6と共に接頭語を発行してください…42 4.8. 不従順なルータ…43 5. 参照…43 5.1. 標準の参照…43 5.2. 有益な参照…44 6. セキュリティ問題…44 7. IANA問題…46 7.1. メッセージタイプ、回答モード、復帰コード…46 7.2. TLVs…47 8. 承認…48
1. Introduction
1. 序論
This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply", and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The second part suggests two methods of reliable reply channels for the echo request message for more robust fault isolation.
このドキュメントはMPLS Label Switched Paths(LSPs)にデータ飛行機の故障を検出するのに使用できる簡単で効率的なメカニズムについて説明します。 このドキュメントへの2つの部品があります: 情報はMPLS「エコー要求」と「エコー・リプライ」、およびエコー・リプライを輸送するためのメカニズムによって運ばれました。 最初の部分は、制御飛行機に対してデータ飛行機について確かめて、その結果、欠点をローカライズすることをデータ飛行機の正しい操作、およびメカニズムをチェックできるくらいの情報を提供するのを目指します。 第二部は、より強健な欠点分離へのエコー要求メッセージのために高信頼の回答チャンネルの2つのメソッドを示します。
Kompella & Swallow Standards Track [Page 2] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[2ページ]RFC4379
An important consideration in this design is that MPLS echo requests follow the same data path that normal MPLS packets would traverse. MPLS echo requests are meant primarily to validate the data plane, and secondarily to verify the data plane against the control plane. Mechanisms to check the control plane are valuable, but are not covered in this document.
このデザインにおける重要な考慮すべき事柄はMPLSエコー要求が正常なMPLSパケットが横断するのと同じデータ経路に続くということです。 MPLSエコー要求は、主としてデータ飛行機を有効にして、二次的に制御飛行機に対してデータ飛行機について確かめることになっています。 制御飛行機をチェックするメカニズムは、貴重ですが、本書ではカバーされていません。
This document makes special use of the address range 127/8. This is an exception to the behavior defined in RFC 1122 [RFC1122] and updates that RFC. The motivation for this change and the details of this exceptional use are discussed in section 2.1 below.
このドキュメントはアドレスの特別な使用を範囲127/8にします。 これは、RFC1122[RFC1122]で定義された振舞いへの例外であり、そのRFCをアップデートします。 下のセクション2.1でこの変化に関する動機とこの例外的な使用の詳細について議論します。
1.1. Conventions
1.1. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
The term "Must Be Zero" (MBZ) is used in object descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
用語が「ゼロでなければならない」という(MBZ)は予約された分野にオブジェクト記述に使用されます。 領収書の上で送られて、無視されると、これらの分野をゼロに設定しなければなりません。
Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs) is defined in [RFC4026].
L2に関係する用語とL3 Virtual兵士のNetworks(VPNs)は[RFC4026]で定義されます。
Since this document refers to the MPLS Time to Live (TTL) far more frequently than the IP TTL, the authors have chosen the convention of using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for the TTL value in the IP header.
このドキュメントがIP TTLよりはるかに頻繁にLive(TTL)とMPLS Timeを呼ぶので、作者は"MPLS TTL"を意味するのに資格のない"TTL"を使用して、TTL値にIPヘッダーで「IP TTL」を使用するコンベンションを選びました。
1.2. Structure of This Document
1.2. このドキュメントの構造
The body of this memo contains four main parts: motivation, MPLS echo request/reply packet format, LSP ping operation, and a reliable return path. It is suggested that first-time readers skip the actual packet formats and read the Theory of Operation first; the document is structured the way it is to avoid forward references.
このメモのボディーは4つの主部を含みます: 動機、MPLSエコー要求/回答パケット・フォーマット、LSPピング操作、および信頼できるリターンパス。 初めての読者が実際のパケット・フォーマットをスキップして、最初にOperationのTheoryを読むことが提案されます。 ドキュメントはそれが前進の参照を避けることになっている方法で構造化されます。
1.3. Contributors
1.3. 貢献者
The following made vital contributions to all aspects of this document, and much of the material came out of debate and discussion among this group.
以下は重大な貢献をしました。材料が討論と議論から来たこのドキュメント、および多くの全面と、これは分類されます。
Ronald P. Bonica, Juniper Networks, Inc.
Dave Cooper, Global Crossing
Ping Pan, Hammerhead Systems
ロナルドP.Bonica、杜松ネットワークInc.デーヴ・クーパー、グローバルクロッシングピングなべ、ハンマーの頭システム
Kompella & Swallow Standards Track [Page 3] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[3ページ]RFC4379
Nischal Sheth, Juniper Networks, Inc.
Sanjay Wadhwa, Juniper Networks, Inc.
Nischal Sheth、杜松はInc.Sanjay Wadhwaをネットワークでつないで、杜松はInc.をネットワークでつなぎます。
2. Motivation
2. 動機
When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults.
LSPが配送しないと、ユーザトラフィックでありMPLS制御飛行機はいつも失敗を検出できるというわけではありません。 適正な期間以内にユーザがそのようなトラフィック「ブラックホール」かmisroutingを検出するのを可能にするツールを提供して、孤立している欠点にメカニズムを提供する必要があります。
In this document, we describe a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [ICMP]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. This document specifies a "ping" mode and a "traceroute" mode for testing MPLS LSPs.
本書では、私たちはこれらの目標を達成するメカニズムについて説明します。 このメカニズムはピング/トレースルートパラダイムに倣われます: ピング(ICMPエコー要求[ICMP])は接続性チェックに使用されます、そして、トレースルートはホップごとのパス追跡と同様に欠点ローカライズに使用されます。 このドキュメントは「ピング」モードと「トレースルート」モードをテストMPLS LSPsに指定します。
The basic idea is to verify that packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on a Label Switching Router (LSR) that is an egress for that FEC. This document proposes that this test be carried out by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies whether it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path.
基本的な考え方は特定のForwarding Equivalence Class(FEC)に属すパケットが実際にそのFECのための出口であるLabel Switching Router(LSR)の上の彼らのMPLS経路を終わらせることを確かめることです。 このドキュメントは、このテストが他と同じデータ経路に沿ったパケット(「MPLSエコー要求」と呼ばれる)にこのFECに属すパケットを送ることによって行われるよう提案します。 また、MPLSエコー要求はMPLS経路が確かめられているFECの情報を運びます。 まさしくそのFECに属すいかなる他のパケットのようにもこのエコー要求を転送します。 「ピング」モード(基本的な接続性チェック)で、パケットは次にFECのために本当に、それが出口であるかどうか確かめるそれがどのポイントであるかで出口LSRの制御飛行機に送られた経路の端に達するはずです。 「トレースルート」モード(欠点分離)で、各トランジットLSRの制御飛行機にパケットを送って、どれが様々な状態で働くかが本当に、それがこの経路へのトランジットLSRであることをチェックします。 また、このLSRはルーティング・プロトコルが経路として決定したものをマッチに送るすなわち、データ飛行機に対する制御飛行機、それをチェックするのを助ける詳細を返します。
One way these tools can be used is to periodically ping an FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and thus should be used with caution.
これらのツールを使用できる1つの方法は定期的に接続性を確実にするFECを確認することです。 ピングが失敗するなら、人は、欠点がどこにあるかを決定するためにトレースルートを開始できます。 1はそうすることができます、また、定期的に、その推進について確かめるトレースルートFECsは制御飛行機に合っています、。 しかしながら、これは、トランジットLSRsにより大きい負担をかけて、その結果、慎重に使用されるべきです。
2.1. Use of Address Range 127/8
2.1. アドレスの範囲127/8の使用
As described above, LSP ping is intended as a diagnostic tool. It is intended to enable providers of an MPLS-based service to isolate network faults. In particular, LSP ping needs to diagnose situations
上で説明されるように、LSPピングは診断用道具として意図します。 MPLSベースのサービスのプロバイダーがネットワーク障害を隔離するのを可能にするのは意図しています。 特に、LSPピングは、状況を診断する必要があります。
Kompella & Swallow Standards Track [Page 4] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[4ページ]RFC4379
where the control and data planes are out of sync. It performs this by routing an MPLS echo request packet based solely on its label stack. That is, the IP destination address is never used in a forwarding decision. In fact, the sender of an MPLS echo request packet may not know, a priori, the address of the router at the end of the LSP.
コントロールとデータ飛行機が同期しているところ。 それはMPLSエコー要求パケットが唯一ラベルスタックに基礎づけたルーティングでこれを実行します。 すなわち、受信者IPアドレスは推進決定に決して使用されません。 事実上、MPLSエコー要求パケットの送付者は知らないかもしれません、先験的です、LSPの端のルータのアドレス。
Providers of MPLS-based services also need the ability to trace all of the possible paths that an LSP may take. Since most MPLS services are based on IP unicast forwarding, these paths are subject to equal-cost multi-path (ECMP) load sharing.
また、MPLSベースのサービスのプロバイダーはLSPが取るかもしれない可能な経路のすべてをたどる能力を必要とします。 ほとんどのMPLSサービスがIPユニキャスト推進に基づいているので、これらの経路は等しい費用マルチ経路(ECMP)負荷分割法を受けることがあります。
This leads to the following requirements:
これは以下の要件に通じます:
1. Although the LSP in question may be broken in unknown ways, the
likelihood of a diagnostic packet being delivered to a user of an
MPLS service MUST be held to an absolute minimum.
1. 問題のLSPは未知の方法で壊れるかもしれませんが、MPLSサービスのユーザに提供される診断パケットの見込みを絶対最小値まで保持しなければなりません。
2. If an LSP is broken in such a way that it prematurely terminates,
the diagnostic packet MUST NOT be IP forwarded.
2. LSPが早まって終わるような方法で壊れているなら、診断パケットは進められたIPであるはずがありません。
3. A means of varying the diagnostic packets such that they exercise
all ECMP paths is thus REQUIRED.
3. その結果、すべてのECMP経路を運動させるように診断パケットを変える手段はREQUIREDです。
Clearly, using general unicast addresses satisfies neither of the first two requirements. A number of other options for addresses were considered, including a portion of the private address space (as determined by the network operator) and the newly designated IPv4 link local addresses. Use of the private address space was deemed ineffective since the leading MPLS-based service is an IPv4 Virtual Private Network (VPN). VPNs often use private addresses.
明確に、一般的なユニキャストアドレスを使用する場合、最初の2つの要件のどちらも満足しません。 プライベート・アドレススペースの部分を含んでいて(ネットワーク・オペレータによって決定されるように)、アドレスのためのオプションが考えられて、新たにIPv4リンクに地方で指定されているのが扱う他の数。 プライベート・アドレススペースの使用は、主なMPLSベースのサービスがIPv4 Virtual兵士のNetwork(VPN)であるので、効力がないと考えられました。 VPNsはしばしばプライベート・アドレスを使用します。
The IPv4 link local addresses are more attractive in that the scope over which they can be forwarded is limited. However, if one were to use an address from this range, it would still be possible for the first recipient of a diagnostic packet that "escaped" from a broken LSP to have that address assigned to the interface on which it arrived and thus could mistakenly receive such a packet. Furthermore, the IPv4 link local address range has only recently been allocated. Many deployed routers would forward a packet with an address from that range toward the default route.
それらを送ることができる範囲が限られているので、IPv4のリンクのローカルのアドレスは、より魅力的です。 しかしながら、1つがこの範囲からのアドレスを使用するなら、壊れているLSPから「逃げられた」診断パケットの最初の受取人には、それが到着して、その結果そのようなパケットを誤って受けることができたインタフェースにそのアドレスを割り当てさせるのはまだ可能でしょうに。 その上、最近、IPv4リンクローカルアドレス範囲を割り当てるだけでした。 ルータであると配布された多くがアドレスがあるパケットをその範囲からデフォルトルートに向かって送るでしょう。
The 127/8 range for IPv4 and that same range embedded in as IPv4- mapped IPv6 addresses for IPv6 was chosen for a number of reasons.
IPv4のための127/8範囲とIPv4がIPv6のためのIPv6アドレスを写像したので中に埋め込まれたその同じ範囲は様々な意味で選ばれました。
RFC 1122 allocates the 127/8 as "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This
RFC1122は「内部のホストループバックアドレス」と州として127/8を割り当てます: 「このフォームのアドレスはホストの外に現れてはいけません。」 したがって、ホストのデフォルトの振舞いはそのようなパケットを捨てることです。 これ
Kompella & Swallow Standards Track [Page 5] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[5ページ]RFC4379
helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded.
ホストにとって、診断パケットが的外れであるなら、それが静かに捨てられるのを保証するのを助けます。
RFC 1812 [RFC1812] states:
RFC1812[RFC1812]州:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127. A router
MAY have a switch that allows the network manager to disable these
checks. If such a switch is provided, it MUST default to
performing the checks.
ループバックインタフェース、どんなパケットを除いても、SHOULD NOTがそれを送るルータはネットワーク127に関する送付先アドレスを持っています。 ルータはネットワークマネージャがこれらのチェックを無効にすることができるスイッチを持っているかもしれません。 そのようなスイッチを提供するなら、それはチェックを実行するのをデフォルトとしなければなりません。
This helps to ensure that diagnostic packets are never IP forwarded.
これは、診断パケットが決して進められたIPでないことを保証するのを助けます。
The 127/8 address range provides 16M addresses allowing wide flexibility in varying addresses to exercise ECMP paths. Finally, as an implementation optimization, the 127/8 provides an easy means of identifying possible LSP packets.
127/8アドレスの範囲は異なったアドレスの広い柔軟性がECMP経路を運動させることができる16Mのアドレスを提供します。 最終的に、実装として、最適化、127/8は可能なLSPパケットを特定する簡単な手段を提供します。
3. Packet Format
3. パケット・フォーマット
An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; the contents of the UDP packet have the following format:
MPLSエコー要求は、(ことによるとラベルされています)のIPv4かIPv6 UDPパケットです。 UDPパケットの内容には、以下の形式があります:
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 Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン番号| グローバルな旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージタイプ| 回答モード| 復帰コード| リターン部分符号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のハンドル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプは発信しました(秒)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプは発信しました(マイクロセカンド)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプは受信されました(秒)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプは受信されました(マイクロセカンド)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs… | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 6] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[6ページ]RFC4379
The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process an MPLS echo request/reply. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub-TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.)
現在、バージョンNumberは1歳です。 (以下に注意してください。 バージョン番号は実装が正しくMPLSエコー要求/回答を分析するか、または処理する能力に影響する変更が行われるときはいつも、増加されていることです。 これらの変化は固定分野のどれかや、または、あるバージョン番号で定義されるどんなType長さの価値(TLV)や、サブTLV課題や書式にもされたどんな構文の、または、意味の変更も含んでいます。 任意のTLVかサブTLVが加えられるなら、バージョン番号は変えられる必要はないかもしれません。)
The Global Flags field is a bit vector with the following format:
Global Flags分野は少し、以下があるベクトルが以下をフォーマットするということです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the V bit; the rest MUST be set to zero when sending and ignored on receipt.
1個の旗が当分定義されて、Vに噛み付きました。 残りを発信するとき、ゼロに設定されて、領収書の上で無視しなければなりません。
The V (Validate FEC Stack) flag is set to 1 if the sender wants the receiver to perform FEC Stack validation; if V is 0, the choice is left to the receiver.
送付者が、受信機にFEC Stack合法化を実行して欲しいなら、V(FEC Stackを有効にする)旗は1に設定されます。 Vが0であるなら、選択は受信機に残されます。
The Message Type is one of the following:
Message Typeは以下のひとりです:
Value Meaning
----- -------
1 MPLS echo request
2 MPLS echo reply
値の意味----- ------- 1つのMPLSエコー要求2MPLSエコー・リプライ
The Reply Mode can take one of the following values:
Reply Modeは以下の値の1つを取ることができます:
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel
値の意味----- ------- 1 アプリケーションレベルコントロールを通してRouter Alert4ReplyがあるIPv4/IPv6 UDPパケットを通した3Replyがチャネルを開設するIPv4/IPv6 UDPパケットを通してどんな回答にも2Replyをしないでください。
An MPLS echo request with 1 (Do not reply) in the Reply Mode field may be used for one-way connectivity tests; the receiving router may log gaps in the Sequence Numbers and/or maintain delay/jitter statistics. An MPLS echo request would normally have 2 (Reply via an IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP return path is deemed unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with Router Alert). Note that this requires that all intermediate routers understand and know how to forward MPLS
1(返答しない)がReply Mode分野にあるMPLSエコー要求は一方向接続性テストに使用されるかもしれません。 受信ルータは、Sequence民数記におけるギャップを登録する、そして/または、遅れ/ジター統計を維持するかもしれません。 通常、MPLSエコー要求はReply Mode分野に2(IPv4/IPv6 UDPパケットを通して、返答する)を持っているでしょう。 正常なIPリターンパスが頼り無いと考えられるなら、3を使用するかもしれません(Router AlertがあるIPv4/IPv6 UDPパケットを通して返答してください)。 これが、すべての中間的ルータが分かるのを必要とすることに注意してください、そして、MPLSを進める方法を知ってください。
Kompella & Swallow Standards Track [Page 7] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[7ページ]RFC4379
echo replies. The echo reply uses the same IP version number as the received echo request, i.e., an IPv4 encapsulated echo reply is sent in response to an IPv4 encapsulated echo request.
回答をまねてください。 エコー・リプライは受信されたエコー要求と同じIPバージョン番号を使用します、すなわち、エコー要求であるとカプセル化されたIPv4に対応してエコー・リプライであるとカプセル化されたIPv4を送ります。
Some applications support an IP control channel. One such example is the associated control channel defined in Virtual Circuit Connectivity Verification (VCCV) [VCCV]. Any application that supports an IP control channel between its control entities may set the Reply Mode to 4 (Reply via application level control channel) to ensure that replies use that same channel. Further definition of this codepoint is application specific and thus beyond the scope of this document.
いくつかのアプリケーションがIP制御チャンネルを支えます。 その一例はVirtual Circuit Connectivity Verification(VCCV)[VCCV]で定義された関連制御チャンネルです。 コントロール実体の間のIP制御チャンネルを支えるどんなアプリケーションも、回答がその同じチャンネルを使用するのを保証するために4にReply Modeを設定するかもしれません(アプリケーションレベルコントロールチャンネルで、返答します)。 アプリケーション特有であり、その結果、このドキュメントの範囲を超えてこのcodepointのさらなる定義。
Return Codes and Subcodes are described in the next section.
リターンCodesとSubcodesは次のセクションで説明されます。
The Sender's Handle is filled in by the sender, and returned unchanged by the receiver in the echo reply (if any). There are no semantics associated with this handle, although a sender may find this useful for matching up requests with replies.
受信機はエコー・リプライ(もしあれば)で変わりがない状態でSenderのHandleに送付者が記入して、返します。 このハンドルに関連しているどんな意味論もありません、送付者は、これが回答によって要求を合わせることの役に立つのがわかるかもしれませんが。
The Sequence Number is assigned by the sender of the MPLS echo request and can be (for example) used to detect missed replies.
Sequence NumberをMPLSエコー要求の送付者が割り当てて、逃された回答を検出するのに使用できます(例えば)。
The TimeStamp Sent is the time-of-day (in seconds and microseconds, according to the sender's clock) in NTP format [NTP] when the MPLS echo request is sent. The TimeStamp Received in an echo reply is the time-of-day (according to the receiver's clock) in NTP format that the corresponding echo request was received.
MPLSエコー要求を送るとき、TimeStamp SentはNTP形式[NTP]において時刻(送付者の時計に従った秒とマイクロセカンドの)です。 エコー・リプライにおけるTimeStamp Receivedは対応するエコーが受け取られたよう要求するNTP書式で時刻(受信機の時計に従って)です。
TLVs (Type-Length-Value tuples) have the following format:
TLVs(タイプ長さの価値のtuples)には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値| . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. TLVs may be nested within other TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs have independent types and MUST also be 4-octet aligned.
タイプは以下で定義されます。 長さは八重奏で、Value分野の長さです。 Value分野をTypeに依存します。 4八重奏の境界に並ぶのはそっと歩いていません。 TLVsは他のTLVsの中で入れ子にされるかもしれません、その場合、入れ子にされたTLVsはサブTLVsと呼ばれます。 サブTLVsは独立しているタイプがあって、また、並べられた4八重奏であるに違いありません。
Kompella & Swallow Standards Track [Page 8] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[8ページ]RFC4379
Two examples follow. The Label Distribution Protocol (LDP) IPv4 FEC sub-TLV has the following format:
2つの例が従います。 Label Distributionプロトコル(自由民主党)IPv4 FECサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1(自由民主党IPv4 FEC)をタイプしてください。| 長さ=5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this TLV is 5. A Target FEC Stack TLV that contains an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the following format:
このTLVのためのLengthは5歳です。 自由民主党IPv4 FECサブTLVとVPN IPv4接頭語サブTLVを含むTarget FEC Stack 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1(FEC TLV)をタイプしてください。| 長さ=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブタイプ=1(自由民主党IPv4 FEC)| 長さ=5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブType=6(VPN IPv4接頭語)| 長さ=13| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルートDistinguisher| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 9] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[9ページ]RFC4379
A description of the Types and Values of the top-level TLVs for LSP ping are given below:
LSPピングのための先端平らなTLVsのTypesとValuesの記述を以下に与えます:
Type # Value Field
------ -----------
1 Target FEC Stack
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
10 Reply TOS Byte
タイプ#値の分野------ ----------- 1 目標FECスタック2川下のマッピング3パッド4は7インタフェースが割り当てられなかった5ベンダーエンタープライズNo.6を割り当てませんでした、そして、ラベルスタック8は回答TOSバイトを9Errored TLVs10に割り当てませんでした。
Types less than 32768 (i.e., with the high-order bit equal to 0) are
mandatory TLVs that MUST either be supported by an implementation or
result in the return code of 2 ("One or more of the TLVs was not
understood") being sent in the echo response.
タイプ32768(すなわち、0と等しい高位のビットがある)はエコー応答で送りながら2(「TLVsの1つ以上は理解されていなかった」)の復帰コードの実装か結果でサポートしなければならない義務的なTLVsです。
Types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them.
32768以上のタイプ(すなわち、1と等しい高位のビットがある)は任意のTLVsです。実装が彼らを理解もしていませんし、サポートもしないなら、SHOULDは無視されます。
3.1. Return Codes
3.1. 復帰コード
The Return Code is set to zero by the sender. The receiver can set it to one of the values listed below. The notation <RSC> refers to the Return Subcode. This field is filled in with the stack-depth for those codes that specify that. For all other codes, the Return Subcode MUST be set to zero.
送付者はゼロにReturn Codeを用意ができさせます。 受信機は以下に記載された値の1つにそれを設定できます。 記法<RSC>はReturn Subcodeについて言及します。 この分野はそれを指定するそれらのコードのためにスタック深さで記入されます。 他のすべてのコードにおいて、Return Subcodeはゼロに用意ができなければなりません。
Value Meaning
----- -------
値の意味----- -------
0 No return code
0 復帰コードがありません。
1 Malformed echo request received
1 奇形のエコー要求は受信されました。
2 One or more of the TLVs was not understood
2 TLVsの1つ以上は理解されていませんでした。
3 Replying router is an egress for the FEC at stack-
depth <RSC>
3返答ルータはスタックの深さ<RSC>のFECのための出口です。
4 Replying router has no mapping for the FEC at stack-
depth <RSC>
4返答ルータはスタックの深さ<RSC>にFECのための写像を持っていません。
Kompella & Swallow Standards Track [Page 10] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[10ページ]RFC4379
5 Downstream Mapping Mismatch (See Note 1)
5の川下のマッピングミスマッチ(注意1を見ます)
6 Upstream Interface Index Unknown (See Note 1)
6の上流のインタフェースインデックス未知(注意1を見ます)
7 Reserved
予約された7
8 Label switched at stack-depth <RSC>
スタック深さ<RSC>で切り換えられた8ラベル
9 Label switched but no MPLS forwarding at stack-depth
<RSC>
9はスタック深さ<RSC>を切り換えられるのにもかかわらずの、いいえ、MPLSを推進とラベルします。
10 Mapping for this FEC is not the given label at stack-
depth <RSC>
このFECのための10マッピングはスタックの深さ<RSC>の与えられたラベルではありません。
11 No label entry at stack-depth <RSC>
11 スタック深さ<RSC>のラベルなしエントリー
12 Protocol not associated with interface at FEC stack-
depth <RSC>
12 FECスタック深さ<RSC>でインタフェースに関連づけられなかったプロトコル
13 Premature termination of ping due to label stack
shrinking to a single label
13 ラベルスタックの縮小するのによる単一のラベルへのピングの未完熟終了
Note 1
注意1
The Return Subcode contains the point in the label stack where
processing was terminated. If the RSC is 0, no labels were
processed. Otherwise the packet would have been label switched at
depth RSC.
Return Subcodeは処理が終えられたラベルスタックにポイントを含んでいます。 RSCが0歳であるなら、ラベルなしは処理されました。 さもなければ、パケットは深さRSCで切り換えられたラベルだったでしょう。
3.2. Target FEC Stack
3.2. 目標FECスタック
A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by looking at the sub-TLV length fields.
Target FEC StackはサブTLVsのリストです。 要素の数は、サブTLV長さの分野を見ることによって、測定されます。
Sub-Type Length Value Field
-------- ------ -----------
1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP
5 Not Assigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated)
10 14 "FEC 128" Pseudowire
11 16+ "FEC 129" Pseudowire
12 5 BGP labeled IPv4 prefix
サブタイプ長さの値の分野-------- ------ ----------- IPv4接頭語とラベルされた1 5自由民主党IPv4接頭語2 17自由民主党IPv6接頭語3 20RSVP IPv4 LSP4 56RSVP IPv6 LSP5Not Assigned6 13VPN IPv4接頭語7 25VPN IPv6接頭語8 14L2 VPN終点9 10「FEC128」Pseudowireの(推奨しない)の10 14「FEC128」Pseudowire11 16+ 「FEC129」Pseudowire12 5BGP
Kompella & Swallow Standards Track [Page 11] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[11ページ]RFC4379
13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix
16 4 Nil FEC
IPv6接頭語14 5Generic IPv4接頭語15 17Generic IPv6接頭語16 4Nil FECとラベルされた13 17BGP
Other FEC Types will be defined as needed.
他のFEC Typesは必要に応じて定義されるでしょう。
Note that this TLV defines a stack of FECs, the first FEC element corresponding to the top of the label stack, etc.
このTLVがFECsのスタックを定義することに注意してください、ラベルスタックなどの先端に対応する最初のFEC要素
An MPLS echo request MUST have a Target FEC Stack that describes the FEC Stack being tested. For example, if an LSR X has an LDP mapping [LDP] for 192.168.1.1 (say, label 1001), then to verify that label 1001 does indeed reach an egress LSR that announced this prefix via LDP, X can send an MPLS echo request with an FEC Stack TLV with one FEC in it, namely, of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send the echo request with a label of 1001.
MPLSエコー要求で、FEC Stackについて説明するTarget FEC Stackをテストしなければなりません。 例えば、LSR Xが自由民主党に192.168のために[自由民主党]を写像させるなら、XがMPLSを送ることができる本当に、ラベル1001が自由民主党を通してこの接頭語を発表した出口LSRに達することを確かめるために当時の.1(たとえば、1001をラベルする)が反響する.1は、あるFECがそれにあるFEC Stack TLVと共にすなわち、IPv4がタイプ自由民主党では、接頭語192.168.1で.1/32を前に置いて、1001年のラベルでエコー要求を送るよう要求します。
Say LSR X wanted to verify that a label stack of <1001, 23456> is the right label stack to use to reach a VPN IPv4 prefix [see section 3.2.5] of 10/8 in VPN foo. Say further that LSR Y with loopback address 192.168.1.1 announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in general be different from the Route Distinguisher that LSR X uses in its own advertisements for VPN foo), label 23456 and BGP next hop 192.168.1.1 [BGP]. Finally, suppose that LSR X receives a label binding of 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS echo request: X can send an MPLS echo request with an FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a Route Distinguisher of RD-foo-Y. Alternatively, X can send an FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 with Route Distinguisher of RD- foo-Y. In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)
LSR Xが、VPN fooで10/8のVPN IPv4接頭語[セクション3.2.5を見る]に達するように<1001、23456>のラベルスタックが使用する右のラベルスタックであることを確かめたがっていたと言ってください。 .1が発表したループバックアドレス192.168.1があるLSR YがRoute Distinguisher RD-foo-Y(一般に、LSR XがVPN fooにそれ自身の広告で使用するRoute Distinguisherと異なっているかもしれない)がある10/8、ラベル23456、およびBGP次のホップ192.168.1.1[BGP]を前に置くとさらに言ってください。 最終的に、LSR Xが192.168で1001を縛るラベルを受けると仮定してください。.1 .1 自由民主党を通して。 XはMPLSエコー要求を送る際に2つの選択を持っています: XはVPN IPv4が10/8の接頭語で前に置くタイプの独身のFECとRD-foo-YのRoute DistinguisherとFEC Stack TLVとのMPLSエコー要求を送ることができます。 あるいはまた、Xは2FECsとFEC Stack TLVを送ることができます、192.168の接頭語があるタイプ自由民主党IPv4の1番目。.1 RD- foo-YのRoute Distinguisherとの接頭語10/8があるタイプのIP VPNの.1/32と2番目。 どちらの場合ではも、MPLSエコー要求は<1001、23456>のラベルスタックを持っているでしょう。 (注意: 1001はこの例では、「外側」のラベルであり、23456は「内側」のラベルです。)
3.2.1. LDP IPv4 Prefix
3.2.1. 自由民主党IPv4接頭語
The IPv4 Prefix FEC is defined in [LDP]. When an LDP IPv4 prefix is encoded in a label stack, the following format is used. The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero. See [LDP] for an example of a Mapping for an IPv4 FEC.
IPv4 Prefix FECは[自由民主党]で定義されます。 自由民主党IPv4接頭語がラベルスタックでコード化されるとき、以下の形式は使用されています。 値はビットにおける、接頭語の長さの1つの八重奏があとに続いたIPv4接頭語の4つの八重奏から成ります。 書式を以下に与えます。 ネットワークバイトオーダーにはIPv4接頭語があります。 接頭語が32ビット、引きずっているビットSHOULDより短いなら、ゼロにセットしてください。 Mappingの例に関してIPv4 FECに関して[自由民主党]を見てください。
Kompella & Swallow Standards Track [Page 12] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[12ページ]RFC4379
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP IPv6 Prefix
3.2.2. 自由民主党IPv6接頭語
The IPv6 Prefix FEC is defined in [LDP]. When an LDP IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero. See [LDP] for an example of a Mapping for an IPv6 FEC.
IPv6 Prefix FECは[自由民主党]で定義されます。 自由民主党IPv6接頭語がラベルスタックでコード化されるとき、以下の形式は使用されています。 値はビットにおける、接頭語の長さの1つの八重奏があとに続いたIPv6接頭語の16の八重奏から成ります。 書式を以下に与えます。 ネットワークバイトオーダーにはIPv6接頭語があります。 接頭語が128ビット、引きずっているビットSHOULDより短いなら、ゼロにセットしてください。 Mappingの例に関してIPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6接頭語| | (16の八重奏) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP IPv4 LSP
3.2.3. RSVP IPv4 LSP
The value has the format below. The value fields are taken from RFC 3209, sections 4.6.1.1 and 4.6.2.1. See [RSVP-TE].
値には、以下の形式があります。 そして、RFC3209、セクション4.6.1から値のグラウンドに出る、.1、4.6 .2 .1。 [RSVP-Te]を見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4トンネルエンドポイントアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張Tunnel ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4トンネル送付者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| LSP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 13] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[13ページ]RFC4379
3.2.4. RSVP IPv6 LSP
3.2.4. RSVP IPv6 LSP
The value has the format below. The value fields are taken from RFC 3209, sections 4.6.1.2 and 4.6.2.2. See [RSVP-TE].
値には、以下の形式があります。 そして、RFC3209、セクション4.6.1から値のグラウンドに出る、.2、4.6 .2 .2。 [RSVP-Te]を見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6トンネルエンドポイントアドレス| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張Tunnel ID| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6トンネル送付者アドレス| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| LSP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. VPN IPv4 Prefix
3.2.5. VPN IPv4接頭語
VPN-IPv4 Network Layer Routing Information (NLRI) is defined in [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN- IPv4 NLRI that has been advertised with an MPLS label in BGP. See [BGP-LABEL].
VPN-IPv4 Network Layer経路情報(NLRI)は[RFC4365]で定義されます。 このドキュメントはMPLSラベルがBGPにある状態で広告に掲載されているVPN- IPv4 NLRIに用語VPN IPv4接頭語を使用します。 [BGP-ラベル]を見てください。
Kompella & Swallow Standards Track [Page 14] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[14ページ]RFC4379
When a VPN IPv4 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and a prefix length, as follows:
VPN IPv4接頭語がラベルスタックでコード化されるとき、以下の形式は使用されています。 値の分野はVPN IPv4接頭語、IPv4接頭語(全部で32ビット作る引きずっている0ビットがある)、および接頭語の長さで広告に掲載されたRoute Distinguisherから成ります、以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルートDistinguisher| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distinguisher (RD) is an 8-octet identifier; it does not contain any inherent information. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. The encoding of the RD is not important here. When matching this field to the local FEC information, it is treated as an opaque value.
Route Distinguisher(RD)は8八重奏の識別子です。 それは少しの固有の情報も含んでいません。 RDの目的は1つが一般的なIPv4アドレス接頭語に異なったルートを作成するのを唯一許容することです。 RDのコード化はここで重要ではありません。 ローカルのFEC情報にこの分野を合わせるとき、それは不透明な値として扱われます。
3.2.6. VPN IPv6 Prefix
3.2.6. VPN IPv6接頭語
VPN-IPv6 Network Layer Routing Information (NLRI) is defined in [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN- IPv6 NLRI that has been advertised with an MPLS label in BGP. See [BGP-LABEL].
VPN-IPv6 Network Layer経路情報(NLRI)は[RFC4365]で定義されます。 このドキュメントはMPLSラベルがBGPにある状態で広告に掲載されているVPN- IPv6 NLRIに用語VPN IPv6接頭語を使用します。 [BGP-ラベル]を見てください。
When a VPN IPv6 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 128 bits in all), and a prefix length, as follows:
VPN IPv6接頭語がラベルスタックでコード化されるとき、以下の形式は使用されています。 値の分野はVPN IPv6接頭語、IPv6接頭語(全部で128ビット作る引きずっている0ビットがある)、および接頭語の長さで広告に掲載されたRoute Distinguisherから成ります、以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルートDistinguisher| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6接頭語| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 15] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[15ページ]RFC4379
The Route Distinguisher is identical to the VPN IPv4 Prefix RD, except that it functions here to allow the creation of distinct routes to IPv6 prefixes. See section 3.2.5. When matching this field to local FEC information, it is treated as an opaque value.
Route DistinguisherはVPN IPv4 Prefix RDと同じです、異なったルートの作成をIPv6接頭語に許容するためにここで機能するのを除いて。 セクション3.2.5を見てください。 ローカルのFEC情報にこの分野を合わせるとき、それは不透明な値として扱われます。
3.2.7. L2 VPN Endpoint
3.2.7. L2 VPN終点
VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI and VE ID (VPLS Edge Identifier) are defined in [VPLS-BGP]. This document uses the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. The Route Distinguisher is an 8-octet identifier used to distinguish information about various L2 VPNs advertised by a node. The VE ID is a 2-octet identifier used to identify a particular node that serves as the service attachment point within a VPLS. The structure of these two identifiers is unimportant here; when matching these fields to local FEC information, they are treated as opaque values. The encapsulation type is identical to the PW Type in section 3.2.8 below.
VPLSはVirtual兵士のLAN Serviceを表します。 用語のVPLS BGP NLRIとVE ID(VPLS Edge Identifier)は[VPLS-BGP]で定義されます。 VPLS BGP NLRIについて言及するとき、このドキュメントは、より簡単な用語L2 VPN終点を使用します。 Route Distinguisherはノードによって広告に掲載された様々なL2 VPNsの情報を区別するのに使用される8八重奏の識別子です。 VE IDはVPLSの中で役立つ特定のノードがサービス付着点であると認識するのに使用される2八重奏の識別子です。 これらの2つの識別子の構造はここで重要ではありません。 ローカルのFEC情報にこれらの分野を合わせるとき、それらは不透明な値として扱われます。 カプセル化タイプはセクション3.2.8未満がPW Typeと同じです。
When an L2 VPN endpoint is encoded in a label stack, the following format is used. The value field consists of a Route Distinguisher (8 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 octets), and an encapsulation type (2 octets), formatted as follows:
L2 VPN終点がラベルスタックでコード化されるとき、以下の形式は使用されています。 送付者(ピングの)は、以下の通りフォーマットされた値の分野がRoute Distinguisher(8つの八重奏)から成って、VE ID(2つの八重奏)と、受信機のVE ID(2つの八重奏)と、カプセル化タイプ(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルートDistinguisher| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のVE ID| 受信機のVE ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | カプセル化タイプ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC 128 Pseudowire (Deprecated)
3.2.8. FEC128Pseudowire(推奨しない)です。
FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values.
FEC128(0×80)は用語のPW ID(Pseudowire ID)とPW Type(Pseudowire Type)のように[PW-CONTROL]で定義されます。 PW IDは非ゼロの32ビットの接続IDです。 PW Typeはカプセル化タイプを示す15ビットの数です。 それは呼ばれたカプセル化タイプの下の分野で高位のビットセットでゼロに正当化された運ばれた権利です。 これらの分野の両方が不透明な値としてこのプロトコルで扱われます。
Kompella & Swallow Standards Track [Page 16] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[16ページ]RFC4379
When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the remote PE address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
FEC128がラベルスタックでコード化されるとき、以下の形式は使用されています。 値の分野は以下のリモートPEアドレス(狙っている自由民主党のセッションの送付先アドレス)、PW ID、およびカプセル化タイプから成ります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモートPEアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWはタイプします。| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward compatibility. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see next section), unless explicitly configured to use the old TLV.
このFECは推奨しなく、後方の互換性のためだけに保有されます。 LSPピングSHOULDの実装は、このTLVを受け入れて、処理しますが、SHOULDは新しいTLVとのピングエコー要求をLSPに送ります(次のセクションを見てください)、古いTLVを使用するために明らかに構成されない場合。
An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the sender's PE address.
このTLV SHOULDを受けるLSRは送付者のPEアドレスを推論するというLSPエコー要求のソースIPアドレスを使用します。
3.2.9. FEC 128 Pseudowire (Current)
3.2.9. FEC128Pseudowire(電流)
FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero.
FEC128(0×80)は用語のPW ID(Pseudowire ID)とPW Type(Pseudowire Type)のように[PW-CONTROL]で定義されます。 PW IDは非ゼロの32ビットの接続IDです。 PW Typeはカプセル化タイプを示す15ビットの数です。 それは呼ばれたカプセル化タイプの下の分野で高位のビットセットでゼロに正当化された運ばれた権利です。
Both of these fields are treated in this protocol as opaque values. When matching these field to the local FEC information, the match MUST be exact.
これらの分野の両方が不透明な値としてこのプロトコルで扱われます。 合っているとき、これらは地方のFECとして情報をさばいて、マッチは正確であるに違いありません。
Kompella & Swallow Standards Track [Page 17] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[17ページ]RFC4379
When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the sender's PE address (the source address of the targeted LDP session), the remote PE address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
FEC128がラベルスタックでコード化されるとき、以下の形式は使用されています。 値の分野は送付者のPEアドレス(狙っている自由民主党のセッションのソースアドレス)から成ります、とリモートPEアドレス(狙っている自由民主党のセッションの送付先アドレス)、PW ID、およびカプセル化は以下の通りタイプします:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のPEアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモートPEアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWはタイプします。| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire
3.2.10. FEC129Pseudowire
FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII), and Target Attachment Individual Identifier (TAII) are defined in [PW-CONTROL]. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below PW Type with the high-order bit set to zero. All the other fields are treated as opaque values and copied directly from the FEC 129 format. All of these values together uniquely define the FEC within the scope of the LDP session identified by the source and remote PE addresses.
用語のFEC129(0×81)、PW Type、Attachment Group Identifier(AGI)、Attachment Group Identifier Type(AGI Type)、Attachment Individual Identifier Type(AII Type)、Source Attachment Individual Identifier(SAII)、およびTarget Attachment Individual Identifier(TAII)は[PW-CONTROL]で定義されます。 PW Typeはカプセル化タイプを示す15ビットの数です。 それはPW Typeの下の分野で高位のビットセットでゼロに正当化された運ばれた権利です。 他のすべての分野が、不透明な値として扱われて、直接FEC129形式からコピーされます。 一緒にこれらの値のすべてがソースとリモートPEアドレスによって特定された自由民主党のセッションの範囲の中で唯一FECを定義します。
Kompella & Swallow Standards Track [Page 18] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[18ページ]RFC4379
When an FEC 129 is encoded in a label stack, the following format is used. The Length of this TLV is 16 + AGI length + SAII length + TAII length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field.
FEC129がラベルスタックでコード化されるとき、以下の形式は使用されています。 このTLVのLengthは16+AGI長さ+SAII長さ+TAIIの長さです。 詰め物は全長を4の倍数にするのに使用されます。 詰め物の長さはLength分野に含まれていません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のPEアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモートPEアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWはタイプします。| AGIはタイプします。| AGIの長さ| +++++++++++++++++++++++++++++++++~AGI価値~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIIはタイプします。| SAIIの長さ| SAII値| +++++++++++++++++++++++++++++++++~SAII価値(続けられている)の~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIIはタイプします。| TAIIの長さ| TAII値| 値..続ける| TAII(cont。) | 0-3 水増しでないのの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix
3.2.11. IPv4接頭語とラベルされたBGP
BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP labeled IPv4 prefix is encoded in a label stack, the following format is used. The value field consists the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and the prefix length, as follows:
IPv4接頭語とラベルされたBGPは[BGP-LABEL]で定義されます。 IPv4接頭語とラベルされたBGPがラベルスタックでコード化されるとき、以下の形式は使用されています。 値の分野が成る、IPv4接頭語(全部で32ビット作る引きずっている0ビットがある)、および接頭語の長さ、以下の通り:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 19] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[19ページ]RFC4379
3.2.12. BGP Labeled IPv6 Prefix
3.2.12. IPv6接頭語とラベルされたBGP
BGP labeled IPv6 prefixes are defined in [BGP-LABEL]. When a BGP labeled IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero.
IPv6接頭語とラベルされたBGPは[BGP-LABEL]で定義されます。 IPv6接頭語とラベルされたBGPがラベルスタックでコード化されるとき、以下の形式は使用されています。 値はビットにおける、接頭語の長さの1つの八重奏があとに続いたIPv6接頭語の16の八重奏から成ります。 書式を以下に与えます。 ネットワークバイトオーダーにはIPv6接頭語があります。 接頭語が128ビット、引きずっているビットSHOULDより短いなら、ゼロにセットしてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6接頭語| | (16の八重奏) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. Generic IPv4 Prefix
3.2.13. ジェネリックIPv4接頭語
The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero. This FEC is used if the protocol advertising the label is unknown or may change during the course of the LSP. An example is an inter-AS LSP that may be signaled by LDP in one Autonomous System (AS), by RSVP-TE [RSVP-TE] in another AS, and by BGP between the ASes, such as is common for inter-AS VPNs.
値はビットにおける、接頭語の長さの1つの八重奏があとに続いたIPv4接頭語の4つの八重奏から成ります。 書式を以下に与えます。 ネットワークバイトオーダーにはIPv4接頭語があります。 接頭語が32ビット、引きずっているビットSHOULDより短いなら、ゼロにセットしてください。 ラベルの広告を出すプロトコルが未知である、またはLSPのコースの間、変化するかもしれないなら、このFECは使用されています。 例は1Autonomous System(AS)の自由民主党、別のASのRSVP-TE[RSVP-TE]、および相互AS VPNsに、一般的なASesの間のBGPによって合図されるかもしれない相互AS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 20] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[20ページ]RFC4379
3.2.14. Generic IPv6 Prefix
3.2.14. ジェネリックIPv6接頭語
The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero.
値はビットにおける、接頭語の長さの1つの八重奏があとに続いたIPv6接頭語の16の八重奏から成ります。 書式を以下に与えます。 ネットワークバイトオーダーにはIPv6接頭語があります。 接頭語が128ビット、引きずっているビットSHOULDより短いなら、ゼロにセットしてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6接頭語| | (16の八重奏) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.15. Nil FEC
3.2.15. 無いFEC
At times, labels from the reserved range, e.g., Router Alert and Explicit-null, may be added to the label stack for various diagnostic purposes such as influencing load-balancing. These labels may have no explicit FEC associated with them. The Nil FEC Stack is defined to allow a Target FEC Stack sub-TLV to be added to the Target FEC Stack to account for such labels so that proper validation can still be performed.
時には、予約された範囲からのラベル(例えば、Router AlertとExplicit-ヌル)は、ロードバランシングに影響を及ぼすことなどの様々な診断目的のためにラベルスタックに加えられるかもしれません。 これらのラベルには、それらに関連しているどんな明白なFECもないかもしれません。 Nil FEC Stackは、Target FEC StackサブTLVがまだ適切な合法化を実行できるようにそのようなラベルの原因になるようにTarget FEC Stackに加えられるのを許容するために定義されます。
The Length is 4. Labels are 20-bit values treated as numbers.
Lengthは4歳です。 ラベルは数として扱われた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 | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| MBZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label is the actual label value inserted in the label stack; the MBZ fields MUST be zero when sent and ignored on receipt.
ラベルはラベルスタックに挿入された実際のラベル値です。 領収書の上で送られて、無視されると、MBZ分野はゼロであるに違いありません。
Kompella & Swallow Standards Track [Page 21] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[21ページ]RFC4379
3.3. Downstream Mapping
3.3. 川下のマッピング
The Downstream Mapping object is a TLV that MAY be included in an echo request message. Only one Downstream Mapping object may appear in an echo request. The presence of a Downstream Mapping object is a request that Downstream Mapping objects be included in the echo reply. If the replying router is the destination of the FEC, then a Downstream Mapping TLV SHOULD NOT be included in the echo reply. Otherwise the replying router SHOULD include a Downstream Mapping object for each interface over which this FEC could be forwarded. For a more precise definition of the notion of "downstream", see section 3.3.2, "Downstream Router and Interface".
Downstream Mappingオブジェクトはエコー要求メッセージに含まれるかもしれないTLVです。 1個のDownstream Mappingオブジェクトだけがエコー要求に現れるかもしれません。 Downstream Mappingオブジェクトの存在はDownstream Mappingオブジェクトがエコー・リプライに含まれているという要求です。 返答ルータであるなら、含まれているコネがエコー・リプライであったなら、FEC、当時のa Downstream Mapping TLV SHOULDの目的地はNOTですか? さもなければ、返答ルータSHOULDはこのFECを送ることができた各インタフェースへのDownstream Mappingオブジェクトを含んでいます。 「川下」の概念の、より正確な定義に関しては、3.3の.2と、「川下のルータとインタフェース」というセクションを見てください。
The Length is K + M + 4*N octets, where M is the Multipath Length, and N is the number of Downstream Labels. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format:
LengthはK+M+4つの*N八重奏です、MがMultipath Lengthであり、NがDownstream Labelsの数であるところで。 Kのための値は以下のAddress Typeの記述で見つけられます。 Downstream MappingのValue分野には、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU| アドレスタイプ| DS旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 川下のIP Address(4か16の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 川下のInterface Address(4か16の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 多重通路タイプ| 深さ限界| 多重通路の長さ| 多重通路..情報| 川下のラベル| プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 川下のラベル| プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit (MTU)
マキシマム・トランスミッション・ユニット(MTU)
The MTU is the size in octets of the largest MPLS frame (including
label stack) that fits on the interface to the Downstream LSR.
MTUはインタフェースでDownstream LSRに合う最も大きいMPLSフレーム(ラベルスタックを含んでいる)の八重奏でサイズです。
Kompella & Swallow Standards Track [Page 22] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[22ページ]RFC4379
Address Type
アドレスタイプ
The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the Downstream IP
Address and Downstream Interface fields. The resulting total for
the initial part of the TLV is listed in the table below as "K
Octets". The Address Type is set to one of the following values:
Address Typeは、インタフェースが番号付である、または無数であるかを示します。 また、それはDownstream IP AddressとDownstream Interface分野の長さを測定します。 TLVの初期の部分への結果として起こる合計は「K八重奏」として以下のテーブルに記載されています。 Address Typeは以下の値の1つに用意ができています:
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
#アドレスタイプK八重奏をタイプしてください。------ ------------ -------- 1 IPv4は無数の16のIPv6番号付の40 4 2IPv4 16 3IPv6無数の28に付番しました。
DS Flags
DS旗
The DS Flags field is a bit vector with the following format:
DS Flags分野は少し、以下があるベクトルが以下をフォーマットするということです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd(MBZ)|I|N| +-+-+-+-+-+-+-+-+
Two flags are defined currently, I and N. The remaining flags
MUST be set to zero when sending and ignored on receipt.
2個の旗が現在定義されて、N. 私と残っている旗は発信するとき、ゼロに用意ができて、領収書の上で無視しなければなりません。
Flag Name and Meaning
---- ----------------
旗の名と意味---- ----------------
I Interface and Label Stack Object Request
Iインターフェースとラベルスタックオブジェクト要求
When this flag is set, it indicates that the replying
router SHOULD include an Interface and Label Stack
Object in the echo reply message.
この旗が設定されるとき、それは、返答ルータSHOULDがエコー応答メッセージにInterfaceとLabel Stack Objectを含んでいるのを示します。
N Treat as a Non-IP Packet
Nは非IPパケットとして扱われます。
Echo request messages will be used to diagnose non-IP
flows. However, these messages are carried in IP
packets. For a router that alters its ECMP algorithm
based on the FEC or deep packet examination, this flag
requests that the router treat this as it would if the
determination of an IP payload had failed.
エコー要求メッセージは、非IP流れを診断するのに使用されるでしょう。 しかしながら、これらのメッセージはIPパケットで伝えられます。 FECに基づくECMPアルゴリズムか深いパケット試験、この旗を変更するルータのために、IPペイロードの決断が失敗したなら、ルータがそれとしてこれを扱うという要求はそうするでしょう。
Kompella & Swallow Standards Track [Page 23] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[23ページ]RFC4379
Downstream IP Address and Downstream Interface Address
川下のIPアドレスと川下のインターフェース・アドレス
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets.
IPv4アドレスとインタフェースインデックスリストは4つの八重奏でコード化されます。 IPv6アドレスは16の八重奏でコード化されます。
If the interface to the downstream LSR is numbered, then the
Address Type MUST be set to IPv4 or IPv6, the Downstream IP
Address MUST be set to either the downstream LSR's Router ID or
the interface address of the downstream LSR, and the Downstream
Interface Address MUST be set to the downstream LSR's interface
address.
川下のLSRへのインタフェースが番号付であるなら、Address TypeはIPv4かIPv6に用意ができなければなりません、そして、Downstream IP Addressは川下のLSRの川下のLSRのRouter IDかインターフェース・アドレスのどちらかに用意ができなければなりません、そして、Downstream Interface Addressは川下のLSRのインターフェース・アドレスに用意ができなければなりません。
If the interface to the downstream LSR is unnumbered, the Address
Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP
Address MUST be the downstream LSR's Router ID, and the Downstream
Interface Address MUST be set to the index assigned by the
upstream LSR to the interface.
川下のLSRへのインタフェースが無数であるなら、Address TypeはIPv4 UnnumberedかIPv6 Unnumberedであるに違いありません、そして、Downstream IP Addressは川下のLSRのRouter IDであるに違いありません、そして、Downstream Interface Addressは上流のLSRによってインタフェースに割り当てられたインデックスに用意ができなければなりません。
If an LSR does not know the IP address of its neighbor, then it
MUST set the Address Type to either IPv4 Unnumbered or IPv6
Unnumbered. For IPv4, it must set the Downstream IP Address to
127.0.0.1; for IPv6 the address is set to 0::1. In both cases,
the interface index MUST be set to 0. If an LSR receives an Echo
Request packet with either of these addresses in the Downstream IP
Address field, this indicates that it MUST bypass interface
verification but continue with label validation.
LSRが隣人のIPアドレスを知らないなら、それはIPv4 UnnumberedかIPv6 UnnumberedのどちらかにAddress Typeを設定しなければなりません。 IPv4のために、Downstream IP Addressを127.0に設定しなければならない、.0、.1。 IPv6に関しては、アドレスは0に以下を設定することです:1. どちらの場合も、インタフェースインデックスを0に設定しなければなりません。 LSRがDownstream IP Address分野でこれらのアドレスのどちらかでEcho Requestパケットを受けるなら、これは、インターフェース検査を迂回させますが、ラベル合法化を続行しなければならないのを示します。
If the originator of an Echo Request packet wishes to obtain
Downstream Mapping information but does not know the expected
label stack, then it SHOULD set the Address Type to either IPv4
Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the
Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be
set to FF02::2. In both cases, the interface index MUST be set to
0. If an LSR receives an Echo Request packet with the all-routers
multicast address, then this indicates that it MUST bypass both
interface and label stack validation, but return Downstream
Mapping TLVs using the information provided.
Echo Requestパケットの生成元がDownstream Mapping情報を得ることを願っていますが、予想されたラベルスタックを知らないで、次に、それがSHOULDセットのIPv4 UnnumberedへのAddress TypeかIPv6 Unnumberedであるなら。 IPv4のために、Downstream IP Addressを224.0に設定しなければならない、.0、.2。 IPv6に関しては、アドレスはFF02に以下を設定することであるに違いありません:2. どちらの場合も、インタフェースインデックスを0に設定しなければなりません。 LSRがオールルータマルチキャストアドレスでEcho Requestパケットを受けるなら、これは、インタフェースとラベルスタック合法化の両方を迂回させなければならないのを示しますが、情報を使用するリターンDownstream Mapping TLVsが提供しました。
Kompella & Swallow Standards Track [Page 24] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[24ページ]RFC4379
Multipath Type
多重通路タイプ
The following Multipath Types are defined:
以下のMultipath Typesは定義されます:
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
主要なタイプ多重通路情報--- ---------------- --------------------- 0 Empty(多重通路Length=0)2IPアドレスIPが8Bit仮面のIP IPアドレス接頭語と噛み付いているマスクアドレスセット9のBit仮面のラベル・セットLabel接頭語とビットがマスクをかける4IPアドレス範囲安値/高値アドレス組に演説する多重通路がありません。
Type 0 indicates that all packets will be forwarded out this one
interface.
タイプ0は、すべてのパケットがこの1つのインタフェースから進められるのを示します。
Types 2, 4, 8, and 9 specify that the supplied Multipath
Information will serve to exercise this path.
タイプ2、4、8、および9は、供給されたMultipath情報が、この経路を運動させるのに役立つと指定します。
Depth Limit
深さ限界
The Depth Limit is applicable only to a label stack and is the
maximum number of labels considered in the hash; this SHOULD be
set to zero if unspecified or unlimited.
Depth Limitはラベルスタックだけに適切であり、ハッシュで考えられたラベルの最大数です。 このSHOULD、不特定であるか、または無制限であるなら、ゼロに設定されてください。
Multipath Length
多重通路の長さ
The length in octets of the Multipath Information.
Multipath情報の八重奏における長さ。
Multipath Information
多重通路情報
Address or label values encoded according to the Multipath Type.
See the next section below for encoding details.
Multipath Typeによると、コード化された値を、扱うか、またはラベルしてください。 詳細をコード化するために下の次のセクションを見てください。
Downstream Label(s)
川下のラベル(s)
The set of labels in the label stack as it would have appeared if
this router were forwarding the packet through this interface.
Any Implicit Null labels are explicitly included. Labels are
treated as numbers, i.e., they are right justified in the field.
このルータがこのインタフェースを通してパケットを送っていたなら、それとしてのラベルスタックのラベルのセットは現れたでしょう。 どんなImplicit Nullラベルも明らかに含まれています。 ラベルは数として扱われます、すなわち、それらがその分野でまさしく正当です。
A Downstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the
LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S
bit. The replying router SHOULD fill in the EXP and S bits; the
LSR receiving the echo reply MAY choose to ignore these bits.
Downstream Labelは24ビットです、そして、TTL分野を引いたMPLSラベルと同じ形式において、すなわち、ラベルのMSBitはビット0です、そして、LSBitはビット19です、そして、EXPビットはビット20-22です、そして、ビット23はSビットです。 返答ルータSHOULDはEXPとSビットに記入します。 エコー・リプライを受けるLSRは、これらのビットを無視するのを選ぶかもしれません。
Kompella & Swallow Standards Track [Page 25] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[25ページ]RFC4379
Protocol
プロトコル
The Protocol is taken from the following table:
以下のテーブルからプロトコルを取ります:
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
プロトコル#シグナリングプロトコル---------- ------------------ 0 1未知の静的な2BGP3の自由民主党4RSVP-Te
3.3.1. Multipath Information Encoding
3.3.1. 多重通路情報コード化
The Multipath Information encodes labels or addresses that will exercise this path. The Multipath Information depends on the Multipath Type. The contents of the field are shown in the table above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses are drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated as numbers, i.e., they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence.
Multipath情報はこの経路を運動させるラベルかアドレスをコード化します。 Multipath情報はMultipath Typeによります。 分野の内容は上のテーブルに示されます。 範囲127/8からIPv4アドレスを得ます。 範囲からIPv6アドレスを得る、0:0:0 0:0::FFFF、: 127/104 ラベルは数として扱われます、すなわち、それらがその分野でまさしく正当です。 Type4に関しては、Address組によって示された範囲は、重なってはいけなくて、昇順にあるに違いありません。
Type 8 allows a more dense encoding of IP addresses. The IP prefix is formatted as a base IP address with the non-prefix low-order bits set to zero. The maximum prefix length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits for IPv4 and 2^(128- prefix length) bits for IPv6. Each bit set to 1 represents a valid address. The address is the base IPv4 address plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. For example, the IPv4 addresses 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded as follows:
タイプ8はIPアドレスの、より濃いコード化を許します。 非接頭語下位のビットがあるベースIPアドレスがゼロにセットしたので、IP接頭語はフォーマットされます。 最大の接頭語の長さは27です。 接頭語に従うのは、IPv4のための2^(32接頭語の長さ)ビットとIPv6のための2^(128接頭語の長さ)ビットの長さのマスクです。 1に設定された各ビットは有効なアドレスを表します。 アドレスは、ビットが左でゼロで正しい始めまで付番されるマスクのビットのベースIPv4アドレスと位置です。 例えば、IPv4が扱う、127.2、.1、.0、127.2.1.5-127.2 .1 .15、および127.2.1.20-127.2 .1 .29は以下の通りコード化されるでしょう:
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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 26] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[26ページ]RFC4379
Those same addresses embedded in IPv6 would be encoded as follows:
IPv6に埋め込まれたそれらの同じアドレスは以下の通りコード化されるでしょう:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 allows a more dense encoding of labels. The label prefix is formatted as a base label value with the non-prefix low-order bits set to zero. The maximum prefix (including leading zeros due to encoding) length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits. Each bit set to one represents a valid label. The label is the base label plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. Label values of all the odd numbers between 1152 and 1279 would be encoded as follows:
タイプ9はラベルの、より濃いコード化を許します。 非接頭語下位のビットがあるベースラベル価値がゼロにセットしたので、ラベル接頭語はフォーマットされます。 最大の接頭語(コード化のため先行ゼロを含んでいる)の長さは27です。 接頭語に従うのは、長さの2^(32接頭語の長さ)ビットのマスクです。 1つに設定された各ビットは有効なラベルを表します。 ラベルは、ビットが左でゼロで正しい始めまで付番されるマスクのビットのベースラベルと位置です。 1152年と1279年の間ときのすべての奇数のラベル値は以下の通りコード化されるでしょう:
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
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the received Multipath Information is non-null, the labels and IP addresses MUST be picked from the set provided. If none of these labels or addresses map to a particular downstream interface, then for that interface, the type MUST be set to 0. If the received Multipath Information is null (i.e., Multipath Length = 0, or for Types 8 and 9, a mask of all zeros), the type MUST be set to 0.
受信されたMultipath情報が非ヌルであるなら、セットからアドレスを選ばなければならないラベルとIPは提供されました。 これらのいずれも特定の川下のインタフェースに地図を分類するか、または扱わないなら、そのインタフェースにおいて、タイプは0に用意ができなければなりません。 受信されたMultipath情報がヌルであるなら(すなわち、Multipath Lengthは0と等しい、またはTypes8と9のためにそうします、すべてのゼロのマスク)、タイプは0に用意ができなければなりません。
Kompella & Swallow Standards Track [Page 27] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[27ページ]RFC4379
For example, suppose LSR X at hop 10 has two downstream LSRs, Y and Z, for the FEC in question. The received X could return Multipath Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for downstream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. The head end reflects this information to LSR Y. Y, which has three downstream LSRs, U, V, and W, computes that 127.1.1.1->127.1.1.127 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would then respond with 3 Downstream Mappings: to U, with Multipath Type 4 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0.
例えば、問題のFECのためにホップ10のLSR Xには2川下LSRs、Y、およびZがあると仮定してください。 容認されたXはMultipath Type4を返すことができました、127.1.1.1->の低いか高いIPアドレスで127.1、.1、.255、川下のLSR Yと127.2.1.1->、127.2、.1、.255、U(V、およびW)が川下のLSR Z.に関して、ギヤエンドが3川下LSRsを持っているLSR Y.Yにこの情報を反映して、その127.1.1.1->を計算する、127.1、.1、.127、Uと127.1.1.128->に行くだろう、127.1、.1、.255、次にYが3Downstream Mappingsと共に反応させるV.に行くでしょう: 多重通路タイプ4があるU、(127.1.1.1>127.1.1、.127)。 多重通路タイプ4があるV、(127.1.1.127>127.1.1、.255)。 そして、多重通路で、Wに、0をタイプしてください。
Note that computing Multipath Information may impose a significant processing burden on the receiver. A receiver MAY thus choose to process a subset of the received prefixes. The sender, on receiving a reply to a Downstream Mapping with partial information, SHOULD assume that the prefixes missing in the reply were skipped by the receiver, and MAY re-request information about them in a new echo request.
Multipath情報を計算すると重要な処理負担が受信機につけ込むかもしれないことに注意してください。その結果、受信機は、容認された接頭語の部分集合を処理するのを選んでもよいです。 送付者、部分的な情報で回答をDownstream Mappingに受け取るとき、SHOULDは回答でなくなった接頭語が受信機によってスキップされて、新しいエコー要求でそれらの情報を再要求するかもしれないと仮定します。
3.3.2. Downstream Router and Interface
3.3.2. 川下のルータとインタフェース
The notion of "downstream router" and "downstream interface" should be explained. Consider an LSR X. If a packet that was originated with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X must be able to compute which LSRs could receive the packet if it was originated with TTL=n+1, over which interface the request would arrive and what label stack those LSRs would see. (It is outside the scope of this document to specify how this computation is done.) The set of these LSRs/interfaces consists of the downstream routers/interfaces (and their corresponding labels) for X with respect to L. Each pair of downstream router and interface requires a separate Downstream Mapping to be added to the reply.
「川下のルータ」と「川下のインタフェース」の概念は説明されるべきです。 LSR X.Ifが一番はずれのラベルLと共に届いたTTL n>1とLSR XのTTL=1と共に溯源されたパケットであると考えてください、そして、XはそれがTTL=n+1と共に溯源されるならどのLSRsがパケットを受けることができるか、そして、要求がどのインタフェースの上で到着するだろうか、そして、それらのLSRsが見るスタックをラベルすることを計算できなければなりません。 (この計算がどのように完了しているかを指定するために、このドキュメントの範囲の外にそれはあります。) これらのLSRs/インタフェースのセットは川下のルータのL.Each組に関してXのための川下のルータ/インタフェース(そして、それらの対応するラベル)から成ります、そして、インタフェースは別々のDownstream Mappingが回答に加えられるのを必要とします。
The case where X is the LSR originating the echo request is a special case. X needs to figure out what LSRs would receive the MPLS echo request for a given FEC Stack that X originates with TTL=1.
Xがエコー要求を溯源するLSRであるケースは特別なケースです。 LSRsが理解することを理解するXの必要性は与えられたFEC Stackを求めるXがTTL=1を発するというMPLSエコー要求を受け取ります。
The set of downstream routers at X may be alternative paths (see the discussion below on ECMP) or simultaneous paths (e.g., for MPLS multicast). In the former case, the Multipath Information is used as a hint to the sender as to how it may influence the choice of these alternatives.
Xの川下のルータのセットは、迂回経路(以下でのECMPについての議論を見る)か同時の経路であるかもしれません(例えば、MPLSマルチキャストのための)。 前の場合では、それがどうこれらの代替手段の選択に影響を及ぼすかもしれないかに関してMultipath情報はヒントとして送付者に使用されます。
Kompella & Swallow Standards Track [Page 28] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[28ページ]RFC4379
3.4. Pad TLV
3.4. パッドTLV
The value part of the Pad TLV contains a variable number (>= 1) of octets. The first octet takes values from the following table; all the other octets (if any) are ignored. The receiver SHOULD verify that the TLV is received in its entirety, but otherwise ignores the contents of this TLV, apart from the first octet.
Pad TLVの値の部は可変数(>=1)の八重奏を含んでいます。 最初の八重奏は以下のテーブルから値を取ります。 他のすべての八重奏(もしあれば)が無視されます。 受信機SHOULDは、TLVが全体として受け取りますが、別の方法でこのTLVのコンテンツを無視することを確かめます、最初の八重奏は別として。
Value Meaning
----- -------
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-255 Reserved for future use
値の意味----- ------- 1 今後の使用のための回答2Copy Pad TLVから回答3-255Reservedまでの低下Pad TLV
3.5. Vendor Enterprise Number
3.5. ベンダーエンタープライズ番号
SMI Private Enterprise Numbers are maintained by IANA. The Length is always 4; the value is the SMI Private Enterprise code, in network octet order, of the vendor with a Vendor Private extension to any of the fields in the fixed part of the message, in which case this TLV MUST be present. If none of the fields in the fixed part of the message have Vendor Private extensions, inclusion of this TLV is OPTIONAL. Vendor Private ranges for Message Types, Reply Modes, and Return Codes have been defined. When any of these are used, the Vendor Enterprise Number TLV MUST be included in the message.
SMI兵士のエンタープライズ民数記はIANAによって維持されます。 いつもLengthは4歳です。 値はSMI兵士のエンタープライズコードです、その場合、メッセージ、このTLV MUSTの固定部分の分野のどれかへのVendor兵士の拡張子があるベンダーのネットワーク八重奏命令で。存在してください。 メッセージの固定部分の分野のいずれにもVendor兵士の拡張子がないなら、このTLVの包含はOPTIONALです。 Message Types、Reply Modes、およびReturn Codesのためのベンダー兵士の範囲は定義されました。 これらのどれかが使用されているとき、メッセージにVendorエンタープライズNumber TLVを含まなければなりません。
3.6. Interface and Label Stack
3.6. スタックを連結して、ラベルしてください。
The Interface and Label Stack TLV MAY be included in a reply message to report the interface on which the request message was received and the label stack that was on the packet when it was received. Only one such object may appear. The purpose of the object is to allow the upstream router to obtain the exact interface and label stack information as it appears at the replying LSR.
InterfaceとLabel Stack TLVは要求メッセージが受け取られたインタフェースとそれを受け取ったときパケットの上にあったラベルスタックを報告する応答メッセージに含まれるかもしれません。 そのようなオブジェクトの1つだけが現れるかもしれません。 オブジェクトの目的は返答しているLSRに現れるように上流のルータが正確なインタフェースとラベルスタック情報を得るのを許容することです。
Kompella & Swallow Standards Track [Page 29] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[29ページ]RFC4379
The Length is K + 4*N octets; N is the number of labels in the label stack. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format:
LengthはK+4つの*N八重奏です。 Nはラベルスタックのラベルの数です。 Kのための値は以下のAddress Typeの記述で見つけられます。 Downstream MappingのValue分野には、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスタイプ| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address(4か16の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (4か16の八重奏)を連結してください。| ラベル..スタック
Address Type
アドレスタイプ
The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the IP Address and
Interface fields. The resulting total for the initial part of the
TLV is listed in the table below as "K Octets". The Address Type
is set to one of the following values:
Address Typeは、インタフェースが番号付である、または無数であるかを示します。 また、それはIP AddressとInterface分野の長さを測定します。 TLVの初期の部分への結果として起こる合計は「K八重奏」として以下のテーブルに記載されています。 Address Typeは以下の値の1つに用意ができています:
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
#アドレスタイプK八重奏をタイプしてください。------ ------------ -------- 1 IPv4は無数の12のIPv6番号付の36 4 2IPv4 12 3IPv6無数の24に付番しました。
IP Address and Interface
IPアドレスとインタフェース
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets.
IPv4アドレスとインタフェースインデックスリストは4つの八重奏でコード化されます。 IPv6アドレスは16の八重奏でコード化されます。
If the interface upon which the echo request message was received
is numbered, then the Address Type MUST be set to IPv4 or IPv6,
the IP Address MUST be set to either the LSR's Router ID or the
interface address, and the Interface MUST be set to the interface
address.
エコー要求メッセージが受け取られたインタフェースが番号付であるなら、Address TypeはIPv4かIPv6に用意ができなければなりません、そして、IP AddressはLSRのRouter IDかインターフェース・アドレスのどちらかに用意ができなければなりません、そして、Interfaceはインターフェース・アドレスに用意ができなければなりません。
Kompella & Swallow Standards Track [Page 30] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[30ページ]RFC4379
If the interface is unnumbered, the Address Type MUST be either
IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the
LSR's Router ID, and the Interface MUST be set to the index
assigned to the interface.
インタフェースが無数であるなら、Address TypeはIPv4 UnnumberedかIPv6 Unnumberedのどちらかであるに違いありません、そして、IP AddressはLSRのRouter IDであるに違いありません、そして、Interfaceはインタフェースに割り当てられたインデックスに用意ができなければなりません。
Label Stack
ラベルスタック
The label stack of the received echo request message. If any TTL
values have been changed by this router, they SHOULD be restored.
受信されたエコー要求メッセージのラベルスタック。 いずれかであるならこのルータでTTL値を変えて、それらはSHOULDです。回復します。
3.7. Errored TLVs
3.7. Errored TLVs
The following TLV is a TLV that MAY be included in an echo reply to inform the sender of an echo request of mandatory TLVs either not supported by an implementation or parsed and found to be in error.
以下のTLVは間違っているのが実現で支持されなかった義務的なTLVsに関するエコー要求について送付者に知らせるためにエコー・リプライに含まれているか、分析されて、またはわかるかもしれないTLVです。
The Value field contains the TLVs that were not understood, encoded as sub-TLVs.
Value分野はサブTLVsとしてコード化されて、理解されていなかったTLVsを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =9をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値| . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Reply TOS Byte TLV
3.8. 回答TOSバイトTLV
This TLV MAY be used by the originator of the echo request to request that an echo reply be sent with the IP header TOS byte set to the value specified in the TLV. This TLV has a length of 4 with the following value field.
このTLV MAY、エコー・リプライがTLVで指定された値に設定されたIPヘッダーTOSバイトと共に送られるよう要求するというエコー要求の創始者によって使用されてください。 このTLVには、4の長さが以下の値の分野と共にあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 回答-TOSバイト| ゼロでなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kompella & Swallow Standards Track [Page 31] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[31ページ]RFC4379
4. Theory of Operation
4. 動作理論
An MPLS echo request is used to test a particular LSP. The LSP to be tested is identified by the "FEC Stack"; for example, if the LSP was set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC Stack contains a single element, namely, an LDP IPv4 prefix sub-TLV with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the FEC Stack consists of a single element that captures the RSVP Session and Sender Template that uniquely identifies the LSP.
MPLSエコー要求は、特定のLSPをテストするのに使用されます。 テストされるべきLSPは「FECスタック」によって特定されます。 例えば、LSPがそうであったなら自由民主党を通してセットアップしてください、そして、IPアドレスは出口への10.1のものです。.1 .1 すなわち、FEC Stackはただ一つの要素に値10.1の.1がある自由民主党IPv4接頭語サブTLV.1/32を含んでいます。 テストされるLSPがRSVP LSPであるなら、FEC StackはRSVP Sessionを捕らえるただ一つの要素と唯一LSPを特定するSender Templateから成ります。
FEC Stacks can be more complex. For example, one may wish to test a VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with egress 10.10.1.1. The FEC Stack would then contain two sub-TLVs, the bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. If the underlying (LDP) tunnel were not known, or was considered irrelevant, the FEC Stack could be a single element with just the VPN IPv4 sub-TLV.
FEC Stacksは、より複雑である場合があります。 例えば、出口があるLDP LSPの上でトンネルを堀られる10.1/8のVPN IPv4接頭語をテストしたがっているかもしれない、10.10、.1、.1 そして、FEC Stackは2サブTLVs、VPN IPv4接頭語である下部、および自由民主党IPv4接頭語である先端を含んでいるでしょう。 基本的な(自由民主党)トンネルが知られていなかったか、または無関係であると考えられるなら、FEC StackはまさしくVPN IPv4がサブTLVであるただ一つの要素であるかもしれないでしょうに。
When an MPLS echo request is received, the receiver is expected to verify that the control plane and data plane are both healthy (for the FEC Stack being pinged) and that the two planes are in sync. The procedures for this are in section 4.4 below.
MPLSエコー要求が受信されているとき、受信機が制御飛行機とデータ飛行機がともに健康であり(確認されるFEC Stackのための)、同時性には2機の飛行機があることを確かめると予想されます。 これのための手順が下のセクション4.4にあります。
4.1. Dealing with Equal-Cost Multi-Path (ECMP)
4.1. 等しい費用マルチ経路に対処します。(ECMP)
LSPs need not be simple point-to-point tunnels. Frequently, a single LSP may originate at several ingresses, and terminate at several egresses; this is very common with LDP LSPs. LSPs for a given FEC may also have multiple "next hops" at transit LSRs. At an ingress, there may also be several different LSPs to choose from to get to the desired endpoint. Finally, LSPs may have backup paths, detour paths, and other alternative paths to take should the primary LSP go down.
LSPsは簡単な二地点間トンネルである必要はありません。 独身のLSPは頻繁に、いくつかの進入で由来して、いくつかの出口で終わるかもしれません。 これは自由民主党LSPsについて非常に一般的です。 また、与えられたFECのためのLSPsはトランジットLSRsに複数の「次のホップ」を持っているかもしれません。 また、イングレスには、選ぶ数個の異なったLSPsがあるかもしれない、必要な終点に着くように。 最終的に、LSPsにはバックアップ道、回り道経路があるかもしれません、そして、取る他の迂回経路はLSPが下る予備選挙を持つべきです。
To deal with the last two first: it is assumed that the LSR sourcing MPLS echo requests can force the echo request into any desired LSP, so choosing among multiple LSPs at the ingress is not an issue. The problem of probing the various flavors of backup paths that will typically not be used for forwarding data unless the primary LSP is down will not be addressed here.
2/1に最終に対処するために: 複数のLSPsの中でイングレスで選ぶのが、問題でなくLSRソーシングMPLSエコー要求がどんな必要なLSPにもエコー要求を力づくで押すことができると思われます。 第一のLSPが下がっていない場合推進データに通常使用されないバックアップ道の様々な特色を調べるという問題はここに記述されないでしょう。
Since the actual LSP and path that a given packet may take may not be known a priori, it is useful if MPLS echo requests can exercise all possible paths. This, although desirable, may not be practical, because the algorithms that a given LSR uses to distribute packets over alternative paths may be proprietary.
与えられたパケットが取るかもしれない実際のLSPと経路が先験的に知られていないかもしれないので、MPLSエコー要求がすべての可能な経路を運動させることができるなら、役に立ちます。 望ましいのですが、これは実用的でないかもしれません、与えられたLSRが迂回経路の上にパケットを分配するのに使用するアルゴリズムが独占であるかもしれないので。
To achieve some degree of coverage of alternate paths, there is a certain latitude in choosing the destination IP address and source
代替パスのいくらかの適用範囲を達成するために、送付先IPアドレスとソースを選ぶのにおいて、ある緯度があります。
Kompella & Swallow Standards Track [Page 32] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[32ページ]RFC4379
UDP port for an MPLS echo request. This is clearly not sufficient; in the case of traceroute, more latitude is offered by means of the Multipath Information of the Downstream Mapping TLV. This is used as follows. An ingress LSR periodically sends an MPLS traceroute message to determine whether there are multipaths for a given LSP. If so, each hop will provide some information how each of its downstream paths can be exercised. The ingress can then send MPLS echo requests that exercise these paths. If several transit LSRs have ECMP, the ingress may attempt to compose these to exercise all possible paths. However, full coverage may not be possible.
MPLSエコー要求のためのUDPポート。 これは明確に十分ではありません。 トレースルートの場合では、Downstream Mapping TLVに関するMultipath情報によってより多くの緯度を提供します。 これは以下の通り使用されます。 LSRが定期的に与えられたLSPのために多重通路があるかどうか決定するMPLSトレースルートメッセージを送るイングレス。 そうだとすれば、各ホップはどうしたらそれぞれの川下の経路を運動させることができるかという何らかの情報を提供するでしょう。 そして、イングレスは運動するMPLSエコー要求にこれらの経路を送ることができます。 数個トランジットLSRsにECMPがあるなら、イングレスは、すべての可能な経路を運動させるためにこれらを構成するのを試みるかもしれません。 しかしながら、完全適用範囲は可能でないかもしれません。
4.2. Testing LSPs That Are Used to Carry MPLS Payloads
4.2. MPLS有効搭載量を運ぶのに使用されるテストLSPs
To detect certain LSP breakages, it may be necessary to encapsulate an MPLS echo request packet with at least one additional label when testing LSPs that are used to carry MPLS payloads (such as LSPs used to carry L2VPN and L3VPN traffic. For example, when testing LDP or RSVP-TE LSPs, just sending an MPLS echo request packet may not detect instances where the router immediately upstream of the destination of the LSP ping may forward the MPLS echo request successfully over an interface not configured to carry MPLS payloads because of the use of penultimate hop popping. Since the receiving router has no means to differentiate whether the IP packet was sent unlabeled or implicitly labeled, the addition of labels shimmed above the MPLS echo request (using the Nil FEC) will prevent a router from forwarding such a packet out unlabeled interfaces.
MPLSペイロードを運ぶのに使用されるLSPsをテストするとき、あるLSP折損を検出するために、少なくとも1個の追加ラベルでMPLSエコー要求パケットをカプセルに入れるのが必要であるかもしれません。(L2VPNとL3VPN交通を運ぶのに使用されるLSPsなどのように例えば; 自由民主党かRSVP-TE LSPsをテストするとき、まさしくMPLSエコー要求パケットが検出しないかもしれない発信がどこを例証するか、ルータ、すぐに、LSPピングの目的地の上流は首尾よく終わりから二番目のホップの飛び出しの使用のためにMPLSペイロードを運ぶために構成されなかったインタフェースの上にMPLSエコー要求を転送するかもしれません; 受信ルータにはIPパケットをラベルされていない状態で送ったか、またはそれとなくラベルしたかを微分する手段が全くないので、MPLSエコー要求(Nil FECを使用する)を超えてshimmedされたラベルの添加は、ルータが出かけているラベルされていないインタフェースをそのようなパケットに送るのを防ぐでしょう。
4.3. Sending an MPLS Echo Request
4.3. MPLSエコー要求を送ります。
An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). The Router Alert option MUST be set in the IP header.
MPLSエコー要求はUDPパケットです。 IPヘッダーは以下の通り用意ができています: ソースIPアドレスは発送可能送信者のアドレスです。 送付先IPアドレスが範囲127/8からの(手当たりしだいに選ばれています)のIPv4アドレスか範囲からのIPv6アドレスである、0:0:0 0:0::FFFF、: 127/104 IP TTLは1に用意ができています。 ソースUDP港は送付者によって選ばれています。 目的地UDP港は3503(MPLSエコー要求のためにIANAによって割り当てられる)に設定されます。 IPヘッダーにRouter Alertオプションを設定しなければなりません。
An MPLS echo request is sent with a label stack corresponding to the FEC Stack being tested. Note that further labels could be applied if, for example, the normal route to the topmost FEC in the stack is via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the stack correspond to Implicit Null labels, the MPLS echo request is considered unlabeled even if further labels will be applied in sending the packet.
テストされるFEC Stackに対応するラベルスタックでMPLSエコー要求を送ります。 例えば、Traffic Engineered Tunnel[RSVP-TE]を通してスタックの最上のFECへのノーマルルートがあるなら、一層のラベルを適用できたことに注意してください。 スタックのFECsのすべてがImplicit Nullラベルに対応しているなら、一層のラベルがパケットを送る際に適用されても、MPLSエコー要求はラベルされていないと考えられます。
If the echo request is labeled, one MAY (depending on what is being pinged) set the TTL of the innermost label to 1, to prevent the ping
エコー要求がラベルされるなら、ある5月に、(確認されていることによります)は、ピングを防ぐために最も奥深いラベルのTTLを1に設定しました。
Kompella & Swallow Standards Track [Page 33] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[33ページ]RFC4379
request going farther than it should. Examples of where this SHOULD be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint or a pseudowire. Preventing the ping request from going too far can also be accomplished by inserting a Router Alert label above this label; however, this may lead to the undesired side effect that MPLS echo requests take a different data path than actual data. For more information on how these mechanisms can be used for pseudowire connectivity verification, see [VCCV].
それより遠くに行くのがそうするべきであるよう要求してください。 a VPN IPv4かIPv6が前に置くインクルードノッキングをこのSHOULDにして、L2 VPN終点かaがpseudowireされるところに関する例。 また、ピング要求は度が過ぎられるのを防ぐのをこのラベルの上のRouter Alertラベルを挿入することによって、実行できます。 しかしながら、これは実際のデータよりMPLSエコーが異なったデータ経路を取るよう要求する望まれない副作用に通じるかもしれません。 pseudowire接続性検証にどうこれらのメカニズムを使用できるかに関する詳しい情報に関しては、[VCCV]を見てください。
In "ping" mode (end-to-end connectivity check), the TTL in the outermost label is set to 255. In "traceroute" mode (fault isolation mode), the TTL is set successively to 1, 2, and so on.
「ピング」モード(終わりから終わりへの接続性チェック)で、一番はずれのラベルのTTLは255に用意ができています。 「トレースルート」モード(欠点孤立モード)で、TTLは相次ぐ1、2などに用意ができています。
The sender chooses a Sender's Handle and a Sequence Number. When sending subsequent MPLS echo requests, the sender SHOULD increment the Sequence Number by 1. However, a sender MAY choose to send a group of echo requests with the same Sequence Number to improve the chance of arrival of at least one packet with that Sequence Number.
送付者はSenderのHandleとSequence Numberを選びます。 その後のMPLSエコー要求を送るとき、送付者SHOULDはSequence Numberを1つ増加します。 しかしながら、送付者は、そのSequence Numberとの少なくとも1つのパケットの到着の機会を改良するために同じSequence Numberとのエコー要求のグループを送るのを選ぶかもしれません。
The TimeStamp Sent is set to the time-of-day (in seconds and microseconds) that the echo request is sent. The TimeStamp Received is set to zero.
TimeStamp Sentはエコーが送られるよう要求する時刻(秒とマイクロセカンドの)に用意ができています。 TimeStamp Receivedはゼロに用意ができています。
An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply Mode must be set to the desired reply mode; the Return Code and Subcode are set to zero. In the "traceroute" mode, the echo request SHOULD include a Downstream Mapping TLV.
MPLSエコー要求には、FEC Stack TLVがなければなりません。 また、Reply Modeは必要な回答モードに用意ができなければなりません。 Return CodeとSubcodeはゼロに用意ができています。 「トレースルート」モードでは、エコー要求SHOULDはDownstream Mapping TLVを含んでいます。
4.4. Receiving an MPLS Echo Request
4.4. MPLSエコー要求を受け取ります。
Sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or the destination address in the 127/8 address range. The control plane further identifies it by UDP destination port 3503.
MPLSエコー要求を制御飛行機に送るのは以下のパケット処理例外の1つによって引き起こされます: 127/8アドレスのルータAlertオプション、IP TTL満了、MPLS TTL満了、MPLS Router Alertラベル、または送付先アドレスが及びます。 制御飛行機はUDP仕向港3503のそばでさらにそれを特定します。
For reporting purposes the bottom of stack is considered to be stack-depth of 1. This is to establish an absolute reference for the case where the actual stack may have more labels than there are FECs in the Target FEC Stack.
報告目的のために、スタックの下部は1のスタック深さであると考えられます。 これは、実際のスタックがFECsがTarget FEC Stackにあるより多くのラベルを持っているかもしれないケースに関する絶対参照を確立するためのものです。
Furthermore, in all the error codes listed in this document, a stack-depth of 0 means "no value specified". This allows compatibility with existing implementations that do not use the Return Subcode field.
その上、本書では記載されたすべてのエラーコードでは、0のスタック深さは、「値は全く指定しませんでした。」と意味します。 これはReturn Subcode分野を使用しない既存の実現との互換性を許容します。
An LSR X that receives an MPLS echo request then processes it as follows.
そして、MPLSエコー要求を受け取るLSR Xは以下の通りそれを処理します。
Kompella & Swallow Standards Track [Page 34] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[34ページ]RFC4379
1. General packet sanity is verified. If the packet is not well-
formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code
set to "Malformed echo request received" and the Subcode to zero.
If there are any TLVs not marked as "Ignore" that LSR X does not
understand, LSR X SHOULD send an MPLS "TLV not understood" (as
appropriate), and the Subcode set to zero. In the latter case,
the misunderstood TLVs (only) are included as sub-TLVs in an
Errored TLVs TLV in the reply. The header fields Sender's Handle,
Sequence Number, and Timestamp Sent are not examined, but are
included in the MPLS echo reply message.
1. 一般パケット正気は確かめられます。 パケットがよく形成されないなら、LSR X SHOULDは「奇形のエコー要求は受信したこと」に用意ができているReturn CodeとSubcodeとMPLS Echo Replyをゼロに送ります。 何かLSR Xが分からないのを「無視する」ときマークされなかったTLVsがあれば、LSR X SHOULDは「TLVは分からなかったこと」を(適宜)MPLSに送ります、そして、Subcodeはゼロにセットしました。 後者の場合では、誤解されたTLVsはサブTLVsとしてErrored TLVs TLVに回答で含まれているだけです。 ヘッダーフィールドのSenderのHandle、Sequence Number、およびTimestamp Sentは調べられませんが、MPLSエコー応答メッセージに含まれています。
The algorithm uses the following variables and identifiers:
アルゴリズムは以下の変数と識別子を使用します:
Interface-I: the interface on which the MPLS echo request was
received.
インタフェースI: MPLSが要求を反映するインタフェースを受け取りました。
Stack-R: the label stack on the packet as it was received.
スタックR: それとしてのパケットの上のラベルスタックを受け取りました。
Stack-D: the label stack carried in the Downstream Mapping
TLV (not always present)
スタックD: Downstream Mapping TLVで運ばれたラベルスタック(いつも現在であるというわけではない)です。
Label-L: the label from the actual stack currently being
examined. Requires no initialization.
ラベルL: 現在調べられる実際のスタックからのラベル。 初期化を全く必要としません。
Label-stack-depth: the depth of label being verified. Initialized to
the number of labels in the received label stack
S.
ラベルスタックの深さ: 確かめられるラベルの深さ。 容認されたラベルスタックSのラベルの数に初期化されます。
FEC-stack-depth: depth of the FEC in the Target FEC Stack that
should be used to verify the current actual label.
Requires no initialization.
FECは深さを積み重ねます: 現在の実際のラベルについて確かめるのに使用されるべきであるTarget FEC StackのFECの深さ。 初期化を全く必要としません。
Best-return-code: contains the return code for the echo reply packet
as currently best known. As algorithm progresses,
this code may change depending on the results of
further checks that it performs.
最も良い復帰コード: 現在最もよく知られるとしてエコー・リプライパケットのための復帰コードを含んでいます。 アルゴリズムが進歩をするとき、それが実行するさらなるチェックの結果によって、このコードは変化するかもしれません。
Best-rtn-subcode: similar to Best-return-code, but for the Echo
Reply Subcode.
最も良いrtn部分符号: Echo Reply Subcodeがなければ、Best-復帰コードと同様です。
FEC-status: result value returned by the FEC Checking
algorithm described in section 4.4.1.
FEC-状態: セクション4.4.1で説明されたFEC Checkingアルゴリズムで結果値は戻りました。
/* Save receive context information */
*が救う/は文脈情報*/を受け取ります。
Kompella & Swallow Standards Track [Page 35] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[35ページ]RFC4379
2. If the echo request is good, LSR X stores the interface over
which the echo was received in Interface-I, and the label stack
with which it came in Stack-R.
2. エコー要求が良いなら、LSR XはエコーがInterface-Iに受け取られたインタフェース、およびそれがStack-Rに入ったラベルスタックを格納します。
/* The rest of the algorithm iterates over the labels in Stack-R,
verifies validity of label values, reports associated label
switching operations (for traceroute), verifies correspondence
between the Stack-R and the Target FEC Stack description in the
body of the echo request, and reports any errors. */
アルゴリズムの残りがStack-Rのラベルの上に繰り返して、正当性について確かめる/*は、値をラベルして、関連ラベル切り換え操作(トレースルートのための)を報告して、エコー要求のボディーでStack-RとTarget FEC Stack記述との通信について確かめて、どんな誤りも報告します。 */
/* The algorithm iterates as follows. */
アルゴリズムが以下の通り繰り返す/*。 */
3. Label Validation:
3. 合法化をラベルしてください:
If Label-stack-depth is 0 {
Labelスタックの深さは0です。
/* The LSR needs to report its being a tail-end for the LSP */
LSRがLSP*/のためにそれが末端であると報告する必要がある/*
Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null).
Set Best-return-code to 3 ("Replying router is an egress for
the FEC at stack depth"), set Best-rtn-subcode to the
value of FEC-stack-depth (1) and go to step 5 (Egress
Processing).
}
FECスタックの深さを1に設定してください、そして、3(内在しているNull)にLabel-Lを設定してください。 Best-復帰コードを3に設定してください、そして、(「返答ルータはスタックの深さのFECのための出口である」)FECスタックの深さ(1)の値にBest-rtn-部分符号を設定してください、そして、ステップ5(出口Processing)に行ってください。 }
/* This step assumes there is always an entry for well-known
label values */
いつもこのステップがそこで仮定する/*は周知のラベル値*/のためのエントリーです。
Set Label-L to the value extracted from Stack-R at depth
Label-stack-depth. Look up Label-L in the Incoming Label Map
(ILM) to determine if the label has been allocated and an
operation is associated with it.
深さLabelスタックの深さでStack-Rから抽出された値にLabel-Lを設定してください。 Incoming Label Map(ILM)でLabel-Lを見上げて、ラベルを割り当てて、操作がそれに関連しているかどうか決定してください。
If there is no entry for L {
Lのためのエントリーが全くありません。
/* Indicates a temporary or permanent label synchronization
problem the LSR needs to report an error */
/*はLSRが、誤り*/を報告する必要があることにおける一時的であるか永久的なラベル同期問題を示します。
Set Best-return-code to 11 ("No label entry at stack-depth")
and Best-rtn-subcode to Label-stack-depth. Go to step 7
(Send Reply Packet).
}
11(「スタック深さでのラベルなしエントリー」)へのBest-復帰コードとLabelスタックの深さへのBest-rtn-部分符号を設定してください。 ステップ7に行ってください(Reply Packetを送ってください)。 }
Else {
ほか
Retrieve the associated label operation from the
corresponding NLFE and proceed to step 4 (Label Operation
check).
対応するNLFEから関連ラベル操作を検索してください、そして、ステップ4に進んでください(ラベルOperationはチェックします)。
Kompella & Swallow Standards Track [Page 36] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[36ページ]RFC4379
}
}
4. Label Operation Check
4. ラベル動作チェック
If the label operation is "Pop and Continue Processing" {
ラベル操作は「飛び出してください、そして、処理し続けてください」です。
/* Includes Explicit Null and Router Alert label cases */
/*はExplicit NullとRouter Alertラベルケース*/を含んでいます。
Iterate to the next label by decrementing Label-stack-depth
and loop back to step 3 (Label Validation).
}
(ラベルValidation)をLabelスタックの深さを減少させるのによる次のラベルとして繰り返して、ステップ3に輪にして戻してください。 }
If the label operation is "Swap or Pop and Switch based on Popped
Label" {
ラベル操作は「Popped Labelに基づくスワッピングかPopとSwitch」です。
Set Best-return-code to 8 ("Label switched at stack-depth")
and Best-rtn-subcode to Label-stack-depth to report transit
switching.
8(「スタック深さで切り換えられたラベル」)へのBest-復帰コードとLabelスタックの深さへのBest-rtn-部分符号をレポートトランジットの切り換えに設定してください。
If a Downstream Mapping TLV is present in the received echo
request {
Downstream Mapping TLVは受信されたエコー要求に存在しています。
If the IP address in the TLV is 127.0.0.1 or 0::1 {
Set Best-return-code to 6 ("Upstream Interface Index
Unknown"). An Interface and Label Stack TLV SHOULD be
included in the reply and filled with Interface-I and
Stack-R.
}
TLVのIPアドレスが127.0である、.0 .1か0:、:1 6. 回答に含まれていて、いっぱいにされた(「上流のインタフェースインデックス未知」)のInterfaceとLabel Stack TLV SHOULD Interface-IとStack-R.にBest-復帰コードを設定してください。
Else {
ほか
Verify that the IP address, interface address, and label
stack in the Downstream Mapping TLV match Interface-I
and Stack-R. If there is a mismatch, set
Best-return-code to 5, "Downstream Mapping Mismatch".
An Interface and Label Stack TLV SHOULD be included in
the reply and filled in based on Interface-I and
Stack-R. Go to step 7 (Send Reply Packet).
}
}
Downstream Mapping TLVでのIPアドレス、インターフェース・アドレス、およびラベルスタックがInterface-IとStack-Rに合っていることを確かめてください。 ミスマッチがあれば、5、「川下のマッピングミスマッチ」にBest-復帰コードを設定してください。 InterfaceとLabel Stack TLV SHOULDは回答に含まれて、いっぱいになりました。中では、Interface-IとStack-Rに基づいています。 ステップ7に行ってください(Reply Packetを送ってください)。 } }
For each available downstream ECMP path {
それぞれの利用可能な川下のECMP経路
Retrieve output interface from the NHLFE entry.
NHLFEエントリーから出力インタフェースを検索してください。
/* Note: this return code is set even if Label-stack-depth
is one */
/*注意: この復帰コードはLabelスタックの深さが1*/であっても設定されます。
Kompella & Swallow Standards Track [Page 37] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[37ページ]RFC4379
If the output interface is not MPLS enabled {
出力インタフェースは有効にされたMPLSではありません。
Set Best-return-code to Return Code 9, "Label switched
but no MPLS forwarding at stack-depth" and set
Best-rtn-subcode to Label-stack-depth and goto
Send_Reply_Packet.
}
Best-復帰コードをReturn Code9に設定してください、そして、「スタック深さで切り換えられるのにもかかわらずの、いいえ、MPLSを推進とラベルしてください」、Labelスタックの深さとgoto Send_Reply_へのBest-rtn-部分符号Packetを設定してください。 }
If a Downstream Mapping TLV is present {
Downstream Mapping TLVは存在しています。
A Downstream Mapping TLV SHOULD be included in the echo
reply (see section 3.3) filled in with information about
the current ECMP path.
}
}
Downstream Mapping TLV SHOULD、現在のECMP経路の情報で記入されたエコー・リプライ(セクション3.3を見る)で含められてください。 } }
If no Downstream Mapping TLV is present, or the Downstream IP
Address is set to the ALLROUTERS multicast address,
go to step 7 (Send Reply Packet).
どんなDownstream Mapping TLVも存在していないか、またはDownstream IP AddressがALLROUTERSマルチキャストアドレスに用意ができているなら、ステップ7に行ってください(Reply Packetを送ってください)。
If the "Validate FEC Stack" flag is not set and the LSR is not
configured to perform FEC checking by default, go to step 7
(Send Reply Packet).
「FECスタックを有効にしてください」という旗が設定されないで、またLSRがデフォルトでチェックするFECを実行するために構成されないなら、ステップ7に行ってください(Reply Packetを送ってください)。
/* Validate the Target FEC Stack in the received echo request.
/*は受信されたエコー要求でTarget FEC Stackを有効にします。
First determine FEC-stack-depth from the Downstream Mapping
TLV. This is done by walking through Stack-D (the Downstream
labels) from the bottom, decrementing the number of labels
for each non-Implicit Null label, while incrementing
FEC-stack-depth for each label. If the Downstream Mapping TLV
contains one or more Implicit Null labels, FEC-stack-depth
may be greater than Label-stack-depth. To be consistent with
the above stack-depths, the bottom is considered to entry 1.
*/
まず最初に、Downstream Mapping TLVからFECスタックの深さを測定してください。 Stack-D(Downstreamラベル)を通って下部から歩くことによって、これをします、それぞれの非内在しているNullラベルのためにラベルの数を減少させて各ラベルのためにFECスタックの深さを増加していて。 Downstream Mapping TLVが1個以上のImplicit Nullラベルを含んでいるなら、FECスタックの深さはLabelスタックの深さより大きいかもしれません。 上のスタック深層と一致しているように、下部はエントリー1と考えられます。 */
Set FEC-stack-depth to 0. Set i to Label-stack-depth.
FECスタックの深さを0に設定してください。 Labelスタックの深さにiを設定してください。
While (i > 0 ) do {
++FEC-stack-depth.
if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
--i.
}
(i>0)はそうしますがFEC-スタック++深さスタックD[FECスタックの深さ]!=3である(暗黙のヌル)なら--i.
If the number of labels in the FEC stack is greater
than or equal to FEC-stack-depth {
FECスタックのラベルの数がそう以上なら、FECは深さを積み重ねます。
Kompella & Swallow Standards Track [Page 38] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[38ページ]RFC4379
Perform the FEC Checking procedure (see subsection 4.4.1
below).
FEC Checking手順を実行してください(小区分4.4.1未満を見てください)。
If FEC-status is 2, set Best-return-code to 10 ("Mapping
for this FEC is not the given label at stack-depth").
FEC-状態が2であるなら、10(「このFECのためのマッピングはスタック深さの与えられたラベルでない」)にBest-復帰コードを設定してください。
If the return code is 1, set Best-return-code to
FEC-return-code and Best-rtn-subcode to FEC-stack-depth.
}
復帰コードが1であるなら、FEC-復帰コードへのBest-復帰コードとFECスタックの深さへのBest-rtn-部分符号を設定してください。 }
Go to step 7 (Send Reply Packet).
}
ステップ7に行ってください(Reply Packetを送ってください)。 }
5. Egress Processing:
5. 出口処理:
/* These steps are performed by the LSR that identified itself
as the tail-end LSR for an LSP. */
これらが踏む/*はLSPのためにそれ自体が末端LSRであると認識したLSRによって実行されます。 */
If received echo request contains no Downstream Mapping TLV, or
the Downstream IP Address is set to 127.0.0.1 or 0::1
go to step 6 (Egress FEC Validation).
受信されたエコー要求がDownstream Mapping TLVを全く含んでいないか、Downstream IP Addressが127.0に.0を設定することである、.1か0:、:1 ステップ6(出口FEC Validation)に行ってください。
Verify that the IP address, interface address, and label stack in
the Downstream Mapping TLV match Interface-I and Stack-R. If
not, set Best-return-code to 5, "Downstream Mapping
Mis-match". A Received Interface and Label Stack TLV SHOULD be
created for the echo response packet. Go to step 7 (Send Reply
Packet).
Downstream Mapping TLVでのIPアドレス、インターフェース・アドレス、およびラベルスタックがInterface-IとStack-Rに合っていることを確かめてください。 そうでなければ、5、「川下のマッピング誤マッチ」にBest-復帰コードを設定してください。 Received InterfaceとLabel Stack TLV SHOULD、エコー応答パケットには、作成されてください。 ステップ7に行ってください(Reply Packetを送ってください)。
6. Egress FEC Validation:
6. 出口FEC合法化:
/* This is a loop for all entries in the Target FEC Stack
starting with FEC-stack-depth. */
/、*これはFECスタックの深さから始まるTarget FEC Stackのすべてのエントリーのための輪です。 */
Perform FEC checking by following the algorithm described in
subsection 4.4.1 for Label-L and the FEC at FEC-stack-depth.
小区分で説明されたアルゴリズムに従うことでチェックするFECを実行してください、4.4、.1、FECスタックの深さのLabel-LとFECのために。
Set Best-return-code to FEC-code and Best-rtn-subcode to the
value in FEC-stack-depth.
FEC-コードへのBest-復帰コードとFECスタックの深さの値へのBest-rtn-部分符号を設定してください。
If FEC-status (the result of the check) is 1,
go to step 7 (Send Reply Packet).
FEC-状態(チェックの結果)が1であるなら、ステップ7に行ってください(Reply Packetを送ってください)。
/* Iterate to the next FEC entry */
*が次のFECエントリー*/として繰り返す/
++FEC-stack-depth.
+ + FEC-スタック深さ。
Kompella & Swallow Standards Track [Page 39] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[39ページ]RFC4379
If FEC-stack-depth > the number of FECs in the FEC-stack,
go to step 7 (Send Reply Packet).
FECスタックの深さ>である、FEC-スタック、7(Reply Packetを送る)を踏む碁における、FECsの数。
If FEC-status is 0 {
++Label-stack-depth.
If Label-stack-depth > the number of labels in Stack-R,
Go to step 7 (Send Reply Packet).
FEC-状態が0である、+ + ラベルスタック深さ、Labelスタックの深さ>である、Stack-R(ステップ7(Reply Packetを送ります)へのGo)のラベルの数
Label-L = extracted label from Stack-R at depth
Label-stack-depth.
Loop back to step 6 (Egress FEC Validation).
}
ラベルL=は深さLabelスタックの深さでStack-Rからラベルを抽出しました。 ステップ6(出口FEC Validation)に輪にして戻ってください。 }
7. Send Reply Packet:
7. 回答パケットを送ってください:
Send an MPLS echo reply with a Return Code of Best-return-code,
and a Return Subcode of Best-rtn-subcode. Include any TLVs
created during the above process. The procedures for sending
the echo reply are found in subsection 4.4.1.
Best-復帰コードのReturn Code、およびBest-rtn-部分符号のReturn SubcodeとのMPLSエコー・リプライを送ってください。 上の過程の間に作成されたあらゆるTLVsを含めてください。 エコー・リプライを送るための手順は小区分4.4.1で見つけられます。
4.4.1. FEC Validation
4.4.1. FEC合法化
/* This subsection describes validation of an FEC entry within the
Target FEC Stack and accepts an FEC, Label-L, and Interface-I.
The algorithm performs the following steps. */
/、*この小区分は、Target FEC Stackの中でFECエントリーの合法化について説明して、FEC、Label-L、およびInterface-Iを受け入れます。 アルゴリズムは以下のステップを実行します。 */
1. Two return values, FEC-status and FEC-return-code, are initialized
to 0.
1. 2つのリターン値(FEC-状態とFEC-復帰コード)が、0に初期化されます。
2. If the FEC is the Nil FEC {
If Label-L is either Explicit_Null or Router_Alert, return.
2. FECがNil FECである、Label-LがExplicit_NullかRouter_Alertのどちらかであるなら、戻ってください。
Else {
Set FEC-return-code to 10 ("Mapping for this FEC is not
the given label at stack-depth").
Set FEC-status to 1
Return.
}
}
ほか、セット10(「このFECのためのマッピングはスタック深さの与えられたラベルでない」)へのFEC-復帰コード. 1へのセットFEC-状態Return。 }
3. Check the FEC label mapping that describes how traffic received on
the LSP is further switched or which application it is associated
with. If no mapping exists, set FEC-return-code to Return 4,
"Replying router has no mapping for the FEC at stack-depth". Set
FEC-status to 1. Return.
3. それを写像すると説明されるLSPで受けられた交通が切り換えられるか、またはそれがさらにそれのアプリケーションに関連しているFECラベルをチェックしてください。 写像でないのが存在するなら、Return4、「返答ルータはスタック深さにFECのための写像を持っていないこと」にFEC-復帰コードを設定してください。 FEC-状態を1に設定してください。 戻ってください。
4. If the label mapping for FEC is Implicit Null, set FEC-status to 2
and proceed to step 5. Otherwise, if the label mapping for FEC is
4. FECのためのラベルマッピングがImplicit Nullであるなら、FEC-状態を2に設定してください、そして、ステップ5に進んでください。 さもなければ、ラベルであるなら、FECのためのマッピングはそうです。
Kompella & Swallow Standards Track [Page 40] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[40ページ]RFC4379
Label-L, proceed to step 5. Otherwise, set FEC-return-code to 10
("Mapping for this FEC is not the given label at stack-depth"),
set FEC-status to 1, and return.
ラベルL、ステップ5に進んでください。 さもなければ、10(「このFECのためのマッピングはスタック深さの与えられたラベルでない」)にFEC-復帰コードを設定してください、そして、FEC-状態を1に設定してください、そして、戻ってください。
5. This is a protocol check. Check what protocol would be used to
advertise FEC. If it can be determined that no protocol
associated with Interface-I would have advertised an FEC of that
FEC-Type, set FEC-return-code to 12 ("Protocol not associated with
interface at FEC stack-depth"). Set FEC-status to 1.
5. これはプロトコルチェックです。 どんなプロトコルがFECの広告を出すのに使用されるかチェックしてください。 Interface-Iに関連しているどんなプロトコルもそのFEC-タイプのFECの広告を出していないことを決定できるなら、12(「FECスタック深さでインタフェースに関連づけられなかったプロトコル」)にFEC-復帰コードを設定してください。 FEC-状態を1に設定してください。
6. Return.
6. 戻ってください。
4.5. Sending an MPLS Echo Reply
4.5. MPLSエコー・リプライを送ります。
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response to an MPLS echo request. The source IP address is a routable address of the replier; the source port is the well-known UDP port for LSP ping. The destination IP address and UDP port are copied from the source IP address and UDP port of the echo request. The IP TTL is set to 255. If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header MUST contain the Router Alert IP option. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [LABEL-STACK]).
MPLSエコー・リプライはUDPパケットです。 MPLSエコー要求に対応してそれを送るだけでよいです。 ソースIPアドレスは「再-プライヤー」の発送可能アドレスです。 ソース港はLSPピングのための周知のUDPポートです。 送付先IPアドレスとUDPポートはアドレスとUDPが移植するエコー要求のソースIPからコピーされます。 IP TTLは255に用意ができています。 エコー要求におけるReply Modeが「Router AlertがあるIPv4 UDPパケットを通した回答」であるなら、IPヘッダーはRouter Alert IPオプションを含まなければなりません。 LSPの上に回答を送るなら、この場合最上のラベルはRouter Alertラベル(1)([LABEL-STACK]を見てください)であるに違いない。
The format of the echo reply is the same as the echo request. The Sender's Handle, the Sequence Number, and TimeStamp Sent are copied from the echo request; the TimeStamp Received is set to the time-of- day that the echo request is received (note that this information is most useful if the time-of-day clocks on the requester and the replier are synchronized). The FEC Stack TLV from the echo request MAY be copied to the reply.
エコー・リプライの形式はエコー要求と同じです。 SenderのHandle、Sequence Number、およびTimeStamp Sentはエコー要求からコピーされます。 TimeStamp Receivedは-日では、それが受け取られている(リクエスタと「再-プライヤー」の上の時刻時計が連動するならこの情報が最も役に立つことに注意してください)エコーが、要求する時に用意ができています。 エコー要求からのFEC Stack TLVは回答にコピーされるかもしれません。
The replier MUST fill in the Return Code and Subcode, as determined in the previous subsection.
「再-プライヤー」は前の小区分で決定するようにReturn CodeとSubcodeに記入しなければなりません。
If the echo request contains a Pad TLV, the replier MUST interpret the first octet for instructions regarding how to reply.
エコー要求がPad TLVを含んでいるなら、「再-プライヤー」はどう返答するかに関する指示のための最初の八重奏を解釈しなければなりません。
If the replying router is the destination of the FEC, then Downstream Mapping TLVs SHOULD NOT be included in the echo reply.
返答ルータであるなら、含まれているコネがエコー・リプライであったなら、FEC、当時のDownstream Mapping TLVs SHOULDの目的地はNOTですか?
If the echo request contains a Downstream Mapping TLV, and the replying router is not the destination of the FEC, the replier SHOULD compute its downstream routers and corresponding labels for the incoming label, and add Downstream Mapping TLVs for each one to the echo reply it sends back.
エコー要求がDownstream Mapping TLVを含んでいて、返答ルータがFECの目的地でないなら、replier SHOULDは入って来るラベルのためにその川下のルータと対応するラベルを計算して、それぞれのためにそれが返送するエコー・リプライにDownstream Mapping TLVsを加えます。
Kompella & Swallow Standards Track [Page 41] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[41ページ]RFC4379
If the Downstream Mapping TLV contains Multipath Information requiring more processing than the receiving router is willing to perform, the responding router MAY choose to respond with only a subset of multipaths contained in the echo request Downstream Mapping. (Note: The originator of the echo request MAY send another echo request with the Multipath Information that was not included in the reply.)
Downstream Mapping TLVが受信ルータより多くの処理が実行しても構わないと思っているMultipath情報必要さを含んでいるなら、応じるルータは、多重通路の部分集合だけがエコー要求Downstream Mappingに含まれている状態で応じるのを選ぶかもしれません。 (注意: エコー要求の創始者は回答に含まれていなかったMultipath情報との別のエコー要求を送るかもしれません。)
Except in the case of Reply Mode 4, "Reply via application level control channel", echo replies are always sent in the context of the IP/MPLS network.
Reply Mode4に関するケース、「アプリケーションレベルコントロールチャンネルを通した回答」を除いて、IP/MPLSネットワークの文脈でいつもエコー・リプライを送ります。
4.6. Receiving an MPLS Echo Reply
4.6. MPLSエコー・リプライを受けます。
An LSR X should only receive an MPLS echo reply in response to an MPLS echo request that it sent. Thus, on receipt of an MPLS echo reply, X should parse the packet to ensure that it is well-formed, then attempt to match up the echo reply with an echo request that it had previously sent, using the destination UDP port and the Sender's Handle. If no match is found, then X jettisons the echo reply; otherwise, it checks the Sequence Number to see if it matches.
LSR Xは発信したというMPLSエコー要求に対応してMPLSエコー・リプライを受けるだけであるはずです。 したがって、MPLSエコー・リプライを受け取り次第Xはそれがよく形成されているのを確実にして、次に、以前に発信したというエコー要求によるエコー・リプライを合わせるのを試みるためにパケットを分析するべきです、目的地UDP港とSenderのHandleを使用して。 マッチが全く見つけられないなら、Xはエコー・リプライを投げ捨てます。 さもなければ、それは、それが合っているかどうか確認するためにSequence Numberをチェックします。
If the echo reply contains Downstream Mappings, and X wishes to traceroute further, it SHOULD copy the Downstream Mapping(s) into its next echo request(s) (with TTL incremented by one).
エコー・リプライがDownstream Mappingsを含んでいるか、そして、Xはさらにトレースルートに願われて、それはSHOULDコピーです。次のエコーの中へのDownstream Mapping(s)は(s)(TTLが1つ増加されている)を要求します。
4.7. Issue with VPN IPv4 and IPv6 Prefixes
4.7. VPN IPv4とIPv6と共に接頭語を発行してください。
Typically, an LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is sent with a label stack of depth greater than 1, with the innermost label having a TTL of 1. This is to terminate the ping at the egress PE, before it gets sent to the customer device. However, under certain circumstances, the label stack can shrink to a single label before the ping hits the egress PE; this will result in the ping terminating prematurely. One such scenario is a multi-AS Carrier's Carrier VPN.
通常、1以上の深さのラベルスタックでVPN IPv4接頭語かVPN IPv6接頭語のためのLSPピングを送ります、1のTTLを持っている最も奥深いラベルで。 これは、顧客装置にそれを送る前に出口PEでピングを終えるためのものです。 しかしながら、ある状況で、ピングが出口PEを打つ前にラベルスタックは単一のラベルに縮まることができます。 これは早まって、ピングの終わりをもたらすでしょう。 そのようなシナリオの1つはマルチAS CarrierのCarrier VPNです。
To get around this problem, one approach is for the LSR that receives such a ping to realize that the ping terminated prematurely, and send back error code 13. In that case, the initiating LSR can retry the ping after incrementing the TTL on the VPN label. In this fashion, the ingress LSR will sequentially try TTL values until it finds one that allows the VPN ping to reach the egress PE.
この問題を逃れるために、1つのアプローチがピングが早まって終わったとわかって、エラーコード13を返送するためにそのようなピングを受けるLSRのためのものです。 その場合、VPNラベルの上のTTLを増加した後に、開始しているLSRはピングを再試行できます。 こんなやり方で、VPNピングが出口PEに達することができるものを見つけるまで、イングレスLSRはTTL値を連続して試みるでしょう。
Kompella & Swallow Standards Track [Page 42] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[42ページ]RFC4379
4.8. Non-compliant Routers
4.8. 不従順なルータ
If the egress for the FEC Stack being pinged does not support MPLS ping, then no reply will be sent, resulting in possible "false negatives". If in "traceroute" mode, a transit LSR does not support LSP ping, then no reply will be forthcoming from that LSR for some TTL, say, n. The LSR originating the echo request SHOULD try sending the echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down the path. In such a case, the echo request for TTL > n SHOULD be sent with Downstream Mapping TLV "Downstream IP Address" field set to the ALLROUTERs multicast address until a reply is received with a Downstream Mapping TLV. The label stack MAY be omitted from the Downstream Mapping TLV. Furthermore, the "Validate FEC Stack" flag SHOULD NOT be set until an echo reply packet with a Downstream Mapping TLV is received.
確認されるFEC Stackのための出口がMPLSピングを支持しないと、回答を全く送らないでしょう、可能な「有病誤診」をもたらして。 aトランジットLSRが「トレースルート」モードでLSPピングを支持しないと、たとえば、いくらかのTTL、nにおいて、どんな回答もそのLSRから用意しないでしょう。 エコー要求SHOULDを溯源するLSRはTTL=n+1、n+2でエコー要求を送ってみます…, さらに経路の下側にLSRsを調べるn+k。 そのようなものでは、ケース、エコーは、TTL>n SHOULDのためにDownstream Mapping TLV「川下のIPアドレス」分野セットでDownstream Mapping TLVと共に回答を受け取るまでALLROUTERsマルチキャストアドレスに送られるよう要求します。 ラベルスタックはDownstream Mapping TLVから省略されるかもしれません。 その上、「FECスタックを有効にしてください」はaがあるエコー・リプライパケットまでのセットが受け取られたDownstream Mapping TLVであったならSHOULD NOTに旗を揚げさせます。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[LABEL-STACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[ラベルスタック] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[NTP] Mills, D., "Simple Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and OSI", RFC 2030, October
1996.
[NTP]工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC2030、1996年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
Kompella & Swallow Standards Track [Page 43] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[43ページ]RFC4379
5.2. Informative References
5.2. 有益な参照
[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information
in BGP-4", RFC 3107, May 2001.
「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[BGP-ラベル]Rekhter、Y.、およびE.ローゼン。
[ICMP] Postel, J., "Internet Control Message Protocol", STD
5, RFC 792, September 1981.
[ICMP] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[PW-CONTROL] Martini, L., El-Aawar, N., Heron, G., Rosen, E.,
Tappan, D., and T. Smith, "Pseudowire Setup and
Maintenance using the Label Distribution Protocol",
Work in Progress.
[PW-コントロール]のマティーニ、L.、高架鉄道-Aawar、N.、サギ、G.、ローゼン、E.、タッパン、D.、およびT.スミスと、「ラベル分配プロトコルを使用するPseudowireセットアップと維持」は進行中で働いています。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4365, February
2006.
[RFC4365]ローゼン、E.、「BGP/MPLS IP仮想私設網(VPNs)のための適用性証明」、RFC4365、2006年2月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual
Circuit Connectivity Verification (VCCV), Work in
Progress, August 2005.
[VCCV] ナドーとT.とR.Aggarwal、「疑似ワイヤの仮想のサーキット接続性検証(VCCV)、処理中の作業、2005年8月。」
[VPLS-BGP] Kompella, K. and Y. Rekhter, "Virtual Private LAN
Service", Work in Progress.
[VPLS-BGP] 「仮想の個人的なLANサービス」というKompella、K.、およびY.Rekhterは進行中で働いています。
6. Security Considerations
6. セキュリティ問題
Overall, the security needs for LSP ping are similar to those of ICMP ping.
全体的に見て、LSPピングの安全要求はICMPピングのものと同様です。
There are at least three approaches to attacking LSRs using the mechanisms defined here. One is a Denial-of-Service attack, by sending MPLS echo requests/replies to LSRs and thereby increasing their workload. The second is obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS echo requests and replies. The third is an unauthorized source using an LSP ping to obtain information about the network.
ここで定義されたメカニズムを使用することでLSRsを攻撃することへの少なくとも3つのアプローチがあります。 LSRsへのエコー要求/回答をMPLSに送って、その結果、彼らのワークロードを増加させることによって、1つはサービス不能攻撃です。 2番目は、MPLSエコー要求と回答をだますか、ハイジャックするか、再演するか、またはそうでなければ、いじることによって、MPLSデータ飛行機活性の状態を困惑させています。 3番目はネットワークの情報を得るのにLSPピングを使用している権限のないソースです。
Kompella & Swallow Standards Track [Page 44] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[44ページ]RFC4379
To avoid potential Denial-of-Service attacks, it is RECOMMENDED that implementations regulate the LSP ping traffic going to the control plane. A rate limiter SHOULD be applied to the well-known UDP port defined below.
潜在的サービス不能攻撃を避けるために、実現が制御飛行機に行くLSPピング交通を規制するのは、RECOMMENDEDです。 以下で周知のUDPポートと定義されていた状態で適用されていて、Aは、リミタがSHOULDであると評定します。
Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring and exact match on this field.
MPLSエコー応答メッセージを見せかけるか、または再演することを伴う単純な再生とスプーフィング攻撃は、有効でありそうにはありません。 これらの回答はSenderの傑出しているMPLSエコー要求メッセージのHandleとSequence Numberに合わなければならないでしょう。 系列が移動したとき、非合っている再生は捨てられるでしょう、その結果、パロディーには、機会の小さい窓しかありません。 しかしながら、より強いディフェンスを提供するために、また、実現はこのフィールドで必要と完全な一致でTimeStamp Sentを有効にするかもしれません。
To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message.
ネットワーク情報を得るMPLSエコー要求メッセージを使用することで権限のないソースから守るために、実現がメッセージを受け入れる前にアクセスリストに対してMPLSエコー要求メッセージのソースアドレスをチェックする手段を提供するのは、RECOMMENDEDです。
It is not clear how to prevent hijacking (non-delivery) of echo requests or replies; however, if these messages are indeed hijacked, LSP ping will report that the data plane is not working as it should.
エコー要求か回答の(非配送)をハイジャックするのをどのように防ぐかは明確ではありません。 しかしながら、これらのメッセージが本当にハイジャックされると、LSPピングは、報告するべきであるようにデータ飛行機が働いていないと報告するでしょう。
It does not seem vital (at this point) to secure the data carried in MPLS echo requests and replies, although knowledge of the state of the MPLS data plane may be considered confidential by some. Implementations SHOULD, however, provide a means of filtering the addresses to which echo reply messages may be sent.
MPLSエコー要求と回答で運ばれたデータを保証するのは(この時点で)重大に思えません、MPLSデータ飛行機の状態に関する知識はいくつかによって秘密であると考えられるかもしれませんが。 しかしながら、実現SHOULDはエコー応答メッセージが送られるかもしれないアドレスをフィルターにかける手段を提供します。
Although this document makes special use of 127/8 address, these are used only in conjunction with the UDP port 3503. Furthermore, these packets are only processed by routers. All other hosts MUST treat all packets with a destination address in the range 127/8 in accordance to RFC 1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 MUST be treated in accordance to RFC 1812. In particular, the default behavior is to treat packets destined to a 127/8 address as "martians".
このドキュメントは127/8アドレスの特別な使用をしますが、これらはUDPポート3503に関連してだけ使用されます。 その上、これらのパケットはルータによって処理されるだけです。 RFC1122への一致における送付先アドレスが範囲127/8にある状態で、他のすべてのホストがすべてのパケットを扱わなければなりません。 一致で3503年の目的地UDP港のない送付先アドレスが範囲127/8にある状態でルータによって受け取られたどんなパケットもRFC1812に扱わなければなりません。 デフォルトの振舞いは特に、127/8アドレスに運命づけられたパケットを"martians"として扱うことです。
Kompella & Swallow Standards Track [Page 45] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[45ページ]RFC4379
7. IANA Considerations
7. IANA問題
The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies.
TCPとUDPポートNo.3503はLSPエコー要求と回答のためにIANAによって割り当てられました。
The following sections detail the new name spaces to be managed by IANA. For each of these name spaces, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in [IANA]), "Specification Required", and "Vendor Private Use".
IANAによって管理されるように、以下のセクションは空間という新しい名前を詳しく述べます。 それぞれのこれらの名前空間において、スペースは課題範囲に分割されます。 次の用語はIANAが値を割り当てる手順について説明する際に使用されます: 「規格Action」([IANA]で定義されるように)、「仕様が必要である」、および「業者私用。」
Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an Experimental RFC that describes the format and procedures for using the code point; the actual assignment is made during the IANA actions for the RFC.
「仕様が必要である」という範囲からの値をIANAに示さなければなりません。 コード・ポイントを使用するための形式と手順について説明するExperimental RFCを通して要求をしなければなりません。 RFCのためにIANA動作の間、実際の課題をします。
Values from "Vendor Private" ranges MUST NOT be registered with IANA; however, the message MUST contain an enterprise code as registered with the IANA SMI Private Network Management Private Enterprise Numbers. For each name space that has a Vendor Private range, it must be specified where exactly the SMI Private Enterprise Number resides; see below for examples. In this way, several enterprises (vendors) can use the same code point without fear of collision.
「業者個人的な」範囲からの値をIANAに示してはいけません。 しかしながら、メッセージは登録されるとしてのIANA SMI兵士のNetwork Management兵士のエンタープライズ民数記がある企業コードを含まなければなりません。 Vendor兵士の範囲を持っているそれぞれの名前スペースとして、SMI兵士のエンタープライズNumberがいったいどこに住んでいるか指定しなければなりません。 例に関して以下を見てください。 このように、いくつかの企業(業者)が衝突への恐怖なしで同じコード・ポイントを使用できます。
7.1. Message Types, Reply Modes, Return Codes
7.1. メッセージタイプ、回答モード、復帰コード
The IANA has created and will maintain registries for Message Types, Reply Modes, and Return Codes. Each of these can take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-251 are made via "Specification Required"; values in the range 252-255 are for Vendor Private Use, and MUST NOT be allocated.
IANAは、作成して、Message Types、Reply Modes、およびReturn Codesのために登録であると主張するでしょう。 それぞれのこれらは範囲0-255で値を取ることができます。 Standards Actionを通して範囲0-191の課題があります。 「仕様が必要であること」を通して範囲192-251の課題をします。 範囲252-255の値はVendor兵士のUseのためにあって、割り当ててはいけません。
If any of these fields fall in the Vendor Private range, a top-level Vendor Enterprise Number TLV MUST be present in the message.
これらの野原のどれかがVendor兵士の範囲で転ぶなら、トップレベルVendorエンタープライズNumber TLVはメッセージに存在していなければなりません。
Message Types defined in this document are the following:
本書では定義されたメッセージTypesは以下です:
Value Meaning
----- -------
1 MPLS echo request
2 MPLS echo reply
値の意味----- ------- 1つのMPLSエコー要求2MPLSエコー・リプライ
Kompella & Swallow Standards Track [Page 46] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[46ページ]RFC4379
Reply Modes defined in this document are the following:
本書では定義された回答Modesは以下です:
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel
値の意味----- ------- 1 アプリケーションレベルコントロールを通してRouter Alert4ReplyがあるIPv4/IPv6 UDPパケットを通した3Replyがチャネルを開設するIPv4/IPv6 UDPパケットを通してどんな回答にも2Replyをしないでください。
Return Codes defined in this document are listed in section 3.1.
本書では定義されたリターンCodesはセクション3.1で記載されています。
7.2. TLVs
7.2. TLVs
The IANA has created and will maintain a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the TLV. The number spaces for the sub-TLVs of various TLVs are independent.
IANAは、作成して、トップレベルTLVsのType分野とどんな関連サブTLVsのためにも登録であると主張するでしょう。 サブTLVの意味がTLVによって見られることに注意してください。 様々なTLVsのサブTLVsのための数の空間は独立しています。
The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [IANA]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated.
TLVsとサブTLVsのための有効枠は0-65535です。 [IANA]で定義されるようにStandards Actionを通して0-16383に32768-49161に範囲の課題をします。 上で定義されるように「仕様が必要であること」を通して16384-31743に49162-64511に範囲の課題をします。 範囲の値はVendor兵士のUseのために31744-32767に64512-65535にあって、割り当ててはいけません。
If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet order. The rest of the Value field is private to the vendor.
TLVかサブTLVにVendor兵士のUseのために範囲に落ちるTypeがあるなら、Lengthは少なくとも4歳であるに違いありません、そして、最初の4つの八重奏がその業者のSMI兵士のエンタープライズNumberであるに違いありません、ネットワーク八重奏命令で。 業者にとって、Value分野の残りは個人的です。
Kompella & Swallow Standards Track [Page 47] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[47ページ]RFC4379
TLVs and sub-TLVs defined in this document are the following:
TLVsと本書では定義されたサブTLVsは以下です:
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack
1 LDP IPv4 prefix
2 LDP IPv6 prefix
3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Not Assigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated)
10 "FEC 128" Pseudowire
11 "FEC 129" Pseudowire
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
タイプサブタイプ値の分野---- -------- ----------- 1 IPv4接頭語13とラベルされた目標FEC Stack1自由民主党IPv4接頭語2自由民主党IPv6接頭語3RSVP IPv4 LSP4RSVP IPv6 LSP5Not Assigned6VPN IPv4接頭語7VPN IPv6接頭語8L2 VPN終点9「FEC128」Pseudowire(非難される)10「FEC128」Pseudowire11「FEC129」Pseudowire12BGP; BGPはDownstream Mapping3Pad4Not Assigned5VendorエンタープライズNumber6Not Assigned7InterfaceとIPv6接頭語14Generic IPv4接頭語15Generic IPv6接頭語16Nil FEC2をラベルして、TLVが理解していなかったLabel Stack8Not Assigned9Errored TLVs Any価値を10Reply TOS Byteとラベルしました。
8. Acknowledgements
8. 承認
This document is the outcome of many discussions among many people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal, and Vanson Lim.
このドキュメントは多くの人々での多くの議論の結果です、Manoj Leelanivas、ポールTraina、ヤコフRekhter、Der-Hwaガン、ブルック・べイリー、エリック・ローゼン、伊奈Minei、Shivani Aggarwal、およびVansonリムを含んでいて。
The description of the Multipath Information sub-field of the Downstream Mapping TLV was adapted from text suggested by Curtis Villamizar.
Downstream Mapping TLVのMultipath情報サブ分野の記述はカーティスVillamizarによって勧められたテキストから適合させられました。
Kompella & Swallow Standards Track [Page 48] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[48ページ]RFC4379
Authors' Addresses
作者のアドレス
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella杜松は1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
George Swallow Cisco Systems 1414 Massachusetts Ave, Boxborough, MA 01719
Boxborough、MA ジョージツバメシスコシステムズ1414マサチューセッツAve、01719
Phone: +1 978 936 1398 EMail: swallow@cisco.com
以下に電話をしてください。 +1 1398年の978 936メール: swallow@cisco.com
Kompella & Swallow Standards Track [Page 49] RFC 4379 Detecting MPLS Data Plane Failures February 2006
飛行機失敗2006年2月にMPLSデータを検出するKompellaとツバメ標準化過程[49ページ]RFC4379
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Kompella & Swallow Standards Track [Page 50]
Kompellaとツバメ標準化過程[50ページ]
一覧
スポンサーリンク
