One document matched: draft-ietf-l2tpext-pwe3-fr-02.txt
Differences from draft-ietf-l2tpext-pwe3-fr-01.txt
Network Working Group W. Mark Townsley
Internet-Draft George Wilkie
Category: Standards Track Skip Booth
<draft-ietf-l2tpext-pwe3-fr-02.txt> Jed Lau
June 2003 Stewart Bryant
cisco Systems
Nishit Vasavada
Nokia
Serge Maskalik
iVMG, Inc.
Frame-Relay Pseudo-Wire Extensions for L2TP
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as <draft-
ietf-l2tpext-pwe3-fr-02.txt> and expires December 2003. Please send
comments to the L2TP mailing list (l2tpext@ietf.org).
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Layer 2 Tunneling Protocol [L2TPv3] defines an extensible
tunneling protocol suitable for Pseudowire Emulation Edge to Edge
(PWE3) applications. This document describes the specifics of how to
use the L2TP control plane for Frame-Relay Pseudo-Wires, including
Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
PVC creation, deletion, and line status change notification.
Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 3
1.1 Abbreviations......................................... 3
2. PE-PE Control Connection Establishment.................... 4
3. PVC Status Notification and Session Establishment......... 4
3.1 PE-PE Session Establishment........................... 4
3.2 PE-PE Session Teardown................................ 6
3.3 PE-PE Session Maintenance............................. 6
3.4 Use of the Circuit Status AVP for Frame-Relay......... 6
4. Encapsulation............................................. 7
4.1 Data Packet Encapsulation............................. 7
4.2 Data Packet Sequencing................................ 8
5. Security Considerations................................... 8
6. IANA Considerations....................................... 8
7. Acknowledgments........................................... 8
8. References................................................ 9
9. Contacts.................................................. 10
1. Introduction
This document describes the specifics of how to use the L2TP for
Frame-Relay Pseudo-Wires, including encapsulation, PVC creation,
deletion, and line status change notification. Any Frame-Relay-
specific AVPs or other L2TP constructs for Frame-Relay Pseudo-Wire
(FRPW) support will be defined here as well. Support for Switched
Virtual Circuits (SVC) and Switched/soft Permanent Virtual Circuits
(SPVC) are for further study.
1.1 Abbreviations
CE Customer Edge
FR Frame-Relay
FRPW Frame-Relay Pseudo-Wire
LCCE L2TP Control Connection Endpoint (See [L2TPv3])
PE Provider Edge (typically also the LCCE).
PSN Packet Switched Network
PVC Permanent virtual circuit
Townsley, et al. Standards Track [Page 3]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
PW Pseudo-Wire
PWE3 Pseudo-Wire Emulation Edge to Edge (Working Group)
VC Virtual circuit
2. PE-PE Control Connection Establishment
Two PEs that wish to establish Pseudo-Wires with L2TP must first
establish an L2TP Control Connection as described in Section 3.3 of
[L2TPv3]. The SCCRQ and corresponding SCCRP MUST include the Frame-
Relay PW Type of TBD (See IANA Considerations Section), in the Pseudo
Wire Capabilities List as defined in 5.4.3 of [L2TPv3]. This
identifies the control connection as able to establish L2TP sessions
to support Frame-Relay Pseudo-Wires (FRPWs).
3. PVC Status Notification and Session Establishment
This section specifies how the status of a PVC is reported between
two PEs. This includes what should happen when a PVC is created,
deleted or when it changes state between ACTIVE and INACTIVE.
3.1 PE-PE Session Establishment
PVC creation (provisioning) results in establishment of an L2TP
session via the standard three-way handshake described in section
3.4.1 of [L2TPv3]. An LCCE MAY initiate the session immediately upon
PVC creation, or wait until the PVC state transitions to ACTIVE
before attempting to establish a session for the PVC. Waiting until
the PVC transitions to ACTIVE is the preferred method of operation,
as it does not needlessly waste L2TP resources.
The Circuit Status AVP (see Section 4) MUST be present in the ICRQ
and ICRP messages, and MAY be present in the SLI message for FRPWs.
Following is an example of the L2TP messages exchanged for an FRPW
which is initiated after a new PVC is provisioned and becomes ACTIVE.
Townsley, et al. Standards Track [Page 4]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
PE (LAC) A PE (LAC) B
------------------ ------------------
FR PVC Provisioned
FR PVC Provisioned
FR PVC ACTIVE
ICRQ (status = 0x03) ---->
FR PVC ACTIVE
<---- ICRP (status = 0x03)
L2TP session established,
OK to send data into tunnel
ICCN ----->
L2TP session established,
OK to send data into tunnel
In the example above, an ICRQ is sent after the PVC is created and
becomes ACTIVE. The Circuit Status AVP indicates that this PVC is
ACTIVE and New (0x03). The Remote End Identifier AVP must be present
in the ICRQ in order to identify the PVC to attach the L2TP session
to. The Remote End Identifier AVP defined in [L2TPv3] is of opaque
form, though FRPW implementions MAY simply use a four-octet value
that is known to both PEs (either by direct configuration, or some
other means). The exact method of how this value is configured,
retrieved, discovered, or otherwise determined at each PE is outside
the scope of this document.
As with the ICRQ, the ICRP is sent only after the FR PVC transitions
to ACTIVE as well. If PE B had not been provisioned for the PVC
identified in the ICRQ, a CDN would have been immediately returned
indicating that the circuit was not provisioned or available at this
PE. PE A should then exhibit a periodic retry mechanism. Specifics of
the retry algorithm is left to the implementation, but SHOULD be
configurable.
An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as
long as the Circuit Status AVP reflects that the PVC is INACTIVE and
an SLI is sent when the PVC becomes ACTIVE (see Section 3.3).
The ICCN is the final stage in the session establishment, confirming
the receipt of the ICRP with acceptable parameters to allow
bidirectional traffic.
Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
3.2 PE-PE Session Teardown
In the event a PVC is deleted (unprovisioned) at either PE, the
associated L2TP session MUST be torn down via the CDN message defined
in Section 3.4.3 of [L2TPv3].
General Result Codes regarding L2TP session establishment are defined
in [L2TPv3]. Additional Frame-Relay result codes are defined as
follows (TBD indicates that both of these values needs to be assigned
by IANA):
TBD: PVC was deleted permanently (no longer provisioned)
TBD: PVC has been INACTIVE for an extended period of time
3.3 PE-PE Session Maintenance
FRPW over L2TP makes use of the Set Link Info (SLI) control message
defined in [L2TPv3] to signal Frame-Relay link status notifications
between PEs. This includes ACTIVE or INACTIVE notifications of the
VC, or any other parameters that may need to be shared between the
tunnel endpoints or PEs in order to provide proper PW emulation. The
SLI message is a single message that is sent over the L2TP control
channel signaling the state change. Since the message is delivered
reliably, there is no additional response or action required of the
PW subsytem to ensure that the state change notification was received
by the tunnel peer.
The SLI message MUST be sent any time there is a line status change
which may be reported by any values identified in the Circuit Status
AVP. The only exception to this is the initial ICRQ, ICRP and CDN
messages which establish and teardown the L2TP session itself when
the PVC is created or deleted. The SLI message may be sent from
either PE at any time after the first ICRQ is sent (and perhaps
before an ICRP is received, requiring the peer to perform a reverse
Session ID lookup).
All sessions established by a given control connection utilize the
L2TP Hello factility defined in Section 4.4 of [L2TPv3] for session
keepalive. This gives all sessions basic dead peer and path detection
between PEs.
3.4 Use of the Circuit Status AVP for Frame-Relay
Frame-relay line status is reported via the Circuit Status AVP
defined in [L2TPv3]. For reference, this AVP is shown below:
Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16 bit mask with the two least significant bits
defined and the remaining bits reserved for future use. Reserved bits
MUST be set to 0 when sending, and ignored upon receipt.
The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or
INACTIVE (0).
The N (New) bit indicates whether the circuit status indication is
for a new FR PVC (1) or an existing FR PVC (0).
4. Encapsulation
4.1 Data Packet Encapsulation
The FR PDU is transported in its entirety, excluding only the opening
and closing HDLC flags and the FCS. Bit stuffing is undone. No
intermediate headers are required between the L2TP header and the
start of the FR PDU. The start of the FR PDU is therefore contiguous
with the end of the L2TP header. This approach conforms to the
Principle of Minimum Intervention [LAYER], and concurs with
[MARTINI].
The NSP function [LAYER] in some PW PEs may need to modify the FR
header. The FR header is defined in [Q922], however the notation
used differs from that used in IETF specifications. For reference the
FR header in IETF notation is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two-octet FR Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Townsley, et al. Standards Track [Page 7]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
Four-octet FR Header
C/R (bit 6)
FR frame C/R (command/response) bit [Q922].
F - FECN (bit 12):
FR FECN (Forward Explicit Congestion Notification) bit [Q922].
B - BECN (bit 13):
FR BECN (Backward Explicit Congestion Notification) bit [Q922].
D - DE (bit 14)
FR DE bit indicates the discard eligibility [Q922].
4.2 Data Packet Sequencing
Data Packet Sequencing MAY be enabled for FRPWs. The sequencing
mechanisms described in [L2TPv3] MUST be used for signaling
sequencing support. FRPW over L2TP MUST request the presence of the
L2TPv3 Default L2-Specific Sublayer when sequencing is enabled, and
MAY request its presence at all times.
5. Security Considerations
For generic security issues regarding PWs and FRPWs, this document
will eventually refer to documents from the PWE3 WG.
6. IANA Considerations
The signaling mechanisms defined in this document rely upon the
assignment of a Frame Relay Pseudowire Type. IANA assignment of this
value should take place within the PWE3 WG.
This document specifies one additional AVP Attribute to be defined by
IANA as described in section 9.1 of [L2TP-IANA].
This document defines two L2TP Result Codes in section 3.2 which will
be defined by IANA as described in section 9.1 of [L2TP-IANA].
7. Acknowledgments
The first Frame Relay over L2TP document was published as "Frame
Relay Service Type for L2TP," draft-vasavada-l2tpext-fr-svctype-
00.txt in Feburary of 2001 by Nishit Vasavada, Jim Boyle, Chris
Garner, Serge Maskalik, and Vijay Gill. This document is
substantially different, but the basic concept of carrying Frame
Relay over L2TP is the same.
Townsley, et al. Standards Track [Page 8]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
Thanks to Lloyd Wood for a razor-sharp review.
8. References
[L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Pall,
A. Rubens, B. Palter, Layer Two Tunneling Protocol a.k.a.
"L2TPv3," work in progress, draft-ietf-l2tpext-l2tp-base-02.txt,
February 2002.
[Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer
Specification for Frame Mode Bearer Services, ITU, Geneva, 1992.
[Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification
for Frame Mode Bearer Services, Geneva, October 1995.
[FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement,
Frame Relay Forum, April 2000.
[FRF2] FRF.2.1, Frame relay PVC NNI Implementation Agreement,
Frame Relay Forum, July 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2661] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer
Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing
L2TP Using IPsec," RFC 3193, November 2001
[L2TP-IANA] Townsley, W., "L2TP IANA Considerations Update", Internet Draft,
draft-ietf-l2tpext-rfc2661-iana-00.txt, April 2002
[LAYER] Bryant, et al. Protocol Layering in PWE3,
draft-pwe3-protocol-layer-00.txt, May 2002, work in progress.
[MARTINI] Martini, et al. Frame Relay Encapsulation over Pseudo-Wires,
draft-martini-frame-encap-mpls-01.txt, June 2002,
work in progress.
Townsley, et al. Standards Track [Page 9]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003
9. Contacts
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
mark@townsley.net
George Wilkie
cisco Systems
Edinburgh, EH6 6LX
United Kingdom
gwilkie@cisco.com
Jed Lau
cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
jedlau@cisco.com
Skip Booth
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
ebooth@cisco.com
Stewart Bryant
cisco Systems
Uxbridge UB11 1BL
United Kingdom
stbryant@cisco.com
Nishit Vasavada
Nokia
545 Whisman Dr
Mountain View, CA 94043
nishit.vasavada@nokia.com
Serge Maskalik
iVMG, Inc.
1020 Rincon Circle
San Jose, CA 95131
serge@ivmg.net
Townsley, et al. Standards Track [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 13:07:10 |