組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：prince1680（prince1680  prince1680@163.com）
譯文發(fā)布時間：2001-5-24
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。


Network Working Group                                           V. Rawat
Request for Comments: 3070                             ONI Systems, Inc.
Category: Standards Track                                         R. Tio
                                                                S. Nanji
                                                  Redback Networks, Inc.
                                                                R. Verma
                                                     Deloitte Consulting
February 2001



基于幀中繼的第二層隧道協(xié)議
（RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay）

本備忘錄的狀態(tài)

   本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建
議以得到改進(jìn)。請參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)” (STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。

版權(quán)聲明

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

概要

   二層隧道協(xié)議 (L2TP) 描述了點到點會話的機制，該協(xié)議已被設(shè)計為獨立于其運行的媒
體，基本規(guī)范描述了它怎樣運于在用戶數(shù)據(jù)報 (UDP) 和網(wǎng)際協(xié)議 (IP) 之上的實現(xiàn)。本文檔
描述了 L2TP 怎樣運行在幀中繼永久虛電路 (PVCs) 和交換虛電路 (SVCs) 之上的。

適用性

   本規(guī)范的目的是實現(xiàn) L2TP 所定義的易用工具，且僅供幀中繼點到點電路使用。

1.0 介紹

   L2TP [1] 定義了在各種媒體之上實現(xiàn) PPP 隧道的常規(guī)目的的機制。按照設(shè)計，它使 L2TP 
操作與要操作媒體的詳細(xì)細(xì)節(jié)分隔開來?；緟f(xié)議規(guī)范闡明了 L2TP 在 IP 環(huán)境下如何使用
的方法。該文檔說明了基于原始幀中繼和地址有關(guān)問題的封裝。

2.0 約定

   本文檔中所用的關(guān)鍵字 "MUST"，"MUST NOT"，"REQUIRED"，"SHALL"，"SHALL NOT"，
"SHOULD"，"SHOULD NOT"，"RECOMMENDED"，"MAY" 和 "OPTIONAL" 已在 RFC 2119 [2] 中闡
明。

3.0 問題空間回顧

   本節(jié)我們將從問題的高層來描述。拓?fù)鋱D：
         +------+           +---------------+          |
         | PSTN |           |               |          |
   用戶--|      |----LAC ===|    幀中繼云   |=== LNS --+ LANs
         | ISDN |           |               |          |
         +------+           +---------------+          |

   L2TP 訪問集中器 (LAC) 是附加在交換網(wǎng)絡(luò)結(jié)構(gòu)上 (例如 PSTN 和 ISDN) 或處于可以處
理 L2TP 協(xié)議的 PPP 端系統(tǒng)上的一個設(shè)備。LAC 只需提供將 L2TP 在一個或多個網(wǎng)絡(luò)間傳送
的媒體實現(xiàn)，它可以為 PPP 中攜帶的任何協(xié)議提供隧道。

   L2TP 網(wǎng)絡(luò)服務(wù)器 (LNS) 可以在任何能夠?qū)崿F(xiàn) PPP 終結(jié)的平臺上操作。LNS 處理 L2TP 
的服務(wù)器端協(xié)議，L2TP 具有連接導(dǎo)向。LNS 和 LAC 維護接入到 LAC 的每個用戶的狀態(tài)。當(dāng)
一個用戶與 LNS 之間試圖建立一個端到端的 PPP 連接時，將建立一個對話。基于該對話的
數(shù)據(jù)流交通過 LAC 和 LNS 間的隧道發(fā)送。隧道是由一個 LNS-LAC 對定義的。 隧道在LAC 
和 LNS 間傳送 PPP 數(shù)據(jù)流。

   L2TP 協(xié)議是在攜帶它的特定媒體的上層操作的。然而，到媒體連接的某些細(xì)節(jié)需要能夠
允許共同實現(xiàn)?；?IP/UDP 的L2TP 已在基本 L2TP 規(guī)范 [1] 中描述。有關(guān)基于幀中繼的 
L2TP 問題將在本文檔稍后的章節(jié)中再討論。

4.0 封裝和包的格式

   L2TP 必須（MUST）能夠與其他協(xié)議共享同一個幀中繼虛電路 (VC)。數(shù)據(jù)包的幀中繼頭格
式需要進(jìn)行定義以標(biāo)識包中所攜帶的協(xié)議。幀中繼網(wǎng)絡(luò)可以不明白這些格式。

   所有通過該電路的協(xié)議必須（MUST）將它們的包封裝進(jìn) Q.922 幀中。幀必須另外包含必
需的信息，以標(biāo)識在幀中繼協(xié)議數(shù)據(jù)單元 (PDU) 中所攜帶的協(xié)議，這樣才可使接收方正確處
理接收的包。

   L2TP 的幀必須（MUST）是在 RFC 1490 [6] and FRF3.1 [3] 中定義的 SNAP 封裝。SNAP 
格式使用后跟組織唯一標(biāo)識符和 PID 的 NLPID。

   NLPID

   該單字節(jié)的標(biāo)識符提供了一種機制，可以對協(xié)議進(jìn)行簡單標(biāo)識。在 SNAP 頭中使用 0x80 
值來表示 L2TP NLPID。

   OUI & PID

   三字節(jié)的組織唯一標(biāo)識符 (OUI) 0x00-00-5E 用來標(biāo)識 IANA，IANA 用來管理協(xié)議標(biāo)識符 
(PID) 0x0007。它們共同標(biāo)識出特定的協(xié)議。

   封裝在幀中繼中的 L2TP 幀格式如圖 1 所示。

          八進(jìn)制                      1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            1   |         Q.922 Address         |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            3   | Control  0x03 | pad   0       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            5   | NLPID 0x80    |  OUI  0x00    |
                +-+-+-+-+-+-+-+-+               +
            7   | OUI     0x00-5E               |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            9   | PID     0x0007                |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                               |
                |          L2TP packet          |
                |                               |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |              FCS              |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           圖 1  封裝在幀中繼中的 L2TP 幀格式


5.0 MTU 考慮

   FRF.12 [5] 是幀中繼分段實現(xiàn)協(xié)議。如果不支持分段，兩個幀中繼端點必須（MUST）支
持不小于 1526 的 MTU，它的大小應(yīng)該是 PPP 最大接收單元 (Max-Receive-Unit)的大小加
上 PPP 頭大小加上 L2TP 最大的頭的大小加上幀中繼頭的大小 (PPP 頭的大小是協(xié)議字段
大小加上 L2TP 所要求的 HDLC 幀字節(jié)數(shù))。為避免包在幀中繼接口上被丟棄，在 PPP 缺省 
MRU 為 1500 的情況下，推薦（RECOMMENDED）的缺省幀中繼 MTU 為 1564，意思是要確保實
現(xiàn)這些 MTU 設(shè)置。

6.0 QOS 問題

   通常，QoS 機制用來粗略提供 LAC 和 LNS 之間局部的私有機制。QoS 的考慮不在本文檔
的范圍之內(nèi)。

7.0 幀中繼和 L2TP 的交互性

   在幀中繼 SVC 的情況下，當(dāng) L2TP 試圖建立隧道時，將會觸發(fā)連接的建立。詳細(xì)的觸發(fā)
機制將留待以后實現(xiàn)。在 L2TP 發(fā)出信號時，幀中繼 SVC 不應(yīng)當(dāng)（SHALL NOT）有任何變化。
在幀中繼 SVC 的情況下，L2TP 隧道的終點必須（MUST）由 X.121/E.164 的地址來指明。這
些地址可能包含在 [4] 中定義的一個用戶隧道終點中。在 PVC 下, 攜帶 L2TP 的虛電路流
量可以進(jìn)行管理配置。隧道的終點必須由 DLCI 標(biāo)識， DLCI 是在配置時指定給 PVC 的。DLCI 
可以作為在 [4] 中定義的用戶隧道終點包含進(jìn)來。

   在 PPP 和幀中繼之間應(yīng)當(dāng)不存在幀的問題。從遠(yuǎn)端用戶由 LAC 接收到的 PPP 幀去掉 
CRC，鏈接幀和透明字節(jié)，封裝進(jìn) L2TP，并通過幀中繼隧道傳送出去。

8.0 安全考慮

   盡管幀中繼論壇正在討論幀中繼秘密協(xié)定，當(dāng)前還沒有幀中繼安全標(biāo)準(zhǔn)規(guī)范。依照這項工
作，稍后的一段時間要檢查安全性，檢查基于幀中繼的 L2TP 規(guī)范 [1] 是否仍需要保護機制。
在過渡期內(nèi)，將在基本 L2TP 規(guī)范中討論基本的安全性。

9.0 致謝

   感謝 Ken Pierce (3Com 公司) 和 Rick Dynarski (3Com 公司) 對本文檔的編輯工作。

10.0 參考資料

   [1]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661,
        August 1999.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 ,
        Frame Relay Forum Technical Committee, June 1995.

   [4]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
        I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
        2868, June 2000.

   [5]  Frame Relay Fragmentation Implementation Agreement, FRF.12,
        Frame Relay Forum Technical Committee, December 1997.

   [6]  Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect
        over Frame Relay", RFC 1490, July 1993.

11.0 作者地址

   Vipin Rawat
   ONI Systems, Inc.
   166 Baypointe Parkway
   San Jose CA 95134

   EMail: vrawat@oni.com


   Rene Tio
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134

   EMail: tor@redback.com


   Rohit Verma
   Deloitte Consulting
   180 N. Stetson Avenue
   Chicago Illinois 60601

   EMail: rverma@dc.com


   Suhail Nanji
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134

   EMail: suhail@redback.com

12.0  完整的版權(quán)聲明

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to others, and 
derivative works that comment on or otherwise explain it or assist in its 
implementation may be prepared, copied, published and distributed, in whole or in 
part, without restriction of any kind, provided that the above copyright notice and 
this paragraph are included on all such copies and derivative works.  However, this 
document itself may not be modified in any way, such as by removing the copyright 
notice or references to the Internet Society or other Internet organizations, except 
as needed for the purpose of developing Internet standards in which case the 
procedures for copyrights defined in the Internet Standards process must be followed, 
or as required to ranslate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked by 
the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS" basis 
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

感謝

   Funding for the RFC Editor function is currently provided by the Internet Society.
RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay    基于幀中繼的第二層隧道協(xié)


1
RFC文檔中文翻譯計劃