As per Relevance of the word mechanism, we have this rfc below:
Network Working Group V.
Request for Comments: 3070 ONI Systems, Inc
Category: Standards Track R.
S.
Redback Networks, Inc
R.
Deloitte
February 2001
Layer Two Tunneling Protocol (L2TP) over Frame
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Layer Two Tunneling Protocol (L2TP) describes a mechanism to
Point-to-Point (PPP) sessions. The protocol has been designed to
independent of the media it runs over. The base
describes how it should be implemented to run over the User
Protocol (UDP) and the Internet Protocol (IP). This
describes how L2TP is implemented over Frame Relay Permanent
Circuits (PVCs) and Switched Virtual Circuits (SVCs).
This specification is intended for those implementations which
to use facilities which are defined for L2TP and applies only to
use of Frame Relay pont-to-point circuits
1.0
L2TP [1] defines a general purpose mechanism for tunneling PPP
various media. By design, it insulates L2TP operation from
details of the media over which it operates. The base
specification illustrates how L2TP may be used in IP environments
This document specifies the encapsulation of L2TP over native
Relay and addresses relevant issues
Rawat, et al. Standards Track [Page 1]
RFC 3070 L2TP over Frame Relay February 2001
2.0
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [2].
3.0 Problem Space
In this section we describe in high level terms the scope of
problem being addressed. Topology
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+
| ISDN | | Cloud | |
+------+ +---------------+ |
An L2TP Access Concentrator (LAC) is a device attached to
switched network fabric (e.g., PSTN or ISDN) or co-located with a
end system capable of handling the L2TP protocol. The LAC need
implement the media over which L2TP is to operate to pass traffic
one or more LNS's. It may tunnel any protocol carried within PPP
L2TP Network Server (LNS) operates on any platform capable of
termination. The LNS handles the server side of the L2TP protocol
L2TP is connection-oriented. The LNS and LAC maintain state for
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.
datagrams related to a session are sent over the tunnel between
LAC and LNS. A tunnel is defined by an LNS-LAC pair. The
carries PPP datagrams between the LAC and the LNS
L2TP protocol operates at a level above the particular media
which it is carried. However, some details of its connection
media are required to permit interoperable implementations. L2
over IP/UDP is described in the base L2TP specification [1].
related to L2TP over Frame Relay are addressed in later sections
this document
4.0 Encapsulation and Packet
L2TP MUST be able to share a Frame Relay virtual circuit (VC)
other protocols carried over the same VC. The Frame Relay
format for data packet needs to be defined to identify the
being carried in the packets. The Frame Relay network may
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
a Q.922 frame. Additionally, frames must contain
necessary to identify the protocol carried within the frame
Protocol Data Unit (PDU), thus allowing the receiver to
process the incoming packet
The frame format for L2TP MUST be SNAP encapsulation as defined
RFC 1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed
Organizationally Unique Identifier and a PID
The single octet identifier provides a mechanism to allow
protocol identification. For L2TP NLPID value 0x80 is used
indicates the presence of SNAP header
OUI &
The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5
identifies IANA who administers the meaning of the
Identifier (PID) 0x0007. Together they identify a distinct protocol
Format of L2TP frames encapsulated in Frame Relay is given in
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
Frame
Rawat, et al. Standards Track [Page 3]
RFC 3070 L2TP over Frame Relay February 2001
5.0 MTU
FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement
If fragmentation is not supported, the two Frame Relay endpoints
support an MTU size of at least 1526 which is based on adding the
Max-Receive-Unit size with the PPP header size with the Max L2
Header Size with the Frame Relay header size (PPP header size is
protocol field size plus HDLC framing bytes, which is required
L2TP). To avoid packet discards on the Frame Relay interface,
RECOMMENDED default Frame Relay MTU is 1564 based on a PPP
MRU of 1500. The means to ensure these MTU settings are left
implementation
6.0 QOS
In general, QoS mechanisms can be roughly provided for
proprietary mechanisms localized within the LAC or LNS.
considerations are beyond the scope of this document
7.0 Frame Relay and L2TP
In case of Frame Relay SVCs, connection setup will be triggered
L2TP tries to create a tunnel. Details of triggering mechanism
left to implementation. There SHALL NOT be any change in Frame
SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST
identified by X.121/E.164 addresses in case of Frame Relay SVC
These addresses MAY be obtained as tunnel endpoints for a user
defined in [4]. In case of PVCs, the Virtual Circuit to carry L2
traffic MAY be configured administratively. The endpoints of
tunnel MUST be identified by DLCI, assigned to the PVC
configuration time. This DLCI MAY be obtained as tunnel
for a user as defined in [4].
There SHALL be no framing issues between PPP and Frame Relay.
frames received by LAC from remote user are stripped of CRC,
framing, and transparency bytes, encapsulated in L2TP, and
over Frame Relay tunnel
8.0 Security
Currently there is no standard specification for Frame Relay
although the Frame Relay Forum is working on a Frame Relay
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
protection mechanisms are still required. In the interim,
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
Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation
contributed to the editing of this document
10.0
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661,
August 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate
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.
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
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
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'
Vipin
ONI Systems, Inc
166 Baypointe
San Jose CA 95134
EMail: vrawat@oni.
Rene
Redback Networks, Inc
300 Holger
San Jose, CA 95134
EMail: tor@redback.
Rohit
Deloitte
180 N. Stetson
Chicago Illinois 60601
EMail: rverma@dc.
Suhail
Redback Networks, Inc
300 Holger
San Jose, CA 95134
EMail: suhail@redback.
Rawat, et al. Standards Track [Page 6]
RFC 3070 L2TP over Frame Relay February 2001
12.0 Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rawat, et al. Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
