One document matched: draft-ietf-l2tpext-svctype-00.txt
Network Working Group Danny McPherson
INTERNET DRAFT Amber Networks, Inc.
Category: Internet Draft Suhail Nanji
Title: draft-ietf-l2tpext-svctype-00.txt Redback Networks, Inc.
Date: August 2000
L2TP Service Type
<draft-ietf-l2tpext-svctype-00.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a
standard method for tunneling PPP [RFC 1661] packets. This document
describes an extension to L2TP which provides a mechanism to support
tunneling of additional payload types over individual sessions within
an L2TP tunnel. These extensions provide added functionality which
is optional and preserves backwards compatibility.
McPherson, Nanji [Page1]
INTERNET DRAFT August 2000
3. Specification of Requirements
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].
4. Introduction
The Layer Two Tunneling Protocol defines a mechanism for tunneling
PPP PDUs only. This document describes an extension which enables
L2TP to support additional payload types. This extension allows
sessions to carry different payloads within the same tunnel. The
normal operation of L2TP is not modified if the attributes described
below are not implemented.
5. Tunnel Establishment
The basic tunnel establishment procedures defined in [RFC 2661] are
unchanged. The only addition is that of a new AVP, the Service
Capabilities List AVP, which is used for indicating which payload
type(s) are supported on sessions of this tunnel.
5.1. Service Capabilities List (SCCRP, SCCRQ)
The Service Capabilities List AVP is encoded as Vendor ID 311, and
the Attribute Value is the 16-bit quantity 999 (the ID 311 reflects
Microsoft, it should be changed to 0 and an official Attribute Value
chosen should this specification advance on as standards track). The
Value is a list of supported Service Types.
The AVP has the following format:
Vendor ID = 311
Attribute = 999
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|H|0|0|0|0| Length | 311 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 999 | Service Type 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Service Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
McPherson, Nanji [Page2]
INTERNET DRAFT August 2000
The AVP MUST be present if the sender can place calls employing the
Service Type when requested. Presence of a given Service Type is not
a guarantee that a given call will be placed by the sender if
requested, just that the capability to terminate the indicated
Service Type(s) exists.
The AVP MAY be hidden (the H-bit may be 0 or 1). The Length (before
hiding) of this AVP MUST be 8 octets with one Service Type specified,
plus 2 octets for each additional Service Type.
The Service Type and Service Capabilities AVPs described in this
document provide the base mechanisms for other PDUs other than PPP to
be tunneled via L2TP. In order to facilitate this in a backwards
compatible manner, the M-bit MUST NOT be set on the Service
Capabilities AVP unless RFC 2661 PPP tunneling is NOT supported.
Thus, if RFC 2661 PPP tunneling is NOT supported by a particular
implementation (or disallowed by configuration or policy), the M-bit
MUST be set on the Service Capabilities AVP in order to ensure that
an implementation unaware of Service Types other than PPP and/or
requiring a Service Type for PPP tunneling would disallow
establishment of the L2TP tunnel.
If the sessions on this tunnel MUST use the Service Type AVP, then
the M-bit MUST be set to 1 for the Service Capabiliites List AVP.
This mode of operation explicitly eliminates backwards comptability
with PPP payload sessions which do not employ the Service Type AVP.
In this mode, sessions carrying a PPP payload MUST use the PPP
Service Type AVP value detailed below.
If the sessions on this tunnel MAY use the Service Type AVP, the the
M-bit MUST be set to 0 for the Service Capabilities List AVP. This
mode of operation maintains backwards comptability with PPP payload
sessions which do not employ the Service Type AVP. In this mode,
sessions carrying a PPP payload MAY use the PPP Service Type AVP
value detailed below.
If a LAC or LNS requires use of the Service Type AVP for every
session and it receives a Service Capabilities List AVP without the
M-bit set to 0, then the tunnel MUST be torn down. If a LAC or LNS
does not support the Service Type Extensions AVPs and it receives a
Service Capabilities List AVP with the M-bit set to 1, then a tunnel
MUST be torn down.
McPherson, Nanji [Page3]
INTERNET DRAFT August 2000
6. Session Establishment
The basic call establishment procedures defined in [RFC 2661] are
unchanged. A new AVP for indicating the payload type the session
will support is defined.
6.1. Service Type (ICRQ, OCRQ)
The Service Type AVP encodes the Service Type for the incoming or
outgoing call. In order to retain backwards compatibility with [RFC
2661], if the Service Type attribute is not present, then the session
MUST carry a PPP payload. If the Service Capabilities List AVP had
only the PPP Service Type, then the PPP Service Type AVP MUST be used
for all sessions.
An LNS MUST NOT send an OCRQ with a Service Type AVP specifying a
value not advertised in the Service Capabilities List AVP received
from the LAC. Similarly, an LAC MUST NOT send an ICRQ with a Service
Type AVP specifying a value not advertised in the Service
Capabilities List AVP received from the LNS. If a Service Type AVP
is received (in an ICRQ or OCRQ) and it contains a value that has not
been advertised for the tunnel in the Services Capabilities List AVP,
then the session MUST be torn down.
The value of this attribute is one of the supported Service Types.
The Service Type AVP is encoded as Vendor ID 311, and the Attribute
Value is the 16-bit quantity 998 (the ID 311 reflects Microsoft, it
should be changed to 0 and an official Attribute Value chosen if this
specification advances on as standards track). The Service Type AVP
MUST be located immediately following the Message Type AVP (unless it
is hidden, in which case the Random Vector AVP will precede it).
The Service Type value is represented by a 16-bit quantity of the
range 0-65535. Assignment of values within this range are defined in
the "Service Type AVP Values" section.
Vendor ID = 311
Attribute = 998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|H|0|0|0|0| Length | 311 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 998 | Service Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
McPherson, Nanji [Page4]
INTERNET DRAFT August 2000
The AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 8.
6.2. Service Type AVP Values
The range of potential Service Type values is 0-65535. This document
defines one of those values for PPP as defined in [RFC 2661].
Service Type AVP Values
Payload Type Value
Reserved 0 (zero)
PPP 1
FCFS 2-65534
Reserved 65535
See Section "IANA Considerations" for additional information on
Service Type AVP values.
7. Migration to Standard Attributes
It is intended that both the Service Capabilities List and Service
Type attributes will be migrated to standard attributes. As a result,
the AVPs outlined in this draft would have a Vendor ID value of 0 and
standard Attribute Values. Furthermore, it is intended the drafts
"L2TP Circuit Emulation Services Extension" and "Ethernet
Encapsulation Extensions to L2TP" will be deprecated.
8. IANA Considerations
The Service Type AVP namespace will be registered and maintained by
IANA as follows:
o Values 0 and 65535 are reserved.
o Value 1 is reserved for PPP payloads.
o Values between 2 and 65534 are to be assigned by IANA, using
the "First Come First Served" policy defined in [RFC 2434].
McPherson, Nanji [Page5]
INTERNET DRAFT August 2000
9. Security Considerations
Security issues are not discussed in this memo.
10. New Service Types
To define a new Service Type for a payload other than PPP,a new RFC
MUST be drafted which MUST:
o Identify any new L2TP AVPs or control messases necessary for the
establishment, maintenance, and teardown of the non-PPP session.
o Identify which AVPs must be present (new or existing) in each
existing or new control message with a given service type.
o Identify any existing AVPs which have a new or revised meaning for
a given Service Type beyond that defined in RFC2661.
11. Acknowledgements
Thanks to W. Mark Townsley of Cisco Systems, Bill Palter of Redback
Networks, and Nishit Vasavada and Andy Koscinski of Amber Networks.
Copious amounts of text were stolen from the L2TP [RFC 2661].
Special thanks to Glen Zorn for suggesting to use Microsoft's Vendor
ID for the new AVPs in the interim.
12. References
[RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661,
August 1999.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations section in RFCs", BCP 26, RFC
2434, October 1998.
McPherson, Nanji [Page6]
INTERNET DRAFT August 2000
13. Authors' Address
Danny McPherson
Amber Networks, Inc.
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.486.6336
Email: danny@ambernetworks.com
Suhail Nanji
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134-1362
Phone: +1 408 571 5413
Email: suhail@redback.com
McPherson, Nanji [Page7]
| PAFTECH AB 2003-2026 | 2026-04-23 13:10:31 |