RFC4591 日本語訳
4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3).M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. August 2006. (Format: TXT=28232 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Townsley
Request for Comments: 4591 G. Wilkie
Category: Standards Track S. Booth
S. Bryant
Cisco Systems
J. Lau
July 2006
Townsleyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4591年のG.ウィルキーカテゴリ: 標準化過程S.ブースS.ブライアントシスコシステムズJ.ラウ2006年7月
Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
層2のトンネリングプロトコルバージョン3の上のフレームリレー(L2TPv3)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual- circuit creation and deletion, and status change notification.
Layer2Tunnelingプロトコル、バージョン3、(L2TPv3)はIPネットワークの上でさまざまなデータリンクプロトコルにトンネルを堀るためにプロトコルを定義します。 このドキュメントはL2TPv3の上でどうFrame Relayにトンネルを堀るかに関する詳細について説明します、フレームカプセル化、仮想のサーキット創造、削除、および状態変更届出書を含んでいて。
Townsley, et al. Standards Track [Page 1] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[1ページ]RFC4591フレームリレー
Table of Contents
目次
1. Introduction ....................................................2
1.1. Abbreviations ..............................................3
1.2. Specification of Requirements ..............................3
2. Control Connection Establishment ................................3
3. PVC Status Notification and Session Establishment ...............3
3.1. L2TPv3 Session Establishment ...............................4
3.2. L2TPv3 Session Teardown ....................................5
3.3. L2TPv3 Session Maintenance .................................5
3.4. Use of the Circuit Status AVP for Frame Relay ..............6
3.5. Frame Relay Header Length AVP ..............................7
4. Encapsulation ...................................................7
4.1. Data Packet Encapsulation ..................................7
4.2. Data Packet Sequencing .....................................9
4.3. MTU Considerations .........................................9
5. Applicability Statement ........................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
7.1. Pseudowire Type ...........................................11
7.2. Result Code AVP Values ....................................11
7.3. Control Message Attribute Value Pairs (AVPs) ..............11
8. Acknowledgements ...............................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
1. 序論…2 1.1. 略語…3 1.2. 要件の仕様…3 2. コネクション確立を制御してください…3 3. PVC状態通知とセッション設立…3 3.1. L2TPv3セッション設立…4 3.2. L2TPv3セッション分解…5 3.3. L2TPv3セッション維持…5 3.4. サーキット状態AVPのフレームリレーの使用…6 3.5. フレームリレーヘッダ長AVP…7 4. カプセル化…7 4.1. データ・パケットカプセル化…7 4.2. データ・パケット配列…9 4.3. MTU問題…9 5. 適用性声明…10 6. セキュリティ問題…10 7. IANA問題…11 7.1. Pseudowireはタイプします…11 7.2. 結果コードAVP値…11 7.3. メッセージ属性値ペア(AVPs)を制御してください…11 8. 承認…11 9. 参照…12 9.1. 標準の参照…12 9.2. 有益な参照…12
1. Introduction
1. 序論
[RFC3931] defines a base protocol for Layer 2 Tunneling over IP networks. This document defines the specifics necessary for tunneling Frame Relay over L2TPv3. Such emulated circuits are referred to as Frame Relay Pseudowires (FRPWs).
[RFC3931]はLayer2TunnelingのためにIPネットワークの上でベースプロトコルを定義します。 このドキュメントはL2TPv3の上でトンネリングFrame Relayに必要な詳細を定義します。 そのような見習われたサーキットはFrame Relay Pseudowires(FRPWs)と呼ばれます。
Protocol specifics defined in this document for L2TPv3 FRPWs operating in a "virtual circuit-to-virtual circuit" mode include those necessary for frame encapsulation, PVC creation and deletion, and status change notification. Frame Relay traffic may also be transported in a "port-to-port" or "interface-to-interface" fashion using High-Level Data Link Control (HDLC) Pseudowires as defined in [RFC4349]. Support for Switched Virtual Circuits (SVCs) and Switched/Soft Permanent Virtual Circuits (SPVCs) are outside the scope of this document.
本書では「仮想の仮想へのサーキットサーキット」モードで作動するL2TPv3 FRPWsのために定義されたプロトコル詳細はフレームカプセル化、PVC創造、削除、および状態変更届出書に必要なそれらを含んでいます。 また、フレームRelay交通は、[RFC4349]で定義されるようにHigh-レベルData Link Control(HDLC)Pseudowiresを使用しながら、「移植するポート」か「インタフェースからインタフェース」ファッションで輸送されるかもしれません。 このドキュメントの範囲の外にSwitched Virtual Circuits(SVCs)のサポートとSwitched/柔らかいPermanent Virtual Circuitsがあります(SPVCs)。
The reader is expected to be very familiar with the terminology and protocol constructs defined in [RFC3931].
読者が[RFC3931]で定義される用語とプロトコル構造物に非常によく知られさせると予想されます。
Townsley, et al. Standards Track [Page 2] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[2ページ]RFC4591フレームリレー
1.1. Abbreviations
1.1. 略語
FR Frame Relay FRPW Frame Relay Pseudowire LCCE L2TP Control Connection Endpoint (See [RFC3931]) PVC Permanent virtual circuit PW Pseudowire VC Virtual circuit
FR Frame Relay FRPW Frame Relay Pseudowire LCCE L2TP Control Connection Endpoint([RFC3931]を見る)PVC相手固定接続PW Pseudowire VC Virtualサーキット
1.2. Specification of Requirements
1.2. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Control Connection Establishment
2. コントロールコネクション確立
In order to tunnel a Frame Relay circuit over IP using L2TPv3, an L2TPv3 Control Connection MUST first be established as described in [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control Message MUST include the Frame Relay Data Link Connection Identifier (DLCI) PW Type of 0x0001 (see IANA Considerations), in the Pseudowire Capabilities List, as defined in Section 5.4.3 of [RFC3931]. This identifies the control connection as able to establish L2TP sessions to support Frame Relay Pseudowires (FRPWs).
L2TPv3を使用することでIPの上でFrame Relayサーキットにトンネルを堀るために、L2TPv3 Control Connectionは最初に、[RFC3931]で説明されるように確立していなければなりません。 L2TPv3 SCCRQ Control Messageと対応するSCCRP Control Messageは0×0001のFrame Relay Data Link Connection Identifier(DLCI)PW Typeを含まなければなりません(IANA Considerationsを見てください)、Pseudowire Capabilities Listで、.3セクション5.4[RFC3931]で定義されるように。 これは、コントロール接続がFrame Relay Pseudowires(FRPWs)を支持するためにL2TPセッションを確立できると認識します。
An LCCE MUST be able to identify itself uniquely in the SCCRQ and SCCRP messages via a globally unique value. By default, this is advertised via the structured Router ID Attribute Value Pairs (AVP) [RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as well.
LCCE MUST、SCCRQとSCCRPメッセージでグローバルにユニークな値で唯一それ自体を特定できてください。 デフォルトで、構造化されたRouter ID Attribute Valueペア(AVP)[RFC3931]でこれの広告を出します、不統一なHostname AVP[RFC3931]はまた、LCCEsを特定するのに使用されるかもしれませんが。
3. PVC Status Notification and Session Establishment
3. PVC状態通知とセッション設立
This section specifies how the status of a PVC is reported between two LCCEs. This includes what should happen when a PVC is created, deleted or when it changes state between ACTIVE and INACTIVE. When emulating a Frame Relay service, if the procedures for PVC status management defined in [Q933] Annex A are being used between an LCCE and the attached Remote System, an LCCE MUST participate in them (see Section 3.3).
このセクションはPVCの状態が2LCCEsの間でどう報告されるかを指定します。 これは、PVCが作成されて、削除されているとき、何が起こるべきであるか、そして、またはそれがいつACTIVEとINACTIVEの間の状態を変えるかを含んでいます。 Frame Relayサービスを見習うときには、[Q933]別館Aで定義されたPVC状態管理のための手順が用いられているなら、LCCEと付属Remote System、LCCE MUSTの間では、それらに参加してください(セクション3.3を見てください)。
Townsley, et al. Standards Track [Page 3] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[3ページ]RFC4591フレームリレー
3.1. L2TPv3 Session Establishment
3.1. L2TPv3セッション設立
PVC creation (provisioning) results in establishment of an L2TP session via the standard three-way handshake described in Section 3.4.1 of [RFC3931]. An LCCE MAY initiate the session immediately upon PVC creation or wait until the PVC state transitions to ACTIVE before attempting to establish a session for the PVC. Waiting until the PVC transitions to ACTIVE may be preferred, as it delays allocation of L2TP resources until it is absolutely necessary.
標準の3方向ハンドシェイクを通したL2TPセッションの設立におけるPVC創造(食糧を供給する)結果はセクション3.4で.1[RFC3931]について説明しました。 すぐPVC創造か待ちのPVCがPVCのためにセッションを確立するのを試みる前にACTIVEへの変遷を述べるまでのセッションのLCCE MAY開始。 PVCがACTIVEに移行するまで待つのは好まれるかもしれません、絶対に必要になるまでL2TPリソースの配分を遅らせるとき。
The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], Attribute Type 68, MUST be present in the Incoming-Call-Request (ICRQ) messages and MUST include the Frame Relay DLCI PW Type of 0x0001 for FRPWs.
.4セクション5.4[RFC3931]で定義されたPseudowire Type AVP(Attribute Type68)はIncoming呼び出し要求(ICRQ)メッセージに存在していなければならなくて、FRPWsのために0×0001のFrame Relay DLCI PW Typeを含まなければなりません。
The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ and Incoming-Call-Reply (ICRP) messages and MAY be present in the Set Link Info (SLI) message for FRPWs.
Circuit Status AVP(セクション3.4を見る)はICRQとIncoming呼び出し回答(ICRP)メッセージに存在していなければならなくて、FRPWsへのSet Link Info(SLI)メッセージに存在しているかもしれません。
The Frame Relay Header Length AVP (see Section 3.5) MAY be present in the ICRQ and ICRP messages.
Frame Relay Header Length AVP(セクション3.5を見る)はICRQとICRPメッセージに存在しているかもしれません。
The following is an example of the L2TP messages exchanged for an FRPW that is initiated after a new PVC is provisioned and becomes ACTIVE.
↓これは新しいPVCが食糧を供給されて、ACTIVEになった後に開始されるFRPWと交換されたL2TPメッセージに関する例です。
LCCE (LAC) A LCCE (LAC) B
------------------ ------------------
FR PVC Provisioned
FR PVC Provisioned
FR PVC ACTIVE
LCCE(ラック)はLCCE(ラック)Bです。------------------ ------------------ FR PVC、食糧を供給されたFR PVCがフランPVCに食糧を供給した、アクティブ
ICRQ (status = 0x03) ---->
ICRQ(状態=0×03)---->。
FR PVC ACTIVE
フラン、PVCアクティブ
<---- ICRP (status = 0x03)
<。---- ICRP(状態=0×03)
L2TP session established,
OK to send data into tunnel
データをトンネルに送るためにOKに確立されたL2TPセッション
ICCN ----->
L2TP session established,
OK to send data into tunnel
ICCN-----データをトンネルに送るためにOKに確立された>L2TPセッション
In the example above, an ICRQ is sent after the PVC is created and becomes ACTIVE. The Circuit Status AVP indicates that this PVC is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be
例では、PVCが作成されて、ACTIVEになった後に上に、ICRQを送ります。 Circuit Status AVPは、このPVCがACTIVEとNew(0×03)であることを示します。 Remote End ID AVP[RFC3931]はそうであるに違いありません。
Townsley, et al. Standards Track [Page 4] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[4ページ]RFC4591フレームリレー
present in the ICRQ in order to identify the PVC (together with the identity of the LCCE itself, as defined in Section 2) to associate the L2TP session with. The Remote End ID AVP, defined in [RFC3931], is of opaque form and variable length, though one MUST at a minimum support use of an unstructured four-octet value that is known to both LCCEs (either by direct configuration, or some other means). The exact method of how this value is configured, retrieved, discovered, or otherwise determined at each LCCE is outside the scope of this document.
PVCを特定する(LCCE自身のアイデンティティセクション2で定義されるように)ために中でICRQを寄贈してください。L2TPセッションを関連づけるために。 [RFC3931]で定義されたRemote End ID AVPは不透明なフォームと可変長のものです、1は両方のLCCEs(ダイレクト構成、またはある他の手段による)において知られている不統一な4八重奏の値の最小のサポート使用のときにそうしなければなりませんが。 このドキュメントの範囲の外にこの値が構成されるか、検索されるか、発見されるか、または別の方法で各LCCEでどう決定するかに関する正確な方法があります。
As with the ICRQ, the ICRP is sent only after the FR PVC transitions to ACTIVE as well. If LCCE B had not been provisioned for the PVC identified in the ICRQ, a Call-Disconnect-Notify (CDN) would have been immediately returned indicating that the circuit was not provisioned or available at this LCCE. LCCE A SHOULD then exhibit a periodic retry mechanism. If so, the period and maximum number of retries MUST be configurable.
ICRQのように、FR PVCがまた、ACTIVEに移行した後にだけICRPを送ります。 LCCE BがICRQで特定されたPVCのために食糧を供給されなかったなら、Call分離に通知している(CDN)は、サーキットが食糧を供給されなかったのを示しながらすぐに、返すか、またはこのLCCEで利用可能だったでしょうに。 そして、LCCE A SHOULDは周期的な再試行メカニズムを示します。 そうだとすれば、再試行の期間と最大数は構成可能であるに違いありません。
An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as long as the Circuit Status AVP reflects that the PVC is INACTIVE and an SLI is sent when the PVC becomes ACTIVE (see Section 3.3).
PVCがACTIVEになる前にImplementationはICRQかICRPを送るかもしれません、Circuit Status AVPが、PVCがINACTIVEであり、PVCがACTIVEになるとき(セクション3.3を見てください)SLIが送られるのを反映する限り。
The Incoming-Call-Connected (ICCN) is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic.
接続されたIncoming要求(ICCN)はセッション設立で最終段階です、双方向の交通を許容するために許容できるパラメタがあるICRPの領収書を確認して。
3.2. L2TPv3 Session Teardown
3.2. L2TPv3セッション分解
In the event that a PVC is deleted (unprovisioned) at either LCCE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [RFC3931].
LCCEでPVCを削除する場合(非食糧を供給しました)、.3セクション3.4[RFC3931]で定義されたCDNメッセージで関連L2TPセッションを取りこわさなければなりません。
General Result Codes regarding L2TP session establishment are defined in [RFC3931]. Additional Frame Relay result codes are defined as follows:
L2TPセッション設立に関するResult Codes司令官は[RFC3931]で定義されます。 追加Frame Relay結果コードは以下の通り定義されます:
17: FR PVC was deleted permanently (no longer provisioned) 18: FR
PVC has been INACTIVE for an extended period of time 19:
Mismatched FR Header Length
17: FR PVCが永久に(もう食糧を供給されない)削除された、18: 延ばされた期間19の間、FR PVCはINACTIVEです: ミスマッチしているFRヘッダ長
3.3. L2TPv3 Session Maintenance
3.3. L2TPv3セッション維持
FRPW over L2TP makes use of the SLI control message defined in [RFC3931] to signal Frame Relay link status notifications between LCCEs. This includes ACTIVE or INACTIVE notifications of the VC, and any other parameters that may need to be shared between the tunnel endpoints or LCCEs in order to provide proper PW emulation. The SLI message is a single message that is sent over the L2TP control
L2TPの上のFRPWはLCCEsの間のFrame Relayリンク状態通知に合図するために[RFC3931]で定義されたSLIコントロールメッセージを利用します。 これはVCのACTIVEかINACTIVE通知、および適切なPWエミュレーションを提供するためにトンネルの終点かLCCEsの間で共有される必要があるかもしれないいかなる他のパラメタも含んでいます。 SLIメッセージはL2TPコントロールの上に送られるただ一つのメッセージです。
Townsley, et al. Standards Track [Page 5] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[5ページ]RFC4591フレームリレー
channel signalling the state change. Since the message is delivered reliably, there is no additional response or action required of the PW subsystem to ensure that the state change notification was received by the tunnel peer.
州の変化に合図しながら、精神を集中してください。 メッセージを確かに送るので、どんな追加応答もないか、または動作がPWサブシステムについて州の変更届出書がトンネル同輩によって受け取られたのを保証するのが必要です。
The SLI message MUST be sent any time there is a circuit status change that may be reported by any values identified in the Circuit Status AVP. The only exceptions to this are the initial ICRQ, ICRP, and CDN messages, which establish and tear down the L2TP session itself when the PVC is created or deleted. The SLI message may be sent from either LCCE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring that the peer to perform a reverse Session ID lookup).
Circuit Status AVPで特定されたどんな値によっても報告されるかもしれないサーキット状態変化がある何時でもSLIメッセージを送らなければなりません。 これへの唯一の例外が、PVCが作成されるか、または削除されるとき、L2TPセッション自体を確立して、取りこわす初期のICRQと、ICRPと、CDNメッセージです。 最初のICRQを送った(aを実行する同輩がSession IDルックアップを逆にするのが必要であることで、ICRPが恐らく受け取られている前に)後にいつでも、LCCEからSLIメッセージを送るかもしれません。
An LCCE participating in the procedures for PVC status management defined in [Q933], Annex A, MUST transmit an SLI message including the Circuit Status AVP (see Section 3.4) when it detects a change in the status for a particular local FR PVC (i.e., when it detects a service-affecting condition or the clearing of such a condition). An LCCE receiving an SLI message indicating a change in the status of a particular FRPW SHOULD generate corresponding updates for the FR PVC towards the Remote System, as defined in [Q933], Annex A.
経営者側が[Q933]で定義したPVC状態に手順に参加するLCCE(Annex A)は特定の地方のFR PVCのために状態で変化を検出するときCircuit Status AVP(セクション3.4を見る)を含むSLIメッセージを送らなければなりません(すなわち、それはいつサービスに影響する状態かそのような状態の開拓地を検出しますか)。 特定のFRPW SHOULDの状態の変化を示すSLIメッセージを受け取るLCCEはFR PVCのために対応するアップデートをRemote Systemに向かって発生させます、[Q933]で定義されるように、Annex A。
All sessions established by a given control connection utilize the L2TP Hello facility, defined in Section 4.4 of [RFC3931], for session keepalive. This gives all sessions basic dead peer and path detection between LCCEs.
与えられたコントロール接続によって確立されたすべてのセッションがセッションkeepaliveに[RFC3931]のセクション4.4で定義されたL2TP Hello施設を利用します。 これはLCCEsの間で基本的な死んでいる同輩と経路検出をすべてのセッションに与えます。
3.4. Use of the Circuit Status AVP for Frame Relay
3.4. サーキット状態AVPのフレームリレーの使用
Frame Relay circuit status is reported via the Circuit Status AVP defined in [RFC3931], Attribute Type 71. For reference, this AVP is shown below:
Attribute Type71、フレームRelayサーキット状態は[RFC3931]で定義されたCircuit Status AVPを通して報告されます。 参照において、このAVPは以下で見せられます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16-bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 by the sender and ignored by the receiver.
Valueは2つの最下位ビットが定義されて、残っているビットが今後の使用のために予約されている16ビットのマスクです。 予約されたビットを送付者によって0に設定されて、受信機で無視しなければなりません。
The N (New) bit indicates whether the Circuit Status indication is for a new FR PVC (1) or an existing FR PVC (0).
(新しい)のNビットは、Circuit Status指示が新しいFR PVC(1)か既存のFR PVC(0)のためのものであるかを示します。
Townsley, et al. Standards Track [Page 6] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[6ページ]RFC4591フレームリレー
The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or INACTIVE (0).
A(アクティブ)のビットは、FR PVCがACTIVE(1)かそれともINACTIVE(0)であるかを示します。
3.5. Frame Relay Header Length AVP
3.5. フレームリレーヘッダ長AVP
The "Frame Relay Header Length AVP", Attribute type 85, indicates the number of bytes in the Frame Relay header. The two peer LCCEs MUST agree on the length of the Frame Relay header.
「フレームリレーヘッダ長AVP」(Attributeタイプ85)はFrame Relayヘッダーでバイト数を示します。 2同輩LCCEsがFrame Relayヘッダーの長さに同意しなければなりません。
This AVP is exchanged during session negotiation (in ICRQ, ICRP). If the other LCCE supports a different Frame Relay header length, the associated L2TP session MUST be torn down via CDN message with result code 19 (see Section 3.2).
セッション交渉(ICRQのICRP)の間、このAVPを交換します。 もう片方のLCCEが異なったFrame Relayヘッダ長を支持するなら、結果コード19があるCDNメッセージで関連L2TPセッションを取りこわさなければなりません(セクション3.2を見てください)。
If the Frame Relay Header Length AVP is not signalled, it MUST be assumed that the peer uses a 2-byte Frame Relay header.
Frame Relay Header Length AVPが合図されないなら、同輩が2バイトのFrame Relayヘッダーを使用すると思わなければなりません。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式があります:
Frame Relay Header Length (ICRQ, ICRP)
フレームリレーヘッダ長(ICRQ、ICRP)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Header Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フレームリレーヘッダ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Frame Relay Header Length Type is a 2-octet unsigned integer with the following values defined in this document:
Frame Relay Header Length Typeは以下の値が本書では定義されている2八重奏の符号のない整数です:
2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header
2: 2八重奏のフレームリレーヘッダー4: 4八重奏のフレームリレーヘッダー
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP MAY be set to 0 but MAY vary (see Section 5.2 of [RFC3931]). The length (before hiding) of this AVP is 8.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP MAYのために噛み付かれたMは、0に設定されますが、異なるかもしれません([RFC3931]のセクション5.2を見てください)。 このAVPの長さ(隠れることの前の)は8です。
4. Encapsulation
4. カプセル化
4.1. Data Packet Encapsulation
4.1. データ・パケットカプセル化
The FR PDU is transported in its entirety, excluding the opening and closing High Level Data Link Control (HDLC) flags and the frame check sequence (FCS). Bit stuffing is undone. The L2TPv3 Session Header is that as defined in [RFC3931]. If sequencing or other features require presence of an L2-Specific Sublayer, the Default format defined in Section 4.6 of [RFC3931] MUST be used.
FR PDUは全体として輸送されます、初めの、そして、終わりのHigh Level Data Link Control(HDLC)旗とフレームチェックシーケンス(FCS)を除いて。 ビット・スタッフィングは元に戻されます。 L2TPv3 Session Headerは[RFC3931]で定義されるようにそれです。 配列か他の特徴がL2特有のSublayerを存在に要求するなら、[RFC3931]のセクション4.6で定義されたDefault書式を使用しなければなりません。
Townsley, et al. Standards Track [Page 7] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[7ページ]RFC4591フレームリレー
The FR header is defined in [Q922]; however, the notation used differs from that used in IETF specifications. For reference, the FR header (referred to as Address Field in [Q922]) in IETF notation is
FRヘッダーは[Q922]で定義されます。 しかしながら、使用される記法はIETF仕様で使用されるそれと異なっています。 参照のために、IETF記法によるFRヘッダー([Q922]にAddress Fieldと呼ばれる)はそうです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | こんにちは、dlci|C|0|最低気温dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two-octet FR Header
2八重奏のFRヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | こんにちは、dlci|C|0| dlci|F|B|D|0| dlci|0| dlci_最低気温|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Four-octet FR Header
4八重奏のFRヘッダー
C/R (bit 6) FR frame C/R (command/response) bit [Q922].
C/R(ビット6)FRはC/R(コマンド/応答)ビット[Q922]を縁どっています。
F - FECN (bit 12): FR FECN (Forward Explicit Congestion Notification) bit [Q922].
F--、FECN(ビット12): FR FECN(前進のExplicit Congestion Notification)は[Q922]に噛み付きました。
B - BECN (bit 13):
B--、BECN(ビット13):
FR BECN (Backward Explicit Congestion Notification) bit [Q922].
FR BECN(後方のExplicit Congestion Notification)は[Q922]に噛み付きました。
D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922].
DE(ビット14)FR DEビットは破棄を示します。D--、適任[Q922]。
Usage of the C/R, FECN, BECN, and DE bits is as specified in [Q922].
C/R、FECN、BECN、およびDEビットの使用法が[Q922]で指定されるようにあります。
The C/R bit is conveyed transparently. Its value MUST NOT be changed by the LCCE.
C/Rビットは透明に運ばれます。 値はLCCEによって変えられてはいけません。
The FECN bit MAY be set by the LCCE to notify the receiving end-user that the frames it receives have encountered congestion. The end- user may use this indication for destination-controlled transmit rate adjustment. The bit must never be cleared by the LCCE. If the LCCE does not support FECN, it shall pass the bit unchanged.
FECNビットが、それが受けるフレームが混雑に遭遇したことを受信エンドユーザに通知するようにLCCEによって設定されるかもしれません。 ユーザがこの指示を使用するかもしれない終わりを目的地で制御しました。料金の調整を伝えてください。 LCCEはビットを決してきれいにしてはいけません。 LCCEがFECNを支持しないなら、それは変わりがない状態でビットを渡すものとします。
The BECN bit MAY be set by the LCCE to notify the receiving end-user that the frames it transmits may encounter congestion. The end-user may use this indication to adjust its transmit rate. The bit must never be cleared by the LCCE. If the LCCE does not support BECN, it shall pass the bit unchanged.
BECNビットが、それが伝えるフレームが混雑に遭遇するかもしれないように受信エンドユーザに通知するようにLCCEによって設定されるかもしれません。 エンドユーザが適応するのにこの指示を使用するかもしれない、それ、レートを伝えてください。 LCCEはビットを決してきれいにしてはいけません。 LCCEがBECNを支持しないなら、それは変わりがない状態でビットを渡すものとします。
Townsley, et al. Standards Track [Page 8] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[8ページ]RFC4591フレームリレー
The DE bit MAY be set by a policing function on the LCCE to indicate that this frame SHOULD be discarded in preference to other frames in a congestion situation. The bit must never be cleared by the LCCE. If the LCCE does not support DE, it shall pass the bit unchanged.
DEに取り締まり機能でオンなセットがこのフレームSHOULDが混雑状況における他のフレームに優先して捨てられるのを示すLCCEであったかもしれないなら噛み付きました。 LCCEはビットを決してきれいにしてはいけません。 LCCEがDEを支持しないなら、それは変わりがない状態でビットを渡すものとします。
The encapsulation of Frame Relay frames with the two-octet FR Header is REQUIRED. The encapsulation of Frame Relay frames with the four- octet FR Header is OPTIONAL. The encapsulation of Frame Relay frames with the three-octet FR Header is outside the scope of this document.
2八重奏のFR HeaderがあるFrame Relayフレームのカプセル化はREQUIREDです。 4八重奏FR HeaderがあるFrame Relayフレームのカプセル化はOPTIONALです。 このドキュメントの範囲の外に3八重奏のFR HeaderがあるFrame Relayフレームのカプセル化があります。
4.2. Data Packet Sequencing
4.2. データ・パケット配列
Data Packet Sequencing MAY be enabled for FRPWs. The sequencing mechanisms described in [RFC3931] MUST be used for signalling sequencing support. FRPW over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer when sequencing is enabled and MAY request its presence at all times.
データPacket SequencingはFRPWsのために有効にされるかもしれません。 合図配列サポートに[RFC3931]で説明された配列メカニズムを使用しなければなりません。 配列が可能にされて、いつも立会いを求めるとき、L2TP MUSTの上のFRPWはL2TPv3 Default L2特有のSublayerの存在を要求します。
If the FRPW is known to be carrying data that does not require packet order be strictly maintained (such as IP), then packet sequencing for the FRPW SHOULD NOT be enabled.
厳密に維持されて(IPなどの)、当時のパケットがFRPW SHOULD NOTのための配列であったならFRPWがパケットオーダーを必要としないデータを運ぶのが知られているなら、可能にされてください。
4.3. MTU Considerations
4.3. MTU問題
With L2TPv3 as the tunneling protocol, the packet resulted from the encapsulation is N bytes longer than Frame Relay frame without the opening and closing HDLC flags or FCS. The value of N depends on the following fields:
Frame Relayが初めの、そして、終わりのHDLCなしで旗かFCSを縁どっているより何バイトも長い間、トンネリングプロトコル、生じられるパケットとしてのL2TPv3と共に、カプセル化はNです。 Nの値を以下のフィールドに依存します:
L2TP Session Header:
Flags, Ver, Res 4 octets (L2TPv3 over UDP only)
Session ID 4 octets
Cookie Size 0, 4, or 8 octets
L2-Specific Sublayer 0 or 4 octets (i.e., with sequencing)
L2TPセッションヘッダー: 旗、Ver、Res4八重奏(UDPだけの上のL2TPv3)セッションID4八重奏Cookie Size0、4、または8八重奏L2特有のSublayer0か4八重奏(すなわち、配列がある)
Thus, the range for N in octets is:
したがって、八重奏におけるNのための範囲は以下の通りです。
N = 4 - 16 L2TPv3 data messages are over IP
N = 16 - 28 L2TPv3 data messages are over UDP
(N does not include the IP header)
N=4--IP N=16の上に16のL2TPv3データメッセージがあります--UDPの上に28のL2TPv3データメッセージがあります。(NはIPヘッダーを含んでいません)
The MTU and fragmentation implications resulting from this are discussed in Section 4.1.4 of [RFC3931].
.4セクション4.1[RFC3931]でこれから生じるMTUと断片化含意について議論します。
Townsley, et al. Standards Track [Page 9] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[9ページ]RFC4591フレームリレー
5. Applicability Statement
5. 適用性証明
The Frame Relay PW emulation described in this document allows a service provider to offer a Frame Relay PVC-based service across an IP packet-switched network (PSN). A Frame Relay port-based service can be offered using [RFC4349].
本書では説明されたFrame Relay PWエミュレーションで、サービスプロバイダーはIPパケット交換網(PSN)の向こう側にFrame Relay PVCベースのサービスを提供できます。 [RFC4349]を使用することでFrame Relayのポートベースのサービスを提供できます。
The FRPW emulation has the following characteristics in relationship to the native service:
FRPWエミュレーションには、ネイティブのサービスとの関係における以下の特性があります:
o There is a one-to-one mapping between a Frame Relay PVC and an
FRPW, supporting bi-directional transport of variable length
frames. The Frame Relay frame is transported in its entirety,
including the DLCI and the C/R, FECN, BECN, and DE bits, but
excluding the opening and closing flags and the FCS. The egress
LCCE re-writes the DLCI and regenerates the FCS.
o 可変長フレームの双方向の輸送を支持して、Frame Relay PVCとFRPWの間には、1〜1つのマッピングがあります。 Frame Relayフレームは全体として輸送されます、DLCI、C/R、FECN、BECN、およびDEビットを含んでいますが、初めの、そして、終わりの旗とFCSを除いて。 出口LCCEはDLCIを書き直して、FCSを作り直します。
o Two- and four-octet address fields are supported. The length is
negotiated between LCCEs during session establishment (see Section
3.5).
o 2と4八重奏のアドレス・フィールドは支持されます。 長さはセッション設立の間、LCCEsの間で交渉されます(セクション3.5を見てください)。
o The availability or unavailability of the PVC is signalled between
LCCEs using the Circuit Status AVP (see Section 3.4). Loss of
connectivity between LCCEs can be detected by the L2TPv3 keepalive
mechanism (see Section 4.4 in [RFC3931]). These indications can be
used to determine the PVC status to be signalled through [Q933]
procedures at the Frame Relay interface.
o Circuit Status AVPを使用することでPVCの有用性か使用不能がLCCEsの間で合図されます(セクション3.4を見てください)。 L2TPv3 keepaliveメカニズムはLCCEsの間の接続性の損失を検出できます([RFC3931]でセクション4.4を見てください)。 Frame Relayインタフェースにおける[Q933]手順でPVC状態が合図されることを決定するのにこれらの指摘を使用できます。
o The maximum frame size that can be supported is limited by the PSN
MTU, unless fragmentation and reassembly is used (see Section 4.1.4
of [RFC3931]).
o 支持できる最大のフレーム・サイズはPSN MTUによって制限されます、断片化と再アセンブリが使用されていない場合(.4セクション4.1[RFC3931]を見てください)。
o Sequencing may be enabled on the FRPW to ensure that frames are
delivered in order (see Section 4.2).
o 配列はフレームが整然とした状態で届けられるのを保証するFRPWで可能にされるかもしれません(セクション4.2を見てください)。
o Quality of Service characteristics, such as throughput (CIR),
committed burst size (bc), excess burst size (be), and priority,
can be provided by leveraging Quality of Service features of the
LCCEs and the underlying PSN.
o LCCEsと基本的なPSNのServiceの特徴のQualityに投機することによって、スループットなどのServiceの特性(CIR)の品質(遂行された放出量(bc)、余分な放出量(ある)、および優先権)を提供できます。
6. Security Considerations
6. セキュリティ問題
Frame Relay over L2TPv3 is subject to the security considerations defined in [RFC3931]. There are no additional considerations specific to carrying Frame Relay that are not present for carrying other data link types.
L2TPv3の上のフレームRelayは[RFC3931]で定義されたセキュリティ問題を受けることがあります。 他のデータリンク型を運ぶために存在していないFrame Relayを運ぶのに特定のどんな追加問題もありません。
Townsley, et al. Standards Track [Page 10] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[10ページ]RFC4591フレームリレー
7. IANA Considerations
7. IANA問題
7.1. Pseudowire Type
7.1. Pseudowireはタイプします。
The following value for the Frame Relay DLCI PW Type (see Pseudowire Capabilities List, as defined in 5.4.3 of [RFC3931], and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]) is allocated by the IANA (number space already created as part of publication of [RFC3931]):
Frame Relay DLCI PW Typeのための以下の値、(Pseudowire Capabilities Listを見てください、中で定義されるように5.4、.3、[RFC3931]、および[RFC3931)のコネ10.6がIANA([RFC3931]の公表の一部として既に作成された数のスペース)によって割り当てられるL2TPv3 Pseudowire Typesについて:
L2TPv3 Pseudowire Types
-----------------------
L2TPv3 Pseudowireはタイプします。-----------------------
0x0001: Frame Relay DLCI Pseudowire Type
0×0001: フレームリレーDLCI Pseudowireはタイプします。
7.2. Result Code AVP Values
7.2. 結果コードAVP値
This number space is managed by IANA as described in Section 2.3 of [RFC3438]. Three new L2TP Result Codes for the CDN message appear in Section 3.2. The following is a summary:
この数のスペースは[RFC3438]のセクション2.3で説明されるようにIANAによって管理されます。 CDNメッセージのための3新しいL2TP Result Codesがセクション3.2に現れます。 ↓これは概要です:
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
結果コードAVP(属性タイプ1)値-----------------------------------------
17: PVC was deleted permanently (no longer provisioned)
18: PVC has been INACTIVE for an extended period of time
19: Mismatched FR Header Length
17: PVCが永久に(もう食糧を供給されない)削除された、18: 延ばされた期間19の間、PVCはINACTIVEです: ミスマッチしているFRヘッダ長
7.3. Control Message Attribute Value Pairs (AVPs)
7.3. コントロールメッセージ属性値ペア(AVPs)
This number space is managed by IANA as described in Section 2.2 of [RFC3438]. An additional AVP Attribute, specified in Section 3.5, was allocated for this specification:
この数のスペースは[RFC3438]のセクション2.2で説明されるようにIANAによって管理されます。 この仕様のために追加セクション3.5で指定されたAVP Attributeを割り当てました:
Control Message Attribute Value Pairs
-------------------------------------
コントロールメッセージ属性値ペア-------------------------------------
85: Frame Relay Header Length
85: フレームリレーヘッダ長
8. Acknowledgements
8. 承認
The first Frame Relay over L2TP document, "Frame Relay Service Type for L2TP", was published in February of 2001, by Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik, and Vijay Gill. This document is substantially different, but the basic concept of carrying Frame Relay over L2TP is the same.
「L2TPのためのフレームリレーサービスタイプ」というL2TPドキュメントの上の最初のFrame Relayは2001年2月に発行されました、Nishit Vasavada、ジム・ボイル、クリス・ガーナー、セルジュMaskalik、およびビジェイGill。 このドキュメントは実質的に異なっていますが、L2TPの上までFrame Relayを運ぶ基本概念は同じです。
Townsley, et al. Standards Track [Page 11] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[11ページ]RFC4591フレームリレー
Thanks to Lloyd Wood for a razor-sharp review.
ロイドのおかげで鋭いかみそりのためのWoodは論評します。
Carlos Pignataro helped with review and editing of the document.
カルロスPignataroはドキュメントのレビューと編集で助けました。
During IETF Last Call, Mark Lewis provided thorough review and comments.
IETF Last Callの間、マーク・ルイスは徹底的なレビューとコメントを提供しました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4349] Pignataro, C. and M. Townsley, "High-Level Data Link
Control (HDLC) Frames over Layer 2 Tunneling Protocol,
Version 3 (L2TPv3)", RFC 4349, February 2006.
2006年2月の[RFC4349]PignataroとC.とM.Townsley、「層2のトンネリングの上のハイレベル・データ・リンク制御手順(HDLC)フレームは議定書を作ります、バージョン3(L2TPv3)」RFC4349
9.2. Informative References
9.2. 有益な参照
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
Assigned Numbers Authority (IANA) Considerations Update",
BCP 68, RFC 3438, December 2002.
w.[RFC3438]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[Q922] ITU-T Recommendation Q.922, "ISDN Data Link Layer
Specification for Frame Mode Bearer Services", ITU, Geneva,
1992.
[Q922]ITU-T推薦Q.922、「フレーム方式運搬人サービスのためのISDNデータ・リンク層仕様」、ITU、ジュネーブ、1992。
[Q933] ITU-T Recommendation Q.933, "Signalling specifications for
frame mode switched and permanent virtual connection
control and status monitoring", ITU, Geneva, 2003.
[Q933]ITU-T Recommendation Q.933、「切り換えられたフレーム方式、相手固定接続コントロール、および状態モニターのための合図仕様」、ITU、ジュネーブ、2003。
Townsley, et al. Standards Track [Page 12] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[12ページ]RFC4591フレームリレー
Authors' Addresses
作者のアドレス
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
7025年のW.マークTownsleyシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709
EMail: mark@townsley.net
メール: mark@townsley.net
George Wilkie Cisco Systems 96 Commercial Street Edinburgh, EH6 6LX United Kingdom
エディンバラ、ジョージウィルキーシスコシステムズ96の商業通りEH6 6LXイギリス
EMail: gwilkie@cisco.com
メール: gwilkie@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
7025年のブースシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709をスキップしてください。
EMail: ebooth@cisco.com
メール: ebooth@cisco.com
Stewart Bryant Cisco Systems 250 Longwater Ave Green Park Reading RG2 6GB United Kingdom
スチュワートブライアントシスコシステムズ250Longwater Aveグリーンパーク読書RG2 6GBイギリス
EMail: stbryant@cisco.com
メール: stbryant@cisco.com
Jed Lau
ジェド・ラウ
EMail: jedlau@gmail.com
メール: jedlau@gmail.com
Townsley, et al. Standards Track [Page 13] RFC 4591 Frame Relay over L2TPv3 July 2006
Townsley、他 L2TPv3 July 2006の上の標準化過程[13ページ]RFC4591フレームリレー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Townsley, et al. Standards Track [Page 14]
Townsley、他 標準化過程[14ページ]
一覧
スポンサーリンク
