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
                                                           W. Henderickx
                                                                   Z. Li
                                                           December 2019

MPLS Segment Routing over IP




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.


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


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 ( 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トラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
   Authors' Addresses
1. Introduction
1. はじめに

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では、一般的なアプリケーションシナリオと、パケット転送の発生方法について説明します。

1.1. Terminology
1.1. 用語

This memo makes use of the terms defined in [RFC3031] and [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.


2. Use Cases
2. ユースケース

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


* 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  |
          --------   --   --  |  |  --  |  |  --  |  |  --   --------
               (__             --        --        --       __)
                  (__                                    __)
          IR : IP-only Router
          SR : SR-MPLS-capable Router
          == : SR-MPLS-over-UDP Tunnel

Figure 2: SR-MPLS Enabled within an IP Network


3. Procedures of SR-MPLS-over-IP
3. SR-MPLS-over-IPの手順

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.


3.1. Forwarding Entry Construction
3.1. 転送エントリの構築

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.


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.


3.1.1. FIB Construction Example
3.1.1. FIBの作成例

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.


* 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


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.


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.


3.2. Packet-Forwarding Procedures
3.2. パケット転送手順

[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.


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.

* 最終的な配信のためにペイロードパケットを転送するドメイン出力ノード。

3.2.1. Packet Forwarding with Penultimate Hop Popping
3.2.1. 最後から2番目のホップポッピングを使用したパケット転送

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  |
                    +-----+       +-----+       +-----+
           +--------+                 +--------+        +--------+
           |  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


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.


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.


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.


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パケットをカプセル化します。

3.2.2. Packet Forwarding without Penultimate Hop Popping
3.2.2. 最後から2番目のホップポッピングのないパケット転送

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  |
                   +-----+       +-----+        +-----+
          +--------+                 +--------+
          |  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


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.


3.2.3. Additional Forwarding Procedures
3.2.3. 追加の転送手順

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.


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.


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.


4. IANA Considerations
4. IANAに関する考慮事項

This document has no IANA actions.


5. Security Considerations
5. セキュリティに関する考慮事項

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.


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.


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].


6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、< rfc2119>。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <>.

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、< / 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, <>.

[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487 / RFC3032、2001年1月、<>。

[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, <>.

[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation(GRE)でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<https:/ />。

[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, <>.

[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>。

[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <>.

[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<>。

[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <>.

[RFC7510] Xu、X.、Sheth、N.、Yong、L.、Callon、R。、およびD. Black、「UDPでのMPLSのカプセル化」、RFC 7510、DOI 10.17487 / RFC7510、2015年4月、<https:/ />。

[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, <>.

[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月、<>。

[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, <>.

[RFC7794] Ginsberg、L.、Ed。、Decraene、B.、Previdi、S.、Xu、X。、およびU. Chunduri、「拡張IPv4およびIPv6到達可能性のためのIS-ISプレフィックス属性」、RFC 7794、DOI 10.17487 / RFC7794、2016年3月、<>。

[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <>.

[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, <>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、< 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, <>.

[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<>。

[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, <>.

[RFC8660] Bashandy、A.、Filsfils、C.、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660、DOI 10.17487 / RFC8660 、2019年12月、<>。

6.2. Informative References
6.2. 参考引用

[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, < 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日、<>。

[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, <>.

[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日、<>。

[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, <>.

[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日、<>。

[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, <>.

[OSPF-ENCAP] Xu、X.、Decraene、B.、Raszuk、R.、Contreras、L。、およびL. Jalil、「トンネルカプセル化OSPFルーター情報」、作業中、インターネットドラフト、draft-ietf -ospf-encapsulation-cap-09、2017年10月10日、<>。

[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <>.

[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<>。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <>.

[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<>。

[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, <>.

[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、 <>。

[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, <>.

[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル(KARP)のキーイングと認証の概要、脅威、および要件」、RFC 6862、DOI 10.17487 / RFC6862、2013年3月、<https: //>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <>.

[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、< / 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, <>.

[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月、<>。

[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, <>.

[RFC8662] Kini、S.、Kompella、K.、Sivabalan、S.、Litkowski、S.、Shakir、R。、およびJ. Tantsura、「ネットワーク(SPRING)トンネルにおけるソースパケットルーティングのエントロピーラベル」、RFC 8662 、DOI 10.17487 / RFC8662、2019年12月、<>。

[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, <>.

[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<>。

[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, <>.

[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月、<>。



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に、慎重なレビューとコメントを提供してくれたことにさらに感謝します。



Ahmed Bashandy Individual Email:

Ahmed Bashandy個人メール

Clarence Filsfils Cisco Email:

Clarence Filsfilsシスコの電子メール

John Drake Juniper Email:


Shaowen Ma Mellanox Technologies Email:

Shaowen Ma Mellanox Technologiesメール

Mach Chen Huawei Email:

Mach Chen Huaweiメール

Hamid Assarpour Broadcom

Hamid Assarpour Broadcomメール

Robert Raszuk Bloomberg LP Email:

Robert Raszuk Bloomberg LPメール

Uma Chunduri Huawei Email:

Uma Chunduri Huaweiメール

Luis M. Contreras Telefonica I+D Email:

Luis M. Contreras Telefonica I + Dメール

Luay Jalil Verizon Email:

Luay Jalil Verizonメール

Gunter Van De Velde Nokia Email:

Gunter Van De Velde Nokiaメール

Tal Mizrahi Marvell Email:

Tal Mizrahi Marvellメール

Jeff Tantsura Apstra, Inc. Email:

Jeff Tantsura Apstra、Inc.メール

Authors' Addresses


Xiaohu Xu Alibaba, Inc

ξOutbackX UA Dad raccoon、Inc


Stewart Bryant Futurewei Technologies

Stewart Bryant Futurewei Technologies


Adrian Farrel Old Dog Consulting



Syed Hassan Cisco



Wim Henderickx Nokia

Wim Henderickxノキア


Zhenbin Li Huawei

Zは非常にビンl IH UAは