One document matched: draft-ietf-l2tpext-link-00.txt
PPP Working Group William L. Palter
INTERNET DRAFT RedBack Networks
Category: Internet Draft W. Mark Townsley
Title: draft-ietf-l2tpext-link-00.txt Cisco Systems
Date: December 1999
L2TP Link Extensions
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026."
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
The physical separation of the LAC and LNS with L2TP[2] and logical
separation of the responsibilities of each with respect to negotiated
link parameters introduces a lack of awareness between the tunnel
endpoints that does not exist in a typical PPP dialup device. When
possible, Proxy LCP provides a manner in which to negotiate link
parameters at the LAC and communication of these in full to the LNS.
If these options can be made acceptable to the LNS, then there should
not be any insurmountable difficulty with regard to mismatch of link
expectations. However, given that there are instances where
negotiation of LCP[1] must take place at the LNS, some direction by
the LAC as to what parameters are acceptable, as well as some
communication from the LNS as to what parameters have been
negotiated, is desirable.
Table of Contents
1.0 Introduction
2.0 Communicating desired link parameters from the LAC to the LNS
2.1 LCP Want Options
2.2 LCP Allow Options
2.4 Communicating negotiated link parameters from the LNS to the LAC
Palter, Townsley expires June 2000 [Page 1]
INTERNET DRAFT December 1999
1.0 Introduction
For the majority of topologies today, the Bearer Type, Bearer
Capabilities, Framing Type, ACCM, and Framing Capabilities AVPs
defined in the L2TP base specification communicate sufficient
information between the LAC and LNS for a typical analog or digital
dialup link with HDLC-like framing[3]. Defaults for PPP LCP options
such as MRU, ACFC and PFC are well understood for various bearer and
framing types and are utilized in the event that LCP negotiation by
the LNS must occur.
For some L2TP applications and, specifically, some PPP media types,
particular link capabilities and requirements may need to be sent
from the LAC to the LNS in order for the LNS to properly initialize
negotiation of LCP. Further, the LCP options negotiated may need to
be transmitted back to the LAC so that it may make allowances at the
physical link if necessary.
LCP options may be classified into roughly three different categories
with respect to their affect on L2TP; (1) options which affect
framing in a way that the LAC may need to know about or handle
specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are
transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the
LAC may wish to influence because they are dependent on the media
type (ACFC, PFC). We are most concerned about options which fall into
category (1) and (3).
This document defines new AVPs to allow the LAC and the LNS to
communicate complete LCP information in order to react accordingly.
LCP option information is structured in the same way as the Proxy LCP
AVPs are in the base L2TP specification. This essentially involves
encapsulation of a PPP LCP Configure- Request or Configure-Ack packet
within an L2TP AVP.
1.1 Conventions
The following language conventions are used in the items of
specification in this document:
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 [15].
2.0 Communicating desired link parameters from the LAC to the LNS
The LAC may utilize the following AVPs within an ICCN or OCCN message
in order to influence the LNS to negotiate LCP in a specific manner.
If these AVPs are supported by the LNS, they should override any
suggestions for LCP options implied by all other AVPs received.
These AVPs may coexist with the Proxy AVPs defined in the base L2TP
specification. If Proxy AVPs are received, the LNS may choose to
accept these parameters, or renegotiate LCP with the options
suggested by these AVPs. If the LAC wishes to force negotiation of
Palter, Townsley expires June 2000 [Page 2]
INTERNET DRAFT December 1999
LCP by the LNS, it should simply omit all Proxy AVPs during call
initialization.
By default, the AVPs defined in 2.1 and 2.2 are not mandatory (M-bit
is set to zero). However, if an LAC implementation needs to strongly
enforce adherence to the options defined within the AVPs, it MAY set
the M-bit to 1, thus forcing the LNS to discontinue the session if it
does not support this AVP.
If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST
be prepared to accept the AVPs as defined in section 2.3.
2.1 LCP Want Options
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|0|0|0|0|0| 6+LCP Confreq len | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | LCP confreq...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP contains a list of options that the LAC would like to see
negotiated by the LNS. In some cases this maps to a desired value
(e.g., MRU) and in some cases it maps to a specific option that is
desired to be enabled (e.g., ACFC). The LNS should use these
suggestions when building its initial Configure- Request. Presence of
this AVP is optional.
The following chart defines some of the more common LCP options that
may be included in this AVP with guidance of how to handle them at
the LAC and LNS. This table is provided for some of the more common
or problematic LCP options. It is not intended to be an exhaustive
representation of all LCP options available.
LCP Want Option LAC Action LNS Action
MRU LAC provides a LNS SHOULD begin negotiation
maximum value with this value. However,
it MAY reduce it if
necessary.
ACCM LAC Provides a mask LNS SHOULD begin negotiation
with this value. LNS may
add bit(s) while negotiating
PFC LAC provides PFC LNS SHOULD being negotiation
if it is desired on with this value.
the link type
(e.g. AHDLC)
ACFC LAC provides ACCOMP LNS SHOULD begin negotiation
if it is desired on with this value.
the link type
Palter, Townsley expires June 2000 [Page 3]
INTERNET DRAFT December 1999
(e.g. AHDLC)
FCS-ALT LAC indicates required LNS SHOULD begin negotiation
values for the link with this value. Note
type that this value is of
no consequence to the LNS
as FCS is stripped at the
LAC, however some PPP
media types require this
option.
2.2 LCP Allow Options
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|0|0|0|0|0| 6+LCP Confack len | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | LCP confack...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP contains a list of options that the LAC will allow to be
negotiated by the LNS. In some cases this maps to a maximum value
(e.g., MRU) and in others it maps to an option that is permitted by
the LAC (e.g., ACFC). If the option is not included here, it can be
assumed by the LNS that the LAC does not understand how to perform
that particular option at the link layer. This may or may not affect
operation of the tunneled session. Information in this AVP should be
utilized when building PPP Configure-Ack, Configure-Reject and
Configure-Nak messages. Presence of this AVP is optional.
The following chart defines some of the more common LCP options that
may be included in this AVP with guidance of how to handle them at
the LAC and LNS. This table is provided for illutration purposes for
some of the more common or problematic LCP options. It is not
intended to be an exhaustive representation of all LCP options
available.
LCP Allow Option LAC Action LNS Action
MRU LAC provides a LNS may accept reduction
maximum value of this value as requested
ACCM LAC Provides a mask LNS may accept bit(s)
defined here. Note that
if ACCM is missing it is
assumed that it is not
applicable to the link type
PFC LAC provides PFC LNS may accept PFC
if it is allowed on
the link type
(e.g. AHDLC)
Palter, Townsley expires June 2000 [Page 4]
INTERNET DRAFT December 1999
ACFC LAC provides ACFC LNS may accept ACFC
if it is allowed on
the link type
(e.g. AHDLC)
FCS-ALT LAC indicates valid Negotiation this option
values for the link is of no consequence to the
type LNS as the FCS is stripped
at the LAC. However, the
LNS SHOULD only accept
FCS-ALT types listed here
(more than one value may be
present).
2.3 Communicating negotiated link parameters from the LNS to the LAC
There are no new AVPs defined for communication of negotiated
parameters from the LNS to the LAC. Instead, two AVPs that are
defined in the base L2TP specification are simply included in a new
location.
When LCP negotiation is complete by the LNS, a Set-Link-Info control
message may be sent with the the Last Sent LCP Confreq (IETF L2TP
Attribute 27) and Last Received LCP Confreq (IETF L2TP Attribute 28)
included in the list of AVPs. These AVPs should contain the last
sent and last received (with respect to the LNS) LCP packets. For AVP
format details, refer to the L2TP base specification.
If LCP negotiation occurs at the LNS and the new AVPs defined in
section 2.1 and 2.2 of this document are utilized, then a Set-Link-
Info control message MUST be sent on completion of the LCP
negotiation, and the Last Sent and Last Received LCP Confreq packets
MUST be included.
3.0 Contacts
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
townsley@cisco.com
Bill Palter
Redback Networks
1389 Moffett Park Drive
Sunnyvale, CA 94089
palter.ietf@zev.net
4.0 References
[1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
Palter, Townsley expires June 2000 [Page 5]
INTERNET DRAFT December 1999
07/21/1994
[2] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol", RFC2661
[3] W. Simpson, "PPP in HDLC-like framing", RFC 1662,
07/21/1994
Palter, Townsley expires June 2000 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-22 23:31:13 |