[要約] RFC 3107は、BGP-4でラベル情報を伝送するための仕様です。目的は、MPLSベースのネットワークでBGPを使用する際に、ラベル情報を効率的に伝送することです。
Network Working Group Y. Rekhter
Request for Comments: 3107 Juniper Networks
Category: Standards Track E. Rosen
Cisco Systems, Inc.
May 2001
Carrying Label Information in BGP-4
BGP-4にラベル情報をキャリングします
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching (MPLS) label which is mapped to that route.
このドキュメントは、特定のルートのラベルマッピング情報が、ルート自体の配布に使用される同じBorder Gateway Protocol（BGP）更新メッセージでピギーバックされる方法を指定します。BGPを使用して特定のルートを配布する場合、そのルートにマッピングされたマルチプロトコルラベルスイッチング（MPLS）ラベルを配布するためにも使用できます。
Table of Contents
目次
1 Specification of Requirements .......................... 2
2 Overview ............................................... 2
3 Carrying Label Mapping Information ..................... 3
4 Advertising Multiple Routes to a Destination ........... 4
5 Capability Advertisement ............................... 4
6 When the BGP Peers are not Directly Adjacent ........... 5
7 Security Considerations ................................ 5
8 Acknowledgments ........................................ 6
9 References ............................................. 6
10 Authors' Addresses ..................................... 7
11 Full Copyright Statement ............................... 8
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
When BGP is used to distribute a particular route, it can also be used to distribute an MPLS label that is mapped to that route [MPLS-ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself.
BGPを使用して特定のルートを配布する場合、そのルート[MPLS-ARCH]にマッピングされたMPLSラベルを配布するためにも使用できます。このドキュメントは、これが行われる方法を指定します。特定のルートのラベルマッピング情報は、ルート自体の配布に使用される同じBGP更新メッセージでピギーバックされています。
This can be useful in the following situations:
これは、次の状況で役立ちます。
- If two immediately adjacent Label Switched Routers (LSRs) are also BGP peers, then label distribution can be done without the need for any other label distribution protocol.
- すぐに隣接する2つのラベル切り替えルーター（LSR）もBGPピアである場合、ラベル分布は他のラベル分布プロトコルを必要とせずに実行できます。
- Suppose one's network consists of two "classes" of LSR: exterior LSRs, which interface to other networks, and interior LSRs, which serve only to carry traffic between exterior LSRs. Suppose that the exterior LSRs are BGP speakers. If the BGP speakers distribute MPLS labels to each other along with each route they distribute, then as long as the interior routers support MPLS, they need not receive any of the BGP routes from the BGP speakers.
- 自分のネットワークがLSRの2つの「クラス」で構成されているとします：他のネットワークへのインターフェースと、外部LSR間のトラフィックのみを運ぶのに役立つインテリアLSR。外部LSRがBGPスピーカーであると仮定します。BGPスピーカーがMPLSラベルを配布する各ルートとともに互いに配布する場合、内部ルーターがMPLSをサポートする限り、BGPスピーカーからBGPルートを受け取る必要はありません。
If exterior router A needs to send a packet to destination D, and A's BGP next hop for D is exterior router B, and B has mapped label L to D, then A first pushes L onto the packet's label stack. A then consults its IGP to find the next hop to B, call it C. If C has distributed to A an MPLS label for the route to B, A can push this label on the packet's label stack, and then send the packet to C.
エクステリアルーターAが宛先Dにパケットを送信する必要があり、AのBGPがDの次のホップが外部ルーターBで、BにラベルLをDにマッピングする場合、最初にLをパケットのラベルスタックに押し込みます。次に、IGPを参照して次のホップにBを見つけ、Cと呼びます。CがBへのルートのMPLSラベルに配布されている場合、Aはこのラベルをパケットのラベルスタックに押し、パケットをCに送信します。。
If a set of BGP speakers are exchanging routes via a Route Reflector [BGP-RR], then by piggybacking the label distribution on the route distribution, one is able to use the Route Reflector to distribute the labels as well. This improves scalability quite significantly. Note that if the Route Reflector is not in the forwarding path, it need not even be capable of forwarding MPLS packets.
BGPスピーカーのセットがルートリフレクター[BGP-RR]を介してルートを交換し、ルート分布のラベル分布をピギーバックすることにより、ルートリフレクターを使用してラベルを配布することができます。これにより、スケーラビリティが大幅に向上します。ルートリフレクターが転送パスにない場合、MPLSパケットを転送することさえできないことに注意してください。
Label distribution can be piggybacked in the BGP Update message by using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The label is encoded into the NLRI field of the attribute, and the SAFI ("Subsequent Address Family Identifier") field is used to indicate that the NLRI contains a label. A BGP speaker may not use BGP to send labels to a particular BGP peer unless that peer indicates, through BGP Capability Advertisement, that it can process Update messages with the specified SAFI field.
ラベル分布は、BGP-4マルチプロトコル拡張属性[RFC 2283]を使用して、BGP更新メッセージでピギーバックすることができます。ラベルは属性のNLRIフィールドにエンコードされ、SAFI（「後続のアドレスファミリ識別子」）フィールドは、NLRIにラベルが含まれていることを示すために使用されます。BGPスピーカーは、BGPの機能広告を通じて、指定されたSAFIフィールドで更新メッセージを処理できることをピアが示していない限り、BGPを使用して特定のBGPピアにラベルを送信することはできません。
Label mapping information is carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes. The AFI indicates, as usual, the address family of the associated route. The fact that the NLRI contains a label is indicated by using SAFI value 4.
ラベルマッピング情報は、マルチプロトコル拡張属性のネットワークレイヤーリーチ可能性情報（NLRI）の一部として運ばれます。AFIは、通常のように、関連するルートの住所ファミリーを示します。NLRIにラベルが含まれているという事実は、SAFI値4を使用して示されています。
The Network Layer Reachability information is encoded as one or more triples of the form <length, label, prefix>, whose fields are described below:
ネットワークレイヤーの到達可能性情報は、フォームの1つ以上のトリプル<長さ、ラベル、プレフィックス>としてエンコードされます。そのフィールドは以下に説明します。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (3 octets) |
+---------------------------+
.............................
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
これらのフィールドの使用と意味は次のとおりです。
a) Length:
a) 長さ：
The Length field indicates the length in bits of the address prefix plus the label(s).
長さフィールドは、アドレスプレフィックスのビットの長さとラベルの長さを示します。
b) Label:
b) ラベル：
The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]).
ラベルフィールドには、1つ以上のラベルが搭載されています（ラベルのスタック[MPLS-ENCAPS]）。各ラベルは3オクテットとしてエンコードされており、高次の20ビットにラベル値が含まれており、低いオーダービットには「スタックの下部」（[MPLS-ENCAPS]で定義されています）が含まれています。
c) Prefix:
c) プレフィックス：
The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.
プレフィックスフィールドには、アドレスプレフィックスに続いて、フィールドの終わりをオクテットの境界に該当するのに十分なトレーリングビットが含まれます。トレーリングビットの値は無関係であることに注意してください。
The label(s) specified for a particular route (and associated with its address prefix) must be assigned by the LSR which is identified by the value of the Next Hop attribute of the route.
特定のルートに指定されたラベル（およびそのアドレスプレフィックスに関連付けられている）は、ルートの次のホップ属性の値によって識別されるLSRによって割り当てる必要があります。
When a BGP speaker redistributes a route, the label(s) assigned to that route must not be changed (except by omission), unless the speaker changes the value of the Next Hop attribute of the route.
BGPスピーカーがルートを再配分する場合、スピーカーがルートの次のホップ属性の値を変更しない限り、そのルートに割り当てられたラベルを変更してはなりません（省略による）。
A BGP speaker can withdraw a previously advertised route (as well as the binding between this route and a label) by either (a) advertising a new route (and a label) with the same NLRI as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field should be set to 0x800000. (Of course, terminating the BGP session also withdraws all the previously advertised routes.)
BGPスピーカーは、以前に宣伝されたルート（およびこのルートとラベルの間のバインディング）を引き出すことができます（a）以前に宣伝されたルートと同じNLRIで新しいルート（およびラベル）を宣伝するか、（b）更新メッセージの撤回されたルートフィールドに、以前に宣伝されたルートのNLRIをリストします。（NLRIの一部として）撤回されたルートフィールドにあるラベル情報は、0x800000に設定する必要があります。（もちろん、BGPセッションを終了すると、以前に宣伝されていたすべてのルートも撤回します。）
A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination, as long as each such route has its own label(s).
BGPスピーカーは、各ルートに独自のラベルがある限り、特定の宛先への複数のルートを維持（およびその仲間に宣伝）する場合があります。
The encoding described above allows a single BGP Update message to carry multiple routes, each with its own label(s).
上記のエンコードでは、単一のBGP更新メッセージが複数のルートを運ぶことができます。それぞれに独自のラベルが付いています。
In the case where a BGP speaker advertises multiple routes to a destination, if a route is withdrawn, and a label(s) is specified at the time of withdrawal, only the corresponding route with the corresponding label is withdrawn. If a route is withdrawn, and no label is specified at the time of withdrawal, then only the corresponding unlabeled route is withdrawn; the labeled routes are left in place.
BGPスピーカーが宛先への複数のルートを宣伝する場合、ルートが撤回され、撤退時にラベルが指定されている場合、対応するラベルを持つ対応するルートのみが撤回されます。ルートが撤回され、撤退時にラベルが指定されていない場合、対応する非標識ルートのみが撤回されます。ラベル付きルートは所定の位置に残されています。
A BGP speaker that uses Multiprotocol Extensions to carry label mapping information should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The MP_EXT Capability Code, as defined in [BGP-MP], is used to advertise the (AFI, SAFI) pairs available on a particular connection.
マルチプロトコル拡張機能を使用してラベルマッピング情報を携帯するBGPスピーカーは、[BGP-CAP]で定義されているように、この機能について同僚に通知する機能オプションパラメーターを使用する必要があります。[BGP-MP]で定義されているMP_EXT機能コードは、特定の接続で利用可能な（AFI、SAFI）ペアを宣伝するために使用されます。
A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers.
BGPスピーカーは、2つのスピーカー間にラベルスイッチ付きパス（LSP）がない限り、この機能を別のBGPスピーカーに宣伝しないでください。
A BGP speaker that is capable of handling multiple routes to a destination (as described above) should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The value of this capability is 4.
（上記のように）宛先に複数のルートを処理できるBGPスピーカーは、[BGP-CAP]で定義されているように、この機能について同僚に通知する機能オプションパラメーターを使用する必要があります。この機能の値は4です。
Consider the following LSR topology: A--B--C--D. Suppose that D distributes a label L to A. In this topology, A cannot simply push L onto a packet's label stack, and then send the resulting packet to B. D must be the only LSR that sees L at the top of the stack. Before A sends the packet to B, it must push on another label, which was distributed by B. B must replace this label with yet another label, which was distributed by C. In other words, there must be an LSP between A and D. If there is no such LSP, A cannot make use of label L. This is true any time labels are distributed between non-adjacent LSRs, whether that distribution is done by BGP or by some other method.
次のLSRトポロジを考えてみましょう。DがラベルLをAに分散するとします。このトポロジでは、AがパケットのラベルスタックにLを押してから、結果のパケットをBに送信することはできません。Dは、スタックの上部にLを見る唯一のLSRでなければなりません。AがBにパケットを送信する前に、Bによって配布された別のラベルをプッシュする必要があります。Bは、このラベルをさらに別のラベルに置き換える必要があります。。そのようなLSPがない場合、AはラベルLを使用できません。これは、その分布がBGPによって行われるか、他の方法によって行われるかにかかわらず、非隣接LSRの間にラベルが分布するときはいつでも当てはまります。
This document does NOT specify any procedure for ensuring in real time that label distribution between non-adjacent LSRs is done only when the appropriate MPLS infrastructure exists in the network or networks connecting the two LSRs. Ensuring that the proper infrastructure exists is an issue for network management and operation.
このドキュメントでは、非隣接LSR間のラベル分布が、2つのLSRを接続するネットワークまたはネットワークに適切なMPLSインフラストラクチャが存在する場合にのみ行われることをリアルタイムで保証する手順を指定しません。適切なインフラストラクチャが存在することを保証することが、ネットワーク管理と操作の問題です。
When an LSR A is directly connected to an LSR B via a point-to-point interface, then when A receives packets over that interface, it knows that they come from B. This makes it easy for A to discard any packets from B whose top labels are not among the labels that A distributed to B. That is, A can easily ensure that B only uses those labels which it is entitled to use. This technique can be used to prevent "label spoofing", i.e., the situation in which an LSR imposes a label which has not been properly distributed to it.
LSR Aがポイントツーポイントインターフェイスを介してLSR Bに直接接続されている場合、そのインターフェイスでパケットを受信すると、Bから来ることがわかります。トップラベルは、AがBに配布されたラベルの1つではありません。つまり、Aは、Bが使用する資格のあるラベルのみを使用することを簡単に保証できます。この手法は、「ラベルスプーフィング」、つまりLSRが適切に分布していないラベルを課す状況を防ぐために使用できます。
The procedures discussed in this document would commonly be used when the label distribution peers are separated not merely by a point-to-point link, but by an MPLS network. This means that when an LSR A processes a labeled packet, it really has no way to determine which other LSR B pushed on the top label. Hence it cannot tell whether the label is one which B is entitled to use. In fact, when Route Reflectors are in use, A may not even know the set of LSRs which receive its label mappings. So the previous paragraph's technique for preventing label spoofing does not apply.
このドキュメントで説明する手順は、一般に、ラベル配布ピアがポイントツーポイントリンクだけでなく、MPLSネットワークによって分離されている場合に使用されます。これは、LSR Aがラベル付きパケットを処理する場合、他のLSR Bがトップレーベルにプッシュされたものを決定する方法が実際にはないことを意味します。したがって、ラベルがBが使用する権利があるかどうかはわかりません。実際、ルートリフレクターが使用されている場合、ラベルマッピングを受け取るLSRのセットさえ知らない場合があります。したがって、ラベルのスプーフィングを防ぐための前の段落の手法は適用されません。
It is possible though to use other techniques to avoid label spoofing problems. If, for example, one never accepts labeled packets from the network's "external" interfaces, and all the BGP-distributed labels are advertised via IBGP, then there is no way for an untrusted router to put a labeled packet into the network. One can generally assume that one's IBGP peers (or the IBGP peers of one's Route Reflector) will not attempt label spoofing, since they are all under the control of a single administration.
ただし、ラベルのスプーフィングの問題を避けるために、他の手法を使用することが可能です。たとえば、ネットワークの「外部」インターフェイスからラベル付きパケットを受け入れない場合、すべてのBGP分散ラベルがIBGPを介して宣伝されている場合、信頼されていないルーターがラベル付きパケットをネットワークに入れる方法はありません。一般に、IBGPのピア（または自分のルートリフレクターのIBGPピア）は、すべてが単一の管理の管理下にあるため、ラベルのスプーフィングを試みないと想定できます。
This condition can actually be weakened significantly. One doesn't need to refuse to accept all labeled packets from external interfaces. One just needs to make sure that any labeled packet received on an external interface has a top label which was actually distributed out that interface.
この状態は実際に大幅に弱体化する可能性があります。外部インターフェイスからラベル付けされたすべてのパケットを受け入れることを拒否する必要はありません。外部インターフェイスで受信したラベル付きパケットには、実際にそのインターフェイスが配布されたトップレーベルがあることを確認する必要があります。
Then a label spoofing problem would only exist if there are both trusted and untrusted systems out the same interface. One way to avoid this problem is simply to avoid this situation.
次に、同じインターフェイスから信頼されていないシステムと信頼されていないシステムがある場合にのみ、ラベルスプーフィングの問題が存在します。この問題を回避する1つの方法は、単にこの状況を避けることです。
Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and Liam Casey for their comments.
Ravi Chandra、Enke Chen、Srihari Ramachandra、Eric Gray、Liam Caseyのコメントに感謝します。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4] Rekhter、Y。およびT. Li、「Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
[BGP-CAP] Chandra、R。およびJ. Scudder、「BGP-4による機能広告」、RFC 2842、2000年5月。
[BGP-MP] Bates, T., Rekhter, Y, Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP] Bates、T.、Rekhter、Y、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[BGP-RR] Bates、T。およびR. Chandra、「BGPルートリフレクション：フルメッシュIBGPの代替」、RFC 1966、1996年6月。
[MPLS-ARCH] Rosen, E., Vishwanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture" RFC 3031, January 2001.
[MPLS-ARCH] Rosen、E.、Vishwanathan、A。およびR. Callon、「Multiprotocol Label Switching Architecture」RFC 3031、2001年1月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLS Label Stack Encoding」、RFC 3032、1月2001年。
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
Eric Rosen Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824
EMail: erosen@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。