1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395
|
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.
Rawat, et al. Standards Track [Page 1]
RFC 3070 L2TP over Frame Relay February 2001
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 RFC 2119 [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.
Rawat, et al. Standards Track [Page 2]
RFC 3070 L2TP over Frame Relay February 2001
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
RFC 1490 [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
Rawat, et al. Standards Track [Page 3]
RFC 3070 L2TP over Frame Relay February 2001
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].
Rawat, et al. Standards Track [Page 4]
RFC 3070 L2TP over Frame Relay February 2001
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'", 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.
Rawat, et al. Standards Track [Page 5]
RFC 3070 L2TP over Frame Relay February 2001
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
Rawat, et al. Standards Track [Page 6]
RFC 3070 L2TP over Frame Relay February 2001
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 RFC Editor function is currently provided by the
Internet Society.
Rawat, et al. Standards Track [Page 7]
|