[要約] RFC 5150は、GMPLS TEを使用したラベルスイッチパスのステッチングに関するものであり、その目的は異なるネットワーク領域間でのトラフィックエンジニアリングを可能にすることです。
Network Working Group A. Ayyangar
Request for Comments: 5150 K. Kompella
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
A. Farrel
Old Dog Consulting
February 2008
Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチ付きパスステッチ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
特定のシナリオでは、いくつかの一般化されたマルチプロトコルラベルスイッチング（GMPLS）ラベルスイッチ付きパス（LSP）を組み合わせる必要がある場合があります。そのため次のLSP。これを「LSPステッチ」と呼びます。重要な要件は、構成LSPが複数のE2E LSPに割り当てられないことです。構成要素LSPは、「LSPセグメント」（S-LSP）と呼ばれます。
This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.
このドキュメントは、既存のGMPLSシグナリングプロトコル（リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE））の拡張を説明して、S-LSPから作成されたE2E LSPを確立し、GMPLSシグナル伝達とルーティングプロトコルを使用してLSPを管理する方法について説明します。
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching.
GMPLSノードを構成して、それが出口であるLSPからトラフィックを切り替えることができます。シグナリングやルーティングの拡張機能を必要とせずに、侵入を必要とせず、操作が完全に透過的であるようにすることはできません。他のノード。これにより、データプレーンでLSPステッチが発生します。ただし、このドキュメントでは、LSPステッチのこのシナリオをカバーしていません。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Comparison with LSP Hierarchy ...................................3
3. Usage ...........................................................4
3.1. Triggers for LSP Segment Setup .............................4
3.2. Applications ...............................................5
4. Routing Aspects .................................................5
5. Signaling Aspects ...............................................6
5.1. RSVP-TE Signaling Extensions ...............................7
5.1.1. Creating and Preparing an LSP Segment for
Stitching ...........................................7
5.1.1.1. Steps to Support Penultimate Hop
Popping ....................................8
5.1.2. Stitching the e2e LSP to the LSP Segment ............9
5.1.3. RRO Processing for e2e LSPs ........................10
5.1.4. Teardown of LSP Segments ...........................11
5.1.5. Teardown of e2e LSPs ...............................11
5.2. Summary of LSP Stitching Procedures .......................12
5.2.1. Example Topology ...................................12
5.2.2. LSP Segment Setup ..................................12
5.2.3. Setup of an e2e LSP ................................13
5.2.4. Stitching of an e2e LSP into an LSP Segment ........13
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. Attribute Flags for LSP_ATTRIBUTES Object .................15
7.2. New Error Codes ...........................................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering (TE) Label Switched Path (LSP) is built from a set of different "LSP segments" (S-LSPs) that are connected together in the data plane in such a way that a single end-to-end LSP is realized in the data plane. In this document, we define the concept of LSP stitching and detail the control plane mechanisms and procedures (routing and signaling) to accomplish this. Where applicable, similarities and differences between LSP hierarchy [RFC4206] and LSP stitching are highlighted. Signaling extensions required for LSP stitching are also described here.
ステッチされた一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）は、データプレーンで接続されている異なる「LSPセグメント」（SLSP）のセットから構築されています。シングルエンドツーエンドのLSPがデータプレーンで実現されます。このドキュメントでは、LSPステッチの概念を定義し、これを達成するために制御プレーンのメカニズムと手順（ルーティングとシグナル伝達）を詳細に説明します。該当する場合、LSP階層[RFC4206]とLSPステッチの類似点と相違点が強調表示されます。LSPステッチに必要なシグナリング拡張機能についてもここで説明します。
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This results in LSP stitching in the data plane, but requires management intervention at the node where the stitching is performed. With the mechanism described in this document, the node performing the stitching does not require configuration of the pair of S-LSPs to be stitched together. Also, LSP stitching as defined here results in an end-to-end LSP both in the control and data planes.
GMPLSノードを構成して、それが出口であるLSPからトラフィックを切り替えることができます。シグナリングやルーティングの拡張機能を必要とせずに、侵入を必要とせず、操作が完全に透過的であるようにすることはできません。他のノード。これにより、データプレーンでLSPステッチが発生しますが、ステッチが実行されるノードでの管理介入が必要です。このドキュメントで説明されているメカニズムを使用すると、ステッチを実行するノードでは、S-LSPのペアの構成を一緒にステッチする必要はありません。また、ここで定義されているLSPステッチは、制御面とデータプレーンの両方でエンドツーエンドのLSPをもたらします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
LSP hierarchy ([RFC4206]) provides signaling and routing procedures so that:
LSP階層（[RFC4206]）は、次のようにシグナル伝達とルーティングの手順を提供します。
a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created in one layer can appear as a data link to LSPs in higher layers. As such, one or more LSPs in a higher layer can traverse this H-LSP as a single hop; we call this "nesting".
a. 階層LSP（H-LSP）を作成できます。1つのレイヤーで作成されたこのようなLSPは、高レイヤーのLSPへのデータリンクとして表示されます。そのため、高層の1つ以上のLSPは、このH-LSPを単一のホップとして横断することができます。これを「ネスト」と呼びます。
b. An H-LSP may be managed and advertised (although this is not a requirement) as a Traffic Engineering (TE) link. Advertising an H-LSP as a TE link allows other nodes in the TE domain in which it is advertised to use this H-LSP in path computation. If the H-LSP TE link is advertised in the same instance of control plane (TE domain) in which the H-LSP was provisioned, it is then defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes can form a forwarding adjacency (FA) over this FA-LSP. There is usually no routing adjacency between end points of an FA. An H-LSP may also be advertised as a TE link in a different TE domain. In this case, the end points of the H-LSP are required to have a routing adjacency between them.
b. H-LSPは、トラフィックエンジニアリング（TE）リンクとして管理および宣伝されます（これは要件ではありませんが）。H-LSPをTEリンクとして宣伝することで、TEドメインの他のノードを使用すると、このH-LSPをパス計算で使用することが宣伝されます。H-LSP TEリンクが、H-LSPがプロビジョニングされたコントロールプレーン（TEドメイン）の同じインスタンスで宣伝されている場合、転送隣接LSP（FA-LSP）として定義され、GMPLSノードは転送を形成できます。このFA-LSPの隣接（FA）。通常、FAのエンドポイント間にルーティング隣接はありません。H-LSPは、別のTEドメインのTEリンクとして宣伝される場合があります。この場合、H-LSPのエンドポイントは、それらの間にルーティング隣接を持つ必要があります。
c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur between nodes that do not have a routing adjacency.
c. LSPセットアップのRSVPシグナル伝達（[RFC3473]、[RFC3209]）は、ルーティング隣接を持たないノード間で発生する可能性があります。
In case of LSP stitching, instead of an H-LSP, an LSP segment (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching is considered to be the moral equivalent of an H-LSP for nesting. An S-LSP created in one layer, unlike an H-LSP, provides a data link to other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be managed and advertised, although it is not required, as a TE link, either in the same TE domain as it was provisioned or a different one. If so advertised, other GMPLS nodes can use the corresponding S-LSP TE link in path computation. While there is a forwarding adjacency between end points of an H-LSP TE link, there is no forwarding adjacency between end points of an S-LSP TE link. In this aspect, an H-LSP TE link more closely resembles a 'basic' TE link as compared to an S-LSP TE link.
LSPステッチの場合、H-LSPの代わりに、2つのGMPLSノードの間にLSPセグメント（S-LSP）が作成されます。ステッチ用のs-lspは、ネストのh-lspに相当する道徳的同等物であると考えられています。H-LSPとは異なり、1つの層で作成されたS-LSPは、同じレイヤーの他のLSPへのデータリンクを提供します。H-LSPと同様に、S-LSPを管理および宣伝することができますが、プロビジョニングと同じTEドメインまたは別のドメインのいずれかで、TEリンクとして必須ではありません。その場合、他のGMPLSノードは、パス計算で対応するS-LSP TEリンクを使用できます。H-LSP TEリンクのエンドポイント間に転送隣接性がありますが、S-LSP TEリンクのエンドポイント間に転送隣接性はありません。この側面では、H-LSP TEリンクは、S-LSP TEリンクと比較して、「基本的な」TEリンクに類似しています。
While LSP hierarchy allows more than one LSP to be mapped to an H-LSP, in case of LSP stitching, at most one LSP may be associated with an S-LSP. Thus, if LSP-AB is an H-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, and LSP3, can potentially be 'nested into' LSP-AB. This is achieved by exchanging a unique label for each of LSP1..3 over the LSP-AB hop, thereby separating the data corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1, and no other LSPs can be associated with LSP-AB. The entire bandwidth on S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs, several S-LSPs may be bundled into a TE link ([RFC4201]).
LSP階層では、LSPステッチの場合、LSPを超えるLSPをH-LSPにマッピングできますが、最大で1つのLSPがS-LSPに関連付けられている可能性があります。したがって、LSP-ABがノードAとBの間のH-LSPである場合、複数のLSP、たとえばLSP1、LSP2、およびLSP3は、潜在的に「LSP-AB」にネストされる可能性があります。これは、LSP-ABホップ上でLSP1..3のそれぞれのユニークなラベルを交換することで達成され、それにより、LSP1..3のそれぞれに対応するデータをH-LSP LSP-ABを横断しながら分離します。LSP1..3のそれぞれは、LSP-ABの帯域幅を予約する場合があります。一方、LSP-ABがS-LSPである場合、最大で1つのLSP、たとえばLSP1がS-LSP LSP-ABに縫われる可能性があります。LSP-ABはLSP1専用であり、LSP-ABに関連する他のLSPはありません。S-LSP LSP-ABの帯域幅全体がLSP1に割り当てられます。ただし、H-LSPと同様に、いくつかのS-LSPがTEリンクにバンドルされる可能性があります（[RFC4201]）。
The LSPs LSP1..3 that are either nested or stitched into another LSP are termed as e2e LSPs in the rest of this document. Routing procedures specific to LSP stitching are detailed in Section 4.
別のLSPにネストまたはステッチされたLSPS LSP1..3は、このドキュメントの残りの部分でE2E LSPと呼ばれます。LSPステッチに固有のルーティング手順については、セクション4で詳しく説明しています。
Targeted (non-adjacent) RSVP signaling defined in [RFC4206] is required for LSP stitching of an e2e LSP to an S-LSP. Specific extensions for LSP stitching are described in Section 5.1. Therefore, in the control plane, there is one RSVP session corresponding to the e2e LSP as well as one for each S-LSP. The creation and termination of an S-LSP may be dictated by administrative control (statically provisioned) or due to another incoming LSP request (dynamic). Triggers for dynamic creation of an S-LSP may be different from that of an H-LSP and will be described in detail in Section 3.1.
[RFC4206]で定義されたターゲット（非隣接）RSVPシグナル伝達は、E2E LSPのS-LSPへのLSPステッチに必要です。LSPステッチの特定の拡張機能は、セクション5.1で説明されています。したがって、コントロールプレーンには、E2E LSPに対応する1つのRSVPセッションと各S-LSPに対応する1つのRSVPセッションがあります。S-LSPの作成と終了は、管理制御（静的にプロビジョニングされた）または別の着信LSP要求（動的）によって決定される場合があります。S-LSPの動的作成のトリガーは、H-LSPの動的作成とは異なる場合があり、セクション3.1で詳細に説明されます。
An S-LSP may be created either by administrative control (configuration trigger) or dynamically due to an incoming LSP request. LSP hierarchy ([RFC4206]) defines one possible trigger for dynamic creation of an FA-LSP by introducing the notion of LSP regions based on Interface Switching Capabilities. As per [RFC4206], dynamic FA-LSP creation may be triggered on a node when an incoming LSP request crosses region boundaries. However, this trigger MUST NOT be used for creation of an S-LSP for LSP stitching as described in this document. In case of LSP stitching, the switching capabilities of the previous hop and the next hop TE links MUST be the same. Therefore, local policies configured on the node SHOULD be used for dynamic creation of LSP segments.
S-LSPは、LSPリクエストが発生するため、管理制御（構成トリガー）または動的に作成される場合があります。LSP階層（[RFC4206]）は、インターフェイススイッチング機能に基づいてLSP領域の概念を導入することにより、FA-LSPを動的に作成するための1つの可能なトリガーを定義します。[RFC4206]によると、着信LSP要求が領域の境界を越えると、ノードで動的なFA-LSP作成がトリガーされる場合があります。ただし、このドキュメントで説明されているように、このトリガーをLSPステッチ用のS-LSPの作成に使用してはなりません。LSPステッチの場合、前のホップと次のホップリンクのスイッチング機能は同じでなければなりません。したがって、ノードで構成されたローカルポリシーは、LSPセグメントの動的な作成に使用する必要があります。
Other possible triggers for dynamic creation of both H-LSPs and S-LSPs include cases where an e2e LSP may cross domain boundaries or satisfy locally configured policies on the node as described in [RFC5151].
H-LSPとS-LSPの両方を動的に作成するための他の可能なトリガーには、[RFC5151]で説明されているように、E2E LSPがドメインの境界を越えたり、ノードでローカルで構成されたポリシーを満たすことができる場合が含まれます。
LSP stitching procedures described in this document are applicable to GMPLS nodes that need to associate an e2e LSP with another S-LSP of the same switching type and LSP hierarchy procedures do not apply. For example, if an e2e lambda LSP traverses an LSP segment TE link that is also lambda-switch capable, then LSP hierarchy is not possible; in this case, LSP switching may be an option.
このドキュメントで説明されているLSPステッチ手順は、E2E LSPを同じスイッチングタイプの別のS-LSPに関連付ける必要があるGMPLSノードに適用され、LSP階層手順は適用されません。たとえば、E2E Lambda LSPがLAMBDA-SWITCHでも有能なLSPセグメントTEリンクを横断する場合、LSP階層は不可能です。この場合、LSPスイッチングがオプションになる場合があります。
LSP stitching procedures can be used for inter-domain TE LSP signaling to stitch an inter-domain e2e LSP to a local intra-domain TE S-LSP ([RFC4726] and [RFC5151]).
LSPステッチ手順は、ドメイン間TE LSPシグナル伝達に使用して、ドメイン間E2E LSPを局所内部domain TE S-LSP（[RFC4726]および[RFC5151]）に縫います。
LSP stitching may also be useful in networks to bypass legacy nodes that may not have certain new capabilities in the control plane and/or data plane. For example, one suggested usage in the case of point-to-multipoint (P2MP) RSVP LSPs ([RFC4875]) is the use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP-capable Label Switching Routers (LSRs) in the network. The LSP segment would traverse legacy LSRs that may be incapable of acting as P2MP branch points, thereby shielding them from the P2MP control and data path. Note, however, that such configuration may limit the attractiveness of RSVP P2MP and should carefully be examined before deployment.
LSPステッチは、コントロールプレーンおよび/またはデータプレーンに特定の新しい機能を持たない可能性のあるレガシーノードをバイパスするためのネットワークでも役立ちます。たとえば、ポイントツーマルチポイント（P2MP）RSVP LSP（[RFC4875]）の場合の使用法は、LSPステッチを使用してP2MP RSVP LSPをP2MP対応ラベルスイッチングルーターの間のLSPセグメント（LSRSRSSRSS）間のLSPセグメントに縫い合わせた使用です。）ネットワーク内。LSPセグメントは、P2MPブランチポイントとして機能することができない可能性のあるレガシーLSRを横断し、それによりP2MP制御とデータパスからそれらを保護します。ただし、そのような構成はRSVP P2MPの魅力を制限し、展開前に慎重に検査する必要があることに注意してください。
An S-LSP is created between two GMPLS nodes, and it may traverse zero or more intermediate GMPLS nodes. There is no forwarding adjacency between the end points of an S-LSP TE link. So although in the TE topology, the end points of an S-LSP TE link are adjacent, in the data plane, these nodes do not have an adjacency. Hence, any data plane resource identifier between these nodes is also meaningless.
S-LSPは2つのGMPLSノードの間に作成され、ゼロ以上の中間GMPLSノードを通過する場合があります。S-LSP TEリンクのエンドポイント間に転送隣接はありません。したがって、TEトポロジでは、S-LSP TEリンクのエンドポイントは隣接していますが、データプレーンでは、これらのノードには隣接がありません。したがって、これらのノード間のデータプレーンリソース識別子も意味がありません。
The traffic that arrives at the head end of the S-LSP is switched into the S-LSP contiguously with a label swap, and no label is associated directly between the end nodes of the S-LSP itself.
An S-LSP MAY be treated and managed as a TE link. This TE link MAY be numbered or unnumbered. For an unnumbered S-LSP TE link, the schemes for assignment and handling of the local and remote link identifiers as specified in [RFC3477] SHOULD be used. When appropriate, the TE information associated with an S-LSP TE link MAY be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203]. Mechanisms similar to that for regular (basic) TE links SHOULD be used to flood S-LSP TE links. Advertising or flooding the S-LSP TE link is not a requirement for LSP stitching. If advertised, this TE information will exist in the TE database (TED) and can then be used for path computation by other GMPLS nodes in the TE domain in which it is advertised. When so advertising S-LSPs, one should keep in mind that these add to the size and complexity of the link-state database.
S-LSPは、TEリンクとして扱われ、管理できます。このリンクには番号が付けられているか、数字が付いていない場合があります。非番号のS-LSP TEリンクの場合、[RFC3477]で指定されているローカルおよびリモートリンク識別子の割り当てと取り扱いのスキームを使用する必要があります。適切な場合、S-LSP TEリンクに関連付けられたTE情報は、ISIS-TE [RFC4205]またはOSPF-TE [RFC4203]を介して浸水する可能性があります。通常の（基本的な）TEリンクと同様のメカニズムは、S-LSP TEリンクをフラッディングするために使用する必要があります。広告または洪水のS-LSP TEリンクは、LSPステッチの要件ではありません。宣伝されている場合、この情報はTEデータベース（TED）に存在し、その後、宣伝されているTEドメインの他のGMPLSノードによるパス計算に使用できます。S-LSPを広告する場合、これらはリンク状態データベースのサイズと複雑さに追加されることに留意する必要があります。
If an S-LSP is advertised as a TE link in the same TE domain in which it was provisioned, there is no need for a routing adjacency between end points of this S-LSP TE link. If an S-LSP TE link is advertised in a different TE domain, the end points of that TE link SHOULD have a routing adjacency between them.
S-LSPがプロビジョニングされた同じドメインのTEリンクとして宣伝されている場合、このS-LSP TEリンクのエンドポイント間のルーティング隣接性は必要ありません。S-LSP TEリンクが別のTEドメインで宣伝されている場合、そのTEリンクのエンドポイントには、それらの間にルーティング隣接性が必要です。
The TE parameters defined for an FA in [RFC4206] SHOULD be used for an S-LSP TE link as well. The switching capability of an S-LSP TE link MUST be equal to the switching type of the underlying S-LSP; i.e., an S-LSP TE link provides a data link to other LSPs in the same layer, so no hierarchy is possible.
An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to zero to prevent further e2e LSPs from being admitted into the S-LSP.
S-LSPは、複数のE2E LSPを認めてはなりません。S-LSPがE2E LSPに割り当てられた場合、予約されていない帯域幅をゼロに設定して、さらなるE2E LSPがS-LSPに入院するのを防ぐ必要があります。
Multiple S-LSPs between the same pair of nodes MAY be bundled using the concept of Link Bundling ([RFC4201]) into a single TE link. In this case, each component S-LSP may be allocated to at most one e2e LSP. When any component S-LSP is allocated for an e2e LSP, the component's unreserved bandwidth SHOULD be set to zero and the Minimum and Maximum LSP bandwidth of the TE link SHOULD be recalculated. This will prevent more than one LSP from being computed and admitted over an S-LSP.
同じノードのペア間の複数のS-LSPは、リンクバンドリング（[RFC4201]）の概念を使用して単一のTEリンクにバンドルされる場合があります。この場合、各コンポーネントS-LSPは、最大1つのE2E LSPに割り当てられる場合があります。E2E LSPにコンポーネントS-LSPが割り当てられた場合、コンポーネントの予約されていない帯域幅をゼロに設定し、TEリンクの最小LSP帯域幅を再計算する必要があります。これにより、複数のLSPがs-lspで計算され、認められないようになります。
The end nodes of an S-LSP may or may not have a routing adjacency. However, they SHOULD have a signaling adjacency (RSVP neighbor relationship) and will exchange RSVP messages with each other. It may, in fact, be desirable to exchange RSVP Hellos directly between the LSP segment end points to allow support for state recovery during Graceful Restart procedures as described in [RFC3473].
s-lspのエンドノードには、ルーティング隣接がある場合とない場合があります。ただし、シグナリング隣接（RSVP近隣関係）が必要であり、RSVPメッセージを互いに交換する必要があります。実際、[RFC3473]に記載されているように、優雅な再起動手順中に状態回復のサポートを可能にするために、LSPセグメントのエンドポイント間でRSVP Hellosを直接交換することが望ましい場合があります。
In order to signal an e2e LSP over an LSP segment, signaling procedures described in Section 8.1.1 of [RFC4206] MUST be used. Additional signaling extensions for stitching are described in the next section.
LSPセグメントでE2E LSPを信号するには、[RFC4206]のセクション8.1.1で説明されているシグナル伝達手順を使用する必要があります。ステッチ用の追加のシグナル伝達拡張機能については、次のセクションで説明します。
The signaling extensions described here MUST be used for stitching an e2e packet or non-packet GMPLS LSP ([RFC3473]) to an S-LSP.
ここで説明するシグナリング拡張機能は、E2Eパケットまたは非パケットGMPLS LSP（[RFC3473]）をS-LSPに縫うために使用する必要があります。
Stitching an e2e LSP to an LSP segment involves the following two-step process:
E2E LSPをLSPセグメントに縫うには、次の2段階のプロセスが含まれます。
1. Creating and preparing the S-LSP for stitching by signaling the desire to stitch between end points of the S-LSP; and
1. s-lspのエンドポイント間でステッチしたいという欲求を知らせることにより、ステッチ用のs-lspを作成および準備します。と
2. Stitching the e2e LSP to the S-LSP.
2. E2E LSPをS-LSPに縫います。
If a GMPLS node desires to create an S-LSP, i.e., one to be used for stitching, then it MUST indicate this in the Path message for the S-LSP. This signaling explicitly informs the S-LSP egress node that the ingress node is planning to perform stitching over the S-LSP. Since an S-LSP is not conceptually different from any other LSP, explicitly signaling 'LSP stitching desired' helps clarify the data plane actions to be carried out when the S-LSP is used by some other e2e LSP. Also, in the case of packet LSPs, this is what allows the egress of the S-LSP to carry out label allocation as explained below. Also, so that the head-end node can ensure that correct stitching actions will be carried out at the egress node, the egress node MUST signal this information back to the head-end node in the Resv, as explained below.
GMPLSノードがs-lsp、つまりステッチに使用するものを作成したい場合は、s-lspのパスメッセージにこれを示す必要があります。このシグナル伝達は、S-LSP Egressノードに、IngressノードがS-LSPのステッチを実行することを計画していることを明示的に通知します。S-LSPは他のLSPと概念的に異なっていないため、「LSPステッチの目的」を明示的に信号することで、S-LSPが他のE2E LSPで使用されるときに実行されるデータプレーンアクションを明確にするのに役立ちます。また、パケットLSPの場合、これは、以下で説明するように、S-LSPの出力をラベル割り当てを実行できるようにするものです。また、ヘッドエンドノードが正しいステッチアクションをEgressノードで実行できるようにするために、Eugressノードは、以下で説明するように、この情報をRESVのヘッドエンドノードに信号に戻す必要があります。
In order to request LSP stitching on the S-LSP, we define a new bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC4420]:
s-lspでLSPステッチを要求するために、[rfc4420]で定義されたlsp_attributesオブジェクトの属性フラグTLVに新しいビットを定義します。
LSP stitching desired bit - This bit SHOULD be set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message for the S-LSP by the head end of the S-LSP that desires LSP stitching. This bit MUST NOT be modified by any other nodes in the network. Nodes other than the egress of the S-LSP SHOULD ignore this bit. The bit number for this flag is defined in Section 7.1.
LSPステッチの希望ビット - このビットは、LSPステッチを必要とするS-LSPのヘッドエンドでS-LSPのパスメッセージにlsp_attributesオブジェクトの属性フラグTLVに設定する必要があります。このビットは、ネットワーク内の他のノードによって変更されてはなりません。S-LSPの出口以外のノードは、このビットを無視する必要があります。このフラグのビット番号は、セクション7.1で定義されています。
An LSP segment can be used for stitching only if the egress node of the S-LSP is also ready to participate in stitching. In order to indicate this to the head-end node of the S-LSP, the following new bit is defined in the Flags field of the Record Route object (RRO) Attributes subobject: "LSP segment stitching ready". The bit number for this flag is defined in Section 7.1.
LSPセグメントは、S-LSPの出口ノードがステッチに参加する準備ができている場合にのみ、ステッチに使用できます。これをS-LSPのヘッドエンドノードに示すために、次の新しいビットは、レコードルートオブジェクト（RRO）属性のフラグフィールドで定義されています。「LSPセグメントステッチ対応」。このフラグのビット番号は、セクション7.1で定義されています。
If an egress node of the S-LSP receiving the Path message supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "LSP stitching desired" bit, but cannot support the requested stitching behavior, then it MUST send back a PathErr message with an error code of "Routing Problem" and an error value of "Stitching unsupported" to the head-end node of the S-LSP. The new error value is defined in Section 7.2.
パスメッセージを受信するS-LSPの出口ノードがLSP_ATTRIBUTESオブジェクトと属性フラグTLVをサポートし、「LSPステッチが望ましい」ビットを認識しますが、要求されたステッチ操作をサポートできない場合は、PatherRメッセージを送信する必要があります。「ルーティング問題」のエラーコードと、s-lspのヘッドエンドノードに「サポートされていない縫い付け」のエラー値があります。新しいエラー値は、セクション7.2で定義されています。
If an egress node receiving a Path message with the "LSP stitching desired" bit set in the Flags field of received LSP_ATTRIBUTES object recognizes the object, the TLV TLV, and the bit and also supports the desired stitching behavior, then it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message. Also, so that the head-end node can ensure that the correct label (forwarding) actions will be carried out by the egress node and that the S-LSP can be used for stitching, the egress node MUST set the "LSP segment stitching ready" bit defined in the Flags field of the RRO Attribute subobject.
「LSPステッチが望ましい」ビットを使用してパスメッセージを受信する出力ノードが、受信したLSP_ATTRIBUTESオブジェクトのフラグフィールドに設定された[TLV TLV]を認識し、ビットを認識し、目的のステッチ挙動をサポートする場合、非非を割り当てる必要があります。 - 対応するRESVメッセージのそのs-lspのヌルラベル。また、ヘッドエンドノードがEgressノードによって正しいラベル（転送）アクションが実行され、S-LSPをステッチに使用できるようにするために、出力ノードは「LSPセグメントステッチ対応」を設定する必要があります。「RRO属性SubObjectのフラグフィールドでビットが定義されています。
Finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV, or supports the TLV as well but does not recognize this particular bit, then it SHOULD simply ignore the above request.
最後に、S-LSPの出口ノードがLSP_ATTRIBUTESオブジェクトをサポートしているが、属性フラグTLVを認識しない場合、またはTLVもサポートしますが、この特定のビットを認識しない場合、上記のリクエストを無視する必要があります。
An ingress node requesting LSP stitching MUST examine the RRO Attributes subobject Flags corresponding to the egress node for the S-LSP, to make sure that stitching actions are carried out at the egress node. It MUST NOT use the S-LSP for stitching if the "LSP segment stitching ready" bit is cleared.
LSPステッチを要求するイングレスノードは、S-LSPの出力ノードに対応するrro属性サブオブジェクトフラグを調べて、縫い目界が出口ノードで実行されることを確認する必要があります。「LSPセグメントステッチ対応」ビットがクリアされている場合、ステッチにS-LSPを使用しないでください。
Note that this section is only applicable to packet LSPs that use Penultimate Hop Popping (PHP) at the last hop, where the egress node distributes the Implicit NULL Label ([RFC3032]) in the Resv Label. These steps MUST NOT be used for a non-packet LSP and for packet LSPs where PHP is not desired.
このセクションは、最後のホップで最後から2番目のホップポップ（PHP）を使用するパケットLSPにのみ適用できることに注意してください。ここで、出口ノードはRESVラベルの暗黙のヌルラベル（[RFC3032]）を分散します。これらの手順は、非パケットLSPおよびPHPが望ましくないパケットLSPに使用してはなりません。
When the egress node of a packet S-LSP receives a Path message for an e2e LSP that uses the S-LSP, the egress of the S-LSP SHOULD first check to see if it is also the egress of the e2e LSP. If the egress node is the egress for both the S-LSP and the e2e TE LSP, and this is a packet LSP that requires PHP, then the node MUST send back a Resv trigger message for the S-LSP with a new label corresponding to the Implicit or Explicit NULL Label. Note that this operation does not cause any traffic disruption because the S-LSP is not carrying any traffic at this time, since the e2e LSP has not yet been established.
パケットS-LSPの出口ノードがS-LSPを使用するE2E LSPのパスメッセージを受信する場合、S-LSPの出口は、それがE2E LSPの出口でもあるかどうかを確認するために最初に確認する必要があります。出口ノードがS-LSPとE2E TE LSPの両方の出口であり、これがPHPを必要とするパケットLSPである場合、ノードは、に対応する新しいラベルを持つS-LSPのRESVトリガーメッセージを送信する必要があります暗黙的または明示的なヌルラベル。E2E LSPがまだ確立されていないため、S-LSPが現時点ではトラフィックを運んでいないため、この操作はトラフィックの混乱を引き起こさないことに注意してください。
If the e2e LSP and the S-LSP are bidirectional, the ingress of the e2e LSP SHOULD first check whether it is also the ingress of the S-LSP. If so, it SHOULD re-issue the Path message for the S-LSP with an Implicit or Explicit NULL Upstream Label, and only then proceed with the signaling of the e2e LSP.
E2E LSPとS-LSPが双方向である場合、E2E LSPの侵入は、まずS-LSPの侵入であるかどうかを確認する必要があります。その場合、暗黙的または明示的なヌルアップストリームラベルを使用して、S-LSPのパスメッセージを再発行し、E2E LSPのシグナル伝達を進める必要があります。
When a GMPLS node receives an e2e LSP request, depending on the applicable trigger, it may either dynamically create an S-LSP based on procedures described above or map an e2e LSP to an existing S-LSP. The switching type in the Generalized Label Request of the e2e LSP MUST be equal to the switching type of the S-LSP. Other constraints like the explicit path encoded in the Explicit Route object (ERO), bandwidth, and local TE policies MUST also be used for S-LSP selection or signaling. In either case, once an S-LSP has been selected for an e2e LSP, the following procedures MUST be followed in order to stitch an e2e LSP to an S-LSP.
GMPLSノードが該当するトリガーに応じてE2E LSP要求を受信すると、上記の手順に基づいてS-LSPを動的に作成するか、E2E LSPを既存のS-LSPにマッピングできます。E2E LSPの一般化されたラベル要求のスイッチングタイプは、S-LSPのスイッチングタイプに等しくなければなりません。明示的なルートオブジェクト（ERO）、帯域幅、およびローカルTEポリシーにエンコードされた明示的なパスなどの制約も、S-LSP選択またはシグナリングに使用する必要があります。どちらの場合でも、E2E LSPにS-LSPが選択されたら、E2E LSPをS-LSPに縫うためには、次の手順に従う必要があります。
The GMPLS node receiving the e2e LSP setup Path message MUST use the signaling procedures described in [RFC4206] to send the Path message to the end point of the S-LSP. In this Path message, the node MUST identify the S-LSP in the RSVP_HOP. An egress node receiving this RSVP_HOP should also be able to identify the S-LSP TE link based on the information signaled in the RSVP_HOP. If the S-LSP TE link is numbered, then the addressing scheme as proposed in [RFC4206] SHOULD be used to number the S-LSP TE link. If the S-LSP TE link is unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be used to exchange S-LSP TE link identifiers between the S-LSP end points. If the TE link is bundled, the RSVP_HOP SHOULD identify the component link as defined in [RFC4201].
E2E LSPセットアップパスメッセージを受信するGMPLSノード[RFC4206]で説明されているシグナル手順を使用して、S-LSPのエンドポイントにパスメッセージを送信する必要があります。このパスメッセージでは、ノードはrsvp_hopのs-lspを識別する必要があります。このrsvp_hopを受信する出力ノードは、RSVP_HOPで信号が掲載されている情報に基づいてS-LSP TEリンクを識別できるはずです。S-LSP TEリンクに番号が付けられている場合、[RFC4206]で提案されているアドレス指定スキームを使用して、S-LSP TEリンクを番号にする必要があります。s-lsp teリンクが1つのリンクである場合、[RFC3477]で提案されているスキームのいずれかを使用して、S-LSPエンドポイント間のS-LSP TEリンク識別子を交換する必要があります。TEリンクがバンドルされている場合、RSVP_HOPは[RFC4201]で定義されているコンポーネントリンクを識別する必要があります。
In case of a bidirectional e2e TE LSP, an Upstream Label MUST be signaled in the Path message for the e2e LSP over the S-LSP hop. However, since there is no forwarding adjacency between the S-LSP end points, any label exchanged between them has no significance. So the node MAY chose any label value for the Upstream Label. The label value chosen and signaled by the node in the Upstream Label is out of the scope of this document and is specific to the implementation on that node. The egress node receiving this Path message MUST ignore the Upstream Label in the Path message over the S-LSP hop.
双方向E2E TE LSPの場合、S-LSPホップ上のE2E LSPのパスメッセージで上流のラベルを通知する必要があります。ただし、S-LSPエンドポイントの間に転送隣接性がないため、それらの間で交換されるラベルは重要ではありません。そのため、ノードは上流ラベルのラベル値を選択できます。アップストリームラベルのノードによって選択および信号が選択および信号が選択され、このドキュメントの範囲外であり、そのノードの実装に固有です。このパスメッセージを受信する出力ノードは、S-LSPホップ上のパスメッセージの上流ラベルを無視する必要があります。
The egress node receiving this Path message MUST signal a Label in the Resv message for the e2e TE LSP over the S-LSP hop. Again, since there is no forwarding adjacency between the egress and ingress S-LSP nodes, any label exchanged between them is meaningless. So the egress node MAY choose any label value for the Label. The label value chosen and signaled by the egress node is out of the scope of this document and is specific to the implementation on the egress node. The egress S-LSP node SHOULD also carry out data plane operations so that traffic coming in on the S-LSP is switched over to the e2e LSP downstream, if the egress of the e2e LSP is some other node downstream. If the e2e LSP is bidirectional, this means setting up label switching in both directions. The Resv message from the egress S-LSP node is IP routed back to the previous hop (ingress of the S-LSP). The ingress node stitching an e2e TE LSP to an S-LSP MUST ignore the Label object received in the Resv for the e2e TE LSP over the S-LSP hop. The S-LSP ingress node SHOULD also carry out data plane operations so that traffic coming in on the e2e LSP is switched into the S-LSP. It should also carry out actions to handle traffic in the opposite direction if the e2e LSP is bidirectional.
このパスメッセージを受信する出力ノードは、S-LSPホップ上のE2E TE LSPのRESVメッセージのラベルを信号する必要があります。繰り返しになりますが、出口と侵入s-lspノードの間に隣接する転送性がないため、それらの間で交換されるラベルは無意味です。したがって、出力ノードは、ラベルのラベル値を選択できます。Egressノードによって選択および信号が選択され、信号が選択され、このドキュメントの範囲外であり、出口ノードの実装に固有のものです。Egress S-LSPノードは、E2E LSPの出力が下流の他のノードである場合、S-LSPに入るトラフィックがE2E LSPの下流に切り替えるように、データプレーン操作を実行する必要があります。E2E LSPが双方向である場合、これは両方向にラベルスイッチングを設定することを意味します。Egress S-LSPノードからのRESVメッセージは、前のホップ（S-LSPのイングレス）に戻るIPです。E2E TE LSPをS-LSPにステッチするイングレスノードは、S-LSPホップ上のE2E TE LSPのRESVで受信したラベルオブジェクトを無視する必要があります。S-LSP Ingressノードは、E2E LSPに入るトラフィックがS-LSPに切り替えるように、データプレーン操作も実行する必要があります。また、E2E LSPが双方向である場合、トラフィックを反対方向に処理するためのアクションを実行する必要があります。
Note that the label exchange procedure for LSP stitching on the S-LSP hop is similar to that for LSP hierarchy over the H-LSP hop. The difference is the lack of the significance of this label between the S-LSP end points in case of stitching. Therefore, in case of stitching, the recipients of the Label/Upstream Label MUST NOT process these labels. Also, at most one e2e LSP is associated with one S-LSP. If a node at the head end of an S-LSP receives a Path message for an e2e LSP that identifies the S-LSP in the ERO and the S-LSP bandwidth has already been allocated to some other LSP, then regular rules of RSVP-TE pre-emption apply to resolve contention for S-LSP bandwidth. If the LSP request over the S-LSP cannot be satisfied, then the node SHOULD send back a PathErr with the error codes as described in [RFC3209].
S-LSPホップでのLSPステッチのラベル交換手順は、H-LSPホップ上のLSP階層のラベルと同様であることに注意してください。違いは、ステッチの場合のS-LSPエンドポイント間のこのラベルの重要性の欠如です。したがって、ステッチの場合、ラベル/アップストリームラベルの受信者はこれらのラベルを処理してはなりません。また、せいぜい1つのE2E LSPは1つのs-lspに関連付けられています。S-LSPのヘッドエンドのノードが、EROのS-LSPを識別するE2E LSPのパスメッセージを受信し、S-LSP帯域幅がすでに他のLSPに割り当てられている場合、RSVPの定期的なルールに割り当てられています。s-lsp帯域幅の競合を解決するために、先制が適用されます。S-LSPを介したLSP要求が満たされない場合、[RFC3209]で説明されているように、ノードはエラーコードを使用してPatherrを送信する必要があります。
RRO procedures for the S-LSP specific to LSP stitching are already described in Section 5.1.1. In this section, we will look at the RRO processing for the e2e LSP over the S-LSP hop.
LSPステッチに固有のS-LSPのRRO手順は、セクション5.1.1ですでに説明されています。このセクションでは、S-LSPホップ上のE2E LSPのRRO処理について説明します。
An e2e LSP traversing an S-LSP SHOULD record in the RRO for that hop, an identifier corresponding to the S-LSP TE link. This is applicable to both Path and Resv messages over the S-LSP hop. If the S-LSP is numbered, then the IPv4 or IPv6 address subobject ([RFC3209]) SHOULD be used to record the S-LSP TE link address. If the S-LSP is unnumbered, then the Unnumbered Interface ID subobject as described in [RFC3477] SHOULD be used to record the node's Router ID and Interface ID of the S-LSP TE link. In either case, the RRO subobject SHOULD identify the S-LSP TE link end point. Intermediate links or nodes traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for the e2e LSP over the S-LSP hop.
S-LSPを通過するE2E LSPは、S-LSP TEリンクに対応する識別子であるそのホップのRROに記録する必要があります。これは、S-LSPホップ上のパスメッセージとRESVメッセージの両方に適用されます。S-LSPに番号が付けられている場合、IPv4またはIPv6アドレスSubObject（[RFC3209]）を使用して、S-LSP TEリンクアドレスを記録する必要があります。s-lspが数になっていない場合、[RFC3477]に記載されている番号のないインターフェイスIDサブオブジェクトを使用して、S-LSP TEリンクのノードのルーターIDとインターフェイスIDを記録する必要があります。どちらの場合でも、RROサブオブジェクトはS-LSP TEリンクエンドポイントを識別する必要があります。S-LSP自体によって通過した中間リンクまたはノードは、S-LSPホップ上のE2E LSPのRROに記録しないでください。
S-LSP teardown follows the standard procedures defined in [RFC3209] and [RFC3473]. This includes procedures without and with setting the administrative status. Teardown of S-LSP may be initiated by the ingress, egress, or any other node along the S-LSP path. Deletion/teardown of the S-LSP SHOULD be treated as a failure event for the e2e LSP associated with it, and corresponding teardown or recovery procedures SHOULD be triggered for the e2e LSP. In case of S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY treat this to be equivalent to administratively shutting down a TE link along the e2e LSP path and take corresponding actions to notify the ingress of this event. The actual signaling procedures to handle this event is out of the scope of this document.
S-LSP分解は、[RFC3209]および[RFC3473]で定義されている標準手順に従います。これには、管理ステータスの設定なしでの手順が含まれます。S-LSPの分解は、s-lspパスに沿った侵入、出口、または他のノードによって開始される場合があります。S-LSPの削除/分解は、それに関連するE2E LSPの故障イベントとして扱う必要があり、E2E LSPに対して対応する分解または回復手順をトリガーする必要があります。メンテナンス目的でS-LSP分解の場合、S-LSP侵入ノードはこれをE2E LSPパスに沿ってTEリンクを管理的にシャットダウンし、対応するアクションを実行してこのイベントの侵入を通知することに相当する可能性があります。このイベントを処理するための実際のシグナル伝達手順は、このドキュメントの範囲外です。
e2e LSP teardown also follows standard procedures defined in [RFC3209] and [RFC3473] either without or with the administrative status. Note, however, that teardown procedures of e2e LSP and of S-LSP are independent of each other. So it is possible that while one LSP follows graceful teardown with administrative status, the other LSP is torn down without administrative status (using PathTear/ResvTear/PathErr with state removal).
E2E LSP分解は、[RFC3209]および[RFC3473]で定義されている標準手順に従って、管理ステータスなしでも伴います。ただし、E2E LSPおよびS-LSPの分解手順は互いに独立していることに注意してください。したがって、1つのLSPは管理ステータスで優雅な分解に従いますが、他のLSPは管理ステータスなしで取り壊される可能性があります（PathTear/Resvtear/Patherrを使用して状態除去を使用）。
When an e2e LSP teardown is initiated from the head end, and a PathTear arrives at the GMPLS stitching node, the PathTear message like the Path message MUST be IP routed to the LSP segment egress node with the destination IP address of the Path message set to the address of the S-LSP end node. Router Alert MUST be off and RSVP Time to Live (TTL) check MUST be disabled on the receiving node. PathTear will result in deletion of RSVP states corresponding to the e2e LSP and freeing of label allocations and bandwidth reservations on the S-LSP. The unreserved bandwidth on the S-LSP TE link SHOULD be readjusted.
E2E LSP分解がヘッドエンドから開始され、PATHTEARがGMPLSステッチノードに到着すると、パスメッセージのようなPATHTEARメッセージは、パスメッセージの宛先IPアドレスを使用してLSPセグメントEgressノードにルーティングされなければなりません。S-LSPエンドノードのアドレス。ルーターアラートはオフにする必要があり、RSVPのライブ時間（TTL）チェックは受信ノードで無効にする必要があります。PathTearは、E2E LSPに対応するRSVP状態の削除と、S-LSPのラベル割り当てと帯域幅の予約の解放をもたらします。S-LSP TEリンクの予約されていない帯域幅を再調整する必要があります。
Similarly, a teardown of the e2e LSP may be initiated from the tail end either using a ResvTear or a PathErr with state removal. The egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, and MUST use IP addressing to target the ingress of the LSP segment.
同様に、E2E LSPの分解は、resvtearまたは状態除去のあるpatherrを使用して、テール端から開始される場合があります。S-LSPの出力は、resvtear/patherrの上流を伝播する必要があり、IPアドレスを使用してLSPセグメントの侵入を標的とする必要があります。
Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is also applicable to stitched LSPs.
[RFC3473]に記載されているように、admin_statusを使用した優雅なLSP分解は、ステッチされたLSPにも適用できます。
If the S-LSP was statically provisioned, tearing down of an e2e LSP MAY not result in tearing down of the S-LSP. If, however, the S-LSP was dynamically set up due to the e2e LSP setup request, then, depending on local policy, the S-LSP MAY be torn down if no e2e LSP is utilizing the S-LSP. Although the S-LSP may be torn down while the e2e LSP is being torn down, it is RECOMMENDED that a delay be introduced in tearing down the S-LSP once the e2e LSP teardown is complete, in order to reduce the simultaneous generation of RSVP errors and teardown messages due to multiple events. The delay interval may be set based on local implementation. The RECOMMENDED interval is 30 seconds.
S-LSPが静的にプロビジョニングされている場合、E2E LSPの引き裂きはS-LSPの引き裂きにつながらない可能性があります。ただし、E2E LSPセットアップリクエストのためにS-LSPが動的にセットアップされた場合、ローカルポリシーに応じて、E2E LSPがS-LSPを使用していない場合、S-LSPが取り壊される場合があります。E2E LSPが取り壊されている間、S-LSPは取り壊される可能性がありますが、RSVPの同時生成を減らすために、E2E LSPの断片が完了すると、S-LSPを破壊する際に遅延を導入することをお勧めします。複数のイベントによるエラーと断downメッセージ。遅延間隔は、ローカルの実装に基づいて設定できます。推奨される間隔は30秒です。
The following topology will be used for the purpose of examples quoted in the following sections.
次のトポロジーは、次のセクションで引用されている例の目的で使用されます。
e2e LSP
+++++++++++++++++++++++++++++++++++> (LSP1-2)
LSP segment (S-LSP)
====================> (LSP-AB)
C --- E --- G
/|\ | / |\
/ | \ | / | \
R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/
D --- F --- H
PATH
====================> (LSP stitching desired)
RESV
<==================== (LSP segment stitching ready)
PATH (Upstream Label)
+++++++++++++++++++++
+++++++ ++++++>
<++++++ +++++++
+++++++++++++++++++++
RESV (Label)
Let us consider an S-LSP LSP-AB being set up between two nodes A and B that are more than one hop away. Node A sends a Path message for the LSP-AB with "LSP stitching desired" set in the Flags field of the LSP_ATTRIBUTES object. If the egress node B is ready to carry out stitching procedures, then B will respond with "LSP segment stitching ready" set in the Flags field of the RRO Attributes subobject, in the RRO sent in the Resv for the S-LSP. Once A receives the Resv for LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for stitching. Node A cannot use LSP-AB for stitching if the bit is cleared in the RRO.
2つのノードAとBの間にセットアップされているS-LSP LSP-ABを考えてみましょう。ノードAは、LSP_ATTRIBUTESオブジェクトのフラグフィールドに設定された「LSPステッチの目的」セットを使用して、LSP-ABのパスメッセージを送信します。出口ノードBがステッチ手順を実行する準備ができている場合、bはs-lspのRROで送信されたrro属性サブオブジェクトのフラグフィールドに「LSPセグメントステッチ対応」で応答します。AがLSP-ABのRESVを受信し、RROでこのビットセットを確認すると、ステッチにLSP-ABを使用できます。ノードAは、RROでビットがクリアされている場合、ステッチにLSP-ABを使用できません。
Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and ending on node R2, as shown above. If the S-LSP has been advertised as a TE link in the TE domain, and R1 and A are in the same domain, then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and identify the LSP-AB hop in the ERO. If not, R1 may compute hops between A and B and A may use these ERO hops for S-LSP selection or signaling a new S-LSP. If R1 and A are in different domains, then LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar to any other basic TE link in the domain, will not be advertised outside the domain. R1 would use either per-domain path computation ([RFC5152]) or PCE-based computation ([RFC4655]) for LSP1-2.
上記のように、R1の前に1つのホップを開始し、ノードR2で終了するE2E LSP LSP1-2を考えてみましょう。S-LSPがTEドメインのTEリンクとして宣伝されており、R1とAが同じドメインにある場合、R1はS-LSP LSP-ABを介してLSP1-2のパスを計算し、LSP-を識別することができます。ab hop in theero。そうでない場合、R1はAとBの間にホップを計算し、A-LSP選択にこれらのEROホップを使用するか、新しいS-LSPを信号することができます。R1とAが異なるドメインにある場合、LSP1-2はドメイン間LSPです。この場合、ドメイン内の他の基本的なTEリンクと同様のS-LSP LSP-ABは、ドメインの外部で宣伝されません。R1は、LSP1-2にドメインごとのパス計算（[RFC5152]）またはPCEベースの計算（[RFC4655]）を使用します。
When the Path message for the e2e LSP LSP1-2 arrives at node A, A matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the switching types are not equal, then LSP-AB cannot be used to stitch LSP1-2. Once the S-LSP LSP-AB to which LSP1-2 will be stitched has been determined, the Path message for LSP1-2 is sent (via IP routing, if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives this Path message for LSP1-2, if B is also the egress for LSP1-2, and if this is a packet LSP requiring PHP, then B will send a Resv refresh for LSP-AB with the NULL Label. In this case, since B is not the egress, the Path message for LSP1-2 is propagated to R2. The Resv for LSP1-2 from B is sent back to A with a Label value chosen by B. B also sets up its data plane to swap the Label sent to either G or H on the S-LSP with the Label received from R2. Node A ignores the Label on receipt of the Resv message and then propagates the Resv to R1. A also sets up its data plane to swap the Label sent to R1 with the Label received on the S-LSP from C or D. This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A and B. In the data plane, this yields a series of label swaps from R1 to R2 along e2e LSP LSP1-2.
E2E LSP LSP1-2のパスメッセージがノードAに到着すると、a-LSP LSP-ABとLSP1-2のスイッチングタイプと一致します。スイッチングタイプが等しくない場合、LSP-ABを使用してLSP1-2を縫うことができません。LSP1-2がステッチされるS-LSP LSP-ABが決定されると、LSP1-2のパスメッセージが（必要に応じてIPルーティングを介して）s-lsp lspを識別するif_id rsvp_hopが送信されます。-AB。BがLSP1-2のこのパスメッセージを受信すると、BがLSP1-2の出口でもあり、これがPHPを必要とするパケットLSPである場合、Bはnullラベルを使用してLSP-ABのRESVリフレッシュを送信します。この場合、Bは出口ではないため、LSP1-2のパスメッセージはR2に伝播されます。BからのLSP1-2のRESVは、Bによって選択されたラベル値でAに送り返されます。Bが選択したラベル値も設定し、R2から受信したラベルでS-LSPのGまたはHのいずれかに送信されたラベルを交換します。ノードAは、RESVメッセージの受信時にラベルを無視し、RESVをR1に伝播します。また、データプレーンをセットアップして、CまたはDからS-LSPで受信したラベルとともにR1に送信されたラベルを交換します。データプレーンでは、E2E LSP LSP1-2に沿ったR1からR2への一連のラベルスワップが得られます。
From a security point of view, the changes introduced in this document model the changes introduced by [RFC4206]. That is, the control interface over which RSVP messages are sent or received need not be the same as the data interface that the message identifies for switching traffic. But the capability for this function was introduced in [RFC3473] to support the concept of out-of-fiber control channels, so there is nothing new in this concept for signaling or security.
セキュリティの観点から、このドキュメントモデルで導入された変更[RFC4206]によって導入された変更。つまり、RSVPメッセージが送信または受信されるコントロールインターフェイスは、トラフィックの切り替えのためにメッセージが識別するデータインターフェイスと同じである必要はありません。しかし、この関数の機能は[RFC3473]で導入され、繊維外の制御チャネルの概念をサポートするため、この概念にはシグナリングやセキュリティの新しいものはありません。
The application of this facility means that the "sending interface" or "receiving interface" may change as routing changes. So these interfaces cannot be used to establish security associations between neighbors, and security associations MUST be bound to the communicating neighbors themselves.
この施設の適用は、「インターフェイスの送信」または「インターフェイスの受信」がルーティングの変更として変更される可能性があることを意味します。したがって、これらのインターフェイスを使用して隣人間のセキュリティ関連を確立することはできず、セキュリティ関連は通信隣人自身に縛られなければなりません。
[RFC2747] provides a solution to this issue: in Section 2.1, under "Key Identifier", an IP address is a valid identifier for the sending (and by analogy, receiving) interface. Since RSVP messages for a given LSP are sent to an IP address that identifies the next/previous hop for the LSP, one can replace all occurrences of 'sending [receiving] interface' with 'receiver's [sender's] IP address' (respectively). For example, in Section 4, third paragraph, instead of:
[RFC2747]は、この問題の解決策を提供します。セクション2.1では、「キー識別子」の下で、IPアドレスは送信（および類推、受信）インターフェイスの有効な識別子です。特定のLSPのRSVPメッセージは、LSPの次の/前のホップを識別するIPアドレスに送信されるため、「[受信]インターフェイスを[それぞれ受信] [送信者] IPアドレス」（それぞれ）に「[受信]インターフェイスを送信する」のすべての発生を置き換えることができます。たとえば、セクション4では、次の代わりに3番目の段落で
"Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH). ... At the sender, security association selection is based on the interface through which the message is sent."
「各送信者には、セキュリティで送信インターフェイス（またはLIH）ごとに異なるセキュリティ協会（およびキー）が必要です。
it should read:
読む必要があります：
"Each sender SHOULD have distinct security associations (and keys) per secured receiver's IP address. ... At the sender, security association selection is based on the IP address to which the message is sent."
「各送信者には、安全なレシーバーのIPアドレスごとに異なるセキュリティ協会（およびキー）が必要です。...送信者では、セキュリティ協会の選択は、メッセージが送信されるIPアドレスに基づいています。」
Thus, the mechanisms of [RFC2747] can be used unchanged to establish security associations between control plane neighbors.
したがって、[RFC2747]のメカニズムを変更して使用して、コントロールプレーンの隣接体間のセキュリティ関連を確立することができます。
This document allows the IP destination address of Path and PathTear messages to be the IP address of a next hop node (receiver's address) instead of the RSVP session destination address. This means that the use of the IPsec Authentication Header (AH) (ruled out in [RFC2747] because RSVP messages were encapsulated in IP packets addressed to the ultimate destination of the Path or PathTear messages) is now perfectly applicable, and standard IPsec procedures can be used to secure the message exchanges.
このドキュメントにより、PATHおよびPATHTEARメッセージのIP宛先アドレスは、RSVPセッションの宛先アドレスではなく、次のホップノード（受信者のアドレス）のIPアドレスになることができます。これは、RSVPメッセージがパスまたはPATHTEARメッセージの究極の目的地にアドレス指定されたIPパケットにカプセル化されているため、IPSEC認証ヘッダー（AH）（[RFC2747]で除外された）の使用が完全に適用されることを意味し、標準のIPSEC手順は完全に適用可能であり、メッセージ交換を確保するために使用されます。
An analysis of GMPLS security issues can be found in [MPLS-SEC].
GMPLSセキュリティの問題の分析は、[MPLS-SEC]に記載されています。
IANA has made the following codepoint allocations for this document.
IANAは、このドキュメントに次のCodePoint割り当てを行いました。
The "RSVP TE Parameters" registry includes the "Attributes Flags" sub-registry.
「RSVP TEパラメーター」レジストリには、「属性フラグ」サブレジストリが含まれます。
IANA has allocated the following new bit (5) defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object.
IANAは、lsp_attributesオブジェクトの属性フラグTLVに対して定義された次の新しいビット（5）を割り当てました。
LSP stitching bit - Bit Number 5
LSPステッチビット - ビット番号5
This bit is only to be used in the Attributes Flags TLV on a Path message.
このビットは、パスメッセージの属性フラグTLVでのみ使用されます。
The 'LSP stitching desired' bit has a corresponding 'LSP segment stitching ready' bit (Bit Number 5) to be used in the RRO Attributes subobject.
「LSPステッチが望ましい」ビットには、RRO属性SubObjectで使用される対応する「LSPセグメントステッチレディング」ビット（ビット番号5）があります。
The following text has been includuded in the registry:
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
5 LSP stitching desired Yes No Yes [RFC5150]
The "Resource ReSerVation Protocol (RSVP) Parameters" registry includes the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry.
「リソース予約プロトコル（RSVP）パラメーター」レジストリには、「エラーコードとグローバルに定義されたエラー値サブコード」サブレジストリが含まれます。
IANA has assigned a new error sub-code (30) under the RSVP error-code "Routing Problem" (24).
This error code (30) is to be used only in an RSVP PathErr.
このエラーコード（30）は、RSVP Patherrでのみ使用されます。
The following text has been included in the registry:
次のテキストがレジストリに含まれています。
24 Routing Problem [RFC3209]
24ルーティングの問題[RFC3209]
30 = Stitching unsupported [RFC5150]
30 =サポートされていないステッチ[RFC5150]
The authors would like to thank Dimitri Papadimitriou and Igor Bryskin for their thorough review of the document and discussions regarding the same.
著者は、Dimitri PapadimitriouとIgor Bryskinに感謝し、それに関する文書と議論を徹底的にレビューしてくれた。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420] Farrel、A.、ed。、Papadimitriou、D.、Vasseur、J.-P。、およびA. Ayyangar、「リソース予約を使用したマルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）確立の属性のエンコーディングプロトコルトラフィックエンジニアリング（RSVP-TE） "、RFC 4420、2006年2月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[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, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、JP。、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、RFC 5152、2008年2月。
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J. L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R. Graveman., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2007.
[MPLS-SEC] Fang、L.、Ed。、Behringer、M.、Callon、R.、Le Roux、J。L.、Zhang、R.、Knight、P.、Stein、Y.、Bitar、N。、およびRGraveman。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2007年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: arthi@juniper.net
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089メール：arthi@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089メール：kireeti@juniper.net
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 EMail: jpv@cisco.com
JP Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719メール：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。