RFC4349 日本語訳
4349 High-Level Data Link Control (HDLC) Frames over Layer 2 TunnelingProtocol, Version 3 (L2TPv3). C. Pignataro, M. Townsley. February 2006. (Format: TXT=22888 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Pignataro Request for Comments: 4349 M. Townsley Category: Standards Track Cisco Systems February 2006
Pignataroがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4349年のM.Townsleyカテゴリ: 標準化過程シスコシステムズ2006年2月
High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
層2のトンネリングプロトコル、バージョン3の上のハイレベル・データ・リンク制御手順(HDLC)フレーム(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 High-Level Data Link Control (HDLC) frames over L2TPv3.
Layer2Tunnelingプロトコル、バージョン3、(L2TPv3)はIPネットワークの上でさまざまなデータリンクプロトコルにトンネルを堀るためにプロトコルを定義します。 このドキュメントはL2TPv3の上でどうHigh-レベルData Link Control(HDLC)フレームにトンネルを堀るかに関する詳細について説明します。
Pignataro & Townsley Standards Track [Page 1] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[1ページ]RFC4349HDLCフレーム
Table of Contents
目次
1. Introduction ....................................................2 1.1. Abbreviations ..............................................2 1.2. Specification of Requirements ..............................3 2. Control Connection Establishment ................................3 3. HDLC Link Status Notification and Session Establishment .........3 3.1. L2TPv3 Session Establishment ...............................3 3.2. L2TPv3 Session Teardown ....................................5 3.3. L2TPv3 Session Maintenance .................................5 3.4. Use of Circuit Status AVP for HDLC .........................6 4. Encapsulation ...................................................6 4.1. Data Packet Encapsulation ..................................6 4.2. Data Packet Sequencing .....................................7 4.3. MTU Considerations .........................................7 5. Applicability Statement .........................................8 6. Security Considerations .........................................9 7. IANA Considerations .............................................9 7.1. Pseudowire Type ............................................9 7.2. Result Code AVP Values .....................................9 8. Acknowledgements ................................................9 9. References .....................................................10 9.1. Normative References ......................................10 9.2. Informative References ....................................10
1. 序論…2 1.1. 略語…2 1.2. 要件の仕様…3 2. コネクション確立を制御してください…3 3. HDLCは状態通知とセッション設立をリンクします…3 3.1. L2TPv3セッション設立…3 3.2. L2TPv3セッション分解…5 3.3. L2TPv3セッションメインテナンス…5 3.4. 回路状態AVPのHDLCの使用…6 4. カプセル化…6 4.1. データ・パケットカプセル化…6 4.2. データ・パケット配列…7 4.3. MTU問題…7 5. 適用性声明…8 6. セキュリティ問題…9 7. IANA問題…9 7.1. Pseudowireはタイプします…9 7.2. 結果コードAVP値…9 8. 承認…9 9. 参照…10 9.1. 標準の参照…10 9.2. 有益な参照…10
1. Introduction
1. 序論
[RFC3931] defines a base protocol for Layer 2 Tunneling over IP networks. This document defines the specifics necessary for tunneling HDLC Frames over L2TPv3. Such emulated circuits are referred to as HDLC Pseudowires (HDLCPWs).
[RFC3931]はLayer2TunnelingのためにIPネットワークの上でベースプロトコルを定義します。 このドキュメントはL2TPv3の上でHDLC Framesにトンネルを堀るのに必要な詳細を定義します。 そのような見習われた回路はHDLC Pseudowires(HDLCPWs)と呼ばれます。
Protocol specifics defined in this document for L2TPv3 HDLCPWs include those necessary for simple point-to-point (e.g., between two L2TPv3 nodes) frame encapsulation, and for simple interface up and interface down notifications.
本書ではL2TPv3 HDLCPWsのために定義されたプロトコル詳細は簡単な二地点間(例えば、2つのL2TPv3ノードの間の)のフレームカプセル化、簡単なインタフェース、および通知の下側へのインタフェースに必要なそれらを含んでいます。
The reader is expected to be very familiar with the terminology and protocol constructs defined in [RFC3931].
読者が[RFC3931]で定義される用語とプロトコル構造物に非常によく知られさせると予想されます。
1.1 Abbreviations
1.1 略語
HDLC High-Level Data Link Control HDLCPW HDLC Pseudowire LAC L2TP Access Concentrator (see [RFC3931]) LCCE L2TP Control Connection Endpoint (see [RFC3931]) PW Pseudowire
HDLCハイレベル・データ・リンク制御手順HDLCPW HDLC PseudowireラックL2TPアクセス集中装置([RFC3931]を見る)LCCE L2TPコントロール接続終点([RFC3931]を見る)PW Pseudowire
Pignataro & Townsley Standards Track [Page 2] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[2ページ]RFC4349HDLCフレーム
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 an HDLC link 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 HDLC Pseudowire Type of 0x0006 (see Section 7, "IANA Considerations"), in the Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931]. This identifies the control connection as able to establish L2TP sessions to support HDLC Pseudowires (HDLCPWs).
L2TPv3を使用することでIPの上でHDLCリンクにトンネルを堀るために、L2TPv3 Control Connectionは最初に、[RFC3931]で説明されるように確立していなければなりません。 L2TPv3 SCCRQ Control Messageと対応するSCCRP Control Messageは0×0006のHDLC Pseudowire Typeを含まなければなりません(セクション7、「IANA問題」を見てください)、中で定義されるPseudowire Capabilities Listで5.4、.3、[RFC3931]について。 これは、コントロール接続がHDLC Pseudowires(HDLCPWs)をサポートするためにL2TPセッションを確立できると認識します。
An LCCE MUST be able to uniquely identify itself in the SCCRQ and SCCRP messages via a globally unique value. By default, this is advertised via the structured Router ID AVP [RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as well.
LCCE MUST、SCCRQとSCCRPメッセージでグローバルにユニークな値で唯一それ自体を特定できてください。 デフォルトで、構造化されたRouter ID AVP[RFC3931]を通してこれの広告を出します、不統一なHostname AVP[RFC3931]はまた、LCCEsを特定するのに使用されるかもしれませんが。
3. HDLC Link Status Notification and Session Establishment
3. HDLCリンク状態通知とセッション設立
This section specifies how the status of an HDLC interface is reported between two LCCEs, and the associated L2TP session creation and deletion that occurs.
このセクションは起こるHDLCインタフェースの状態が2LCCEsの間でどう報告されるか、そして、関連L2TPセッション作成、および削除を指定します。
3.1. L2TPv3 Session Establishment
3.1. L2TPv3セッション設立
Associating an HDLC serial interface with a PW and its transition to "Ready" or "Up" results in the establishment of an L2TP session via the standard three-way handshake described in Section 3.4.1 of [RFC3931]. For purposes of this discussion, the action of locally associating an interface running HDLC with a PW by local configuration or otherwise is referred to as "provisioning" the HDLC interface. The transition of the interface to "ready" or "up" will be referred to as the interface becoming ACTIVE. The transition of the interface to "not-ready" or "down" will be referred to as the interface becoming INACTIVE.
L2TPセッションの設立で「準備ができる」か“Up"結果へのPWとその変遷にHDLCシリアルインタフェースを標準の3方向ハンドシェイクで関連づけると、セクション3.4では、.1[RFC3931]が説明されました。 この議論の目的のために、そうでなければ、地方の構成で局所的にインタフェース実行HDLCをPWに関連づける動作はHDLCインタフェースが「食糧を供給する」であると呼ばれます。 インタフェースと呼ぶようになる「準備ができる」か“up"のふさわしいACTIVEへのインタフェースの変遷。 インタフェースと呼ぶようになる「準備ができない」か“down"のふさわしいINACTIVEへのインタフェースの変遷。
Pignataro & Townsley Standards Track [Page 3] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[3ページ]RFC4349HDLCフレーム
An LCCE MAY initiate the session immediately upon association with an HDLC interface or wait until the interface becomes ACTIVE before attempting to establish an L2TP session. Waiting until the interface transitions to ACTIVE may be preferred, as it delays allocation of resources until absolutely necessary.
すぐHDLCインタフェースか待ちとの協会のインタフェースがL2TPセッションを確立するのを試みる前にACTIVEになるまでのセッションのLCCE MAY開始。 絶対に必要になるまでリソースの配分を遅らせるとき、インタフェースがACTIVEに移行するまで待つのは好まれるかもしれません。
The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], Attribute Type 68, MUST be present in the ICRQ messages and MUST include the Pseudowire Type of 0x0006 for HDLCPWs.
.4セクション5.4[RFC3931]で定義されたPseudowire Type AVP(Attribute Type68)はICRQメッセージに存在していなければならなくて、HDLCPWsのために0×0006のPseudowire Typeを含まなければなりません。
The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ and ICRP messages and MAY be present in the SLI message for HDLCPWs.
Circuit Status AVP(セクション3.4を見る)はICRQとICRPメッセージに存在していなければならなくて、HDLCPWsへのSLIメッセージに存在しているかもしれません。
Following is an example of the L2TP messages exchanged for an HDLCPW that is initiated after an HDLC interface is provisioned and becomes ACTIVE.
以下に、HDLCインタフェースが食糧を供給されて、ACTIVEになった後に開始されるHDLCPWと交換されたL2TPメッセージに関する例があります。
LCCE (LAC) A LCCE (LAC) B ------------------ ------------------ HDLC Interface Provisioned HDLC Interface Provisioned HDLC Interface ACTIVE
LCCE(ラック)はLCCE(ラック)Bです。------------------ ------------------ HDLCインタフェースの食糧を供給されたHDLCは食糧を供給されたHDLCインタフェース能動態を連結します。
ICRQ (status = 0x03) ---->
ICRQ(状態=0×03)---->。
HDLC Interface ACTIVE
HDLCインタフェースアクティブです。
<---- 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 interface is provisioned and becomes ACTIVE. The Circuit Status AVP indicates that this link is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be present in the ICRQ in order to identify the HDLC link (together with the identity of the LCCE itself as defined in Section 2) with which to associate the L2TP session. 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.
例では、インタフェースが食糧を供給されて、ACTIVEになった後に上に、ICRQを送ります。 Circuit Status AVPは、このリンクがACTIVEとNew(0×03)であることを示します。 Remote End ID AVP[RFC3931]は、L2TPセッションを関連づけるHDLCリンク(セクション2における定義されるとしてのLCCE自身のアイデンティティに伴う)を特定するためにICRQに存在していなければなりません。 [RFC3931]で定義されたRemote End ID AVPは不透明なフォームと可変長のものです、1は両方のLCCEs(ダイレクト構成、またはある他の手段による)において知られている不統一な4八重奏価値の最小のサポート使用のときにそうしなければなりませんが。 このドキュメントの範囲の外にこの値が構成されるか、検索されるか、発見されるか、または別の方法で各LCCEでどう決定するかに関する正確なメソッドがあります。
Pignataro & Townsley Standards Track [Page 4] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[4ページ]RFC4349HDLCフレーム
As with the ICRQ, the ICRP is sent only after the associated HDLC interface transitions to ACTIVE as well. If LCCE B had not been provisioned for the interface identified in the ICRQ, a CDN would have been immediately returned indicating that the associated link 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のように、関連HDLCがまた、ACTIVEへの変遷を連結した後にだけICRPを送ります。 LCCE BがICRQで特定されたインタフェースに食糧を供給されなかったなら、CDNは関連リンクが食糧を供給されなかったのを示しながらすぐに、返すか、またはこのLCCEで利用可能だったでしょうに。 そして、LCCE A SHOULDは周期的な再試行メカニズムを示します。 そうだとすれば、再試行の期間と最大数は構成可能であるに違いありません。
An Implementation MAY send an ICRQ or ICRP before an HDLC interface is ACTIVE, as long as the Circuit Status AVP reflects that the link is INACTIVE and an SLI is sent when the HDLC interface becomes ACTIVE (see Section 3.3).
HDLCインタフェースがACTIVEになる前にImplementationはICRQかICRPを送るかもしれません、Circuit Status AVPが、リンクがINACTIVEであり、HDLCインタフェースがACTIVEになるとき(セクション3.3を見てください)SLIが送られるのを反映する限り。
The ICCN is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic.
ICCNはセッション設立で最終段階です、双方向のトラフィックを許容するために許容できるパラメタがあるICRPの領収書を確認して。
3.2. L2TPv3 Session Teardown
3.2. L2TPv3セッション分解
In the event a link is removed (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でリンクを取り外して(非食糧を供給しました)、.3セクション3.4[RFC3931]で定義されたCDNメッセージで関連L2TPセッションを取りこわさなければなりません。
General Result Codes regarding L2TP session establishment are defined in [RFC3931]. Additional HDLC result codes are defined as follows:
L2TPセッション設立に関するResult Codes司令官は[RFC3931]で定義されます。 追加HDLC結果コードは以下の通り定義されます:
20 - HDLC Link was deleted permanently (no longer provisioned) 21 - HDLC Link has been INACTIVE for an extended period of time
20、--、HDLC Linkが永久に(もう食糧を供給されない)削除された21、--時間の長期間の間、HDLC LinkがINACTIVEである
3.3. L2TPv3 Session Maintenance
3.3. L2TPv3セッションメインテナンス
HDLCPWs over L2TP make use of the Set Link Info (SLI) control message defined in [RFC3931] to signal HDLC link status notifications between PEs. The SLI message is a single message that is sent over the L2TP control channel, signaling the interface state change.
L2TPの上のHDLCPWsはPEsの間のHDLCリンク状態通知に合図するために[RFC3931]で定義されたSet Link Info(SLI)コントロールメッセージを利用します。 SLIメッセージは界面準位変化に合図して、L2TP制御チャンネルの上に送られるただ一つのメッセージです。
The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exceptions to this are the initial ICRQ, ICRP, and CDN messages, which establish and teardown the L2TP session itself. The SLI message may be sent from either PE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup).
Circuit Status AVPで特定されたどんな値の状態変化もある何時でもSLIメッセージを送らなければなりません。 これへの唯一の例外が初期のICRQと、ICRPと、CDNメッセージである、どれ、設立、分解はL2TPセッション自体をそうするか。 最初のICRQを送った(同輩が逆のSession IDルックアップを実行するのが必要であることで、ICRPが恐らく受け取られている前に)後にいつでも、PEからSLIメッセージを送るかもしれません。
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 PEs.
与えられたコントロール接続によって確立されたすべてのセッションがセッションkeepaliveのために[RFC3931]のセクション4.4で定義されたL2TP Hello施設を利用します。 これはPEsの間で基本的な死んでいる同輩と経路検出をすべてのセッションに与えます。
Pignataro & Townsley Standards Track [Page 5] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[5ページ]RFC4349HDLCフレーム
3.4. Use of Circuit Status AVP for HDLC
3.4. 回路状態AVPのHDLCの使用
HDLC reports Circuit Status with the Circuit Status AVP defined in [RFC3931], Attribute Type 71. For reference, this AVP is shown below:
Attribute Type71、Circuit Status AVPが[RFC3931]で定義されている状態で、HDLCはCircuit Statusを報告します。 参照において、この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 when sending, and ignored upon receipt.
Valueは2つの最下位ビットが定義されて、残っているビットが今後の使用のために予約されている16ビットのマスクです。 予約されたビットを発信するとき、0に設定されて、領収書で無視しなければなりません。
The N (New) bit SHOULD be set to one (1) if the Circuit Status indication is for a new HDLC circuit; to zero (0) otherwise.
N(新しい)は1つへのセットが(1)であったなら新しいHDLC回路にCircuit Status指示があるならSHOULDに噛み付きました。 (0) そうでなければ、ゼロに合わせるために。
The A (Active) bit indicates whether the HDLC interface is ACTIVE (1) or INACTIVE (0).
A(アクティブ)のビットは、HDLCインタフェースがACTIVE(1)かそれともINACTIVE(0)であるかを示します。
4. Encapsulation
4. カプセル化
4.1. Data Packet Encapsulation
4.1. データ・パケットカプセル化
HDLCPWs use the default encapsulations defined in [RFC3931] for demultiplexing, sequencing, and flags. The HDLCPW Type over L2TP is intended to operate in an "interface to interface" or "port to port" fashion, passing all HDLC data and control PDUs over the PW. The HDLC PDU is stripped of flags and trailing FCS, bit/byte unstuffing is performed, and the remaining data, including the address, control, and protocol fields, is transported over the PW.
HDLCPWsは逆多重化、配列、および旗のために[RFC3931]で定義されたデフォルトカプセル化を使用します。 L2TPの上のHDLCPW Typeが「連結するインタフェース」か「移植するポート」ファッションで作動することを意図します、すべてのHDLCデータとコントロールPDUsをPWの上に渡して。 旗と引きずっているFCSはHDLC PDUから奪い取られます、そして、ビット/バイト「非-物質」は実行されます、そして、アドレス、コントロール、およびプロトコル分野を含む残っているデータはPWの上で輸送されます。
Since all packets are passed in a largely transparent manner over the HDLCPW, any protocol that has HDLC-like framing may utilize the HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay transport), X.25 (LAPB), etc. In such cases, the negotiations and signaling of the specific protocols transported over the HDLCPW take place between the Remote Systems. A non-exhaustive list of examples and considerations of this transparent nature include:
すべてのパケットがHDLCPWの上の主に見え透いた方法で通過されるので、HDLCのような縁どりを持っているどんなプロトコルもHDLCPWモードを利用するかもしれません、PPP、Frame-リレー(「移植するポート」Frame-リレー輸送)、X.25(LAPB)などを含んでいて そのような場合、HDLCPWの上で輸送された特定のプロトコルの交渉とシグナリングはRemote Systemsの間の場所を取ります。例に関する非完全なりストとこの見え透いた自然の問題は:
o When the HDLCPW transports Point-to-Point Protocol (PPP) traffic, PPP negotiations (Link Control Protocol, optional authentication, and Network Control Protocols) are performed between Remote Systems, and LCCEs do not participate in these negotiations.
o 実行されて、Remote Systems、およびLCCEsは参加しません。HDLCPWがPointからポイントへのプロトコルを輸送する、(PPP) トラフィック、PPP交渉、(Controlプロトコルをリンクしてください、任意の認証、およびNetwork Controlプロトコル、)、これらの交渉に参加してください。
Pignataro & Townsley Standards Track [Page 6] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[6ページ]RFC4349HDLCフレーム
o When the HDLCPW transports Frame-Relay traffic, PVC status management procedures (Local Management Interface) take place between Remote Systems, and LCCEs do not participate in LMI. Additionally, individual Frame-Relay virtual-circuits are not visible to the LCCEs, and the FECN, BECN, and DE bits are transported transparently.
o HDLCPWがFrame-リレートラフィックを輸送するとき、PVC状態管理手順(地方のManagement Interface)はRemote Systemsの間の場所を取ります、そして、LCCEsはLMIに参加しません。 さらに、個々のFrame-リレー仮想の回路はLCCEsに目に見えません、そして、FECN、BECN、およびDEビットは透過的に輸送されます。
o When the HDLCPW transports X.25 (LAPB) traffic, LCCEs do not function as either LAPB DCE or DTE devices.
o HDLCPWがX.25(LAPB)トラフィックを輸送するとき、LCCEsはLAPB DCEかDTEデバイスのどちらかとして機能しません。
On the other hand, exceptions include cases where direct access to the HDLC interface is required, or modes that operate on the flags, FCS, or bit/byte unstuffing that is performed before sending the HDLC PDU over the PW. An example of this is PPP ACCM negotiation.
他方では、例外はHDLCインタフェースへの直接アクセスが必要であるケース、旗を作動させるモード、FCS、またはPWの上にHDLC PDUを送る前に実行されるビット/バイト「非-物質」を含んでいます。 この例はPPP ACCM交渉です。
4.2. Data Packet Sequencing
4.2. データ・パケット配列
Data Packet Sequencing MAY be enabled for HDLCPWs. The sequencing mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for signaling sequencing support. HDLCPWs over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer defined in Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request its presence at all times.
データPacket SequencingはHDLCPWsのために有効にされるかもしれません。 シグナリング配列サポートに.1セクション4.6[RFC3931]で説明された配列メカニズムを使用しなければなりません。 L2TP MUSTの上のHDLCPWsは、L2TPv3 Default L2特有のSublayerの存在が[RFC3931]のセクション4.6でいつも配列がいつ可能にされて、立会いを求めるかもしれないかを定義したよう要求します。
4.3. MTU Considerations
4.3. MTU問題
With L2TPv3 as the tunneling protocol, the packet resulting from the encapsulation is N bytes longer than the HDLC frame without the flags or FCS. The value of N depends on the following fields:
トンネリングプロトコルとしてのL2TPv3と共に、カプセル化から生じるパケットがHDLCフレームよりNバイト長い間、旗もFCSなしであります。 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., using sequencing)
L2TPセッションヘッダー: 旗、Ver、Res4八重奏(UDPだけの上のL2TPv3)セッションID4八重奏Cookie Size0、4、または8八重奏L2特有のSublayer0か4八重奏(すなわち、配列を使用します)
Hence 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-16と等しく、IPの上にL2TPv3データメッセージがあります。 Nは16-28と等しく、UDPの上に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と断片化含意について議論します。
Pignataro & Townsley Standards Track [Page 7] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[7ページ]RFC4349HDLCフレーム
5. Applicability Statement
5. 適用性証明
HDLC Pseudowires support a "port to port" or "interface to interface" deployment model operating in a point-to-point fashion. In addition to the transport of HDLC frames, a natural application of HDLCPWs allows for the transport of any protocol using an HDLC-like framing.
HDLC Pseudowiresは二地点間ファッションで「移植するポート」か「連結するインタフェース」展開モデル操作をサポートします。 HDLCフレームの輸送に加えて、HDLCPWsの自然なアプリケーションは、HDLCのような縁どりを使用することでどんなプロトコルの輸送も考慮します。
The HDLCPW emulation over a packet-switched network (PSN) has the following characteristics in relationship to the native service:
パケット交換網(PSN)の上のHDLCPWエミュレーションには、ネイティブのサービスとの関係における以下の特性があります:
o HDLC data and control fields are transported transparently (see Section 4.1). The specific negotiations and signaling of the protocol being transported are performed between Remote Systems transparently, and the LCCE does not participate in them.
o HDLCデータと制御フィールドは透過的に輸送されます(セクション4.1を見てください)。 輸送されるプロトコルの特定の交渉とシグナリングはRemote Systemsの間で透過的に実行されます、そして、LCCEは彼らに参加しません。
o The trailing FCS (Frame Check Sequence) containing a CRC (Cyclic Redundancy Check) is stripped at the ingress LCCE and not transported over HDLCPWs. It is therefore regenerated at the egress LCCE (see Section 4.1). This means that the FCS may not accurately reflect errors on the end-to-end HDLC link. Errors or corruption introduced in the HDLCPW payload during encapsulation or transit across the packet-switched network may not be detected. This lack of integrity-check transparency may not be of concern if it is known that the inner payloads or upper protocols transported perform their own error and integrity checking. To allow for payload integrity-checking transparency on HDLCPWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can utilize IPSec as specified in Section 4.1.3 of [RFC3931].
o CRC(周期的なRedundancy Check)を含む引きずっているFCS(フレームCheck Sequence)はイングレスLCCEで剥取られて、HDLCPWsの上で輸送されません。 したがって、それは出口LCCEに作り直されます(セクション4.1を見てください)。 これは、FCSが正確に終わりから終わりへのHDLCリンクに誤りを反映しないかもしれないことを意味します。 カプセル化かトランジットの間にパケット交換網の向こう側にHDLCPWペイロードで導入された誤りか不正が検出されないかもしれません。 輸送された内側のペイロードか上側のプロトコルがそれら自身の誤りと保全の照合を実行するのが知られているなら、保全チェック透明のこの不足は重要でないかもしれません。 HDLCPWsでUDP/IPの上でIPかL2TPの上でL2TPを使用することで保全をチェックするペイロード透明を考慮するために、L2TPv3セッションは.3セクション4.1[RFC3931]の指定されるとしてのIPSecを利用できます。
o HDLC link status notification is provided using the Circuit Status AVP in the SLI message (see Section 3.4).
o SLIメッセージでCircuit Status AVPを使用することでHDLCリンク状態通知を提供します(セクション3.4を見てください)。
o The length of the resulting L2TPv3 packet is longer than the encapsulated HDLC frame without flags and FCS (see Section 4.3), with resulting MTU and fragmentation implications discussed in Section 4.1.4 of [RFC3931].
o 結果として起こるL2TPv3パケットの長さがカプセル化されたHDLCフレームより長い間、旗とFCSなしであります(セクション4.3を見てください)、.4セクション4.1[RFC3931]で結果として起こるMTUと断片化含意について議論していて。
o The packet-switched network may reorder, duplicate, or silently drop packets. Sequencing may be enabled in the HDLCPW for some or all packets to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 4.2).
o パケット交換網がそうするかもしれない、追加注文、パケットをコピーするか、または静かに下げてください。 配列は1セッションあたり1個のベースに無くなっているか、写しの、または、故障しているパケットを検出するいくつかかすべてのパケットのためにHDLCPWで可能にされるかもしれません(セクション4.2を見てください)。
o The faithfulness of an HDLCPW may be increased by leveraging Quality of Service features of the LCCEs and the underlying PSN.
o HDLCPWの忠実は、LCCEsと基本的なPSNのServiceの特徴のQualityを利用することによって、増強されるかもしれません。
Pignataro & Townsley Standards Track [Page 8] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[8ページ]RFC4349HDLCフレーム
6. Security Considerations
6. セキュリティ問題
HDLC over L2TPv3 is subject to the security considerations defined in [RFC3931]. Beyond the considerations when carrying other data link types, there are no additional considerations specific to carrying HDLC.
L2TPv3の上のHDLCは[RFC3931]で定義されたセキュリティ問題を受けることがあります。 他のデータリンク型を運ぶとき、問題を超えて、HDLCを運ぶのに特定のどんな追加問題もいません。
7. IANA Considerations
7. IANA問題
7.1. Pseudowire Type
7.1. Pseudowireはタイプします。
The signaling mechanisms defined in this document rely upon the allocation of an HDLC Pseudowire Type (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space created as part of publication of [RFC3931]). The HDLC Pseudowire Type is defined in Section 2 of this specification:
本書では定義されたシグナル伝達機構がHDLC Pseudowire Typeの配分を当てにする、(中で定義されるようにPseudowire Capabilities Listを見てください、5.4、.3、IANA([RFC3931]の公表の一部として作成された数のスペース)による10.6[RFC3931)の[RFC3931]とL2TPv3 Pseudowire Typesについて。 HDLC Pseudowire Typeはこの仕様のセクション2で定義されます:
L2TPv3 Pseudowire Types -----------------------
L2TPv3 Pseudowireはタイプします。-----------------------
0x0006 - HDLC Pseudowire Type
0×0006--HDLC Pseudowireはタイプします。
7.2. Result Code AVP Values
7.2. 結果コードAVP値
This number space is managed by IANA as described in section 2.3 of [BCP0068]. Two new L2TP Result Codes for the CDN message appear in Section 3.2. The following is a summary:
この数のスペースは[BCP0068]のセクション2.3で説明されるようにIANAによって管理されます。 CDNメッセージのための2新しいL2TP Result Codesがセクション3.2に現れます。 ↓これは概要です:
Result Code AVP (Attribute Type 1) Values -----------------------------------------
結果コードAVP(属性タイプ1)値-----------------------------------------
20 - HDLC Link was deleted permanently (no longer provisioned) 21 - HDLC Link has been INACTIVE for an extended period of time
20、--、HDLC Linkが永久に(もう食糧を供給されない)削除された21、--時間の長期間の間、HDLC LinkがINACTIVEである
8. Acknowledgements
8. 承認
Thanks to Sudhir Rustogi and George Wilkie for valuable input. Maria Alice Dos Santos provided helpful review and comment. Many thanks to Mark Lewis for providing review and clarifying comments during IETF Last Call.
貴重な入力をSudhir Rustogiとジョージ・ウィルキーをありがとうございます。 マリア・アリス・ドス・サントスは役立っているレビューとコメントを提供しました。 レビューを提供して、IETF Last Callの間、コメントをマーク・ルイスにはっきりさせてくださいといってくださってありがとうございますこと。
Pignataro & Townsley Standards Track [Page 9] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[9ページ]RFC4349HDLCフレーム
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月。
9.2. Informative References
9.2. 有益な参照
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
w.[BCP0068]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
Authors' Addresses
作者のアドレス
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
7025年のカルロスPignataroシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709
EMail: cpignata@cisco.com
メール: cpignata@cisco.com
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
Pignataro & Townsley Standards Track [Page 10] RFC 4349 HDLC Frames over L2TPv3 February 2006
L2TPv3 February 2006の上のPignataro&Townsley標準化過程[10ページ]RFC4349HDLCフレーム
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)によって提供されます。
Pignataro & Townsley Standards Track [Page 11]
Pignataro&Townsley標準化過程[11ページ]
一覧
スポンサーリンク