分享
 
 
 

RFC3070 - Layer Two Tunneling Protocol (L2TP) over Frame Relay

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

Layer Two Tunneling Protocol (L2TP) over Frame Relay

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.

Copyright Notice

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

Abstract

Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel

Point-to-Point (PPP) sessions. The protocol has been designed to be

independent of the media it runs over. The base specification

describes how it should be implemented to run over the User Datagram

Protocol (UDP) and the Internet Protocol (IP). This document

describes how L2TP is implemented over Frame Relay Permanent Virtual

Circuits (PVCs) and Switched Virtual Circuits (SVCs).

Applicability

This specification is intended for those implementations which desire

to use facilities which are defined for L2TP and applies only to the

use of Frame Relay pont-to-point circuits.

1.0 IntrodUCtion

L2TP [1] defines a general purpose mechanism for tunneling PPP over

various media. By design, it insulates L2TP operation from the

details of the media over which it operates. The base protocol

specification illustrates how L2TP may be used in IP environments.

This document specifies the encapsulation of L2TP over native Frame

Relay and addresses relevant issues.

2.0 Conventions

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 [2].

3.0 Problem Space Overview

In this section we describe in high level terms the scope of the

problem being addressed. Topology:

+------+ +---------------+

PSTN Frame Relay

User-- ----LAC === === LNS --+ LANs

ISDN Cloud

+------+ +---------------+

An L2TP Access Concentrator (LAC) is a device attached to the

switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP

end system capable of handling the L2TP protocol. The LAC need only

implement the media over which L2TP is to operate to pass traffic to

one or more LNS's. It may tunnel any protocol carried within PPP.

L2TP Network Server (LNS) operates on any platform capable of PPP

termination. The LNS handles the server side of the L2TP protocol.

L2TP is connection-oriented. The LNS and LAC maintain state for each

user that is attached to an LAC. A session is created when an end-

to-end PPP connection is attempted between a user and the LNS. The

datagrams related to a session are sent over the tunnel between the

LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel

carries PPP datagrams between the LAC and the LNS.

L2TP protocol operates at a level above the particular media over

which it is carried. However, some details of its connection to

media are required to permit interoperable implementations. L2TP

over IP/UDP is described in the base L2TP specification [1]. Issues

related to L2TP over Frame Relay are addressed in later sections of

this document.

4.0 Encapsulation and Packet Format

L2TP MUST be able to share a Frame Relay virtual circuit (VC) with

other protocols carried over the same VC. The Frame Relay header

format for data packet needs to be defined to identify the protocol

being carried in the packets. The Frame Relay network may not

understand these formats.

All protocols over this circuit MUST encapsulate their packets within

a Q.922 frame. Additionally, frames must contain information

necessary to identify the protocol carried within the frame relay

Protocol Data Unit (PDU), thus allowing the receiver to properly

process the incoming packet.

The frame format for L2TP MUST be SNAP encapsulation as defined in

RFC1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed by

Organizationally Unique Identifier and a PID.

NLPID

The single octet identifier provides a mechanism to allow easy

protocol identification. For L2TP NLPID value 0x80 is used which

indicates the presence of SNAP header.

OUI & PID

The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E

identifies IANA who administers the meaning of the Protocol

Identifier (PID) 0x0007. Together they identify a distinct protocol.

Format of L2TP frames encapsulated in Frame Relay is given in Figure

1.

Octet 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 Format for L2TP frames encapsulated in

Frame Relay

5.0 MTU Considerations

FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement.

If fragmentation is not supported, the two Frame Relay endpoints MUST

support an MTU size of at least 1526 which is based on adding the PPP

Max-Receive-Unit size with the PPP header size with the Max L2TP

Header Size with the Frame Relay header size (PPP header size is the

protocol field size plus HDLC framing bytes, which is required by

L2TP). To avoid packet discards on the Frame Relay interface, the

RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default

MRU of 1500. The means to ensure these MTU settings are left to

implementation.

6.0 QOS Issues

In general, QoS mechanisms can be roughly provided for with

proprietary mechanisms localized within the LAC or LNS. QoS

considerations are beyond the scope of this document.

7.0 Frame Relay and L2TP Interaction

In case of Frame Relay SVCs, connection setup will be triggered when

L2TP tries to create a tunnel. Details of triggering mechanism are

left to implementation. There SHALL NOT be any change in Frame Relay

SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST be

identified by X.121/E.164 addresses in case of Frame Relay SVC.

These addresses MAY be oBTained as tunnel endpoints for a user as

defined in [4]. In case of PVCs, the Virtual Circuit to carry L2TP

traffic MAY be configured administratively. The endpoints of the

tunnel MUST be identified by DLCI, assigned to the PVC at

configuration time. This DLCI MAY be obtained as tunnel endpoints

for a user as defined in [4].

There SHALL be no framing issues between PPP and Frame Relay. PPP

frames received by LAC from remote user are stripped of CRC, link

framing, and transparency bytes, encapsulated in L2TP, and forwarded

over Frame Relay tunnel.

8.0 Security Considerations

Currently there is no standard specification for Frame Relay security

although the Frame Relay Forum is working on a Frame Relay Privacy

Agreement. In light of this work, the issue of security will be re-

examined at a later date to see if L2TP over Frame Relay specific

protection mechanisms are still required. In the interim, basic

security issues are discussed in the base L2TP specification [1].

9.0 Acknowledgments

Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation)

contributed to the editing of this document.

10.0 References

[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and

B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC2661,

August 1999.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, 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", RFC1490, July 1993.

11.0 Authors' Addresses

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 Full Copyright Statement

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 translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有