[要約] RFC 8663は、MPLSセグメントルーティングをIP上で実現するためのプロトコル仕様です。その目的は、MPLSネットワークの柔軟性とスケーラビリティを向上させ、IPネットワーク上でセグメントルーティングを実現することです。
Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 8663 Alibaba, Inc
Category: Standards Track S. Bryant
ISSN: 2070-1721 Futurewei Technologies
A. Farrel
Old Dog Consulting
S. Hassan
Cisco
W. Henderickx
Nokia
Z. Li
Huawei
December 2019
MPLS Segment Routing over IP
IPを介したMPLSセグメントルーティング
Abstract
概要
MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.
MPLSセグメントルーティング（SR-MPLS）は、MPLSラベルのスタックをパケットに課してパスを指定することにより、MPLSデータプレーンを介してパケットをソースルーティングし、そのパスで実行するパケット固有の命令を指定します。 SR-MPLSを活用して、MPLSラベルスタックをソースルーティング命令セットとして使用し、SR-MPLS仕様に変更を加えず、SR-MPLSと相互運用することにより、MPLS、IPv4、およびIPv6データプレーン全体でソースルーティングメカニズムを実現できます。実装。
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510.
このドキュメントでは、RF-7510で定義されているSR-MPLSラベルスタックとMPLS-over-UDPなどのIPカプセル化/トンネリングを使用して、SR-MPLS対応ルーターとIP専用ルーターをシームレスに共存させ、相互運用する方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8663.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8663で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
2. Use Cases
3. Procedures of SR-MPLS-over-IP
3.1. Forwarding Entry Construction
3.1.1. FIB Construction Example
3.2. Packet-Forwarding Procedures
3.2.1. Packet Forwarding with Penultimate Hop Popping
3.2.2. Packet Forwarding without Penultimate Hop Popping
3.2.3. Additional Forwarding Procedures
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
MPLS Segment Routing (SR-MPLS) [RFC8660] is a method of source routing a packet through an MPLS data plane. This is achieved by the sender imposing a stack of MPLS labels that partially or completely specify the path that the packet is to take and any instructions to be executed on the packet as it passes through the network. SR-MPLS uses an MPLS label stack to encode a sequence of source-routing instructions. This can be used to realize a source-routing mechanism that can operate across MPLS, IPv4, and IPv6 data planes. This approach makes no changes to SR-MPLS specifications and allows interworking with SR-MPLS implementations. More specifically, the source-routing instructions in a source-routed packet could be uniformly encoded as an MPLS label stack regardless of whether the underlay is IPv4, IPv6 (including Segment Routing for IPv6 (SRv6) [RFC8354]), or MPLS.
MPLSセグメントルーティング（SR-MPLS）[RFC8660]は、MPLSデータプレーンを介してパケットをソースルーティングする方法です。これは、パケットが通過するパスを部分的または完全に指定するMPLSラベルのスタックと、パケットがネットワークを通過するときにパケットで実行される命令を課す送信者によって実現されます。 SR-MPLSはMPLSラベルスタックを使用して、一連のソースルーティング命令をエンコードします。これは、MPLS、IPv4、およびIPv6データプレーンで動作できるソースルーティングメカニズムを実現するために使用できます。このアプローチはSR-MPLS仕様に変更を加えず、SR-MPLS実装との相互作用を可能にします。より具体的には、ソースルーティングされたパケットのソースルーティング命令は、アンダーレイがIPv4、IPv6（Segment Routing for IPv6（SRv6）[RFC8354]を含む）、またはMPLSであるかどうかに関係なく、MPLSラベルスタックとして均一にエンコードできます。
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP [RFC7510].
このドキュメントでは、SR-MPLS対応のルーターとIP専用のルーターが、SR-MPLSラベルスタックとMPLS-over-UDP [RFC7510]などのIPカプセル化/トンネリングを使用してシームレスに共存し、相互運用する方法について説明します。
Section 2 describes various use cases for tunneling SR-MPLS over IP. Section 3 describes a typical application scenario and how the packet forwarding happens.
セクション2では、SR-MPLS over IPのトンネリングのさまざまな使用例について説明します。セクション3では、一般的なアプリケーションシナリオと、パケット転送の発生方法について説明します。
This memo makes use of the terms defined in [RFC3031] and [RFC8660].
このメモは、[RFC3031]と[RFC8660]で定義されている用語を利用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Tunneling SR-MPLS using IPv4 and/or IPv6 (including SRv6) tunnels is useful at least in the use cases listed below. In all cases, this can be enabled using an IP tunneling mechanism such as MPLS-over-UDP as described in [RFC7510]. The tunnel selected MUST have its remote endpoint (destination) address equal to the address of the next node capable of SR-MPLS identified as being on the SR path (i.e., the egress of the active segment). The local endpoint (source) address is set to an address of the encapsulating node. [RFC7510] gives further advice on how to set the source address if the UDP zero-checksum mode is used with MPLS-over-UDP. Using UDP as the encapsulation may be particularly beneficial because it is agnostic of the underlying transport.
IPv4および/またはIPv6（SRv6を含む）トンネルを使用したSR-MPLSのトンネリングは、少なくとも以下にリストしたユースケースで役立ちます。すべての場合において、これは、[RFC7510]で説明されているように、MPLS-over-UDPなどのIPトンネリングメカニズムを使用して有効にできます。選択されたトンネルは、SR-MPLSが可能な次のノードのアドレスと等しいリモートエンドポイント（宛先）アドレスをSRパス上にある（つまり、アクティブセグメントの出口）として識別しなければなりません（MUST）。ローカルエンドポイント（送信元）アドレスは、カプセル化ノードのアドレスに設定されます。 [RFC7510]は、UDPゼロチェックサムモードがMPLS-over-UDPで使用されている場合にソースアドレスを設定する方法についてさらにアドバイスを提供します。カプセル化としてUDPを使用すると、基になるトランスポートに依存しないため、特に有益な場合があります。
* Incremental deployment of the SR-MPLS technology may be facilitated by tunneling SR-MPLS packets across parts of a network that are not SR-MPLS as shown in Figure 1. This demonstrates how islands of SR-MPLS may be connected across a legacy network. It may be particularly useful for joining sites (such as data centers).
* SR-MPLSテクノロジーの段階的な導入は、図1に示すように、SR-MPLSではないネットワークの一部にSR-MPLSパケットをトンネリングすることで促進できます。これは、レガシーネットワーク全体でSR-MPLSのアイランドを接続する方法を示しています。これは、サイト（データセンターなど）の結合に特に役立ちます。
________________________
_______ ( ) _______
( ) ( IP Network ) ( )
( SR-MPLS ) ( ) ( SR-MPLS )
( Network ) ( ) ( Network )
( -------- -------- )
( | Border | SR-in-UDP Tunnel | Border | )
( | Router |========================| Router | )
( | R1 | | R2 | )
( -------- -------- )
( ) ( ) ( )
( ) ( ) ( )
(_______) ( ) (_______)
(________________________)
Figure 1: SR-MPLS-over-UDP to Tunnel between SR-MPLS Sites
図1：SR-MPLS-over-UDPからSR-MPLSサイト間のトンネル
* If the encoding of entropy [RFC6790] is desired, IP-tunneling mechanisms that allow the encoding of entropy, such as MPLS-over-UDP encapsulation [RFC7510] where the source port of the UDP header is used as an entropy field, may be used to maximize the utilization of Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs), especially when it is difficult to make use of the entropy-label mechanism. This is to be contrasted with [RFC4023] where MPLS-over-IP does not provide for an entropy mechanism. Refer to [RFC8662]) for more discussion about using entropy labels in SR-MPLS.
* エントロピーのエンコード[RFC6790]が必要な場合、MPLS-over-UDPカプセル化[RFC7510]などのエントロピーのエンコードを可能にするIPトンネリングメカニズムは、UDPヘッダーのソースポートがエントロピーフィールドとして使用され、特にエントロピーラベルメカニズムを利用することが困難な場合に、等コストマルチパス（ECMP）やリンク集約グループ（LAG）の利用を最大化するために使用されます。これは、MPLS-over-IPがエントロピーメカニズムを提供しない[RFC4023]と対照的です。 SR-MPLSでのエントロピーラベルの使用の詳細については、[RFC8662]を参照してください。
* Tunneling MPLS over IP provides a technology that enables Segment Routing (SR) in an IPv4 and/or IPv6 network where the routers do not support SRv6 capabilities [IPv6-SRH] and where MPLS forwarding is not an option. This is shown in Figure 2.
* MPLS over IPのトンネリングは、ルーターがSRv6機能[IPv6-SRH]をサポートせず、MPLS転送がオプションではないIPv4またはIPv6ネットワークでセグメントルーティング（SR）を有効にするテクノロジーを提供します。これを図2に示します。
__________________________________
__( IP Network )__
__( )__
( -- -- -- )
-------- -- -- |SR| -- |SR| -- |SR| -- --------
| Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress|
-->| Router |===========| |======| |======| |======| Router|-->
| SR | | | | | | | | | | | | | | | | | | SR |
-------- -- -- | | -- | | -- | | -- --------
(__ -- -- -- __)
(__ __)
(__________________________________)
Key:
IR : IP-only Router
SR : SR-MPLS-capable Router
== : SR-MPLS-over-UDP Tunnel
Figure 2: SR-MPLS Enabled within an IP Network
図2：IPネットワーク内で有効になっているSR-MPLS
This section describes the construction of forwarding information base (FIB) entries and the forwarding behavior that allow the deployment of SR-MPLS when some routers in the network are IP only (i.e., do not support SR-MPLS). Note that the examples in Sections 3.1.1 and 3.2 assume that OSPF or IS-IS is enabled; in fact, other mechanisms of discovery and advertisement could be used including other routing protocols (such as BGP) or a central controller.
このセクションでは、ネットワーク内の一部のルーターがIPのみである（つまり、SR-MPLSをサポートしていない）場合にSR-MPLSの展開を可能にする転送情報ベース（FIB）エントリの構築と転送動作について説明します。セクション3.1.1および3.2の例では、OSPFまたはIS-ISが有効になっていると想定しています。実際、他のルーティングプロトコル（BGPなど）やセントラルコントローラなど、他のディスカバリとアドバタイズのメカニズムを使用できます。
This subsection describes how to construct the forwarding information base (FIB) entry on an SR-MPLS-capable router when some or all of the next hops along the shortest path towards a prefix Segment Identifier (Prefix-SID) are IP-only routers. Section 3.1.1 provides a concrete example of how the process applies when using OSPF or IS-IS.
このサブセクションでは、プレフィックスセグメント識別子（Prefix-SID）への最短パスに沿ったネクストホップの一部またはすべてがIPのみのルーターである場合に、SR-MPLS対応ルーターで転送情報ベース（FIB）エントリを構築する方法について説明します。セクション3.1.1は、OSPFまたはIS-ISを使用するときにプロセスがどのように適用されるかの具体例を提供します。
Consider router A that receives a labeled packet with top label L(E) that corresponds to the Prefix-SID SID(E) of prefix P(E) advertised by router E. Suppose the i-th next-hop router (termed NHi) along the shortest path from router A toward SID(E) is not SR-MPLS capable while both routers A and E are SR-MPLS capable. The following processing steps apply:
ルーターEによってアドバタイズされたプレフィックスP（E）のプレフィックスSID SID（E）に対応するトップラベルL（E）のラベル付きパケットを受信するルーターAを考えます。i番目のネクストホップルーター（NHiと呼ばれる）を想定します。ルータAからSID（E）への最短パスに沿ってはSR-MPLSに対応していませんが、ルータAとEの両方はSR-MPLSに対応しています。以下の処理ステップが適用されます。
* Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB). The SRGB is defined in [RFC8402]. There are a number of ways that the advertisement can be achieved including IGPs, BGP, and configuration/management protocols. For example, see [DC-GATEWAY].
* ルーターEはSR-MPLS対応であるため、セグメントルーティンググローバルブロック（SRGB）をアドバタイズします。 SRGBは[RFC8402]で定義されています。 IGP、BGP、構成/管理プロトコルなど、アドバタイズを実現する方法はいくつかあります。たとえば、[DC-GATEWAY]を参照してください。
* When Router E advertises the Prefix-SID SID(E) of prefix P(E), it MUST also advertise the egress endpoint address and the encapsulation type of any tunnel used to reach E. This information is flooded domain wide.
* ルーターEがプレフィックスP（E）のプレフィックスSID SID（E）をアドバタイズするときは、Eに到達するために使用されるすべてのトンネルの出力エンドポイントアドレスとカプセル化タイプもアドバタイズする必要があります。
* If A and E are in different routing domains, then the information MUST be flooded into both domains. How this is achieved depends on the advertisement mechanism being used. The objective is that router A knows the characteristics of router E that originated the advertisement of SID(E).
* AとEが異なるルーティングドメインにある場合、情報は両方のドメインにフラッディングされる必要があります。これがどのように達成されるかは、使用されている通知メカニズムによって異なります。目的は、ルーターAがSID（E）の通知を発信したルーターEの特性を知っていることです。
* Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) according to whether a pop or swap action is advertised for the prefix. The resulting action may be:
* ルータAは、ポップアクションまたはスワップアクションがプレフィックスに対してアドバタイズされるかどうかに応じて、SID（E）に対応するプレフィックスP（E）のFIBエントリをプログラムします。結果のアクションは次のとおりです。
- pop the top label
- トップラベルをポップ
- swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E
- トップラベルをSID（E）にEのSRGBの下限を加えた値に置き換えます
Once constructed, the FIB can be used by a router to tell it how to process packets. It encapsulates the packets according to the appropriate encapsulation advertised for the segment and then sends the packets towards the next hop NHi.
構築されたFIBは、ルーターでパケットの処理方法を伝えるために使用できます。セグメントにアドバタイズされた適切なカプセル化に従ってパケットをカプセル化し、ネクストホップNHiに向けてパケットを送信します。
This section is non-normative and provides a worked example of how a FIB might be constructed using OSPF and IS-IS extensions. It is based on the process described in Section 3.1.
このセクションは非規範的であり、OSPFおよびIS-IS拡張を使用してFIBを構築する方法の実際の例を提供します。これは、セクション3.1で説明されているプロセスに基づいています。
* Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB) using [RFC8665] or [RFC8667].
* ルータEはSR-MPLS対応であるため、[RFC8665]または[RFC8667]を使用してセグメントルーティンググローバルブロック（SRGB）をアドバタイズします。
* When Router E advertises the Prefix-SID SID(E) of prefix P(E), it also advertises the encapsulation endpoint address and the tunnel type of any tunnel used to reach E using [ISIS-ENCAP] or [OSPF-ENCAP].
* ルーターEは、プレフィックスP（E）のプレフィックスSID SID（E）をアドバタイズするとき、カプセル化エンドポイントアドレスと、[ISIS-ENCAP]または[OSPF-ENCAP]を使用してEに到達するために使用されるトンネルのトンネルタイプもアドバタイズします。
* If A and E are in different domains, then the information is flooded into both domains and any intervening domains.
* AとEが異なるドメインにある場合、情報は両方のドメインと介在するドメインにフラッディングされます。
- The OSPF Tunnel Encapsulations TLV [OSPF-ENCAP] or the IS-IS Tunnel Encapsulation Type sub-TLV [ISIS-ENCAP] is flooded domain wide.
- OSPFトンネルカプセル化TLV [OSPF-ENCAP]またはIS-ISトンネルカプセル化タイプサブTLV [ISIS-ENCAP]は、ドメイン全体にフラッディングされます。
- The OSPF SID/Label Range TLV [RFC8665] or the IS-IS SR-Capabilities sub-TLV [RFC8667] is advertised domain wide so that router A knows the characteristics of router E.
- OSPF SID /ラベル範囲TLV [RFC8665]またはIS-IS SR-CapabilityサブTLV [RFC8667]はドメイン全体に通知されるため、ルーターAはルーターEの特性を認識します。
- When router E advertises the prefix P(E):
- ルータEがプレフィックスP（E）をアドバタイズする場合：
o If router E is running IS-IS, it uses the extended reachability TLV (TLVs 135, 235, 236, 237) and associates the IPv4/IPv6 or IPv4/IPv6 Source Router ID sub-TLV(s) [RFC7794].
o ルータEがIS-ISを実行している場合、拡張到達可能性TLV（TLV 135、235、236、237）を使用し、IPv4 / IPv6またはIPv4 / IPv6ソースルータIDサブTLVを関連付けます[RFC7794]。
o If router E is running OSPF, it uses the OSPFv2 Extended Prefix Opaque Link-State Advertisement (LSA) [RFC7684] and sets the flooding scope to Autonomous System (AS) wide.
o ルータEがOSPFを実行している場合、OSPFv2拡張プレフィックスの不透明リンク状態アドバタイズメント（LSA）[RFC7684]を使用し、フラッディングスコープを自律システム（AS）全体に設定します。
- If router E is running IS-IS and advertises the IS-IS Router CAPABILITY TLV (TLV 242) [RFC7981], it sets the "Router ID" field to a valid value or includes an IPv6 TE Router ID sub-TLV (TLV 12), or it does both. The "S" bit (flooding scope) of the IS-IS Router CAPABILITY TLV (TLV 242) is set to "1".
- ルーターEがIS-ISを実行していて、IS-ISルーターCAPABILITY TLV（TLV 242）[RFC7981]をアドバタイズする場合、「ルーターID」フィールドを有効な値に設定するか、IPv6 TEルーターIDサブTLV（TLV 12 ）、または両方を行います。 IS-ISルーターCAPABILITY TLV（TLV 242）の「S」ビット（フラッディングスコープ）が「1」に設定されます。
* Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) according to whether a pop or swap action is advertised for the prefix as follows:
* ルータAは、次のようにポップまたはスワップアクションがプレフィックスに対してアドバタイズされるかどうかに応じて、SID（E）に対応するプレフィックスP（E）のFIBエントリをプログラムします。
- If the No-PHP (NP) Flag in OSPF or the Persistent (P) Flag in IS-IS is clear:
- OSPFの非PHP（NP）フラグまたはIS-ISの永続的（P）フラグがクリアされている場合：
pop the top label
トップラベルをポップ
- If the No-PHP (NP) Flag in OSPF or the Persistent (P) Flag in IS-IS is set:
- OSPFの非PHP（NP）フラグまたはIS-ISの永続的（P）フラグが設定されている場合：
swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E
トップラベルをSID（E）にEのSRGBの下限を加えた値に置き換えます
When forwarding the packet according to the constructed FIB entry, the router encapsulates the packet according to the encapsulation as advertised using the mechanisms described in [ISIS-ENCAP] or [OSPF-ENCAP]. It then sends the packets towards the next hop NHi.
構築されたFIBエントリに従ってパケットを転送する場合、ルータは、[ISIS-ENCAP]または[OSPF-ENCAP]で説明されているメカニズムを使用してアドバタイズされたカプセル化に従ってパケットをカプセル化します。次に、パケットをネクストホップNHiに送信します。
Note that [RFC7510] specifies the use of port number 6635 to indicate that the payload of a UDP packet is MPLS, and port number 6636 for MPLS-over-UDP utilizing DTLS. However, [ISIS-ENCAP] and [OSPF-ENCAP] provide dynamic protocol mechanisms to configure the use of any Dynamic Port for a tunnel that uses UDP encapsulation. Nothing in this document prevents the use of an IGP or any other mechanism to negotiate the use of a Dynamic Port when UDP encapsulation is used for SR-MPLS, but if no such mechanism is used, then the port numbers specified in [RFC7510] are used.
[RFC7510]は、UDPパケットのペイロードがMPLSであることを示すためにポート番号6635の使用を指定し、DTLSを利用するMPLS-over-UDPの場合はポート番号6636を指定することに注意してください。ただし、[ISIS-ENCAP]と[OSPF-ENCAP]は、UDPカプセル化を使用するトンネルの動的ポートの使用を構成する動的プロトコルメカニズムを提供します。このドキュメントでは、SR-MPLSにUDPカプセル化が使用されている場合、IGPまたはその他のメカニズムを使用して動的ポートの使用をネゴシエートすることを妨げるものはありませんが、そのようなメカニズムが使用されていない場合、[RFC7510]で指定されているポート番号は中古。
[RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS-over-UDP. This approach is applicable where IP-based encapsulation for MPLS is required and further fine-grained load balancing of MPLS packets over IP networks over ECMP and/or LAGs is also required. This section provides details about the forwarding procedure when UDP encapsulation is adopted for SR-MPLS-over-IP. Other encapsulation and tunneling mechanisms can be applied using similar techniques, but for clarity, this section uses UDP encapsulation as the exemplar.
[RFC7510]は、MPLSのIPベースのカプセル化、つまりMPLS-over-UDPを指定します。このアプローチは、MPLSのIPベースのカプセル化が必要な場合に適用でき、ECMPやLAGを介したIPネットワークを介したMPLSパケットの詳細なロードバランシングも必要です。このセクションでは、SR-MPLS-over-IPにUDPカプセル化が採用されている場合の転送手順について詳しく説明します。他のカプセル化およびトンネリングメカニズムは、同様の手法を使用して適用できますが、わかりやすくするために、このセクションでは、UDPカプセル化を例として使用しています。
Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may be "legacy routers" that cannot handle SR-MPLS packets but can forward IP packets. A node capable of SR-MPLS MAY advertise its capabilities using the IGP as described in Section 3. There are six types of nodes in an SR-MPLS domain:
SR-MPLS対応のノードは、SR-MPLSパケットを処理できます。 SR-MPLSドメインのすべてのノードがSR-MPLSに対応しているわけではありません。一部のノードは、SR-MPLSパケットを処理できないがIPパケットを転送できる「レガシールーター」である場合があります。 SR-MPLSに対応するノードは、セクション3で説明されているように、IGPを使用してその機能をアドバタイズする場合があります。
* Domain ingress nodes that receive packets and encapsulate them for transmission across the domain. Those packets may be any payload protocol including native IP packets or packets that are already MPLS encapsulated.
* パケットを受信し、ドメイン全体に送信するためにそれらをカプセル化するドメイン入力ノード。これらのパケットは、ネイティブIPパケットまたはすでにMPLSカプセル化されているパケットを含む任意のペイロードプロトコルです。
* Legacy transit nodes that are IP routers but that are not SR-MPLS capable (i.e., are not able to perform Segment Routing).
* IPルーターであるがSR-MPLSに対応していない（つまり、セグメントルーティングを実行できない）レガシートランジットノード。
* Transit nodes that are SR-MPLS capable but that are not identified by a SID in the SID stack.
* SR-MPLS対応であるが、SIDスタック内のSIDで識別されないトランジットノード。
* Transit nodes that are SR-MPLS capable and need to perform SR-MPLS routing because they are identified by a SID in the SID stack.
* SR-MPLS対応であり、SIDスタック内のSIDによって識別されるため、SR-MPLSルーティングを実行する必要があるトランジットノード。
* The penultimate node capable of SR-MPLS on the path that processes the last SID on the stack on behalf of the domain egress node.
* ドメイン出口ノードに代わってスタックの最後のSIDを処理するパスでSR-MPLSが可能な最後から2番目のノード。
* The domain egress node that forwards the payload packet for ultimate delivery.
* 最終的な配信のためにペイロードパケットを転送するドメイン出力ノード。
The description in this section assumes that the label associated with each Prefix-SID is advertised by the owner of the Prefix-SID as a Penultimate Hop-Popping (PHP) label. That is, if one of the IGP flooding mechanisms is used, the NP-Flag in OSPF or the P-Flag in IS-IS associated with the Prefix-SID is not set.
このセクションの説明では、各Prefix-SIDに関連付けられたラベルが、Prefix-SIDの所有者によってPenultimate Hop-Popping（PHP）ラベルとしてアドバタイズされることを前提としています。つまり、IGPフラッディングメカニズムの1つが使用されている場合、OSPFのNP-FlagまたはPrefix-SIDに関連付けられたIS-ISのP-Flagは設定されません。
+-----+ +-----+ +-----+ +-----+ +-----+
| A +-------+ B +-------+ C +-------+ D +-------+ H |
+-----+ +--+--+ +--+--+ +--+--+ +-----+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +-------+ F +-------+ G |
+-----+ +-----+ +-----+
+--------+
|IP(A->E)|
+--------+ +--------+ +--------+
| UDP | |IP(E->G)| |IP(G->H)|
+--------+ +--------+ +--------+
| L(G) | | UDP | | UDP |
+--------+ +--------+ +--------+
| L(H) | | L(H) | |Exp Null|
+--------+ +--------+ +--------+
| Packet | ---> | Packet | ---> | Packet |
+--------+ +--------+ +--------+
Figure 3: Packet-Forwarding Example with PHP
図3：PHPを使用したパケット転送の例
In the example shown in Figure 3, assume that routers A, E, G, and H are capable of SR-MPLS while the remaining routers (B, C, D, and F) are only capable of forwarding IP packets. Routers A, E, G, and H advertise their Segment Routing related information, such as via IS-IS or OSPF.
図3の例では、ルーターA、E、G、HがSR-MPLSに対応し、残りのルーター（B、C、D、F）はIPパケットの転送のみに対応していると想定しています。ルータA、E、G、Hは、IS-ISやOSPFなどを介して、セグメントルーティング関連の情報をアドバタイズします。
Now assume that router A (the Domain ingress) wants to send a packet to router H (the Domain egress) via the explicit path {E->G->H}. Router A will impose an MPLS label stack on the packet that corresponds to that explicit path. Since the next hop toward router E is only IP capable (B is a legacy transit node), router A replaces the top label (that indicated router E) with a UDP-based tunnel for MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the packet. In other words, router A pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router E.
次に、ルーターA（ドメインの入口）が明示的なパス{E-> G-> H}を介してルーターH（ドメインの出口）にパケットを送信したいとします。ルータAは、その明示的なパスに対応するパケットにMPLSラベルスタックを課します。ルーターEへのネクストホップはIPにのみ対応しているため（Bはレガシートランジットノード）、ルーターAはトップラベル（ルーターEと示されている）をMPLSのUDPベースのトンネル（つまり、MPLS-over-UDP [RFC7510 ]）をルーターEに送信し、パケットを送信します。つまり、ルータAはトップラベルをポップし、MPLSパケットをルータEへのUDPトンネルにカプセル化します。
When the IP-encapsulated MPLS packet arrives at router E (which is a transit node capable of SR-MPLS), router E strips the IP-based tunnel header and then processes the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router G. Since the next hop toward router G is only IP capable, router E replaces the current top label with an MPLS-over-UDP tunnel toward router G and sends it out. That is, router E pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router G.
IPカプセル化MPLSパケットがルーターE（SR-MPLS対応の中継ノード）に到着すると、ルーターEはIPベースのトンネルヘッダーを取り除き、カプセル化解除されたMPLSパケットを処理します。トップラベルは、パケットをルーターGに転送する必要があることを示しています。ルーターGへのネクストホップはIPにのみ対応しているため、ルーターEは現在のトップラベルをルーターGへのMPLS-over-UDPトンネルに置き換えて送信します。つまり、ルータEはトップラベルをポップし、MPLSパケットをルータGへのUDPトンネルにカプセル化します。
When the packet arrives at router G, router G will strip the IP-based tunnel header and then process the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router H. Since the next hop toward router H is only IP capable (D is a legacy transit router), router G would replace the current top label with an MPLS-over-UDP tunnel toward router H and send it out. However, since router G reaches the bottom of the label stack (G is the penultimate node capable of SR-MPLS on the path), this would leave the original packet that router A wanted to send to router H encapsulated in UDP as if it was MPLS (i.e., with a UDP header and destination port indicating MPLS) even though the original packet could have been any protocol. That is, the final SR-MPLS has been popped exposing the payload packet.
パケットがルーターGに到着すると、ルーターGはIPベースのトンネルヘッダーを取り除き、カプセル化解除されたMPLSパケットを処理します。トップラベルは、パケットをルーターHに転送する必要があることを示しています。ルーターHへのネクストホップはIPにのみ対応しているため（Dはレガシートランジットルーター）、ルーターGは現在のトップラベルをMPLS-over-UDPトンネルに置き換えます。ルータHに向けて送信します。ただし、ルーターGはラベルスタックの最下部（Gはパス上のSR-MPLSに対応する最後から2番目のノード）に到達するため、ルーターAがルーターHに送信しようとした元のパケットは、UDPにカプセル化されたかのように残ります。元のパケットが任意のプロトコルであったとしても、MPLS（つまり、UDPヘッダーと宛先ポートがMPLSを示す）。つまり、最後のSR-MPLSがポップされ、ペイロードパケットが公開されています。
To handle this, when a router (here it is router G) pops the final SR-MPLS label, it inserts an explicit NULL label [RFC3032] before encapsulating the packet in an MPLS-over-UDP tunnel toward router H and sending it out. That is, router G pops the top label, discovers it has reached the bottom of stack, pushes an explicit NULL label, and then encapsulates the MPLS packet in a UDP tunnel to router H.
これを処理するために、ルーター（ここではルーターG）が最後のSR-MPLSラベルをポップすると、ルーターHへのMPLS-over-UDPトンネルでパケットをカプセル化して送信する前に、明示的なNULLラベル[RFC3032]が挿入されます。 。つまり、ルーターGは最上位のラベルをポップし、スタックの最下部に達したことを検出し、明示的なNULLラベルをプッシュし、ルーターHへのUDPトンネルでMPLSパケットをカプセル化します。
Figure 4 demonstrates the packet walk in the case where the label associated with each Prefix-SID advertised by the owner of the Prefix-SID is not a Penultimate Hop-Popping (PHP) label (e.g., the NP-Flag in OSPF or the P-Flag in IS-IS associated with the Prefix-SID is set). Apart from the PHP function, the roles of the routers are unchanged from Section 3.2.1.
図4は、Prefix-SIDの所有者によってアドバタイズされた各Prefix-SIDに関連付けられたラベルがPenultimate Hop-Popping（PHP）ラベルではない場合（たとえば、OSPFのNP-FlagまたはP -Prefix-SIDに関連付けられたIS-ISのフラグが設定されます）。 PHP関数を除いて、ルーターの役割はセクション3.2.1から変更されていません。
+-----+ +-----+ +-----+ +-----+ +-----+
| A +-------+ B +-------+ C +--------+ D +--------+ H |
+-----+ +--+--+ +--+--+ +--+--+ +-----+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +-------+ F +--------+ G |
+-----+ +-----+ +-----+
+--------+
|IP(A->E)|
+--------+ +--------+
| UDP | |IP(E->G)|
+--------+ +--------+ +--------+
| L(E) | | UDP | |IP(G->H)|
+--------+ +--------+ +--------+
| L(G) | | L(G) | | UDP |
+--------+ +--------+ +--------+
| L(H) | | L(H) | | L(H) |
+--------+ +--------+ +--------+
| Packet | ---> | Packet | ---> | Packet |
+--------+ +--------+ +--------+
Figure 4: Packet-Forwarding Example without PHP
図4：PHPを使用しないパケット転送の例
As can be seen from the figure, the SR-MPLS label for each segment is left in place until the end of the segment where it is popped and the next instruction is processed.
図からわかるように、各セグメントのSR-MPLSラベルは、それがポップされて次の命令が処理されるセグメントの終わりまでそのままです。
Non-MPLS Interfaces: Although the description in the previous two sections is based on the use of Prefix-SIDs, tunneling SR-MPLS packets is useful when the top label of a received SR-MPLS packet indicates an Adjacency SID and the corresponding adjacent node to that Adjacency SID is not capable of MPLS forwarding but can still process SR-MPLS packets. In this scenario, the top label would be replaced by an IP tunnel toward that adjacent node and then forwarded over the corresponding link indicated by the Adjacency SID.
非MPLSインターフェイス：前の2つのセクションの説明はPrefix-SIDの使用に基づいていますが、SR-MPLSパケットのトンネリングは、受信したSR-MPLSパケットのトップラベルが隣接SIDと対応する隣接ノードを示している場合に役立ちます。その隣接SIDに対しては、MPLS転送はできませんが、SR-MPLSパケットを処理できます。このシナリオでは、最上位ラベルはその隣接ノードへのIPトンネルに置き換えられ、隣接SIDによって示される対応するリンクを介して転送されます。
When to Use IP-Based Tunnels: The description in the previous two sections is based on the assumption that an MPLS-over-UDP tunnel is used when the next hop towards the next segment is not MPLS enabled. However, even in the case where the next hop towards the next segment is MPLS capable, an MPLS-over-UDP tunnel towards the next segment could still be used instead due to local policies. For instance, in the example as described in Figure 4, assume F is now a transit node capable of SR-MPLS while all the other assumptions remain unchanged; since F is not identified by a SID in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP according to local policies, router E replaces the current top label with an MPLS-over-UDP tunnel toward router G and sends it out. (Note that if an MPLS LSP was preferred, the packet would be forwarded as native SR-MPLS.)
IPベースのトンネルを使用する場合：前の2つのセクションの説明は、次のセグメントへのネクストホップでMPLSが有効になっていない場合にMPLS-over-UDPトンネルが使用されるという前提に基づいています。ただし、次のセグメントへのネクストホップがMPLS対応である場合でも、ローカルポリシーにより、代わりに次のセグメントへのMPLS-over-UDPトンネルを使用できます。たとえば、図4で説明されている例では、FがSR-MPLSに対応できるトランジットノードであり、他のすべての仮定は変更されていないと仮定します。 Fはスタック内のSIDによって識別されず、MPLS-over-UDPトンネルはローカルポリシーに従ってMPLS LSPよりも優先されるため、ルーターEは現在のトップラベルをルーターGに向かうMPLS-over-UDPトンネルに置き換えて送信しますそれを出します。 （MPLS LSPが優先された場合、パケットはネイティブSR-MPLSとして転送されることに注意してください。）
IP Header Fields: When encapsulating an MPLS packet in UDP, the resulting packet is further encapsulated in IP for transmission. IPv4 or IPv6 may be used according to the capabilities of the network. The address fields are set as described in Section 2. The other IP header fields (such as the ECN field [RFC6040], the Differentiated Services Code Point (DSCP) [RFC2983], or IPv6 Flow Label) on each UDP-encapsulated segment SHOULD be configurable according to the operator's policy; they may be copied from the header of the incoming packet; they may be promoted from the header of the payload packet; they may be set according to instructions programmed to be associated with the SID; or they may be configured dependent on the outgoing interface and payload. The TTL field setting in the encapsulating packet header is handled as described in [RFC7510], which refers to [RFC4023].
IPヘッダーフィールド：MPLSパケットをUDPでカプセル化する場合、結果のパケットはIPにさらにカプセル化されて送信されます。 IPv4またはIPv6は、ネットワークの機能に応じて使用できます。アドレスフィールドは、セクション2で説明されているように設定されます。各UDPカプセル化セグメント上の他のIPヘッダーフィールド（ECNフィールド[RFC6040]、Differentiated Services Code Point（DSCP）[RFC2983]、IPv6フローラベルなど）は、SHOULDオペレーターのポリシーに従って構成可能であること。それらは着信パケットのヘッダーからコピーできます。ペイロードパケットのヘッダーから昇格される場合があります。それらは、SIDに関連付けられるようにプログラムされた指示に従って設定できます。または、発信インターフェイスとペイロードに応じて設定できます。カプセル化パケットヘッダーのTTLフィールド設定は、[RFC4023]を参照する[RFC7510]で説明されているように処理されます。
Entropy and ECMP: When encapsulating an MPLS packet with an IP tunnel header that is capable of encoding entropy (such as [RFC7510]), the corresponding entropy field (the source port in the case of a UDP tunnel) MAY be filled with an entropy value that is generated by the encapsulator to uniquely identify a flow. However, what constitutes a flow is locally determined by the encapsulator. For instance, if the MPLS label stack contains at least one entropy label and the encapsulator is capable of reading that entropy label, the entropy label value could be directly copied to the source port of the UDP header. Otherwise, the encapsulator may have to perform a hash on the whole label stack or the five-tuple of the SR-MPLS payload if the payload is determined as an IP packet. To avoid recalculating the hash or hunting for the entropy label each time the packet is encapsulated in a UDP tunnel, it MAY be desirable that the entropy value contained in the incoming packet (i.e., the UDP source port value) is retained when stripping the UDP header and is reused as the entropy value of the outgoing packet.
エントロピーとECMP：エントロピーをエンコードできるIPトンネルヘッダー（[RFC7510]など）を使用してMPLSパケットをカプセル化する場合、対応するエントロピーフィールド（UDPトンネルの場合はソースポート）にエントロピーを埋めてもよい（MAY）フローを一意に識別するためにカプセル化装置によって生成される値。ただし、フローを構成するものは、カプセル化装置によってローカルに決定されます。たとえば、MPLSラベルスタックに少なくとも1つのエントロピーラベルが含まれていて、カプセル化機能がそのエントロピーラベルを読み取ることができる場合、エントロピーラベルの値をUDPヘッダーの送信元ポートに直接コピーできます。それ以外の場合、ペイロードがIPパケットとして決定された場合、カプセル化装置は、ラベルスタック全体またはSR-MPLSペイロードの5タプルでハッシュを実行する必要がある場合があります。パケットがUDPトンネルにカプセル化されるたびにエントロピーラベルのハッシュまたはハンティングを再計算しないようにするには、UDPを取り除くときに着信パケットに含まれるエントロピー値（つまり、UDP送信元ポート値）を保持することが望ましいヘッダーであり、発信パケットのエントロピー値として再利用されます。
Congestion Considerations: Section 5 of [RFC7510] provides a detailed analysis of the implications of congestion in MPLS-over-UDP systems and builds on Section 3.1.3 of [RFC8085], which describes the congestion implications of UDP tunnels. All of those considerations apply to SR-MPLS-over-UDP tunnels as described in this document. In particular, it should be noted that the traffic carried in SR-MPLS flows is likely to be IP traffic.
輻輳の考慮事項：[RFC7510]のセクション5は、MPLS-over-UDPシステムにおける輻輳の影響の詳細な分析を提供し、[RFC8085]のセクション3.1.3に基づいて構築されており、UDPトンネルの輻輳の影響について説明しています。これらの考慮事項はすべて、このドキュメントで説明されているSR-MPLS-over-UDPトンネルに適用されます。特に、SR-MPLSフローで伝送されるトラフィックはIPトラフィックである可能性が高いことに注意してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The security consideration of [RFC8354] (which redirects the reader to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used where security is needed on an SR-MPLS-over-UDP segment including when the IP segment crosses the public Internet or some other untrusted environment. [RFC8402] provides security considerations for Segment Routing, and Section 8.1 of [RFC8402] is particularly applicable to SR-MPLS.
[読者を[RFC5095]にリダイレクトする）[RFC8354]および[RFC7510]のセキュリティに関する考慮事項が適用されます。 DTLS [RFC6347]は、IPセグメントがパブリックインターネットやその他の信頼できない環境を通過する場合を含め、SR-MPLS-over-UDPセグメントでセキュリティが必要な場合に使用する必要があります（SHOULD）。 [RFC8402]はセグメントルーティングのセキュリティに関する考慮事項を提供し、[RFC8402]のセクション8.1は特にSR-MPLSに適用されます。
It is difficult for an attacker to pass a raw MPLS-encoded packet into a network, and operators have considerable experience in excluding such packets at the network boundaries, for example, by excluding all packets that are revealed to be carrying an MPLS packet as the payload of IP tunnels. Further discussion of MPLS security is found in [RFC5920].
攻撃者が未加工のMPLSエンコードされたパケットをネットワークに渡すことは困難であり、オペレーターは、たとえばMPLSパケットをIPトンネルのペイロード。 MPLSセキュリティの詳細については、[RFC5920]で説明されています。
It is easy for a network ingress node to detect any attempt to smuggle an IP packet into the network since it would see that the UDP destination port was set to MPLS, and such filtering SHOULD be applied. If, however, the mechanisms described in [RFC8665] or [RFC8667] are applied, a wider variety of UDP port numbers might be in use making port filtering harder.
UDP宛先ポートがMPLSに設定されていることがわかり、そのようなフィルタリングを適用する必要があるため、ネットワーク入力ノードがIPパケットをネットワークに密輸しようとする試みを簡単に検出できます。ただし、[RFC8665]または[RFC8667]で説明されているメカニズムが適用されている場合、さまざまなUDPポート番号が使用されている可能性があり、ポートフィルタリングが困難になります。
SR packets not having a destination address terminating in the network would be transparently carried and would pose no different security risk to the network under consideration than any other traffic.
ネットワークで終端する宛先アドレスを持たないSRパケットは透過的に伝送され、検討中のネットワークに他のトラフィックと異なるセキュリティリスクをもたらすことはありません。
Where control-plane techniques are used (as described in Section 3), it is important that these protocols are adequately secured for the environment in which they are run as discussed in [RFC6862] and [RFC5920].
コントロールプレーン技術が使用される場合（セクション3で説明）、これらのプロトコルは、[RFC6862]と[RFC5920]で説明されているように、それらが実行される環境に対して適切に保護されることが重要です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487 / RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <https://www.rfc-editor.org/info/rfc4023>.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<https：/ /www.rfc-editor.org/info/rfc4023>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、DOI 10.17487 / RFC5095、2007年12月、<https：//www.rfc -editor.org/info/rfc5095>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<https://www.rfc-editor.org/info/rfc6040>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.
[RFC7510] Xu、X.、Sheth、N.、Yong、L.、Callon、R。、およびD. Black、「UDPでのMPLSのカプセル化」、RFC 7510、DOI 10.17487 / RFC7510、2015年4月、<https：/ /www.rfc-editor.org/info/rfc7510>。
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7684] Psenak、P.、Gredler、H.、Shakir、R.、Henderickx、W.、Tantsura、J。、およびA. Lindem、「OSPFv2 Prefix / Link Attribute Advertisement」、RFC 7684、DOI 10.17487 / RFC7684、 2015年11月、<https://www.rfc-editor.org/info/rfc7684>。
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC7794] Ginsberg、L.、Ed。、Decraene、B.、Previdi、S.、Xu、X。、およびU. Chunduri、「拡張IPv4およびIPv6到達可能性のためのIS-ISプレフィックス属性」、RFC 7794、DOI 10.17487 / RFC7794、2016年3月、<https://www.rfc-editor.org/info/rfc7794>。
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.
[RFC7981] Ginsberg、L.、Previdi、S。、およびM. Chen、「IS-IS Extensions for Advertising Router Information」、RFC 7981、DOI 10.17487 / RFC7981、2016年10月、<https：//www.rfc-editor .org / info / rfc7981>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8660] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8660] Bashandy、A.、Filsfils、C.、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660、DOI 10.17487 / RFC8660 、2019年12月、<https://www.rfc-editor.org/info/rfc8660>。
[DC-GATEWAY] Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil, "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", Work in Progress, Internet-Draft, draft-ietf-bess-datacenter-gateway-04, 21 August 2019, <https://tools.ietf.org/html/ draft-ietf-bess-datacenter-gateway-04>.
[DC-GATEWAY] Farrel、A.、Drake、J.、Rosen、E.、Patel、K。、およびL. Jalil、「セグメントルーティングが有効なドメインの相互接続のためのゲートウェイの自動検出とルートアドバタイズ」、進行中の作業、 Internet-Draft、draft-ietf-bess-datacenter-gateway-04、2019年8月21日、<https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-04>。
[IPv6-SRH] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man-segment-routing-header-26, 22 October 2019, <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>.
[IPv6-SRH] Filsfils、C.、Dukes、D.、Previdi、S.、Leddy、J.、Matsushima、S。、およびD. Voyer、「IPv6 Segment Routing Header（SRH）」、Work in Progress、インターネット-Draft、draft-ietf-6man-segment-routing-header-26、2019年10月22日、<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>。
[ISIS-ENCAP] Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, L., and L. Jalil, "Advertising Tunnelling Capability in IS-IS", Work in Progress, Internet-Draft, draft-ietf-isis-encapsulation-cap-01, 24 April 2017, <https://tools.ietf.org/html/draft-ietf-isis-encapsulation-cap-01>.
[ISIS-ENCAP] Xu、X.、Decraene、B.、Raszuk、R.、Chunduri、U.、Contreras、L。、およびL. Jalil、「IS-ISでの広告トンネリング機能」、Work in Progress、インターネット-Draft、draft-ietf-isis-encapsulation-cap-01、2017年4月24日、<https://tools.ietf.org/html/draft-ietf-isis-encapsulation-cap-01>。
[OSPF-ENCAP] Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. Jalil, "The Tunnel Encapsulations OSPF Router Information", Work in Progress, Internet-Draft, draft-ietf-ospf-encapsulation-cap-09, 10 October 2017, <https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-09>.
[OSPF-ENCAP] Xu、X.、Decraene、B.、Raszuk、R.、Contreras、L。、およびL. Jalil、「トンネルカプセル化OSPFルーター情報」、作業中、インターネットドラフト、draft-ietf -ospf-encapsulation-cap-09、2017年10月10日、<https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-09>。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<https://www.rfc-editor.org/info/rfc2983>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、and L. Yong、 "The Use of Entropy Labels in MPLS Forwarding"、RFC 6790、DOI 10.17487 / RFC6790、November 2012、 <https://www.rfc-editor.org/info/rfc6790>。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, DOI 10.17487/RFC6862, March 2013, <https://www.rfc-editor.org/info/rfc6862>.
[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル（KARP）のキーイングと認証の概要、脅威、および要件」、RFC 6862、DOI 10.17487 / RFC6862、2013年3月、<https： //www.rfc-editor.org/info/rfc6862>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Routing in Networking (SPRING)", RFC 8354, DOI 10.17487/RFC8354, March 2018, <https://www.rfc-editor.org/info/rfc8354>.
[RFC8354] Brzozowski、J.、Leddy、J.、Filsfils、C.、Maglione、R.、Ed。、and M. Townsley、 "Use Cases for IPv6 Source Packet Routing in Networking（SPRING）"、RFC 8354、DOI 10.17487 / RFC8354、2018年3月、<https://www.rfc-editor.org/info/rfc8354>。
[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels", RFC 8662, DOI 10.17487/RFC8662, December 2019, <https://www.rfc-editor.org/info/rfc8662>.
[RFC8662] Kini、S.、Kompella、K.、Sivabalan、S.、Litkowski、S.、Shakir、R。、およびJ. Tantsura、「ネットワーク（SPRING）トンネルにおけるソースパケットルーティングのエントロピーラベル」、RFC 8662 、DOI 10.17487 / RFC8662、2019年12月、<https://www.rfc-editor.org/info/rfc8662>。
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<https://www.rfc-editor.org/info/rfc8665>。
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8667] Previdi、S.、Ed。、Ginsberg、L.、Ed。、Filsfils、C.、Bashandy、A.、Gredler、H.、and B. Decraene、 "IS-IS Extensions for Segment Routing"、RFC 8667、DOI 10.17487 / RFC8667、2019年12月、<https://www.rfc-editor.org/info/rfc8667>。
Acknowledgements
謝辞
Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert Sparks, and Al Morton for their insightful comments on this document.
このドキュメントに対する洞察に満ちたコメントを提供してくれたJoel Halpern、Bruno Decraene、Loa Andersson、Ron Bonica、Eric Rosen、Jim Guichard、Gunter Van De Velde、Andy Malis、Robert Sparks、Al Mortonに感謝します。
Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer Dawkins, Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric Vyncke for careful reviews and resulting comments.
Mirja Kuehlewind、Alvaro Retana、Spencer Dawkins、Benjamin Kaduk、Martin Vigoureux、Suresh Krishnan、Eric Vynckeに、慎重なレビューとコメントを提供してくれたことにさらに感謝します。
Contributors
貢献者
Ahmed Bashandy Individual Email: abashandy.ietf@gmail.com
Ahmed Bashandy個人メール：abashandy.ietf@gmail.com
Clarence Filsfils Cisco Email: cfilsfil@cisco.com
Clarence Filsfilsシスコの電子メール：cfilsfil@cisco.com
John Drake Juniper Email: jdrake@juniper.net
ジョンドレイクジュニパーメール：jdrake@juniper.net
Shaowen Ma Mellanox Technologies Email: mashaowen@gmail.com
Shaowen Ma Mellanox Technologiesメール：mashaowen@gmail.com
Mach Chen Huawei Email: mach.chen@huawei.com
Mach Chen Huaweiメール：mach.chen@huawei.com
Hamid Assarpour Broadcom Email:hamid.assarpour@broadcom.com
Hamid Assarpour Broadcomメール：hamid.assarpour@broadcom.com
Robert Raszuk Bloomberg LP Email: robert@raszuk.net
Robert Raszuk Bloomberg LPメール：robert@raszuk.net
Uma Chunduri Huawei Email: uma.chunduri@gmail.com
Uma Chunduri Huaweiメール：uma.chunduri@gmail.com
Luis M. Contreras Telefonica I+D Email: luismiguel.contrerasmurillo@telefonica.com
Luis M. Contreras Telefonica I + Dメール：luismiguel.contrerasmurillo@telefonica.com
Luay Jalil Verizon Email: luay.jalil@verizon.com
Luay Jalil Verizonメール：luay.jalil@verizon.com
Gunter Van De Velde Nokia Email: gunter.van_de_velde@nokia.com
Gunter Van De Velde Nokiaメール：gunter.van_de_velde@nokia.com
Tal Mizrahi Marvell Email: talmi@marvell.com
Tal Mizrahi Marvellメール：talmi@marvell.com
Jeff Tantsura Apstra, Inc. Email: jefftant.ietf@gmail.com
Jeff Tantsura Apstra、Inc.メール：jefftant.ietf@gmail.com
Authors' Addresses
著者のアドレス
Xiaohu Xu Alibaba, Inc
ξOutbackX UA Dad raccoon、Inc
Email: xiaohu.xxh@alibaba-inc.com
Stewart Bryant Futurewei Technologies
Stewart Bryant Futurewei Technologies
Email: stewart.bryant@gmail.com
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Email: adrian@olddog.co.uk
Syed Hassan Cisco
サイードハッサンシスコ
Email: shassan@cisco.com
Wim Henderickx Nokia
Wim Henderickxノキア
Email: wim.henderickx@nokia.com
Zhenbin Li Huawei
Zは非常にビンl IH UAは
Email: lizhenbin@huawei.com