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）ラベルは、単一のエンド・ツー・エンド（E2E）LSPが実現され、1つの構成LSPからのすべてのトラフィックを上に切り替えられるように（のLSP）パスのスイッチ次のLSP。私たちは、重要な要件は、構成LSPが複数のE2EのLSPに割り当てられないということで、「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.
この文書は、（リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE））はS-のLSPから作成されたE2EのLSPを確立するためのシグナリングプロトコル既存のGMPLSへの拡張機能について説明し、LSPのは、GMPLSシグナリングおよびルーティングプロトコルを使用して管理する方法について説明します。
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.
操作がに完全に透明であることいかなるシグナリングまたはルーティング拡張を必要とせず、そのような、入力された別のLSPに、それが出力されたLSPのトラフィックを切り替えるGMPLSノードを構成することも可能です他のノード。これはまた、データプレーンにおける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セグメント」（S-のLSP）のセットから構築され単一のエンドツーエンドの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.
操作がに完全に透明であることいかなるシグナリングまたはルーティング拡張を必要とせず、そのような、入力された別のLSPに、それが出力されたLSPのトラフィックを切り替えるGMPLSノードを構成することも可能です他のノード。これは、データプレーン内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）を作成することができます。一つの層で作成されたそのような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）リンクとして（これは必要条件ではないが）管理およびアドバタイズされてもよいです。 TEリンクは、それがアドバタイズされたTEドメイン内の他のノードは、経路計算において、このH-LSPを使用することを可能にするように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。 RSVPシグナリング（[RFC3473]、[RFC3209]）LSPセットアップのためのルーティング隣接関係を持たないノード間で発生する可能性があります。
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.
代わりにH-LSPからLSPステッチの場合、LSPセグメント（S-LSP）は、2つのGMPLSノードとの間に作成されます。ステッチングのためのS-LSPは、ネスティングのためのH-LSPの道徳的等価であると考えられます。 S-LSPは、H-LSPとは異なり、同じ層内の他のLSPへのデータリンクを提供し、一つの層で作成されました。それはどちらか、それがプロビジョニングされたのと同じTEドメインまたは異なるもので、TEリンクとして、必須ではないH-LSPと同様に、S-LSPは、管理およびアドバタイズすることができました。そうアドバタイズされた場合、他の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が多くても1つのLSPに、LSPステッチの場合には、H-LSPにマッピングすることを可能にしながら、S-LSPに関連付けられてもよいです。 LSP-ABは、ノードAとBの間のH-LSPである場合したがって、その後、複数のLSPは、LSP1、LSP2、LSP3とは、潜在的にLSP-AB '内にネストされた' ことができると言います。これによりH-LSP LSP-ABを横断しながらLSP1..3のそれぞれに対応するデータを分離し、LSP-ABホップ上LSP1..3のそれぞれに一意のラベルを交換することによって達成されます。 LSP1..3のそれぞれは、LSP-AB上のいくつかの帯域幅を予約することができます。 LSP-ABは、S-LSPである一方、は、多くても1つのLSPに、LSP1を言い、S-LSP LSP-ABに縫合されてもよいです。 LSP-ABは、その後、LSP1に専用であり、他のLSPは、LSP-ABに関連付けすることができません。 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にステッチされたLSPの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シグナリングは、S-LSPへE2E LSPのLSPステッチのために必要とされます。 LSPステッチのための特定の拡張機能は、セクション5.1で説明されています。したがって、制御プレーンで、E2E LSPならびに各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],
S-LSPは、管理制御（設定トリガー）によって、または動的に起因する受信LSP要求のいずれかを作成することができます。 LSP階層は（[RFC4206]）インタフェーススイッチング機能に基づいて、LSP領域の概念を導入することにより、FA-LSPを動的に作成するための一つの可能なトリガを定義します。 [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.
動的FA-LSPの作成は、着信LSP要求が領域境界を横切るノードにトリガされてもよいです。この文書で説明したようにしかし、このトリガーは、LSPステッチのためのS-LSPの作成に使用してはいけません。 LSPステッチの場合には、前のホップのスイッチング機能とネクストホップTEリンクは同じでなければなりません。したがって、ノードに設定されたローカルポリシーは、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の動的生成のための他の可能なトリガーはE2E LSPはドメイン境界を横切るか、[RFC5151]に記載されているように、ノードにローカルに設定されたポリシーを満たすことができる場合が挙げられます。
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ステッチ手順は同じスイッチングタイプの別のS-LSPを有するLSPとLSP階層の手順が適用されないE2Eを関連付ける必要GMPLSノードに適用可能です。 E2EラムダLSPもラムダスイッチ可能な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 S-LSP（[RFC4726]及び[RFC5151]）にドメイン間E2EのLSPをステッチするシグナリングドメイン間TE LSPのために使用することができます。
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ステッチは、制御プレーン及び/又はデータプレーン内の特定の新機能を持っていない可能性がレガシーノードをバイパスするネットワークにおいて有用であり得ます。例えば、一つのLSR（ポイントツーマルチポイント（P2MP）のRSVPのLSP（[RFC4875]）の場合には使用がスイッチングルータP2MP可能なラベルとの間のLSPセグメントにP2MP RSVP LSPをステッチするLSPステッチの使用で示唆しました）ネットワークインチLSPセグメントは、それにより、P2MP分岐点として作用するP2MP制御およびデータパスからそれらを遮蔽することができないかもしれレガシーのLSRを横切ることになります。このような構成は、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は、二つの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.
S-LSPのヘッドエンドに到達するトラフィックは、ラベル交換で連続S-LSPに切り替えられ、そしていかなるラベルがS-LSP自体のエンドノードの間に直接関連付けられていません。
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リンクとして扱われ、管理されていてもよいです。このTEリンクは、番号または番号なしかもしれません。無数S-LSP TEリンクのために、[RFC3477]で指定されるように、ローカルおよびリモートのリンク識別子の割り当ておよび取り扱いのためのスキームを使用すべきです。適切な場合、S-LSP TEリンクに関連付けられTE情報は、ISIS-TE [RFC4205]またはOSPF-TE [RFC4203]を介してフラッディングされるかもしれません。通常の（基本）TEリンクと同様のメカニズムは、S-LSP TEリンクをあふれさせるために使用されるべきです。広告またはS-LSP TEリンクをフラッディングは、LSPステッチの要件ではありません。アドバタイズ場合、このTE情報は、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ドメインの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.
[RFC4206]でのFAに対して定義されたTEパラメータも同様にS-LSP TEリンクのために使用されるべきです。 S-LSP TEリンクのスイッチング能力は、基礎となるS-LSPの切替型に等しくなければなりません。すなわち、S-LSP TEリンクは、同じ層内の他のLSPへのデータリンクを提供するので、何階層は不可能です。
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に割り当てられている場合、予約されていない帯域幅は、S-LSPに導入されることから、さらにE2Eの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は、単一のTEリンクにリンクバンドル（[RFC4201]）の概念を使用してバンドルされるかもしれません。この場合、各成分S-LSPは、最大1つのE2EのLSPに割り当てられてもよいです。任意成分S-LSPがE2E LSPに割り当てられている場合、コンポーネントの予約されていない帯域幅がゼロに設定されるべきであり、TEリンクの最小値と最大LSP帯域幅が再計算されるべきです。これは、計算され、S-LSP上に入院されることから、複数の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 helloを交換することが望ましい場合があります。
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.
[RFC4206]のセクション8.1.1に記載した手順をシグナリング、LSPセグメント上E2EのLSPをシグナリングするために使用されなければなりません。ステッチのための追加のシグナリング拡張は、次のセクションで説明されています。
The signaling extensions described here MUST be used for stitching an e2e packet or non-packet GMPLS LSP ([RFC3473]) to an S-LSP.
ここで説明するシグナリング拡張は、S-LSPにE2Eパケットまたは非パケットGMPLS LSP（[RFC3473]）を縫合するために使用されなければなりません。
Stitching an e2e LSP to an LSP segment involves the following two-step process:
LSPセグメントにE2EのLSPをステッチすると、以下の二段階プロセスを含みます。
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を調製します。そして
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の上にステッチを行うことを計画しているS-LSPの出口ノードを通知します。 S-LSPは、明示的に「所望のLSPステッチ」をシグナリング、他のLSPから概念的に異ならないためS-LSPが他のE2EのLSPによって使用されるときに実行されるデータプレーン動作を明確に役立ちます。また、パケットLSPの場合、これは以下に説明するようにS-LSPの出口がラベル割り当てを行うことを可能にするものです。ヘッドエンドノードが正しいスティッチングアクションが出口ノードで行われることを保証することができるように、以下に説明するように、また、出口ノードは、バックの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の出口ノードはまた、ステッチに参加する準備ができている場合にのみ、縫合のために使用することができます。 「LSPセグメントステッチREADY」：S-LSPのヘッドエンドノードにこのことを示すために、次の新しいビットは、レコードルートオブジェクト（RRO）のFlagsフィールドで定義されるサブオブジェクト属性。このフラグのビット数は、セクション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.
Pathメッセージを受信した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オブジェクトのFlagsフィールドに設定されたビットがPathメッセージを受信した出口ノードが、オブジェクト、TLV TLV、及びビットを認識し、また、所望のステッチの動作をサポートしている場合、それは非を割り当てる必要がありますそれのヌルラベルは、対応するResvメッセージに-LSP S。また、ヘッドエンドノードが正しいラベル（転送）ことを保証することができるように、アクションは、出口ノードによって実施されると、S-LSPをステッチするために使用することができることは、出口ノードは準備完了ステッチ」LSPセグメントを設定しなければなりません「RROのFlagsフィールドで定義されたビットは、サブオブジェクトの属性。
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ステッチは、RROがステッチアクションが出口ノードで行われていることを確認するために、S-LSPのための出口ノードに対応するサブオブジェクトフラグ属性調べる必要があります。ビット「準備をステッチ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.
このセクションでは、出口ノードのResvラベルで暗黙NULLラベル（[RFC3032]）配信最終ホップ、で最後から二番目のホップポッピング（PHP）を使用するパケットのLSPにのみ適用可能であることに留意されたいです。これらの手順は、非パケット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のためのPathメッセージを受信すると、S-LSPの出口は、最初にもE2E LSPの出口であるかどうかを確認すべきです。出口ノードが、S-LSPおよびE2E TE LSPの両方のための出口であり、これはPHPを必要とするパケットLSPである場合、ノードは、新しいラベルに対応するS-LSPのためのResvトリガメッセージを返送しなければなりません暗黙的または明示的なNULLのラベル。 S-LSPは、LSPがまだ確立されていないE2Eいるので、この時点ですべてのトラフィックを搬送されていないため、この操作は、すべてのトラフィックの中断が発生しないことに注意してください。
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の入口であるかどうかを確認する必要があります。もしそうなら、それは暗黙的または明示的なNULL上流のラベルとS-LSPのためのPathメッセージを再発行し、その後にのみ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を作成するか、既存のS-LSPへE2EのLSPをマッピングすることができます。 E2EのLSPの一般ラベル要求のスイッチングタイプがS-LSPの切替型に等しくなければなりません。明示的経路オブジェクト（ERO）、帯域幅、及びローカルTEポリシーで符号化された明示的なパスのような他の制約は、S-LSP選択またはシグナリングのためにも使用されなければなりません。 S-LSPがE2E LSPのために選択された後、いずれの場合においても、次の手順では、S-LSPにE2Eの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セットアップPathメッセージを受信したGMPLSノードは、S-LSPの終点までPathメッセージを送信するために、[RFC4206]に記載のシグナリング手順を使用しなければなりません。このPathメッセージにおいて、ノードはRSVP_HOPにS-LSPを識別しなければなりません。このRSVP_HOPを受信出口ノードもRSVP_HOPでシグナリング情報に基づいて、S-LSP TEリンクを識別することができなければなりません。 S-LSP TEリンクが番号付けされている場合は、[RFC4206]で提案されているようにアドレス指定方式は、S-LSP TEリンクに番号を付けるために使用されるべきです。 S-LSP TEリンクが無数である場合には、[RFC3477]で提案されたスキームのいずれかがS-LSPの端点間S-LSP TEリンク識別子を交換するために使用されるべきです。 TEリンクがバンドルされている場合は[RFC4201]で定義されるように、RSVP_HOPコンポーネントリンクを識別すべきです。
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のPATHメッセージでシグナリングされなければなりません。 S-LSPエンドポイントの間には、転送隣接関係がありませんので、任意のラベルには意味がありませんそれらの間で交換しました。だから、ノードMAYは、上流のラベルのための任意のラベル値を選択しました。上流のラベル内のノードによって選択されたと合図ラベル値は、この文書の範囲外であると、そのノード上の実装に固有です。このPathメッセージを受信した出口ノードは、S-LSPのホップ上Pathメッセージで上流のラベルを無視しなければなりません。
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.
このPathメッセージを受信した出口ノードは、S-LSPのホップ上E2E TE LSPのためのResvメッセージにラベルをシグナリングしなければなりません。再び、出入りS-LSPのノード間の転送隣接関係がないので、任意のラベルは、それらの間で交換無意味です。だから、出口ノードは、ラベルのための任意のラベル値を選択することができます。出口ノードによって選択されたと合図ラベル値は、この文書の範囲外であり、出口ノード上の実装に固有です。トラフィックがE2E LSPの出口が下流いくつかの他のノードである場合、下流E2EのLSPに切り替えるS-LSP上に来るように、出口S-LSPのノードは、データプレーン動作を実行すべきです。 E2E LSPが双方向である場合、これは両方向にラベルスイッチングを設定することを意味します。出口S-LSPノードからResvメッセージは、IPは、前のホップ（S-LSPの入口）に戻されます。 S-LSPにE2E TE LSPをステッチ入口ノードは、S-LSPのホップ上E2E TE LSPのためのResvで受信したラベルオブジェクトを無視しなければなりません。トラフィックがE2E LSPに着信がS-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のヘッドエンドにおけるノードが、すでにいくつかの他のLSPに割り当てられたEROおよびS-LSPの帯域幅でS-LSPを特定するE2EのLSPのためのパスメッセージを受信した場合、RSVP-の次に、正規ルールTEプリエンプションは、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
S-LSPを通過E2E LSPは、そのホップのためのRROにS-LSP TEリンクに対応する識別子を記録する必要があります。これは、パスとS-LSPのホップを超えるRESVメッセージの両方に適用可能です。 S-LSPを番号付けされている場合は、IPv4またはIPv6アドレスのサブオブジェクト（[RFC3209]）はS-LSP TEリンクアドレスを記録するために使用されるべきです。 S-LSPに番号が付いていない場合、[RFC3477]に記載されているようにアンナンバードインターフェイスIDサブオブジェクトは、S-LSP TEリンクのノードのルータID及びインタフェースIDを記録するために使用されるべきです。いずれの場合も、RROのサブオブジェクト
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 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のティアダウン手順は、互いに独立しています。一つの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ステッチノードに到着、PathメッセージのようなPathTearメッセージは、IPはに設定Pathメッセージの宛先IPアドレスを持つLSPセグメントの出口ノードにルーティングする必要がある場合S-LSPエンドノードのアドレス。ルータアラートがオフでなければならないとRSVP時間ライブする（TTL）のチェックが受信ノード上で無効にする必要があります。 PathTearはS-LSPのラベルの割り当てと帯域幅の予約のE2EのLSPと解放に対応するRSVP状態の削除になります。 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を伝搬しなければならない、およびLSPセグメントの侵入を標的とするIPアドレス指定を使用しなければなりません。
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の解体につながるないかもしれません。しかし、S-LSPを動的に起因するE2E LSP設定要求に設定された場合は何もE2E LSPは、S-LSPを利用されていない場合、その後、ローカルポリシーに応じて、S-LSPは取り壊されるかもしれません。 E2E LSPが切断されている間S-LSPをティアダウンすることができるが、E2EのLSPティアダウンが完了すると、RSVPの同時発生を低減するために、S-LSPを切断に遅延が導入されることが推奨されますエラーや複数のイベントのためにティアダウンメッセージ。遅延間隔は、ローカル実装に基づいて設定されてもよいです。推奨間隔は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)
PATH（上流ラベル）+++++++++++++++++++++ +++++++ ++++++> <++++++ +++ ++++ +++++++++++++++++++++ RESV（ラベル）
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
私たちは、S-LSP LSP-ABが複数ホップ離れている2つのノードAとBの間に設定されて考えてみましょう。ノードAは、フラグフィールドに設定された「所望のLSPステッチ」とLSP-ABのためのPathメッセージを送信します
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.
LSP_ATTRIBUTESオブジェクト。出口ノードBは、縫合処置を行う準備ができている場合には、Bは、RROのFlagsフィールドに設定されている「準備ステッチLSPセグメント」で応答するS-LSPのためのResvで送信RROに、サブオブジェクト属性。 Aは、LSP-ABのためのResvを受け取り、RROに設定され、このビットを見ていると、それはその後、ステッチのためのLSP-ABを使用することができます。ビットがRROにクリアされている場合、ノードAは、ステッチのための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.
上記のように、私たちは、E2E LSP LSP1-2はR1にAの前に1つのホップを開始し、ノードR2に終了を考えてみましょう。 S-LSPがTEドメインのTEリンクとして宣伝されており、R1およびAは同じドメイン内にある場合、R1は、S-LSP LSP-AB上LSP1-2のパスを計算し、LSP-を識別することができますEROにおけるABホップ。そうでない場合、R1は、AとBとAとの間のホップを計算することができるこれらのEROがS-LSP選択のために、または新しい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ためのPathメッセージがノードAに到達したとき、Aは、S-LSP LSP-ABでLSP1-2のスイッチングタイプと一致します。スイッチングタイプが等しくない場合、LSP-ABはLSP1-2ステッチするために使用することができません。 LSP1-2が決定された縫合するためのS-LSP LSP-ABと、LSP1-2ためのPathメッセージは、（必要に応じて、IPルーティングを介して、）IF_ID RSVP_HOPはS-LSP LSPを識別してノードBに送られます。 -AB。 BはまたLSP1-2ための出口であり、これはPHPを必要とするパケットLSPである場合、Bは、のResvがNULLラベルとLSP-ABのリフレッシュ送信する場合はBは、LSP1-2このPathメッセージを受信した場合。 Bが出口ではないので、この場合には、LSP1-2ためのPathメッセージは、R2に伝播されます。 BからLSP1-2ためのResvはB. Bによって選択されたラベル値もラベルR2から受信したS-LSP上にGまたはHのいずれかに送信されたラベルを交換するために、そのデータ・プレーンを設定してバックに送られます。ノードAは、Resvメッセージの受信時にラベルを無視して、R1へのResvを伝播します。また、これはノードAとBとの間S-LSP LSP-ABへE2E LSP LSP1-2をステッチラベルが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章、第三段落で、代わりに：
"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アドレスごとに個別のセキュリティアソシエーション（およびキー）を持つべきである（SHOULD）。...送信者では、セキュリティアソシエーションの選択は、メッセージが送信される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]
この文書では、パスとPathTearメッセージのIP宛先アドレスは、次ホップノード（受信者のアドレス）の代わりに、RSVPセッションの宛先アドレスのIPアドレスにすることができます。これは、IPsec認証ヘッダ（AH）（の使用は、[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.
RSVPメッセージは、IPパケットにカプセル化されたため）パスまたはPathTearメッセージの最終的な宛先に宛て今や完全に適用可能であり、標準の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はこのドキュメントのために、以下のコードポイントの割り当てを行っています。
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は、（5）属性フラグLSP_ATTRIBUTESオブジェクト内のTLVのために定義され、次の新しいビットを割り当てました。
LSP stitching bit - Bit Number 5
LSPステッチビット - ビット番号5
This bit is only to be used in the Attributes Flags TLV on a Path message.
このビットは、Pathメッセージに属性フラグ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に使用される対応する「LSPセグメントステッチレディ」ビット（ビット番号5）は、サブオブジェクト属性有します。
The following text has been includuded in the registry:
次のテキストは、レジストリにinclududedされています。
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).
IANAは、RSVPエラーコード「ルーティング問題」（24）の下に新しいエラーサブコード（30）を割り当てました。
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.
作者はドキュメントと同じに関する議論の彼らの徹底的な見直しのためのディミトリPapadimitriouとイゴールBryskinに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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]ファレル、A.編、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[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.、エド。、およびY. Rekhter、エド。、 "中間システム（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ファレル、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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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]ファレル、A.編、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。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（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]牙、L.、エド。、ベーリンガー、M.、Callon、R.、ルルー、JL、張、R.、ナイト、P.、スタイン、Y.、ビタール、N.、およびR 。Graveman。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2007年7月の作業。
Authors' Addresses
著者のアドレス
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: arthi@juniper.net
Arthi Ayyangarジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：arthi@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：kireeti@juniper.net
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 EMail: jpv@cisco.com
JP Vasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 Eメール：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。