Network Working Group                                   JP. Vasseur, Ed.
Request for Comments: 5330                            Cisco Systems, Inc
Category: Standards Track                                      M.  Meyer
                                                                      BT
                                                               K. Kumaki
                                                           KDDI R&D Labs
                                                                A. Bonda
                                                          Telecom Italia
                                                            October 2008
        
              A Link-Type sub-TLV to Convey the Number of
        Traffic Engineering Label Switched Paths Signalled with
                 Zero Reserved Bandwidth across a Link
        

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

抽象

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link.

いくつかのリンク型のサブタイプの長さ値(サブのTLV)はマルチプロトコルラベルのコンテキスト・スイッチング(MPLS)交通工学の中間システム(IS-IS)へのOSPF(Open Shortest Path First)のと中間システムのために定義されています(TE)は、そのようなように利用可能な帯域幅、トラフィックエンジニアリングメトリック、管理グループ、およびなど、いくつかのリンク特性を宣伝するためです。集約されたトラフィックに関する統計的な仮定を行うことで、TEラベルのセット上に搬入パス(LSPを)交換ゼロ帯域幅(本書では「非拘束TE LSP」と呼ぶ)とシグナリング、アルゴリズムは、(既存のまたは新たに構成されたバランスをロードするように設計することができます)等コスト・パスのセットにわたって非拘束TE LSP。これは、リンクを介して合図制約のないTEのLSPの数の知識が必要です。この文書では、トラフィックエンジニアリングサブTLVは、制約のないTE LSPの数は、リンクを介して合図宣伝するために使用される新しいリンクタイプを指定します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................3
      2.1. Requirements Language ......................................4
   3. Protocol Extensions .............................................4
      3.1. IS-IS ......................................................4
      3.2. OSPF .......................................................4
   4. Elements of Procedure ...........................................5
   5. IANA Considerations .............................................5
   6. Security Considerations .........................................5
   7. Acknowledgements ................................................6
   8. References ......................................................6
      8.1. Normative References .......................................6
      8.2. Informative References .....................................6
        
1. Introduction
1. はじめに

It is not uncommon to deploy MPLS Traffic Engineering for the sake of fast recovery, relying on a local protection recovery mechanism such as MPLS TE Fast Reroute (see [RFC4090]). In this case, a deployment model consists of deploying a full mesh of TE LSPs signalled with zero bandwidth (also referred to as unconstrained TE LSP in this document) between a set of LSRs (Label Switching Routers) and protecting these TE LSPs against link, SRLG (Shared Risk Link Group), and/or node failures with pre-established backup tunnels. The traffic routed onto such unconstrained TE LSPs simply follows the IGP shortest path, but is protected with MPLS TE Fast Reroute. This is because the TE LSP computed by the path computation algorithm (e.g., CSPF) will be no different than the IGP (Interior Gateway Protocol) shortest path should the TE metric be equal to the IGP metric.

このようなMPLS TE高速リルート([RFC4090]を参照)のようなローカルの保護・リカバリ・メカニズムに頼って、高速リカバリのためにMPLSトラフィックエンジニアリングを展開することは珍しいことではありません。この場合には、展開モデルは、TE LSPのフルメッシュを展開から構成は、のLSRのセットとの間のゼロ帯域幅(この文書に記載されているような制約のないTE LSPと呼ぶ)(ラベルスイッチングルータ)とのシグナリングとリンクに対してこれらのTE LSPを保護しますSRLG(共有リスクリンクグループ)、および/または事前に確立されたバックアップトンネルを持つノード障害。そのような制約のないTE LSPの上にルーティングされたトラフィックは、単にIGPの最短経路に従うが、MPLS TE高速リルートで保護されています。 TE LSPは、経路計算アルゴリズムによって計算からである(例えば、CSPF)はTEメトリックはIGPメトリックに等しくなければならないIGP(インテリアゲートウェイプロトコル)最短パスよりも異なることはありません。

When a reoptimization process is triggered for an existing TE LSP, the decision on whether to reroute that TE LSP onto a different path is governed by the discovery of a lower cost path satisfying the constraints (other metrics, such as the percentage of reserved bandwidth or the number of hops, can also be used). Unfortunately, metrics such as the path cost or the number of hops may be ineffective in various circumstances. For example, in the case of a symmetrical network with ECMPs (Equal Cost Multi-Paths), if the network operator uses unconstrained TE LSP, this may lead to a poorly load balanced traffic; indeed, several paths between a source and a destination of a TE LSP may exist that have the same cost, and the reservable amount of bandwidth along each path cannot be used as a tie-breaker.

再最適化プロセスは、既存のTE LSPのためにトリガされたときに、異なるパスにTE LSPこと再ルーティングするかどうかの決定は、予約帯域幅またはパーセンテージとして制約(他のメトリックを満たす低コストのパスの発見によって支配されますホップの数、使用することもできます)。残念ながら、そのような経路のコストまたはホップの数などのメトリックは、様々な状況で無効であってもよいです。ネットワークオペレータは、制約のないTE LSPを使用する場合、例えば、ECMPs対称ネットワーク(等価コストマルチパス)の場合には、これは不十分負荷分散トラフィックをもたらし得ます。確かに、ソース及びTE LSPの宛先との間の複数のパスは、各パスに沿って同じコスト、帯域幅の予約可能量は、タイブレーカとして使用することができない持っている存在してもよいです。

By making statistical assumptions about the aggregated traffic carried by a set of unconstrained TE LSPs, algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSPs across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across each link.

非拘束TE LSPのセットによって運ば集約トラフィックに関する統計的な仮定を行うことによって、アルゴリズムは、等コスト・パスのセットにわたってバランス(既存または新たに構成された)非拘束のTE LSPをロードするように設計することができます。これは、各リンクを介して合図を拘束されていないのTE LSPの数の知識が必要です。

Note that the specification of load balancing algorithms is outside the scope of this document and is referred to for the sake of illustration of the motivation for gathering such information.

ロード・バランシング・アルゴリズムの仕様はこの文書の範囲外であり、そのような情報を収集するための動機の説明のために参照されることに留意されたいです。

Furthermore, the knowledge of the number of unconstrained TE LSPs signalled across each link can be used for other purposes -- for example, to evaluate the number of affected unconstrained TE LSPs in case of a link failure.

また、非拘束TE LSPの数の知識が各リンクを介してシグナリングを他の目的に使用することができる - 例えば、リンクに障害が発生した場合に影響を受けた非拘束のTE LSPの数を評価します。

A set of Link-type sub-TLVs have been defined for OSPF and IS-IS (see [RFC3630] and [RFC5305]) in the context of MPLS Traffic Engineering in order to advertise various link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. As currently defined in [RFC3630] and [RFC5305], the information related to the number of unconstrained TE LSPs is not available. This document specifies a new Link-type Traffic Engineering sub-TLV used to indicate the number of unconstrained TE LSPs signalled across a link.

リンク型サブのTLVのセットは、OSPFのために定義されていると、IS-IS、利用可能な帯域幅、トラフィックエンジニアリングなどの様々なリンク特性を宣伝するために、MPLSトラフィックエンジニアリングの文脈で([RFC3630]と[RFC5305]を参照してください)その上メトリック、管理グループ、および。現在[RFC3630]及び[RFC5305]で定義されるように、非拘束TE LSPの数に関する情報は入手できません。この文書では、トラフィックエンジニアリングサブTLVは、制約のないTE LSPの数は、リンクを介してシグナルを示すのに使用される新しいリンクタイプを指定します。

Unconstrained TE LSPs that are configured and provisioned through a management system MAY be omitted from the count that is reported.

管理システムを介して設定およびプロビジョニングされている制約のないTEのLSPが報告されているカウントから省略されるかもしれません。

2. Terminology
2.用語

Terminology used in this document:

このドキュメントで使用される用語:

CSPF: Constrained Shortest Path First

CSPF:制約最短パスファースト

IGP : Interior Gateway Protocol

IGP:インテリアゲートウェイプロトコル

LSA: Link State Advertisement

LSA:リンク状態アドバタイズメント

LSP: Link State Packet

LSP:リンクステートパケット

MPLS: Multiprotocol Label Switching

MPLS:マルチプロトコルラベルスイッチング

LSR: Label Switching Router

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

SRLG: Shared Risk Link Group

SRLG:共有リスクリンクグループ

TE LSP: Traffic Engineering Label Switched Path

TE LSP:トラフィックエンジニアリングラベルスイッチパス

Unconstrained TE LSP: A TE LSP signalled with a bandwidth equal to 0

非拘束TE LSP:TE LSPは、0に等しい帯域幅を持つシグナリング

2.1. Requirements Language
2.1. 要件言語

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

3. Protocol Extensions
3.プロトコル拡張

Two Unconstrained TE LSP Count sub-TLVs are defined that specify the number of TE LSPs signalled with zero bandwidth across a link.

二つの制約なしTE LSPすなわちTE LSPの数を指定する定義されたサブTLVをカウントリンクを横切るゼロ帯域幅で合図をしました。

3.1. IS-IS
3.1. IS-IS

The IS-IS Unconstrained TE LSP Count sub-TLV is OPTIONAL and MUST NOT appear more than once within the extended IS reachability TLV (type 22) specified in [RFC5305] or the Multi-Topology (MT) Intermediate Systems TLV (type 222) specified in [RFC5120]. If a second instance of the Unconstrained TE LSP Count sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV.

IS-IS制約なしTE LSPは、サブTLVはオプションであり、一度拡張内に[RFC5305]またはマルチトポロジー(MT)中間システムTLV(タイプ222)で指定された到達可能性TLV(タイプ22)よりも多く現れてはいけませんカウント[RFC5120]で指定されました。制約なしTE LSPの第二のインスタンスはサブTLVが存在してカウントした場合、受信システムは、サブTLVの最初のインスタンスを処理しなければなりません。

The IS-IS Unconstrained TE LSP Count sub-TLV format is defined below:

IS-IS制約なしTE LSPサブTLVのフォーマットは以下に定義されている数:

Type (1 octet): 23

タイプ(1つのオクテット):23

Length (1 octet): 2

長さ(1つのオクテット):2

Value (2 octets): number of unconstrained TE LSPs signalled across the link.

値(2つのオクテット):制約のないTEのLSPの数は、リンクを介して合図をしました。

3.2. OSPF
3.2. OSPF

The OSPF Unconstrained TE LSP Count sub-TLV is OPTIONAL and MUST NOT appear more than once within the Link TLV (Type 2) that is itself carried within either the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in [RFC5329]. If a second instance of the Unconstrained TE LSP Count sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV.

OSPF制約のないTE LSPサブTLVはオプションであり、それ自体が[RFC3630]やOSPFv3のエリア内-TE LSAで指定されたトラフィックエンジニアリングLSAのいずれかの中に運ばれるリンクTLV(タイプ2)内に複数回現れてはならないカウント[RFC5329]で定義された(機能コード10)。制約なしTE LSPの第二のインスタンスはサブTLVが存在してカウントした場合、受信システムは、サブTLVの最初のインスタンスを処理しなければなりません。

The OSPF Unconstrained TE LSP Count sub-TLV format is defined below:

OSPF制約なしTE LSPは、サブTLVのフォーマットは以下に定義されている数:

Type (2 octets): 23

タイプ(2つのオクテット):23

Length (2 octets): 4

長さ(2つのオクテット):4

Value (4 octets): number of unconstrained TE LSPs signalled across the link.

値(4つのオクテット):非拘束のTE LSPの数は、リンクを介して合図しました。

4. Elements of Procedure
手順の4要素

The absence of the Unconstrained TE LSP Count sub-TLV SHOULD be interpreted as an absence of information about the link.

制約なしTE LSPが存在しない場合は、サブTLVはリンクに関する情報がないとして解釈されるべきでカウント。

Similar to other MPLS Traffic Engineering link characteristics, LSA/LSP origination trigger mechanisms are outside the scope of this document. Care must be given to not trigger the systematic flooding of a new IS-IS LSP or OSPF LSA with a too high granularity in case of change in the number of unconstrained TE LSPs.

他のMPLSトラフィックエンジニアリングのリンク特性と同様に、LSA / LSP発信トリガ機構は、この文書の範囲外です。ケアは、新しいの体系的なフラッディングをトリガしないように与えられなければならない制約のないTE LSPの数の変化の場合は高すぎる粒度でLSPまたはOSPF LSAは、IS-IS。

5. IANA Considerations
5. IANAの考慮事項

IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS TLV 22 and has assigned a new TLV codepoint for the Unconstrained TE LSP Count sub-TLV carried within the TLV 22.

IANAはで運ばサブTLVのためのサブレジストリを定義しているIS-IS TLV 22とサブTLVは、TLV 22内に運ばカウント制約なしTE LSPのための新しいTLVコードポイントを割り当てました。

Value TLV Name Reference

値TLV名前リファレンス

23 Unconstrained TE LSP Count (sub-)TLV RFC 5330

23制約のないTE LSPカウント(サブ)TLVのRFC 5330

IANA has defined a sub-registry for the sub-TLVs carried in an OSPF TE Link TLV (type 2) and has assigned a new sub-TLV codepoint for the Unconstrained TE LSP Count sub-TLV carried within the TE Link TLV.

IANAはOSPF TEリンクTLV(タイプ2)で搬送サブTLVのためのサブレジストリを定義しているサブTLVは、TEリンクTLVの中で運ばカウント制約なしTE LSPのための新しいサブTLVコードポイントを割り当てました。

Value TLV Name Reference

値TLV名前リファレンス

23 Unconstrained TE LSP Count (sub-)TLV RFC 5330

23制約のないTE LSPカウント(サブ)TLVのRFC 5330

6. Security Considerations
6.セキュリティの考慮事項

The function described in this document does not create any new security issues for the OSPF and IS-IS protocols. Security considerations are covered in [RFC2328] and [RFC5340] for the base OSPF protocol and in [RFC1195] and [RFC5304] for IS-IS.

このドキュメントで説明する機能は、OSPFのための新たなセキュリティ問題を作成していないプロトコルIS-IS。セキュリティに関する注意事項は、IS-ISのために[RFC2328]と[RFC5340]ベースOSPFプロトコル用とでは、[RFC1195]と[RFC5304]でカバーされています。

A security framework for MPLS and Generalized MPLS can be found in [G/MPLS].

MPLS及び一般MPLS用のセキュリティフレームワークは、[G / MPLS]に見出すことができます。

7. Acknowledgements
7.謝辞

The authors would like to thank Jean-Louis Le Roux, Adrian Farrel, Daniel King, Acee Lindem, Lou Berger, Attila Takacs, Pasi Eronen, Russ Housley, Tim Polk, and Loa Anderson for their useful inputs.

著者は、彼らの便利な入力のためのジャン=ルイ・ル・ルー、エードリアンファレル、ダニエル・キング、ACEE Lindem、ルー・バーガー、アッティラタカーチ、パシEronen、ラスHousley、ティムポーク、およびロア・アンダーソンに感謝したいと思います。

8. References
8.参照文献
8.1. Normative References
8.1. 引用規格

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。

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

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング(TE)OSPFバージョン2への拡張"、RFC 3630、2003年9月。

[RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008.

[RFC5304]李、T.とR.アトキンソン、 "中間システム(IS-IS)暗号化認証に中間システム"、RFC 5304、2008年10月。

[RFC5305] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering", RFC 5305, October 2008.

[RFC5305]李、T.とH.スミットは、 "IS-ISトラフィックエンジニアリング用の拡張機能"、RFC 5305、2008年10月。

[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.

[RFC5329]石黒、K.、Manral、V.、デイビー、A.、およびA. Lindem、エド。、RFC 5329、2008年9月 "OSPFバージョン3へのトラフィックエンジニアリングの拡張"。

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.

[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。

8.2. Informative References
8.2. 参考文献

[G/MPLS] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work In Progress, July 2008.

[G / MPLS]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年7月で働いています。

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

[RFC5120] Przygienda、T.、シェン、N.、およびN. Shethは、 "M-ISIS:中間システムへの中間システムにおけるマルチトポロジー(MT)ルーティング(IS-ISS)"、RFC 5120、2008年2月。

Authors' Addresses

著者のアドレス

JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA

JP Vasseur(エディタ)は、シスコシステムズ、株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

EMail: jpv@cisco.com

メールアドレス:jpv@cisco.com

Matthew R. Meyer BT Boston, MA USA

マシュー・R.マイヤーBTボストン、MA USA

EMail: matthew.meyer@bt.com

メールアドレス:matthew.meyer@bt.com

Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN

けんじ くまき Kっぢ R&D ぁぼらとりえs、 いんc。 2ー1ー15 おはら ふじみの さいたま 356ー8502、 じゃぱん

EMail: ke-kumaki@kddi.com

メールアドレス:ke-kumaki@kddi.com

Alberto Tempia Bonda Telecom Italia via G. Reiss Romoli 274 Torino, 10148 ITALIA

G.ライスRomoli経由アルベルトTempia Bondaテレコムイタリア274トリノ、イタリア10148

EMail: alberto.tempiabonda@telecomitalia.it

メールアドレス:alberto.tempiabonda@telecomitalia.it

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に情報を記述してください。