RFC4720 日本語訳
4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check SequenceRetention. A. Malis, D. Allan, N. Del Regno. November 2006. (Format: TXT=18248 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Malis Request for Comments: 4720 Tellabs Category: Standards Track D. Allan Nortel Networks N. Del Regno MCI November 2006
Malisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4720年のTellabsカテゴリ: 規格はN.デルRegno MCI2006年11月にD.アランノーテルネットワークを追跡します。
Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
Pseudowireのエミュレーションの縁から縁(PWE3)へのフレームチェックシーケンス保有
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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires.
このドキュメントは、イーサネット、Frame Relay、High-レベルData Link Control(HDLC)、およびPPP pseudowiresを通してFrame Check Sequence(FCS)を保存するためにメカニズムを定義します。
Table of Contents
目次
1. Overview ........................................................1 2. Specification of Requirements ...................................3 3. Signaling FCS Retention with MPLS-Based Pseudowires .............3 4. Signaling FCS Retention with L2TPv3-Based Pseudowires ...........4 5. Security Considerations .........................................5 6. Applicability Statement .........................................5 7. IANA Considerations .............................................6 8. Acknowledgement .................................................6 9. Normative References ............................................6
1. 概観…1 2. 要件の仕様…3 3. MPLSベースのPseudowiresとのシグナリングFCS保有…3 4. L2TPv3ベースのPseudowiresとのシグナリングFCS保有…4 5. セキュリティ問題…5 6. 適用性声明…5 7. IANA問題…6 8. 承認…6 9. 標準の参照…6
Malis, et al. Standards Track [Page 1] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[1ページ]。
1. Overview
1. 概観
The specifications for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode of use whereby frames are transparently delivered across the pseudowire without any header or other alterations by the pseudowire ingress or egress Provider Edge (PE). (Note that this mode is inherent for HDLC and PPP Pseudowires.)
イーサネット、Frame Relay、HDLC、およびPPP pseudowireカプセル化[1][2][3][9][10][11]のための仕様はフレームがpseudowireの向こう側にpseudowireイングレスによって少しもヘッダーや他の変更なしで透明に届けられる使用か出口Provider Edge(PE)のモードを含んでいます。 (HDLCとPPP Pseudowiresに、このモードが固有であることに注意してください。)
However, these specifications all specify that the original Frame Check Sequence (FCS) be removed at ingress and regenerated at egress, which means that the frames may be subject to unintentional alteration during their traversal of the pseudowire from the ingress to the egress PE. Thus, the pseudowire cannot absolutely be guaranteed to be "transparent" in nature.
しかしながら、これらの仕様はすべて、オリジナルのFrame Check Sequence(FCS)がイングレスで取り外されて、出口で作り直されると指定します。(出口はフレームが彼らのpseudowireのイングレスから出口PEまでの縦断の間意図的でない変更を受けることがあるかもしれないことを意味します)。 したがって、現実に「透明に」なるようにpseudowireを絶対に保証できません。
To be more precise, pseudowires, as currently defined, leave the payload vulnerable to unintended modification occurring while transiting the encapsulating network. Not only can a PW-aware device internally corrupt an encapsulated payload, but ANY LSR or router in the path can corrupt the encapsulated payload. In the event of such corruption, there is no way to detect the corruption through the path of the pseudowire. Further, because the FCS is calculated upon network egress, any corruption will pass transparently through ALL Layer 2 switches (Ethernet and Frame Relay) through which the packets travel. Only at the endpoint, assuming that the corrupted packet even reaches the correct endpoint, can the packet be discarded, and depending on the contents of the packet, the corruption may not ever be detected.
より正確に、なるように、現在定義されているとして、pseudowiresは、故意でない変更に傷つきやすいペイロードが要約ネットワークを通過している間、現れているままにします。 PW意識している装置が要約のペイロードを内部的に崩壊させることができるだけではなく、経路のANY LSRかルータが要約のペイロードを崩壊させることができます。 そのような不正の場合、pseudowireの経路を通した不正を検出する方法が全くありません。 さらに、FCSがネットワーク出口で計算されるので、どんな不正も透明に、パケットが移動するすべてのLayer2スイッチ(イーサネットとFrame Relay)を通り抜けるでしょう。 終点だけでは、崩壊したパケットが正しい終点に達しさえすると仮定する場合、パケットを捨てることができます、そして、パケットのコンテンツによって、不正がかつて、検出されないかもしれません。
Not only does the encapsulation technique leave the payload unprotected, it also subverts the error checking mechanisms already in place in SP and customer networks by calculating FCS on questionable data.
また、カプセル化技術はペイロードを保護がない状態でおくだけではなく、それが疑わしいデータで適所で計算のFCSでSPと顧客ネットワークで既にメカニズムをチェックする誤りを打倒します。
In a perfect network comprising perfect equipment, this is not an issue. However, as there is no such thing, it is an issue. SPs should have the option of saving overhead by yielding the ability to detect faults. Equally, SPs should have the option to sacrifice the overhead of carrying the original FCS end-to-end to ensure the ability to detect faults in the encapsulating network.
完全な設備を包括する完全なネットワークでは、これは問題ではありません。 しかしながら、どんなそのようなものもないとき、それは問題です。 SPsには、欠点を検出する能力をもたらすことによってオーバーヘッドを節約するオプションがあるはずです。 等しく、SPsには、要約ネットワークで欠点を検出する能力を確実にするために元のFCSの終わりからエンドを運ぶオーバーヘッドを犠牲にするオプションがあるはずです。
This document defines such a mechanism to allow the ingress PE to retain the original frame FCS on ingress to the network, and it relieves the egress PE of the task of regenerating the FCS.
このドキュメントはイングレスPEがイングレスでオリジナルのフレームFCSをネットワークに保有するのを許容するためにそのようなメカニズムを定義します、そして、それはFCSを作り直すタスクを出口PEに取り除きます。
Malis, et al. Standards Track [Page 2] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[2ページ]。
This is an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that do not implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3].
これはpseudowire実現のためのOPTIONALメカニズムです。 このドキュメントを実行しないシステムがある相互運用性のために、デフォルトの振舞いはFCSがイングレスPEで取り外されて、出口PEに作り直されるということです、[1]、[2]、および[3]で指定されるように。
This capability may be used only with Ethernet pseudowires that use "raw mode" [1], Frame Relay pseudowires that use "port mode" [2] [3], and HDLC and PPP pseudowires [3].
この能力は「生のモード」[1]を使用するイーサネットpseudowires、「ポートモード」[2][3]を使用するFrame Relay pseudowires、HDLC、およびPPP pseudowires[3]だけと共に使用されるかもしれません。
Note that this mechanism is not intended to carry errored frames through the pseudowire; as usual, the FCS MUST be examined at the ingress PE, and errored frames MUST be discarded. The FCS MAY also be examined by the egress PE; if this is done, errored frames MUST be discarded. The egress PE MAY also wish to generate an alarm or count the number of errored frames.
このメカニズムが運ぶことを意図しないというメモはpseudowireを通してフレームをerroredしました。 FCS MUSTはいつものように、イングレスPEで調べられて、フレームをerroredしました。捨てなければなりません。 FCS MAY、また、出口PEが調べられてください。 これが完了しているなら、erroredフレームを捨てなければなりません。 出口PE MAYはアラームを発生させたいか、またはまた、erroredフレームの数を数えたがっています。
2. Specification of Requirements
2. 要件の仕様
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 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
3. Signaling FCS Retention with MPLS-Based Pseudowires
3. MPLSベースのPseudowiresとのシグナリングFCS保有
When using the signaling procedures in [4], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the desire to retain the FCS when advertising a VC label [5]:
[4]でシグナリング手順を用いるとき、VCラベル[5]の広告を出すときFCSを保有する願望に合図するのに使用されるPseudowire Interface Parameter Sub-TLVタイプがあります:
Parameter Length Description 0x0A 4 FCS Retention Indicator
パラメタ長さの記述0x0A4FCS保有インディケータ
The presence of this parameter indicates that the egress PE requests that the ingress PE retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter is not present in the VC FEC element.
このパラメタの存在は、出口PEが、イングレスPEが広告に掲載されているVCラベルのためのFCSを保有するよう要求するのを示します。 それは、イングレスPEがFCSを保有するのを義務付けません。 それは単にイングレスPE MAYがFCSを保有するという指示です。 このパラメタがVC FEC要素に存在していないなら、送付者はFCSを保有してはいけません。
The parameter includes a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this parameter allows the PEs to ensure that the FCS is only retained when it makes sense.
パラメタは16ビットのFCS長さの分野を含んでいます。(それは、保有されるオリジナルのFCSの長さを示します)。 イーサネットpseudowiresにおいて、この長さは4にいつも設定されるでしょう。 HDLC、PPP、およびFrame Relay pseudowiresにおいて、この長さは2か4に設定されるでしょう。 これらのインタフェースのFCSの長さがローカル設定であるので、FCSの長さがpseudowireの両端で同じである場合にだけ、FCSを保有するのは理解できます。 このパラメタにFCSの長さを含んでいるのに、PEsは、理解できるときだけ、FCSが保有されるのを保証できます。
Malis, et al. Standards Track [Page 3] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[3ページ]。
Since unknown parameters are silently ignored [4], backward compatibility with systems that do not implement this document is provided by requiring that the FCS be retained ONLY if the FCS Retention Indicator with an identical setting for the FCS length has been included in the advertisements for both directions on a pseudowire.
[4] 未知のパラメタが静かに無視されるので、FCSの長さのための同じ設定があるFCS Retention Indicatorが広告に含まれるだけであったならFCSが保有されるのを必要とすることによって、pseudowireでこのドキュメントを実行しないシステムとの後方の互換性を両方の方向に提供します。
If the ingress PE recognizes the FCS Retention Indicator parameter but does not wish to retain the FCS with the indicated length, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction.
イングレスPEがFCS Retention Indicatorパラメタを認識しますが、示された長さがあるFCSを保有したくないなら、FCS Retention Indicatorを含んでいなくて、それは逆方向へのそれ自身のラベルマッピングメッセージを発行するだけでよいです。 これはどちらの方向にもFCS保有を防ぐでしょう。
If PWE3 signaling [4] is not in use for a pseudowire, then whether the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behavior is to remove the FCS.
pseudowireには、PWE3シグナリング[4]が使用中でないなら、同様にpseudowire終点の両方のPEsでFCSが保有されることになっているかどうか食糧を供給しなければなりません。 このオプションのサポートに食糧を供給してはいけなければ、デフォルトの振舞いはFCSを取り外すことです。
4. Signaling FCS Retention with L2TPv3-Based Pseudowires
4. L2TPv3ベースのPseudowiresとのシグナリングFCS保有
This section uses the following terms as defined in [7]:
このセクションは[7]で定義されるように次の用語を使用します:
Incoming-Call-Request (ICRQ) Incoming-Call-Reply (ICRP) Incoming-Call-Connected (ICCN) Attribute Value Pair (AVP) L2TP Control Connection Endpoint (LCCE)
入って来る発呼要求(ICRQ)の入って来る呼び出し回答(ICRP)の入って来る接続完了(ICCN)属性値組(AVP)L2TPコントロール接続終点(LCCE)
When using the signaling procedures in [7], the FCS Retention AVP, Attribute Type 92, is used.
[7]でシグナリング手順を用いるとき、FCS Retention AVP(Attribute Type92)は使用されています。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCSの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FCS Length is a 2-octet unsigned integer.
FCS Lengthは2八重奏の符号のない整数です。
The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) requests that its peer retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention AVP as an acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is always bidirectional; thus, FCS is only
ICRQかICRPメッセージでのこのAVPの存在は、LCCE(PE)が、同輩が確立されるL2TPセッションのためにFCSを保有するよう要求するのを示します。 受信LCCEがAVPを認識して、FCS保有要求に応じるなら、それは承認として対応するICRPかICCNメッセージにFCS Retention AVPを含まなければなりません。 FCS Retentionはいつも双方向です。 したがって、FCSがそうである、唯一
Malis, et al. Standards Track [Page 4] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[4ページ]。
retained if both LCCEs send an FCS Retention AVP during session establishment.
両方のLCCEsがセッション設立の間、FCS Retention AVPを送るなら、保有されます。
The Attribute Value is a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this AVP allows the PEs to ensure that the FCS is only retained when doing so makes sense.
Attribute Valueは16ビットのFCS長さの分野です。(その分野は保有されるオリジナルのFCSの長さを示します)。 イーサネットpseudowiresにおいて、この長さは4にいつも設定されるでしょう。 HDLC、PPP、およびFrame Relay pseudowiresにおいて、この長さは2か4に設定されるでしょう。 これらのインタフェースのFCSの長さがローカル設定であるので、FCSの長さがpseudowireの両端で同じである場合にだけ、FCSを保有するのは理解できます。 このAVPの長さがそうするときだけ、FCSが保有されるのを保証するのをPEsを許容するFCSを含んでいるのは理解できます。
The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).
このAVPのLengthは8歳です。 0へのセットが(ゼロ)であったならこのAVP MUSTのために噛み付かれたM。 このAVP MAY、隠されてください(Hビットは、1か0であるかもしれません)。
5. Security Considerations
5. セキュリティ問題
This mechanism enhances the data integrity of transparent Ethernet, Frame Relay, and HDLC pseudowires, because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, it is clear that the payload was not altered during its transmission through the network (or at least to the accuracy of the original FCS; but that is demonstrably better than no FCS at all).
このメカニズムが透明のデータ保全を高める、イーサネット、Frame Relay、HDLC pseudowiresは、Customer Edge(CE)で、オリジナルのFCSで、発生しているので、カプセル化に含まれています。 要約のペイロードが目的地CEでチェックするFCSを渡すとき、ペイロードがネットワークを通したトランスミッションの間変更されなかったのは(少なくともオリジナルのFCSの精度に; それだけが全くどんなFCSよりも論証できて良いというわけではありません)、明確です。
Of course, nothing comes for free; this requires the additional overhead of carrying the original FCS (in general, either two or four octets per payload packet).
もちろん、何もただで来ません。 これはオリジナルのFCS(一般にと、ペイロードパケットあたり2か4つの八重奏)を運ぶ追加オーバーヘッドを必要とします。
This signaling is backward compatible and interoperable with systems that do not implement this document.
このシグナリングはこのドキュメントを実行しないシステムで互換性があって共同利用できた状態で後方です。
6. Applicability Statement
6. 適用性証明
In general, this document is intended to further extend the applicability of the services defined by [1], [2], and [3] to make them more suitable for use in deployments where data integrity is an issue (or at least is as much of an issue as in the original services that defined the FCS usage in the first place). There are some situations where this extension is not necessary, such as where the inner payloads have their own error-checking capabilities (such as TCP). But for inner payloads that do rely on the error-detecting capabilities of the link layer (such as SNA), this additional protection can be invaluable.
一般に、このドキュメントがさらに[1]、[2]、および[3]によって定義された、データ保全が問題(または、少なくとも第一にFCS用法を定義したオリジナルのサービスと同じくらい多くの問題である)であるところでそれらを展開における使用により適するようにしたサービスの適用性を広げることを意図します。 いくつかの状況がこの拡大は必要でないところにあります、内側のペイロードにはそれら自身の誤りをチェックしている機能(TCPなどの)があるところのように。 しかし、リンクレイヤ(SNAなどの)の誤りを検出する能力を当てにする内側のペイロードにおいて、この追加保護は非常に貴重である場合があります。
Malis, et al. Standards Track [Page 5] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[5ページ]。
When pseudowires are being used to connect 802.1 bridges, this document allows pseudowires to comply with the requirement that all media interconnecting 802.1 bridges have (at least) 32-bit FCS protection.
pseudowiresが802.1の橋を接続するのに使用されているとき、このドキュメントで、pseudowiresは802.1の橋とインタコネクトするすべてのメディアが32ビットのFCS保護を持っているという(少なくとも)要件に従うことができます。
Note that this document is one possible alternative for a service provider to enhance the end-to-end data integrity of pseudowires. Other mechanisms may include the use of end-to-end IPsec between the PEs, or internal mechanisms in the P routers to ensure the integrity of packets as they are switched between ingress and egress interfaces. Service providers may wish to compare the relative strengths of each approach when planning their pseudowire deployments; however, an argument can be made that it may be wasteful for an SP to use an end-to-end integrity mechanism that is STRONGER than the FCS generated by the source CE and checked by the destination CE.
このドキュメントが1つの可能な選択肢であることに注意して、サービスプロバイダーは終わりから終わりへのpseudowiresのデータ保全を高めてください。 他のメカニズムは、それらがイングレスと出口のインタフェースの間に切り換えられるときパケットの保全を確実にするためにPEsの間の終わりから終わりへのIPsec、またはPルータにおける内部のメカニズムの使用を含むかもしれません。 彼らのpseudowire展開を計画しているとき、サービスプロバイダーはそれぞれのアプローチの相対的な強さを比較したがっているかもしれません。 しかしながら、SPが終わりから終わりへの保全STRONGERであるメカニズムを使用するのが、ソースCEによって発生して、目的地CEによってチェックされたFCSより無駄であるかもしれないという主張をすることができます。
7. IANA Considerations
7. IANA問題
This document does not specify any new registries for IANA to maintain.
このドキュメントはIANAが維持するどんな新しい登録も指定しません。
Note that [5] allocates the FCS Retention Indicator interface parameter; therefore, no further IANA action is required.
[5]がFCS Retention Indicatorインタフェース・パラメータを割り当てることに注意してください。 したがって、さらなるIANA動作は全く必要ではありません。
IANA assigned one value within the L2TP "Control Message Attribute Value Pairs" section as per [8]. The new AVP is 92 and is referred to in the IANA L2TP parameters registry as "FCS Retention".
IANAは[8]に従ってL2TP「コントロールメッセージ属性値ペア」セクションの中の1つの値を割り当てました。 新しいAVPは92であり、IANA L2TPパラメタ登録に「FCS保有」と呼ばれます。
8. Acknowledgement
8. 承認
The authors would like to thank Mark Townsley for the text in Section 4.
作者はセクション4のテキストについてマークTownsleyに感謝したがっています。
9. Normative References
9. 引用規格
[1] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[1] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、およびG.サギ、「MPLSネットワークの上のイーサネットの輸送のためのカプセル化方法」、RFC4448(2006年4月)。
[2] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[2] マティーニ、L.(エド)、Kawa、C.(エド)、およびA.Malis(エド)、「Multiprotocolの上のフレームリレーの輸送のためのカプセル化方法は切り換え(MPLS)をネットワークとラベルします」、RFC4619、2006年9月。
Malis, et al. Standards Track [Page 6] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[6ページ]。
[3] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[3]マティーニ、L.、ローゼン、E.、サギ、G.、およびA.Malis、「MPLSネットワークの上のppp/ハイレベル・データ・リンク制御手順(HDLC)の輸送のためのカプセル化方法」、RFC4618(2006年9月)。
[4] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[4] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[5] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[5] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[7] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[8] w.Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[9] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
[9] Aggarwal、R.、Townsley、M.、およびM.ドス・サントス、「イーサネットの輸送はプロトコルバージョン3(L2TPv3)にトンネルを堀りながら、層2の上で縁どっています」、RFC4719、2006年11月。
[10] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4591, August 2006.
[10]Townsley、M.、ウィルキー、G.、ブース、S.、ブライアント、S.、およびJ.ラウ、「層2のトンネリングプロトコルバージョン3の上のフレームリレー(L2TPv3)」、RFC4591(2006年8月)。
[11] Pignataro, C. and M. Townsley, "High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)", RFC 4349, February 2006.
C.とM.Townsley、[11]はPignataroします、「層2の上のハイレベル・データ・リンク制御手順(HDLC)フレームはプロトコル、バージョン3(L2TPv3)にトンネルを堀っ」て、RFC4349、2006年2月。
Malis, et al. Standards Track [Page 7] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[7ページ]。
Authors' Addresses
作者のアドレス
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134
サンノゼ、アンドリューG.Malis Tellabs90リオロブレスカリフォルニア博士 95134
EMail: Andy.Malis@tellabs.com
メール: Andy.Malis@tellabs.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
デヴィッドアランノーテルは3500縦梁Aveをネットワークでつなぎます。 オタワ、オンタリオ(カナダ)
EMail: dallan@nortel.com
メール: dallan@nortel.com
Nick Del Regno MCI 400 International Parkway Richardson, TX 75081
国際パークウェイのリチャードソン、ニックデルRegno MCI400テキサス 75081
EMail: nick.delregno@mci.com
メール: nick.delregno@mci.com
Malis, et al. Standards Track [Page 8] RFC 4720 PWE3 Frame Check Sequence Retention November 2006
Malis、他 規格はPWE3フレームチェックシーケンス保有2006年11月にRFC4720を追跡します[8ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Malis, et al. Standards Track [Page 9]
Malis、他 標準化過程[9ページ]
一覧
スポンサーリンク