Network Working Group K. Kompella
Request for Comments: 3480 Y. Rekhter
Category: Standards Track Juniper Networks
A. Kullberg
NetPlane Systems
February 2003
Signalling Unnumbered Links in CR-LDP
(Constraint-Routing Label Distribution Protocol)
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links.
トラフィックエンジニアリング（MPLS TE）をマルチプロトコルラベルスイッチングによって使用される現在のシグナリングはアンナンバードリンクのサポートを提供していません。この文書では、手順および拡張が制約ルーティングするラベル配布プロトコル（CR-LDP）、無数のリンクをサポートするために必要とされているMPLS TEシグナリングプロトコルのいずれかを定義します。
Specification of Requirements
要件の仕様
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Supporting MPLS TE over unnumbered links (i.e., links that do not have IP addresses) involves two components: (a) the ability to carry (TE) information about unnumbered links in IGP TE extensions (ISIS or OSPF), and (b) the ability to specify unnumbered links in MPLS TE signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The focus of this document is on the latter.
アンナンバードリンク上でMPLS TEをサポートする（つまり、IPアドレスを持っていないリンク）が二つの成分を含む：（a）の（TE）IGP TE拡張（ISISまたはOSPF）でアンナンバードリンクに関する情報などを運ぶ能力（B） MPLS TEシグナリングにアンナンバードリンクを指定する機能。前者は[GMPLS-ISIS、GMPLS-OSPF]で覆われています。このドキュメントの焦点は後者です。
Current signalling used by MPLS TE does not provide support for unnumbered links because the current signalling does not provide a way to indicate an unnumbered link in its Explicit Route Objects. This document proposes simple procedures and extensions that allow CR-LDP signalling [CR-LDP] to be used with unnumbered links.
現在のシグナリングはその明示的経路オブジェクトでアンナンバードリンクを示すための方法を提供していないので、MPLS TEによって使用される現在のシグナリングはアンナンバードリンクのサポートを提供していません。この文書では、CR-LDPは、無数のリンクを使用する[CR-LDP]をシグナリングできるように簡単な手順と拡張を提案します。
An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then the IS-IS and/or OSPF and CR-LDP modules on an LSR must agree on the identifiers.
アンナンバードリンクは、ポイントツーポイントリンクである必要があります。無数のリンクの各端におけるLSRは、そのリンクに識別子を割り当てます。この識別子は、それを割り当てLSRの範囲内で一意である非ゼロの32ビットの数値です。 1は、トラフィックエンジニアリングのサポートにIGPとしてOSPFやISISを使用している場合は、LSR上のISISおよび/またはOSPFとCR-LDPモジュールは、識別子に同意しなければなりません。
There is no a priori relationship between the identifiers assigned to a link by the LSRs at each end of that link.
そのリンクの両端でのLSRによってリンクに割り当てられた識別子の間には先験的関係はありません。
LSRs at the two end points of an unnumbered link exchange with each other the identifiers they assign to the link. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP ([LMP]), by means of CR-LDP (especially in the case where a link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]).
それらはリンクに割り当てる識別子互いに無数のリンク交換の両端点でのLSR。識別子を交換する構成により、例えばLMP（[LMP]）などのプロトコルを用いて、CR-LDP（特にリンクが転送隣接場合には、以下を参照）によって、または手段によって達成することができますISIS又はOSPF拡張（[ISIS-GMPLS]、[OSPF-GMPLS]）。
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an identifier for that link. So does LSR B. From A's perspective, we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective, the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.
LSRのAとB LSR A間（番号なし）リンクがそのリンクの識別子を選択考えます。だから、LSR B.は、Aの観点から行い、我々は「リンクローカル識別子」（または単に「ローカル識別子」）としてリンクに割り当てられた識別子に、そしてBは、「リンクとしてリンクに割り当てられた識別子を参照してください。リモート識別子」（または単に 『リモート識別子』）。同様に、Bの観点から、Bはリンクに割り当てられた識別子はローカル識別子であり、リンクに割り当てられた識別子は、リモート識別子です。
In the context of this document, the term "Router ID" means a stable IP address of an LSR that is always reachable if there is any connectivity to the LSR. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface on the LSR is down. In some cases, this value will need to be configured. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then it is RECOMMENDED for the Router ID to be set to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE].
この文書の文脈において、用語「ルータIDは」LSRへの接続性があるかどうか、常に到達可能であるLSRの安定したIPアドレスを意味します。これは、典型的には、「ループバックアドレス」として実装されています。キー属性は、LSR上のインターフェイスがダウンしている場合は、アドレスが使用できなくなることがないということです。いくつかのケースでは、この値を設定する必要があります。 1は、トラフィックエンジニアリングのサポートでIGPとしてOSPFやISISを使用している場合、次のように[OSPF-TE]、または「トラフィックエンジニアリングルータID」で定義された「ルータアドレス」に設定するルータIDに推奨されます[ISIS-TE]で定義されます。
This section is equally applicable to the case of unnumbered component links (see [LINK-BUNDLE]).
このセクションでは、（[LINK-BUNDLE]参照）は無数のコンポーネントリンクの場合にも同様に適用可能です。
If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR uses the Forwarding Adjacency formed by this LSP as an unnumbered component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Moreover, the REQUEST message used for establishing the LSP that forms the Forwarding Adjacency MUST contain an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's Router ID set to the head end's Router ID, and the Interface ID set to the identifier that the LSR allocated to the Forwarding Adjacency.
LSPを発信LSRは、IS-ISまたはOSPFにおける無数転送隣接（[LSP-HIER]を参照）、このLSPをアドバタイズ、またはLSRは束ねられたリンクの無数のコンポーネントリンクこのLSPによって形成された転送隣接を使用している場合（[LINK-BUNDLE]を参照）、LSRは、（ちょうど他の無数のリンクのためのような）その転送隣接に識別子を割り当てなければなりません。また、LSRのルータIDを有する（後述）LSP_TUNNEL_INTERFACE_ID TLVを含まなければなりません転送隣接を形成LSPを確立するために使用される要求メッセージは、ヘッドエンドのルータIDに設定され、インタフェースIDはLSRが割り当てられた識別子に設定します転送隣接します。
If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then the tail-end LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Furthermore, the MAPPING message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the tail-end's Router ID, and the Interface ID set to the identifier allocated by the tail-end LSR.
REQUESTメッセージはLSP_TUNNEL_INTERFACE_ID TLVが含まれている場合、テールエンドLSRは、（ちょうど他の無数のリンクのためのような）その転送隣接に識別子を割り当てなければなりません。また、LSPのマッピングメッセージは、LSRのルータIDは、テールエンドのルータIDに設定され、インタフェースIDがテールエンドLSRによって割り当てられた識別子に設定し、LSP_TUNNEL_INTERFACE_ID TLVを含まなければなりません。
For the purpose of processing the Explicit Route TLV and the Interface ID TLV, an unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link or an unnumbered component link as follows. The LSR that originates the Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Reverse Interface ID TLV (for the definition of Reverse Interface ID TLV see below). The LSR that is a tail-end of that Forwarding Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Forward Interface ID TLV (for the definition of Forward Interface ID see below).
次のように明示ルートTLV及びインタフェースID TLVを処理する目的のために、無数の転送隣接は無数（TE）リンク又は無数コンポーネントリンクとして扱われます。隣接関係を発信LSRは、定義のためのLSRがその転送隣接に割り当てた値に、そのリンクのためのリンクローカル識別子、及びリバース・インタフェースID TLVのインタフェースIDフィールド内で運ば値にリンク遠隔識別子（セットリバース・インタフェースID TLVの）以下を参照してください。その転送隣接の末尾であるLSRは、フォワード・インターフェースのインターフェースIDフィールドで運ばれた値にLSRがその転送隣接に割り当てる値へのリンクのためのリンクローカル識別子、およびリンク遠隔識別子を設定しますID TLV（フォワードインタフェースIDの定義については下記を参照）。
The LSP_TUNNEL_INTERFACE ID TLV has Type 0x0836 and length 8. The format is given below.
LSPトンネルインターフェイスIP TLVは、形式は以下のとおりである0x0836と長さ8.有します。
Figure 1: LSP_TUNNEL_INTERFACE_ID TLV
図1：LSP_TUNNEL_INTERFACE_ID TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV can optionally appear in either a REQUEST message or a MAPPING message. In the former case, we call it the "Forward Interface ID" for that LSP; in the latter case, we call it the "Reverse Interface ID" for the LSP.
このTLVは、必要に応じてREQUESTメッセージやマッピング・メッセージのいずれかで表示されます。前者の場合、我々はそのLSPのための「転送インタフェースID」と呼んで。後者の場合には、我々はLSPのための「リバース・インタフェースID」と呼んでいます。
A new Type of ER-Hop TLV of the Explicit Route TLV is used to specify unnumbered links. This Type is called Unnumbered Interface ID, and has the following format:
明示的ルートTLVのERホップTLVの新しいタイプは、アンナンバードのリンクを指定するために使用されます。このタイプは、アンナンバードインターフェイスIDと呼ばれ、次の書式を備えています
The Type is 0x0837, and the Length is 12. The L bit is set to indicate a loose hop, and cleared to indicate a strict hop.
タイプ0x0837であり、長さはLビットがルーズホップを示すように設定され、厳格なホップを示すためにクリアされる12です。
The Interface ID is the identifier assigned to the link by the LSR specified by the router ID.
インタフェースIDはルータIDで指定されたLSRによってリンクに割り当てられた識別子です。
Figure 2: Unnumbered Interface ID
図2：アンナンバードインターフェイスID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When an LSR receives a REQUEST message containing the IF_ID (Interface ID) TLV (see [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as follows. The LSR must have information about the identifiers assigned by its neighbors to the unnumbered links between the neighbors and the LSR. The LSR uses this information to find a link with tuple <Router ID, local identifier> matching the tuple <IP Address, Interface ID> carried in the IF_INDEX TLV. If the matching tuple is found, the match identifies the link for which the LSR has to perform label allocation.
LSRはIF_INDEX TLVとIF_ID（インタフェースID）TLVを（[GMPLS-CRLDP]を参照）を含む要求メッセージを受信すると、以下のように、LSRはこのTLVを処理します。 LSRは隣人とLSR間のアンナンバードリンクに隣人によって割り当てられた識別子についての情報を持っている必要があります。 LSRはタプルにマッチするタプル<ルータID、ローカル識別子>のリンクを見つけるために、この情報を使用し、<IPアドレス、インタフェースID>はIF_INDEX TLVで搬送されます。マッチングタプルが見つかった場合、一致がLSRがラベル割り当てを実行するために持っているリンクを識別する。
Otherwise, the LSR SHOULD return an error.
そうでなければ、LSRはエラーを返すべきです。
The Unnumbered Interface ID ER-Hop is defined to be a part of a particular abstract node if that node has the Router ID that is equal to the Router ID field in the Unnumbered Interface ID ER-Hop, and if the node has an (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local identifier (from that node's point of view) is equal to the value carried in the Interface ID field of the Unnumbered Interface ID ER-Hop.
アンナンバードインターフェイスID ERホップは、そのノードがアンナンバードインターフェイスID ERホップのルータIDフィールドと等しくなるルータIDを持っている場合、特定の抽象ノードの一部であると定義され、ノードが（非番号を有する場合）リンクまたはそのローカル識別子（図のノードの点から）アンナンバードインターフェイスID ERホップのインタフェースIDフィールドで運ばれた値に等しい（番号なし）転送隣接。
With this in mind, the Explicit Route TLV processing in the presence of the Unnumbered Interface ID ER-Hop follows the rules specified in section 4.8.1 of [CR-LDP].
これを念頭において、アンナンバードインターフェイスID ERホップの存在下で、明示的ルートTLV処理[CR-LDP]のセクション4.8.1で指定された規則に従います。
As part of the Explicit Route TLV processing, or to be more precise, as part of the next hop selection, if the outgoing link is unnumbered, the REQUEST message that the node sends to the next hop MUST include the IF_ID TLV, with the IP address field of that TLV set to the Router ID of the node, and the Interface ID field of that TLV set to the identifier assigned to the link by the node.
明示的ルートTLV処理の一部として、またはより正確に発信リンクに番号が付いていない場合、次のホップの選択の一部として、ノードは、次ホップに送信要求メッセージはIPと、IF_ID TLVを含まなければなりませんノードのルータIDを設定することTLVのアドレスフィールド、及びノードがリンクに割り当てられた識別子に設定されているTLVのインタフェースIDフィールド。
RFC 3036 [LDP] defines the LDP TLV name space. RFC 3212 [CD-LDP] further subdivides the range of that TLV space for TLVs associated with the CR-LDP in the range 0x0800 - 0x08FF, and defines the rules for the assignment of TLVs within that range using the terminology of BCP 26, RFC 2434, "Guidelines for Writing an IANA Considerations Section in RFCs". Those rules apply to the assignment of TLV Types for the Unnumbered Interface ID and LSP_TUNNEL_INTERFACE_ID TLVs defined in this document.
RFC 3036 [LDP]はLDP TLVの名前空間を定義します。 RFC 3212 [CD-LDP】さらなる範囲に0x0800でCR-LDPと関連のTLVのためにそのTLV空間の範囲を細分 - 0x08FF、およびBCP 26の用語を使用して、その範囲内のTLVの割り当てのためのルールを定義し、RFC 2434年、「RFCでIANA問題部に書くためのガイドライン」。これらのルールは、この文書で定義されたアンナンバードインターフェイスIDとLSP_TUNNEL_INTERFACE_IDのTLVのためのTLVタイプの割り当てに適用されます。
This document extends CR-LDP and raises no new security issues. CR-LDP inherits the same security mechanism described in Section 4.0 of [LDP] to protect against the introduction of spoofed TCP segments into LDP session connection streams.
この文書では、CR-LDPを拡張し、新たなセキュリティ問題を提起していません。 CR-LDPは、LDPセッション接続ストリームにスプーフィングされたTCPセグメントの導入から保護する[LDP]のセクション4.0に記載したのと同じセキュリティメカニズムを継承します。
Thanks to Rahul Aggarwal for his comments on the text. Thanks also to Bora Akyol, Vach Kompella, and George Swallow.
テキスト上の彼のコメントのためのラウール・アガーウォールに感謝します。またボラAkyol、VACH Kompella、ジョージくんに感謝します。
[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[CR-LDP] Jamoussi、B.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、 Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GMPLS-SIG]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[GMPLS-CRLDP] Ashwood, P., Ed. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472 January 2003.
[GMPLS-CRLDP]アッシュウッド、P.、エド。およびL.バーガー、RFC 3472 2003年1月、 "一般化マルチプロトコルラベルスイッチング（GMPLS）は、制約ベースのルーティングのラベル配布プロトコル（CR-LDP）拡張機能を合図"。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001
[LDP]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月
[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月。
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[LINK-BUNDLE] Kompella、K.、Rekhter、Y.、およびバーガー、L.、 "MPLSトラフィックエンジニアリングにバンドルリンク" が進行中で働いています。
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Work in Progress.
、進行中の作業 "MPLS TE LSPと階層" [LSP-HIER] Kompella、K.、およびRekhter、Y.、。
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", Work in Progress.
[LMP]ラング、J.、ミトラ、K.、ら。、 "リンク管理プロトコル（LMP）"、ProgressのWork。
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-ISIS] Kompella、K.、Rekhter、Y.、バネルジー、A.ら、 "一般化MPLSのサポートにおけるISIS拡張"、ProgressのWork。
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-OSPF] Kompella、K.、Rekhter、Y.、バネルジー、A.ら、 "一般化MPLSのサポートにOSPF拡張"、ProgressのWork。
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", Work in Progress.
[OSPF-TE]カッツ、D.、ヨン、D.、Kompella、K.、進行中で働いて "OSPFバージョン2へのトラフィックエンジニアリングの拡張"。
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress.
[ISIS-TE]李、T.、スミット、H.、 "トラフィックエンジニアリングのためのISISの拡張" が進行中で働いています。
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Alan Kullberg NetPlane Systems, Inc. Westwood Executive Center 200 Lowder Brook Drive Westwood, MA 02090
アランKullberg網面Systems、Inc.のウェストウッドエグゼクティブセンター200 Lowderブルックドライブウェストウッド、MA 02090
EMail: akullber@netplane.com
メールアドレス：akullber@netplane.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。