[要約] RFC 8400は、RSVP-TEの拡張であり、ラベルスイッチパス(LSP)の出口保護に関するものです。その目的は、ネットワークの信頼性と可用性を向上させるために、LSPの出口保護機能を提供することです。

Internet Engineering Task Force (IETF)                           H. Chen
Request for Comments: 8400                           Huawei Technologies
Category: Standards Track                                         A. Liu
ISSN: 2070-1721                                                    Ciena
                                                                 T. Saad
                                                           Cisco Systems
                                                                   F. Xu
                                                                 Verizon
                                                                L. Huang
                                                            China Mobile
                                                               June 2018
        

Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection

ラベルスイッチドパス(LSP)出力保護のためのRSVP-TEの拡張

Abstract

概要

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).

このドキュメントでは、ポイントツーポイント(P2P)またはポイントツーマルチポイント(P2MP)トラフィックエンジニアリング(TE)ラベルの出力ノードをローカルで保護するためのリソース予約プロトコル-トラフィックエンジニアリング(RSVP-TE)の拡張機能について説明します交換パス(LSP)。

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/rfc8400.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8400で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2018 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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Local Protection of Egress Nodes  . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Extensions to SERO  . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Primary Egress Subobject  . . . . . . . . . . . . . .   7
       4.1.2.  P2P LSP ID Subobject  . . . . . . . . . . . . . . . .   8
   5.  Egress Protection Behaviors . . . . . . . . . . . . . . . . .   9
     5.1.  Ingress Behavior  . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Primary Egress Behavior . . . . . . . . . . . . . . . . .  10
     5.3.  Backup Egress Behavior  . . . . . . . . . . . . . . . . .  10
     5.4.  Transit Node and PLR Behavior . . . . . . . . . . . . . .  11
       5.4.1.  Signaling for One-to-One Protection . . . . . . . . .  12
       5.4.2.  Signaling for Facility Protection . . . . . . . . . .  12
       5.4.3.  Signaling for S2L Sub-LSP Protection  . . . . . . . .  13
       5.4.4.  PLR Procedures during Local Repair  . . . . . . . . .  14
   6.  Application Traffic Considerations  . . . . . . . . . . . . .  14
     6.1.  A Typical Application . . . . . . . . . . . . . . . . . .  14
     6.2.  PLR Procedure for Applications  . . . . . . . . . . . . .  17
     6.3.  Egress Procedures for Applications  . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21
        
1. Introduction
1. はじめに

[RFC4090] describes two methods for locally protecting the transit nodes of a P2P LSP: one-to-one and facility protection. [RFC4875] specifies how these methods can be used to protect the transit nodes of a P2MP LSP. These documents do not discuss the procedures for locally protecting the egress node(s) of an LSP.

[RFC4090]は、P2P LSPのトランジットノードをローカルで保護するための2つの方法、1対1とファシリティ保護について説明しています。 [RFC4875]は、これらの方法を使用してP2MP LSPのトランジットノードを保護する方法を指定しています。これらのドキュメントでは、LSPの出力ノードをローカルで保護する手順については説明していません。

This document fills that void and specifies extensions to RSVP-TE for local protection of the egress node(s) of an LSP. "Egress node" and "egress" are used interchangeably.

このドキュメントはその空白を埋め、LSPの出力ノードのローカル保護のためのRSVP-TEへの拡張を指定します。 「出力ノード」と「出力」は同じ意味で使用されます。

1.1. Local Protection of Egress Nodes
1.1. 出力ノードのローカル保護

In general, locally protecting an egress node of an LSP means that when the egress node fails, the traffic that the LSP carries will be delivered to its destination by the direct upstream node of the egress node to a backup egress node. Without protecting the egress node of the LSP, when the egress node fails, the traffic will be lost (i.e., the traffic will not be delivered to its destination).

一般に、LSPの出力ノードをローカルに保護するということは、出力ノードに障害が発生すると、LSPが運ぶトラフィックが、出力ノードの直接の上流ノードからバックアップ出力ノードに宛先に配信されるということです。 LSPの出力ノードを保護しないと、出力ノードに障害が発生するとトラフィックが失われます(つまり、トラフィックは宛先に配信されません)。

Figure 1 shows an example of using backup LSPs to locally protect egress nodes L1 and L2 of a primary P2MP LSP starting from ingress node R1. La and Lb are the designated backup egress nodes for primary egress nodes L1 and L2, respectively. The backup LSP for protecting L1 is from its upstream node R3 to backup egress node La, and the backup LSP for protecting L2 is from R5 to Lb.

図1は、バックアップLSPを使用して、入力ノードR1から始まるプライマリP2MP LSPの出力ノードL1およびL2をローカルに保護する例を示しています。 LaおよびLbは、それぞれプライマリ出力ノードL1およびL2の指定されたバックアップ出力ノードです。 L1を保護するためのバックアップLSPは、その上流ノードR3からバックアップ出口ノードLaまでであり、L2を保護するためのバックアップLSPは、R5からLbまでです。

                       *******  *******                 S Source
                    [R2]-----[R3]-----[L1]            CEx Customer Edge
                   */           &\        \            Rx Non-Egress
                  */             &\        \           Lx Egress
                 */               &\        [CE1]     *** Primary LSP
                */                 &\      /          &&& Backup LSP
               */                   &\    /
              */                      [La]
             */
            */
           */
          */ ********  ********  *******
    [S]---[R1]------[R4]------[R5]-----[L2]
                                 &\        \
                                  &\        \
                                   &\        [CE2]
                                    &\      /
                                     &\    /
                                       [Lb]
        

Figure 1: Backup LSP for Locally Protecting Egress

図1:出力をローカルで保護するためのバックアップLSP

During normal operations, the traffic carried by the P2MP LSP is sent through R3 to L1, which delivers the traffic to its destination CE1. When R3 detects the failure of L1, R3 switches the traffic to the backup LSP to backup egress node La, which delivers the traffic to CE1. The time for switching the traffic is within tens of milliseconds.

通常の動作中、P2MP LSPによって伝送されるトラフィックはR3を介してL1に送信され、L1は宛先CE1にトラフィックを配信します。 R3がL1の障害を検出すると、R3はトラフィックをバックアップLSPに切り替え、バックアップ出力ノードLaがトラフィックをCE1に配信します。トラフィックを切り替える時間は数十ミリ秒以内です。

The exact mechanism by which the failure of the primary egress node is detected by the upstream node R3 is out of the scope of this document.

プライマリ出力ノードの障害がアップストリームノードR3によって検出される正確なメカニズムは、このドキュメントの範囲外です。

In the beginning, the primary P2MP LSP from ingress node R1 to primary egress nodes L1 and L2 is configured. It may be used to transport the traffic from source S, which is connected to R1, to destinations CE1 and CE2, which are connected to L1 and L2, respectively.

最初に、入口ノードR1からプライマリ出口ノードL1およびL2へのプライマリP2MP LSPが構成されます。 R1に接続されているソースSから、L1とL2にそれぞれ接続されている宛先CE1とCE2にトラフィックを転送するために使用できます。

To protect the primary egress nodes L1 and L2, one configures on the ingress node R1 a backup egress node for L1, another backup egress node for L2, and other options. After the configuration, the ingress node sends a Path message for the LSP with information such as the Secondary Explicit Route Objects (SEROs), refer to Section 4.1, containing the backup egress nodes for protecting the primary egress nodes.

プライマリ出力ノードL1およびL2を保護するために、入力ノードR1でL1のバックアップ出力ノードを構成し、別のバックアップ出力ノードをL2で構成し、その他のオプションを設定します。設定後、入口ノードはセカンダリ明示ルートオブジェクト(SERO)などの情報とともにLSPのパスメッセージを送信します。セクション4.1を参照してください。プライマリ出口ノードを保護するためのバックアップ出口ノードが含まれています。

After receiving the Path message with the information, the upstream node of a primary egress node sets up a backup LSP to the corresponding backup egress node for protecting the primary egress node.

情報を含むPathメッセージを受信した後、プライマリ出力ノードの上流ノードは、対応するバックアップ出力ノードにバックアップLSPを設定して、プライマリ出力ノードを保護します。

2. Conventions Used in This Document
2. このドキュメントで使用される規則

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]で説明されているように解釈されます。

3. Terminology
3. 用語

The following terminology is used in this document.

このドキュメントでは、次の用語が使用されています。

LSP: Label Switched Path

LSP:ラベルスイッチドパス

TE: Traffic Engineering

て: Tらっふぃc えんぎねえりんg

P2MP: Point-to-Multipoint

P2MP:ポイントツーマルチポイント

P2P: Point-to-Point

P2P:ポイントツーポイント

LSR: Label Switching Router

LSR:ラベルスイッチングルーター

RSVP: Resource Reservation Protocol

RSVP:リソース予約プロトコル

S2L: Source-to-Leaf

S2L: そうrせーとーぇあf

SERO: Secondary Explicit Route Object

SERO:セカンダリ明示ルートオブジェクト

RRO: Record Route Object BFD: Bidirectional Forwarding Detection

RRO:Record Route Object BFD:Bidirectional Forwarding Detection

VPN: Virtual Private Network

VPN:仮想プライベートネットワーク

L3VPN: Layer 3 VPN

L3VPN:レイヤー3 VPN

VRF: Virtual Routing and Forwarding

VRF:仮想ルーティングおよび転送

LFIB: Label Forwarding Information Base

LFIB:ラベル転送情報ベース

UA: Upstream Assigned

UA:アップストリーム割り当て済み

PLR: Point of Local Repair

PLR:ローカル修理のポイント

BGP: Border Gateway Protocol

BGP:ボーダーゲートウェイプロトコル

CE: Customer Edge

CE:カスタマーエッジ

PE: Provider Edge

PE:プロバイダーエッジ

4. Protocol Extensions
4. プロトコル拡張
4.1. Extensions to SERO
4.1. えxてんしおんs と せろ

The Secondary Explicit Route Object (SERO) is defined in [RFC4873]. The format of the SERO is reused.

セカンダリ明示ルートオブジェクト(SERO)は[RFC4873]で定義されています。 SEROのフォーマットが再利用されます。

The SERO used for protecting a primary egress node of a primary LSP may be added into the Path messages for the LSP and sent from the ingress node of the LSP to the upstream node of the egress node. It contains three subobjects.

プライマリLSPのプライマリ出力ノードを保護するために使用されるSEROは、LSPのPathメッセージに追加され、LSPの入力ノードから出力ノードの上流ノードに送信されます。 3つのサブオブジェクトが含まれています。

The first subobject (refer to Section 4.2 of [RFC4873]) indicates the branch node that is to originate the backup LSP (to a backup egress node). The branch node is typically the direct upstream node of the primary egress node of the primary LSP. If the direct upstream node does not support local protection against the failure of the primary egress node, the branch node can be any (upstream) node on the primary LSP. In this case, the backup LSP from the branch node to the backup egress node protects against failures on the segment of the primary LSP from the branch node to, and including, the primary egress node.

最初のサブオブジェクト([RFC4873]のセクション4.2を参照)は、バックアップLSPを(バックアップ出力ノードに)発信するブランチノードを示します。ブランチノードは通常、プライマリLSPのプライマリ出力ノードの直接のアップストリームノードです。直接アップストリームノードがプライマリ出力ノードの障害に対するローカル保護をサポートしていない場合、ブランチノードはプライマリLSP上の任意の(アップストリーム)ノードにすることができます。この場合、ブランチノードからバックアップ出力ノードへのバックアップLSPは、ブランチノードからプライマリ出力ノードまでのプライマリLSPのセグメントの障害から保護します。

The second subobject is an Egress Protection subobject, which is a PROTECTION object with a new C-Type (3). The format of the Egress Protection subobject is defined as follows:

2番目のサブオブジェクトは、出力保護サブオブジェクトです。これは、新しいCタイプ(3)のPROTECTIONオブジェクトです。出力保護サブオブジェクトの形式は次のように定義されています。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |    Reserved   |   C-Type (3)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   |E-Flags|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Optional Subobjects                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

E-Flags are defined for local protection of egress nodes.

Eフラグは、出力ノードのローカル保護のために定義されています。

Bit 31 ("egress local protection" flag): It is the least significant bit of the 32-bit word and is set to 1, which indicates that local protection of egress nodes is desired.

ビット31(「出力ローカル保護」フラグ):これは32ビットワードの最下位ビットであり、1に設定されています。これは、出力ノードのローカル保護が必要であることを示します。

Bit 30 ("S2L sub-LSP backup desired" flag): It is the second least significant bit of the 32-bit word and is set to 1, which indicates an S2L sub-LSP (refer to [RFC4875]) is desired for protecting an egress node of a P2MP LSP.

ビット30(「S2LサブLSPバックアップが必要」フラグ):これは32ビットワードの2番目の最下位ビットであり、1に設定されています。これは、S2LサブLSP([RFC4875]を参照)が必要であることを示します。 P2MP LSPの出力ノードを保護します。

The Reserved parts MUST be set to zero on transmission and MUST be ignored on receipt.

予約済みパーツは送信時にゼロに設定する必要があり、受信時に無視する必要があります。

Four optional subobjects are defined: they are IPv4 and IPv6 primary egress node subobjects as well as IPv4 and IPv6 P2P LSP ID subobjects. IPv4 and IPv6 primary egress node subobjects indicate the IPv4 and IPv6 address of the primary egress node, respectively. IPv4 and IPv6 P2P LSP ID subobjects contain the information for identifying IPv4 and IPv6 backup P2P LSP tunnels, respectively. Their contents are described in Sections 4.1.1 through 4.1.2.2. They have the following format:

4つのオプションのサブオブジェクトが定義されています。これらは、IPv4およびIPv6のプライマリ出力ノードサブオブジェクト、およびIPv4およびIPv6 P2P LSP IDサブオブジェクトです。 IPv4およびIPv6のプライマリ出力ノードサブオブジェクトは、それぞれプライマリ出力ノードのIPv4およびIPv6アドレスを示します。 IPv4およびIPv6 P2P LSP IDサブオブジェクトには、IPv4およびIPv6バックアップP2P LSPトンネルをそれぞれ識別するための情報が含まれています。それらの内容は、セクション4.1.1から4.1.2.2で説明されています。それらの形式は次のとおりです。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |    Length     |         Reserved (zero)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Contents / Body of Subobject               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

where Type is the type of a subobject and Length is the total size of the subobject in bytes, including Type, Length, and Contents fields. The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt.

Typeはサブオブジェクトのタイプ、Lengthはサブオブジェクトの合計サイズ(バイト)で、Type、Length、Contentsフィールドを含みます。予約済みフィールドは送信時にゼロに設定する必要があり、受信時に無視する必要があります。

The third (final) subobject (refer to Section 4.2 of [RFC4873]) in the SERO contains the egress node of the backup LSP, i.e., the address of the backup egress node in the place of the merge node.

SEROの3番目の(最終)サブオブジェクト([RFC4873]のセクション4.2を参照)には、バックアップLSPの出力ノード、つまりマージノードの代わりにバックアップ出力ノードのアドレスが含まれています。

After the upstream node of the primary egress node (a.k.a. the branch node) receives the SERO and determines a backup egress node for the primary egress node, it computes a path from itself to the backup egress node and sets up a backup LSP along the path for protecting the primary egress node according to the information in the FAST_REROUTE object in the Path message. For example, if facility protection is desired, it is provided for the primary egress node.

プライマリ出力ノード(別名ブランチノード)の上流ノードがSEROを受信し、プライマリ出力ノードのバックアップ出力ノードを決定した後、それ自体からバックアップ出力ノードへのパスを計算し、パスに沿ってバックアップLSPを設定しますPathメッセージのFAST_REROUTEオブジェクトの情報に従ってプライマリ出力ノードを保護するため。たとえば、ファシリティ保護が必要な場合は、プライマリ出力ノードに提供されます。

The upstream node constructs a new SERO based on the SERO received and adds the new SERO into the Path message for the backup LSP. The new SERO also contains three subobjects as the SERO for the primary LSP. The first subobject in the new SERO indicates the upstream node, which may be copied from the first subobject in the SERO received. The second subobject in the new SERO includes a primary egress node, which indicates the address of the primary egress node. The third one contains the backup egress node.

アップストリームノードは、受信したSEROに基づいて新しいSEROを作成し、バックアップLSPのPathメッセージに新しいSEROを追加します。新しいSEROには、プライマリLSPのSEROとして3つのサブオブジェクトも含まれています。新しいSEROの最初のサブオブジェクトは、受信したSEROの最初のサブオブジェクトからコピーできる上流ノードを示します。新しいSEROの2番目のサブオブジェクトには、プライマリ出力ノードのアドレスを示すプライマリ出力ノードが含まれます。 3番目のノードには、バックアップ出力ノードが含まれています。

The upstream node updates the SERO in the Path message for the primary LSP. The Egress Protection subobject in the SERO contains a subobject called a P2P LSP ID subobject, which contains the information for identifying the backup LSP. The final subobject in the SERO indicates the address of the backup egress node.

上流ノードは、プライマリLSPのPathメッセージのSEROを更新します。 SEROのEgress Protectionサブオブジェクトには、バックアップLSPを識別するための情報を含むP2P LSP IDサブオブジェクトと呼ばれるサブオブジェクトが含まれています。 SEROの最後のサブオブジェクトは、バックアップ出力ノードのアドレスを示します。

4.1.1. Primary Egress Subobject
4.1.1. プライマリ出力サブオブジェクト

There are two primary egress subobjects: the IPv4 primary egress subobject and the IPv6 primary egress subobject.

2つのプライマリ出力サブオブジェクトがあります。IPv4プライマリ出力サブオブジェクトとIPv6プライマリ出力サブオブジェクトです。

The Type of an IPv4 primary egress subobject is 1, and the body of the subobject is given below:

IPv4プライマリ出力サブオブジェクトのタイプは1で、サブオブジェクトの本体は次のとおりです。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv4 Address (4 bytes)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o IPv4 Address: The IPv4 address of the primary egress node.

o IPv4アドレス:プライマリ出力ノードのIPv4アドレス。

The Type of an IPv6 primary egress subobject is 2, and the body of the subobject is shown below:

IPv6プライマリ出力サブオブジェクトのタイプは2で、サブオブジェクトの本体は次のとおりです。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv6 Address (16 bytes)                    |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o IPv6 Address: The IPv6 address of the primary egress node.

o IPv6アドレス:プライマリ出力ノードのIPv6アドレス。

4.1.2. P2P LSP ID Subobject
4.1.2. P2P LSP IDサブオブジェクト

A P2P LSP ID subobject contains the information for identifying a backup P2P LSP tunnel.

P2P LSP IDサブオブジェクトには、バックアップP2P LSPトンネルを識別するための情報が含まれています。

4.1.2.1. IPv4 P2P LSP ID Subobject
4.1.2.1. IPv4 P2P LSP IDサブオブジェクト

The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the subobject is shown below:

IPv4 P2P LSP IDサブオブジェクトのタイプは3で、サブオブジェクトの本体は次のとおりです。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               P2P LSP Tunnel Egress IPv4 Address              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved (MUST be zero)    |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Extended Tunnel ID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o P2P LSP Tunnel Egress IPv4 Address: The IPv4 address of the egress node of the tunnel.

o P2P LSPトンネル出力IPv4アドレス:トンネルの出力ノードのIPv4アドレス。

o Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-bit identifier that remains constant over the life of the tunnel and occupies the least significant 16 bits of the 32-bit word.

o トンネルID([RFC4875]および[RFC3209]を参照):トンネルの存続期間を通じて一定であり、32ビットワードの最下位16ビットを占める16ビットの識別子。

o Extended Tunnel ID (refer to [RFC4875] and [RFC3209]): A 4-byte identifier that remains constant over the life of the tunnel.

o 拡張トンネルID([RFC4875]および[RFC3209]を参照):トンネルの存続期間を通じて一定である4バイトの識別子。

4.1.2.2. IPv6 P2P LSP ID Subobject
4.1.2.2. IPv6 P2P LSP IDサブオブジェクト

The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the subobject is illustrated below:

IPv6 P2P LSP IDサブオブジェクトのタイプは4であり、サブオブジェクトの本体を以下に示します。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~         P2P LSP Tunnel Egress IPv6 Address (16 bytes)         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved (MUST be zero)    |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                 Extended Tunnel ID (16 bytes)                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o P2P LSP Tunnel Egress IPv6 Address: The IPv6 address of the egress node of the tunnel.

o P2P LSPトンネル出力IPv6アドレス:トンネルの出力ノードのIPv6アドレス。

o Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-bit identifier that remains constant over the life of the tunnel and occupies the least significant 16 bits of the 32-bit word.

o トンネルID([RFC4875]および[RFC3209]を参照):トンネルの存続期間を通じて一定であり、32ビットワードの最下位16ビットを占める16ビットの識別子。

o Extended Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-byte identifier that remains constant over the life of the tunnel.

o 拡張トンネルID([RFC4875]および[RFC3209]を参照):トンネルの存続期間を通じて一定である16バイトの識別子。

5. Egress Protection Behaviors
5. 出力保護動作
5.1. Ingress Behavior
5.1. イングレス動作

To protect a primary egress node of an LSP, the ingress node MUST set the "label recording desired" flag and the "node protection desired" flag in the SESSION_ATTRIBUTE object.

LSPのプライマリ出力ノードを保護するために、入力ノードはSESSION_ATTRIBUTEオブジェクトに「label recording desired」フラグと「node protection desired」フラグを設定する必要があります。

If one-to-one backup or facility backup is desired to protect a primary egress node of an LSP, the ingress node MUST include a FAST_REROUTE object and set the "one-to-one backup desired" or "facility backup desired" flag, respectively.

LSPのプライマリ出力ノードを保護するために1対1のバックアップまたはファシリティバックアップが必要な場合は、入力ノードにFAST_REROUTEオブジェクトを含めて、「1対1のバックアップが必要」または「施設のバックアップが必要」のフラグを設定する必要があります。それぞれ。

If S2L sub-LSP backup is desired to protect a primary egress node of a P2MP LSP, the ingress node MUST set the "S2L sub-LSP backup desired" flag in an SERO object.

P2MP LSPのプライマリ出力ノードを保護するためにS2LサブLSPバックアップが必要な場合、入力ノードはSEROオブジェクトに「S2LサブLSPバックアップが必要」フラグを設定する必要があります。

The decision to instantiate a backup egress node for protecting the primary egress node of an LSP can be initiated by either the ingress node or the primary egress node of that LSP, but not both.

LSPのプライマリ出力ノードを保護するためにバックアップ出力ノードをインスタンス化する決定は、そのLSPの入力ノードまたはプライマリ出力ノードのいずれかで開始できますが、両方で開始することはできません。

A backup egress node MUST be configured on the ingress node of an LSP to protect a primary egress node of the LSP if and only if the backup egress node is not configured on the primary egress node (refer to Section 5.2).

バックアップ出力ノードがプライマリ出力ノードで構成されていない場合にのみ、LSPのプライマリ出力ノードを保護するために、LSPの入力ノードでバックアップ出力ノードを構成する必要があります(セクション5.2を参照)。

The ingress node MUST send a Path message for the LSP with the objects above and the SEROs for protecting egress nodes of the LSP if protection of the egress nodes is desired. For each primary egress node of the LSP to be protected, the ingress node MUST add an SERO object into the Path message if the backup egress node, or some options, are given. If the backup egress node is given, then the final subobject in the SERO contains it; otherwise, the address in the final subobject is zero.

入力ノードは、上記のオブジェクトと、出力ノードの保護が必要な場合はLSPの出力ノードを保護するためのSEROを含むLSPのPathメッセージを送信する必要があります。保護するLSPの各プライマリ出力ノードについて、バックアップ出力ノードまたはいくつかのオプションが指定されている場合、入力ノードはSEROオブジェクトをPathメッセージに追加する必要があります。バックアップ出力ノードが指定されている場合、SEROの最後のサブオブジェクトにそれが含まれます。それ以外の場合、最終サブオブジェクトのアドレスはゼロです。

5.2. Primary Egress Behavior
5.2. プライマリ下り動作

To protect a primary egress node of an LSP, a backup egress node MUST be configured on the primary egress node of the LSP to protect the primary egress node if and only if the backup egress node is not configured on the ingress node of the LSP (refer to Section 5.1).

LSPのプライマリ出力ノードを保護するには、LSPの入力ノードでバックアップ出力ノードが構成されていない場合にのみ、LSPのプライマリ出力ノードでバックアップ出力ノードを構成して、プライマリ出力ノードを保護する必要があります(セクション5.1を参照してください)。

If the backup egress node is configured on the primary egress node of the LSP, the primary egress node MUST send its upstream node a Resv message for the LSP with an SERO for protecting the primary egress node. It sets the flags in the SERO in the same way as an ingress node.

LSPのプライマリ出力ノードでバックアップ出力ノードが構成されている場合、プライマリ出力ノードは、プライマリ出力ノードを保護するために、SEROを使用してLSPのResvメッセージをアップストリームノードに送信する必要があります。これは、入力ノードと同じ方法でSEROにフラグを設定します。

If the LSP carries the service traffic with a service label, the primary egress node sends its corresponding backup egress node the information about the service label as a UA label (refer to [RFC5331]) and the related forwarding.

LSPがサービスラベル付きのサービストラフィックを伝送する場合、プライマリ出力ノードは、対応するバックアップ出力ノードに、サービスラベルに関する情報をUAラベル([RFC5331]を参照)および関連する転送として送信します。

5.3. Backup Egress Behavior
5.3. バックアップ出力動作

When a backup egress node receives a Path message for an LSP, it determines whether the LSP is used for egress local protection by checking the SERO with an Egress Protection subobject in the message. If there is an Egress Protection subobject in the Path message for the LSP and the "egress local protection" flag in the object is set to 1, the LSP is the backup LSP for local protection of an egress node. The primary egress node to be protected is in the primary egress subobject in the SERO.

バックアップ出力ノードがLSPのPathメッセージを受信すると、メッセージ内のEgress Protectionサブオブジェクトを使用してSEROをチェックすることにより、LSPが出力ローカル保護に使用されるかどうかを決定します。 LSPのPathメッセージに出力保護サブオブジェクトがあり、オブジェクトの「出力ローカル保護」フラグが1に設定されている場合、LSPは出力ノードのローカル保護のバックアップLSPです。保護されるプライマリ出力ノードは、SEROのプライマリ出力サブオブジェクトにあります。

When the backup egress node receives the information about a UA label and its related forwarding from the primary egress node, it uses the backup LSP label as a context label and creates a forwarding entry using the information about the UA label and the related forwarding.

バックアップ出力ノードは、プライマリ出力ノードからUAラベルとその関連転送に関する情報を受信すると、バックアップLSPラベルをコンテキストラベルとして使用し、UAラベルと関連転送に関する情報を使用して転送エントリを作成します。

This forwarding entry is in a forwarding table for the primary egress node.

この転送エントリは、プライマリ出力ノードの転送テーブルにあります。

When the primary egress node fails, its upstream node switches the traffic from the primary LSP to the backup LSP to the backup egress node, which delivers the traffic to its receiver, such as a CE, using the backup LSP label as a context label to get the forwarding table for the primary egress node and using the service label as a UA label to find the forwarding entry in the table to forward the traffic to the receiver.

プライマリ出力ノードに障害が発生すると、そのアップストリームノードは、プライマリLSPからバックアップLSPへのトラフィックをバックアップ出力ノードに切り替えます。バックアップ出力ノードは、CEなどのレシーバーにトラフィックを配信し、バックアップLSPラベルをコンテキストラベルとして使用して、プライマリ出力ノードの転送テーブルを取得し、サービスラベルをUAラベルとして使用して、トラフィックをレシーバーに転送するための転送エントリをテーブルから検索します。

5.4. Transit Node and PLR Behavior
5.4. トランジットノードとPLRの動作

If a transit node of an LSP receives the Path message with the SEROs and it is not an upstream node of any primary egress node of the LSP as a branch node, it MUST forward them unchanged.

LSPのトランジットノードがSEROを含むPathメッセージを受信し、それがブランチノードとしてのLSPのプライマリ出力ノードの上流ノードではない場合、それらを変更せずに転送する必要があります。

If the transit node is the upstream node of a primary egress node to be protected as a branch node, it determines the backup egress node, obtains a path for the backup LSP, and sets up the backup LSP along the path. If the upstream node receives the Resv message with an SERO object, it MUST send its upstream node the Resv message without the object.

トランジットノードは、ブランチノードとして保護されるプライマリ出力ノードの上流ノードである場合、バックアップ出力ノードを決定し、バックアップLSPのパスを取得し、パスに沿ってバックアップLSPをセットアップします。上流ノードがSEROオブジェクトを含むResvメッセージを受信した場合、その上流ノードはオブジェクトなしでResvメッセージを送信する必要があります。

The PLR (which is the upstream node of the primary egress node a.k.a. the branch node) MUST extract the backup egress node from the respective SERO object in either a Path or a Resv message. If no matching SERO object is found, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP address as the destination IP address of the LSP.

PLR(プライマリ出口ノードの別名、ブランチノード)は、PathまたはResvメッセージでそれぞれのSEROオブジェクトからバックアップ出口ノードを抽出する必要があります。一致するSEROオブジェクトが見つからない場合、PLRはプライマリ出力ノードではないが、LSPの宛先IPアドレスと同じIPアドレスを持つバックアップ出力ノードを見つけようとします。

Note that if a backup egress node is not configured explicitly for protecting a primary egress node, the primary egress node and the backup egress node SHOULD have the same local address configured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local address on the primary egress node. Thus, the primary egress node and backup egress node are considered as a "virtual node". Note that the backup egress node is different from this local address (e.g., from the primary egress node's point of view). In other words, it is identified by an address different from this local address.

プライマリ出力ノードを保護するためにバックアップ出力ノードが明示的に構成されていない場合、プライマリ出力ノードとバックアップ出力ノードには同じローカルアドレスが構成されている必要があり(SHOULD)、バックアップ出力ノードのローカルアドレスへのコストは非常に大きいことに注意してくださいプライマリ出力ノードのローカルアドレスのコストよりも大きい。したがって、プライマリ出力ノードとバックアップ出力ノードは「仮想ノード」と見なされます。バックアップ出力ノードはこのローカルアドレスとは異なることに注意してください(たとえば、プライマリ出力ノードの観点から)。つまり、このローカルアドレスとは異なるアドレスで識別されます。

After obtaining the backup egress node, the PLR computes a backup path from itself to the backup egress node and sets up a backup LSP along the path. It excludes the segment including the primary egress node to be protected when computing the path. The PLR sends the primary egress node a Path message with an SERO for the primary LSP, which indicates the backup egress node by the final subobject in the SERO. The PLR puts an SERO into the Path messages for the backup LSP, which indicates the primary egress node.

バックアップ出力ノードを取得した後、PLRはそれ自体からバックアップ出力ノードへのバックアップパスを計算し、パスに沿ってバックアップLSPを設定します。パスの計算時に保護されるプライマリ出力ノードを含むセグメントは除外されます。 PLRは、プライマリLSPのSEROを含むPathメッセージをプライマリ出力ノードに送信します。これは、SEROの最後のサブオブジェクトによってバックアップ出力ノードを示します。 PLRはSEROをバックアップLSPのPathメッセージに入れます。これはプライマリ出力ノードを示します。

The PLR MUST provide one-to-one backup protection for the primary egress node if the "one-to-one backup desired" flag is set in the message; otherwise, it MUST provide facility backup protection if the "facility backup desired" flag is set.

メッセージに「1対1のバックアップが必要」フラグが設定されている場合、PLRはプライマリ出力ノードに1対1のバックアップ保護を提供する必要があります。それ以外の場合、「施設のバックアップが必要」フラグが設定されている場合は、施設のバックアップ保護を提供する必要があります。

The PLR MUST set the protection flags in the RRO subobject for the primary egress node in the Resv message according to the status of the primary egress node and the backup LSP protecting the primary egress node. For example, it sets the "local protection available" flag and the "node protection" flag, which indicate that the primary egress node is protected when the backup LSP is up and ready to protect the primary egress node.

PLRは、プライマリ出力ノードとプライマリ出力ノードを保護するバックアップLSPのステータスに従って、Resvメッセージのプライマリ出力ノードのRROサブオブジェクトに保護フラグを設定する必要があります。たとえば、「ローカル保護利用可能」フラグと「ノード保護」フラグを設定します。これは、バックアップLSPが起動し、プライマリ出力ノードを保護する準備ができたときにプライマリ出力ノードが保護されることを示します。

5.4.1. Signaling for One-to-One Protection
5.4.1. 1対1保護のシグナリング

The behavior of the upstream node of a primary egress node of an LSP (as a PLR) is the same as that of a PLR for one-to-one backup described in [RFC4090], except that the upstream node (as a PLR) creates a backup LSP from itself to a backup egress node in a session different from the primary LSP.

LSPのプライマリ出力ノードの上流ノードの動作(PLRとして)は、上流ノード(PLRとして)を除いて、[RFC4090]で説明されている1対1バックアップのPLRの動作と同じです。プライマリLSPとは異なるセッションで、自分自身からバックアップ出力ノードにバックアップLSPを作成します。

If the LSP is a P2MP LSP and a primary egress node of the LSP is also a transit node (i.e., bud node), the upstream node of the primary egress node (as a PLR) creates a backup LSP from itself to each of the next hops of the primary egress node.

LSPがP2MP LSPであり、LSPのプライマリ出力ノードがトランジットノード(つまり、バッドノード)でもある場合、プライマリ出力ノードの上流ノード(PLRとして)は、それ自体から各LSPにバックアップLSPを作成します。プライマリ出力ノードのネクストホップ。

When the PLR detects the failure of the primary egress node, it switches the packets from the primary LSP to the backup LSP to the backup egress node. For the failure of the bud node of a P2MP LSP, the PLR also switches the packets to the backup LSPs to the bud node's next hops, where the packets are merged into the primary LSP.

PLRは、プライマリ出力ノードの障害を検出すると、パケットをプライマリLSPからバックアップLSPに、バックアップ出力ノードに切り替えます。 P2MP LSPのバッドノードに障害が発生した場合、PLRは、パケットをバックアップLSPに切り替えて、バッドノードのネクストホップに切り替えます。そこで、パケットはプライマリLSPにマージされます。

5.4.2. Signaling for Facility Protection
5.4.2. 施設保護のためのシグナリング

Except for backup LSP and downstream label, the behavior of the upstream node of the primary egress node of a primary LSP (as a PLR) follows the PLR behavior for facility backup, which is described in [RFC4090].

バックアップLSPとダウンストリームラベルを除いて、プライマリLSPのプライマリ出力ノードのアップストリームノードの動作(PLRとして)は、[RFC4090]で説明されているファシリティバックアップのPLR動作に従います。

For a number of primary P2P LSPs going through the same PLR to the same primary egress node, the primary egress node of these LSPs MAY be protected by one backup LSP from the PLR to the backup egress node designated for protecting the primary egress node.

同じPLRを経由して同じプライマリ出力ノードに向かう多数のプライマリP2P LSPの場合、これらのLSPのプライマリ出力ノードは、プライマリ出力ノードを保護するために指定されたPLRからバックアップ出力ノードへの1つのバックアップLSPによって保護される場合があります。

The PLR selects or creates a backup LSP from itself to the backup egress node. If there is a backup LSP that satisfies the constraints given in the Path message, then this one is selected; otherwise, a new backup LSP to the backup egress node is created.

PLRは、それ自体からバックアップ出力ノードへのバックアップLSPを選択または作成します。 Pathメッセージで指定された制約を満たすバックアップLSPがある場合、これが選択されます。それ以外の場合は、バックアップ出力ノードへの新しいバックアップLSPが作成されます。

After getting the backup LSP, the PLR associates the backup LSP with a primary LSP for protecting its primary egress node. The PLR records that the backup LSP is used to protect the primary LSP against its primary egress node failure and MUST include an SERO object in the Path message for the primary LSP. The object MUST contain the backup LSP ID. It indicates that the primary egress node MUST send the backup egress node the service label as a UA label and also send the information about forwarding the traffic to its destination using the label if there is a service carried by the LSP and the primary LSP label as a UA label (if the label is not implicit null). How a UA label is sent is out of scope for this document (refer to [FRAMEWK]).

PLSは、バックアップLSPを取得した後、プライマリLSPをプライマリLSPに関連付けて、プライマリ出力ノードを保護します。 PLRは、プライマリLSPがプライマリ出力ノードの障害から保護するためにバックアップLSPが使用されることを記録し、プライマリLSPのPathメッセージにSEROオブジェクトを含める必要があります。オブジェクトには、バックアップLSP IDが含まれている必要があります。これは、プライマリ出力ノードがバックアップ出力ノードにサービスラベルをUAラベルとして送信する必要があり、LSPとプライマリLSPラベルによって運ばれるサービスがある場合、ラベルを使用してトラフィックを宛先に転送することに関する情報も送信する必要があることを示します。 UAラベル(ラベルが暗黙のnullでない場合)。 UAラベルの送信方法は、このドキュメントの範囲外です([FRAMEWK]を参照)。

When the PLR detects the failure of the primary egress node, it redirects the packets from the primary LSP into the backup LSP to the backup egress node and keeps the primary LSP label from the primary egress node in the label stack if the label is not implicit null. The backup egress node delivers the packets to the same destinations as the primary egress node using the backup LSP label as a context label and the labels under as UA labels.

PLRは、プライマリ出力ノードの障害を検出すると、パケットをプライマリLSPからバックアップLSPにバックアップ出力ノードにリダイレクトし、ラベルが暗黙的でない場合、プライマリスタック出力ノードからのプライマリLSPラベルをラベルスタックに保持します。ヌル。バックアップ出力ノードは、バックアップLSPラベルをコンテキストラベルとして使用し、その下のラベルをUAラベルとして使用して、プライマリ出力ノードと同じ宛先にパケットを配信します。

5.4.3. Signaling for S2L Sub-LSP Protection
5.4.3. S2L Sub-LSP保護のシグナリング

The S2L sub-LSP protection uses an S2L sub-LSP (refer to [RFC4875]) as a backup LSP to protect a primary egress node of a P2MP LSP. The PLR MUST determine to protect a primary egress node of a P2MP LSP via S2L sub-LSP protection when it receives a Path message with the "S2L sub-LSP backup desired" flag set.

S2LサブLSP保護は、S2LサブLSP([RFC4875]を参照)をバックアップLSPとして使用して、P2MP LSPのプライマリ出力ノードを保護します。 PLRは、「S2L sub-LSP backup desired」フラグが設定されたPathメッセージを受信したときに、S2L sub-LSP保護を介してP2MP LSPのプライマリ出力ノードを保護することを決定する必要があります。

The PLR MUST set up the backup S2L sub-LSP to the backup egress node and create and maintain its state in the same way as if setting up a S2L sub-LSP defined in [RFC4875] from the signaling's point of view. It computes a path for the backup LSP from itself to the backup egress node, constructs and sends a Path message along the path, and receives and processes a Resv message responding to the Path message.

PLRは、バックアップS2LサブLSPをバックアップ出力ノードに設定し、シグナリングの観点から[RFC4875]で定義されたS2LサブLSPを設定する場合と同じ方法でその状態を作成および維持する必要があります。自身からバックアップ出力ノードまでのバックアップLSPのパスを計算し、パスに沿ってPathメッセージを作成して送信し、Pathメッセージに応答するResvメッセージを受信して​​処理します。

After receiving the Resv message for the backup LSP, the PLR creates a forwarding entry with an inactive state or flag called "inactive forwarding entry". This inactive forwarding entry is not used to forward any data traffic during normal operations.

PLSは、バックアップLSPのResvメッセージを受信した後、「非アクティブな転送エントリ」と呼ばれる非アクティブな状態またはフラグを持つ転送エントリを作成します。この非アクティブな転送エントリは、通常の操作中にデータトラフィックを転送するために使用されません。

When the PLR detects the failure of the primary egress node, it changes the forwarding entry for the backup LSP to "active". Thus, the PLR forwards the traffic to the backup egress through the backup LSP, which sends the traffic to its destination.

PLRは、プライマリ出力ノードの障害を検出すると、バックアップLSPの転送エントリを「アクティブ」に変更します。したがって、PLRは、トラフィックを宛先に送信するバックアップLSPを介して、トラフィックをバックアップ出力に転送します。

5.4.4. PLR Procedures during Local Repair
5.4.4. ローカル修復中のPLR手順

When the upstream node of a primary egress node of an LSP (as a PLR) detects the failure of the primary egress node, it follows the procedures defined in Section 6.5 of [RFC4090]. It SHOULD notify the ingress node about the failure of the primary egress node in the same way as a PLR notifies the ingress node about the failure of a transit node.

LSPのプライマリ出力ノードの上流ノード(PLRとして)がプライマリ出力ノードの障害を検出すると、[RFC4090]のセクション6.5で定義された手順に従います。 PLRが入口ノードにトランジットノードの障害を通知するのと同じ方法で、プライマリ出口ノードの障害について入口ノードに通知する必要があります(SHOULD)。

Moreover, the PLR MUST let the upstream part of the primary LSP stay alive after the primary egress node fails by sending the Resv message to its upstream node along the primary LSP. The downstream part of the primary LSP from the PLR to the primary egress node SHOULD be removed. When a bypass LSP from the PLR to a backup egress node protects the primary egress node, the PLR MUST NOT send any Path message for the primary LSP through the bypass LSP to the backup egress node.

さらに、PLRは、プライマリLSPに沿って上流ノードにResvメッセージを送信することにより、プライマリ出口ノードで障害が発生した後、プライマリLSPの上流部分を存続させなければなりません(MUST)。 PLRからプライマリ出力ノードへのプライマリLSPのダウンストリーム部分は削除されるべきです(SHOULD)。 PLRからバックアップ出力ノードへのバイパスLSPがプライマリ出力ノードを保護する場合、PLRは、バイパスLSPを介してプライマリLSPのパスメッセージをバックアップ出力ノードに送信してはなりません(MUST NOT)。

In the local revertive mode, the PLR will re-signal each of the primary LSPs that were routed over the restored resource once it detects that the resource is restored. Every primary LSP successfully re-signaled along the restored resource will be switched back.

ローカルリバーティブモードでは、PLRは、リソースが復元されたことを検出すると、復元されたリソースを介してルーティングされたプライマリLSPをそれぞれ再シグナリングします。復元されたリソースに沿って正常に再シグナリングされたすべてのプライマリLSPがスイッチバックされます。

Note that the procedure for protecting the primary egress node is triggered on the PLR if the primary egress node failure is determined. If link (from PLR to primary egress node) failure and primary egress node alive are determined, then the link protection procedure is triggered on the PLR. How to determine these is out of scope for this document.

プライマリ出力ノードの障害が判別されると、プライマリ出力ノードを保護する手順がPLRでトリガーされることに注意してください。リンク(PLRからプライマリ出力ノードへの)の障害とプライマリ出力ノードのアライブが決定されると、PLRでリンク保護手順がトリガーされます。これらを判別する方法は、このドキュメントの範囲外です。

6. Application Traffic Considerations
6. アプリケーショントラフィックに関する考慮事項

This section focuses on an example with application traffic carried by P2P LSPs.

このセクションでは、P2P LSPによって伝送されるアプリケーショントラフィックの例に焦点を当てます。

6.1. A Typical Application
6.1. 典型的なアプリケーション
   L3VPN is a typical application.  Figure 2 below shows a simple VPN
   that consists of two CEs, CE1 and CE2, connected to two PEs, R1 and
   L1, respectively.  There is a P2P LSP from R1 to L1, which is
   represented by stars (****).  This LSP is called the primary LSP.  R1
   is the ingress node of the LSP and L1 is the (primary) egress node of
   the LSP.  R1 sends the VPN traffic received from CE1 through the P2P
   LSP to L1, which delivers the traffic to CE2.  R1 sends the VPN
   traffic with an LSP label and a VPN label via the LSP.  When the
   traffic reaches the egress node L1 of the LSP, L1 pops the LSP label
   and uses the VPN label to deliver the traffic to CE2.
        

In previous solutions based on ingress protection to protect the VPN traffic against failure of the egress node L1 of the LSP, when the egress node fails, the ingress node R1 of the LSP does the reroute (refer to Figure 2). This solution entailed:

LSPの出力ノードL1の障害からVPNトラフィックを保護するための入力保護に基づく以前のソリューションでは、出力ノードに障害が発生すると、LSPの入力ノードR1が再ルーティングを行います(図2を参照)。このソリューションには次のものが含まれます。

1. A multi-hop BFD session between ingress node R1 and egress node L1 of the primary LSP. The BFD session is represented by dots (....).

1. プライマリLSPの入力ノードR1と出力ノードL1の間のマルチホップBFDセッション。 BFDセッションはドット(....)で表されます。

2. A backup LSP from ingress node R1 to backup egress node La, which is indicated by ampersands (&&&&).

2. 入力ノードR1からバックアップ出力ノードLaへのバックアップLSP。これはアンパサンド(&&&&)で示されます。

3. La sends R1 a VPN backup label and related information via BGP.

3. LaはBGP経由でR1にVPNバックアップラベルと関連情報を送信します。

4. R1 has a VRF with two sets of routes for CE2: one set uses the primary LSP and L1 as the next hop; the other uses the backup LSP and La as the next hop.

4. R1には、CE2のルートの2つのセットを持つVRFがあります。1つのセットは、プライマリLSPとL1をネクストホップとして使用します。もう1つは、次のホップとしてバックアップLSPとLaを使用します。

                      *****    *****
    CE1,CE2 in    [R2]-----[R3]-----[L1]             **** Primary LSP
    one VPN      */                 :   \            &&&& Backup LSP
                */ .................:    \           .... BFD Session
     [CE1]--[R1] ..:                      [CE2]
                &\                       /
                 &\                     /
                  [R4]-----[R5]-----[La](BGP sends R1 VPN backup label)
                      &&&&&    &&&&&
        

Figure 2: Protect Egress for L3VPN Traffic

図2:L3VPNトラフィックの出力を保護する

In normal operations, R1 sends the VPN traffic from CE1 through the primary LSP with the VPN label received from L1 as the inner label to L1, which delivers the traffic to CE2 using the VPN label.

通常の動作では、R1は、L1から受信したVPNラベルを内部ラベルとしてL1に送信し、VPNラベルを使用してCE2にトラフィックを配信します。

When R1 detects the failure of L1, R1 sends the traffic from CE1 via the backup LSP with the VPN backup label received from La as the inner label to La, which delivers the traffic to CE2 using the VPN backup label.

R1はL1の障害を検出すると、Laから受信したVPNバックアップラベルを内部ラベルとしてLaに送信し、VPNバックアップラベルを使用してCE2にトラフィックを配信します。

The solution defined in this document that uses egress local protection for protecting L3VPN traffic entails (refer to Figure 3):

このドキュメントで定義されている、L3VPNトラフィックを保護するために出力ローカル保護を使用するソリューションには、次のものが含まれます(図3を参照)。

1. A BFD session between R3 (i.e., upstream node of L1) and egress node L1 of the primary LSP. This is different from the BFD session in Figure 2, which is a multi-hop between ingress node R1 and egress node L1. The PLR R3 is closer to L1 than the ingress node R1. It may detect the failure of the egress node L1 faster and more reliably. Therefore, this solution can provide faster protection for failure of an egress node.

1. R3(つまり、L1の上流ノード)とプライマリLSPの出口ノードL1の間のBFDセッション。これは、入力ノードR1と出力ノードL1の間のマルチホップである図2のBFDセッションとは異なります。 PLR R3は、入力ノードR1よりもL1に近いです。出口ノードL1の障害をより速く、より確実に検出できます。したがって、このソリューションは、出力ノードの障害に対するより高速な保護を提供できます。

2. A backup LSP from R3 to backup egress node La. This is different from the backup LSP in Figure 2, which is an end-to-end LSP from ingress node R1 to backup egress node La.

2. R3からバックアップ出口ノードLaへのバックアップLSP。これは、図2のバックアップLSPとは異なります。これは、入口ノードR1からバックアップ出口ノードLaへのエンドツーエンドLSPです。

3. Primary egress node L1 sends backup egress node La the VPN label as a UA label and also sends related information. The backup egress node La uses the backup LSP label as a context label and creates a forwarding entry using the VPN label in an LFIB for the primary egress node L1.

3. プライマリ出力ノードL1は、バックアップ出力ノードLaにVPNラベルをUAラベルとして送信し、関連情報も送信します。バックアップ出力ノードLaは、バックアップLSPラベルをコンテキストラベルとして使用し、プライマリ出力ノードL1のLFIBのVPNラベルを使用して転送エントリを作成します。

4. L1 and La are virtualized as one node (or address). R1 has a VRF with one set of routes for CE2, using the primary LSP from R1 to L1 and a virtualized node as the next hop. This can be achieved by configuring the same local address on L1 and La using the address as a destination of the LSP and BGP next hop for the VPN traffic. The cost to L1 is configured to be less than the cost to La.

4. L1とLaは1つのノード(またはアドレス)として仮想化されます。 R1には、CE2に1セットのルートを持つVRFがあり、R1からL1へのプライマリLSPと仮想化ノードをネクストホップとして使用します。これは、VPNトラフィックのLSPおよびBGPネクストホップの宛先としてアドレスを使用して、L1とLaに同じローカルアドレスを設定することで実現できます。 L1のコストは、Laのコストよりも小さくなるように構成されます。

                      *****    *****
    CE1,CE2 in    [R2]-----[R3]-----[L1]             **** Primary LSP
    one VPN      */         &\:.....:   \            &&&& Backup LSP
                */           &\          \           .... BFD Session
     [CE1]--[R1]               &\         [CE2]
                                 &\      /
                                   &\   /
                                   [La](VPN label from L1 as a UA label)
        

Figure 3: Locally Protect Egress for L3VPN Traffic

図3:L3VPNトラフィックの出力をローカルで保護する

In normal operations, R1 sends the VPN traffic from CE1 via the primary LSP with the VPN label as an inner label to L1, which delivers the traffic to CE2 using the VPN label.

通常の運用では、R1はVPNトラフィックをCE1からプライマリLSP経由で内部ラベルとして内部ラベルとしてL1に送信し、VPNラベルを使用してトラフィックをCE2に配信します。

When the primary egress node L1 fails, its upstream node R3 detects it and switches the VPN traffic from the primary LSP to the backup LSP to La, which delivers the traffic to CE2 using the backup LSP label as a context label to get the LFIB for L1 and the VPN label as a UA label to find the forwarding entry in the LFIB to forward the traffic to CE2.

プライマリ出力ノードL1に障害が発生すると、その上流ノードR3がそれを検出し、VPNトラフィックをプライマリLSPからバックアップLSPにLaに切り替えます。これにより、バックアップLSPラベルをコンテキストラベルとして使用してCE2にトラフィックが配信され、 L1およびUAラベルとしてのVPNラベル。トラフィックをCE2に転送するためのLFIBの転送エントリを検索します。

6.2. PLR Procedure for Applications
6.2. アプリケーションのPLR手順

When the PLR gets a backup LSP from itself to a backup egress node for protecting a primary egress node of a primary LSP, it includes an SERO object in the Path message for the primary LSP. The object contains the ID information of the backup LSP and indicates that the primary egress node sends the backup egress node the application traffic label (e.g., the VPN label) as a UA label when needed.

PLRが自身からバックアップLSPを取得して、プライマリLSPのプライマリ出力ノードを保護する場合、プライマリLSPのPathメッセージにSEROオブジェクトが含まれます。このオブジェクトには、バックアップLSPのID情報が含まれており、必要に応じて、プライマリ出力ノードがバックアップ出力ノードにアプリケーショントラフィックラベル(VPNラベルなど)をUAラベルとして送信することを示します。

6.3. Egress Procedures for Applications
6.3. アプリケーションの出力手順

When a primary egress node of an LSP sends the ingress node of the LSP a label for an application such as a VPN label, it sends the label (as a UA label) to the backup egress node for protecting the primary egress node. Exactly how the label is sent is out of scope for this document.

LSPのプライマリ出力ノードがLSPの入力ノードにVPNラベルなどのアプリケーションのラベルを送信すると、プライマリ出力ノードを保護するために、ラベルが(UAラベルとして)バックアップ出力ノードに送信されます。正確にラベルが送信される方法は、このドキュメントの範囲外です。

When the backup egress node receives a UA label from the primary egress node, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the backup egress node receives a packet from the backup LSP, it uses the top label as a context label to find the LFIB for the primary egress node and uses the inner label to deliver the packet to the same destination as the primary egress node according to the LFIB.

バックアップ出力ノードは、プライマリ出力ノードからUAラベルを受信すると、ラベル付きの転送エントリをプライマリ出力ノードのLFIBに追加します。バックアップ出力ノードがバックアップLSPからパケットを受信すると、トップラベルをコンテキストラベルとして使用してプライマリ出力ノードのLFIBを検索し、内部ラベルを使用してパケットをプライマリ出力ノードと同じ宛先に配信しますLFIBに。

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

This document builds upon existing work, specifically, the security considerations of [RFC4090], [RFC4875], [RFC3209], and [RFC2205] continue to apply. Additionally, protecting a primary egress node of a P2P LSP carrying service traffic through a backup egress node requires out-of-band communication between the primary egress node and the backup egress node in order for the primary egress node to convey a service label as a UA label and also convey its related forwarding information to the backup egress node. It is important to confirm that the identifiers used to identify the primary and backup egress nodes in the LSP are verified to match with the identifiers used in the out-of-band protocol (such as BGP).

このドキュメントは既存の作業に基づいて構築されています。具体的には、[RFC4090]、[RFC4875]、[RFC3209]、および[RFC2205]のセキュリティに関する考慮事項が引き続き適用されます。さらに、バックアップ出力ノードを介してサービストラフィックを伝送するP2P LSPのプライマリ出力ノードを保護するには、プライマリ出力ノードがサービスラベルをUAラベルは、関連する転送情報をバックアップ出力ノードに伝えます。 LSPでプライマリおよびバックアップ出力ノードを識別するために使用される識別子が、帯域外プロトコル(BGPなど)で使用される識別子と一致することを確認することを確認することが重要です。

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

IANA maintains a registry called "Class Names, Class Numbers, and Class Types" under "Resource Reservation Protocol (RSVP) Parameters". IANA has assigned a new C-Type under the PROTECTION object class, Class Number 37:

IANAは、「リソース予約プロトコル(RSVP)パラメータ」の下に「クラス名、クラス番号、およびクラスタイプ」と呼ばれるレジストリを保持しています。 IANAは、PROTECTIONオブジェクトクラス、クラス番号37の下に新しいCタイプを割り当てました。

     Value     Description          Definition
     -----     -----------          ----------
     3         Egress Protection    Section 4.1
        

IANA has created and now maintains a registry under the PROTECTION object class (Class Number 37) and Egress Protection (C-Type 3). Initial values for the registry are given below. Future assignments are to be made through IETF Review [RFC8216].

IANAは、PROTECTIONオブジェクトクラス(クラス番号37)およびEgress Protection(Cタイプ3)の下にレジストリを作成し、現在維持しています。レジストリの初期値は以下のとおりです。今後の割り当ては、IETFレビュー[RFC8216]を通じて行われる予定です。

     Value      Description              Definition
     -----      -----------              ----------
      0         Reserved
      1         IPv4_PRIMARY_EGRESS      Section 4.1.1
      2         IPv6_PRIMARY_EGRESS      Section 4.1.1
      3         IPv4_P2P_LSP_ID          Section 4.1.2
      4         IPv6_P2P_LSP_ID          Section 4.1.2
      5-127     Unassigned
      128-255   Reserved
        
9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

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

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE:Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.

[RFC4090] Pan、P。、編、Swallow、G。、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<https://www.rfc-editor.org/info/rfc4090>。

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.

[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<https://www.rfc-editor .org / info / rfc4873>。

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.

[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering(RSVP-TE)for Point-to-Multipoint TE Label Switchedパス(LSP)」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<https://www.rfc-editor.org/info/rfc4875>。

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

[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", RFC 8216, DOI 10.17487/RFC8216, August 2017, <https://www.rfc-editor.org/info/rfc8216>.

[RFC8216]パントス、R。、エド。 W. May、「HTTP Live Streaming」、RFC 8216、DOI 10.17487 / RFC8216、2017年8月、<https://www.rfc-editor.org/info/rfc8216>。

9.2. Informative References
9.2. 参考引用

[FRAMEWK] Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., Michel, C., Chen, H., and Y. Jiang, "MPLS Egress Protection Framework", Work in Progress, draft-ietf-mpls-egress-protection-framework-00, January 2018.

[フレーム] Shen、Y.、Jeganathan、J.、Decraene、B.、Gredler、H.、Michel、C.、Chen、H.、Y。Jiang、「MPLS Egress Protection Framework」、Work in Progress、draft -ietf-mpls-egress-protection-framework-00、2018年1月。

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol(RSVP)-Version 1 Functional Specification」、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.

[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https://www.rfc -editor.org/info/rfc5331>。

Acknowledgements

謝辞

The authors would like to thank Richard Li, Nobo Akiya, Lou Berger, Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam, and Quintin Zhao for their valuable comments and suggestions on this document.

著者は、リチャード・リー、Nobo Akiya、Lou Berger、Jeffrey Zhang、Lizhong Jin、Ravi Torvi、Eric Grey、Olufemi Komolafe、Michael Yue、Daniel King、Rob Rennison、Neil Harrison、Kannan Sampath、Yimin Shen、Ronhazli Adamに感謝します、およびこのドキュメントに関する貴重なコメントと提案を提供してくれたQuintin Zhao。

Contributors

貢献者

The following people contributed significantly to the content of this document and should be considered coauthors:

次の人々はこの文書の内容に大きく貢献し、共著者と見なされるべきです:

Ning So Tata Email: ningso01@gmail.com

Ning So Tataメール:ningso01@gmail.com

Mehmet Toy Verizon Email: mehmet.toy@verizon.com

Mehmet Toy Verizonメール:mehmet.toy@verizon.com

Lei Liu Fujitsu Email: lliu@us.fujitsu.com

ぇい ぃう ふじつ えまいl: っぃう@うs。ふじつ。こm

Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com

Zは非常にビンl IH UAは技術メール:李振彬@ Huawei.com

We also acknowledge the contributions of the following individuals:

また、次の個人の貢献も認めます。

Boris Zhang Telus Communications Email: Boris.Zhang@telus.com

Boris Zhang Telusコミュニケーションメール:Boris.Zhang@telus.com

Nan Meng Huawei Technologies Email: mengnan@huawei.com

NaN men GH UAはテクノロジーメールです:猛男@ Huawei.com

Prejeeth Kaladharan Huawei Technologies Email: prejeeth@gmail.com

Prejeeth Huawei Technologiesメール:prejeeth@gmail.com

Vic Liu China Mobile Email: liu.cmri@gmail.com

Vic Liu Chinaモバイルメール:liu.cmri@gmail.com

Authors' Addresses

著者のアドレス

Huaimo Chen Huawei Technologies Boston, MA United States of America

ふあいも ちぇん ふあうぇい てchのぉぎえs ぼsとん、 ま うにてd Sたてs おf あめりか

   Email: huaimo.chen@huawei.com
        

Autumn Liu Ciena United States of America

秋リューシエナアメリカ合衆国

   Email: hliu@ciena.com
        

Tarek Saad Cisco Systems

Saad Cisco Systemsの追跡

   Email: tsaad@cisco.com
        

Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 United States of America

Fengman Xu Verizon 2400 N. Glenville Dr Richardson、TX 75082アメリカ合衆国

   Email: fengman.xu@verizon.com
        

Lu Huang China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing 100053 China

l u Huang China Mobile no.32 X u Press Wumen west street、ξは北京100053 China地区になります

   Email: huanglu@chinamobile.com