Network Working Group M. Kelkar
Internet Draft T. Mistretta
Expires: December 2006 P. Howard
Juniper Networks
V. Jain
Riverstone Networks
June 22, 2006
PPP over L2TP Tunnel Switching
draft-ietf-l2tpext-tunnel-switching-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
Distribution of this document is unlimited. Please send comments to
the Layer Two Tunneling Protocol Extensions (l2tpext) working group
at l2tpext@ietf.org.
Abstract
PPP [7] over L2TP Tunnel Switching, also called L2TP Multihop, is the
process of forwarding PPP payload from an L2TP session to another
L2TP session over a different tunnel. It facilitates moving the
logical termination point of an L2TP session, based on layer 2
characteristics or administrative policies, to different L2tp
Kelkar, et al. Expires December 22, 2006 [Page 1]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Endpoint. This document introduces the L2TP tunnel switching
nomenclature and defines the behavior of standard AVPs in tunnel
switching deployment. The scope of this document is limited to the
discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels.
Table of Contents
1. Introduction...................................................3
2. L2TPv2 to L2TPv3 switch........................................4
3. AVP Behavior...................................................4
3.1. IETF Vendor AVPs..........................................5
4. Loop Detection................................................11
5. CDN Messages and L2TP tunnel Switching........................12
6. IANA Considerations...........................................12
6.1. Control Message Attribute Value Pairs (AVPs).............12
6.2. Result Code AVP Values...................................13
7. Security Considerations.......................................13
8. Intellectual Property Statement...............................13
9. Copyright Statement...........................................14
10. Acknowledgments..............................................14
11. References...................................................15
11.1. Normative References....................................15
11.2. Informative References..................................15
Author's Addresses...............................................16
Terminology
Tunnel Switching Aggregator (TSA): These are the devices that switch
the layer 2 payload from a first L2TP session/tunnel on to second
L2TP session/tunnel.
First Tunnel: The first L2tp Tunnel to be established at the TSA.
Second Tunnel: The second L2TP Tunnel to be established at the TSA.
First Session: The first L2tp Session to be established at the TSA.
Second Session: The second L2TP Session to be established at the TSA.
L2TP Control Connection Endpoint (LCCE): An L2TP node that exists at
either end of an L2TP control connection. May also be referred to as
an LAC or LNS, depending on whether tunneled frames are processed at
the data link (LAC) or network layer (LNS).
L2TP, as defined in [1], is now referred to as "L2TPv2," while the
extended version defined in [2] is referred to as "L2TPv3". The
remainder of this document will refer simply to L2TP in general,
Kelkar, et al. Expires December 22, 2006 [Page 2]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
unless contrasting specific features of L2TPv2 or L2TPv3, which may
differ in function.
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].
1. Introduction
L2TP allows processing of PPP packets to be divorced from the
termination of the layer 2 circuit. L2TP tunnel switching
facilitates moving the termination point of a PPP session further on
to another LCCE that is possibly unknown to the originating LCCE. It
does so by re-tunneling the PPP session within another L2TP tunnel to
a different LCCE. The knowledge of whether to switch a PPP session to
another L2TP tunnel can be static or dynamic (for example, during PPP
session establishment).
At the TSA, First and Second sessions are two discrete entities. The
First session is established in the beginning and then TSA uses the
negotiated parameters of the First session as a basis to negotiate
the Second session. If the Second session fails to negotiate then it
should be terminated. Same thing can be said for the tunnel.
PPP LAC TSA LNS
User [LNS LAC]
|---- PPP----| | | |
| |---- PPP/L2TP ----| | |
| | |-- PPP --| |
| | | |----- PPP/L2TP -----|
| | |<----- tunnel switching ----->|
| | | | |
| |<--First tunnel-->| |<--Second tunnel--->|
Figure 1: L2TP tunnel Switching for incoming calls
The figure above presents a typical tunnel switching scenario for
incoming calls. The user opens a PPP session to a LAC, which tunnels
the session to TSA as defined by L2TP protocol. The TSA, based on
the local policies, determines if the First session should be further
tunneled. If the TSA decides to tunnel the session further, then,
for every such session it initiates another session onto another L2TP
tunnel originating on the TSA terminating on a different LNS. Once
the session is established, the data packets are switched from an
incoming tunnel to a corresponding outgoing tunnel.
Kelkar, et al. Expires December 22, 2006 [Page 3]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
2. L2TPv2 to L2TPv3 switch
If First and Second tunnels use different versions of L2TP protocol
at TSA i.e. if it involves a 'version switch', then it must adapt the
data encapsulation change.
+------------------------+ +----------------------------+
| PPP Tunneled Frame | | PPP Tunneled Frame |
| | | |
+------------------------+ +----------------------------+
| | | Default L2-Specific |
| | | Sublayer |
| L2TPv2 Data Header | | (Ref [6] section 4.1) |
| over UDP | +----------------------------+
| (Ref [1] section 3.1) | | L2TPv3 Data Session |
| | | Header over UDP or IP |
| | | (Ref [2] section 4.1.1.1 |
| | | and 4.1.2.1) |
+------------------------+ +----------------------------+
| L2TPv2 Data Channel | | L2TPv3 Data Channel |
| (unreliable) | | (unreliable) |
+------------------------+----+----------------------------+
| Packet-Switched Network (UDP, IP, FR, MPLS, etc.) |
+----------------------------------------------------------+
Figure 2: L2TPv2 to L2TPv3 data encapsulation switch
When PPP frames, which are encapsulated in the L2TPv2 header, are
received at the TSA and are switched to Second tunnel using L2TPv3,
then L2TPv2 headers are stripped and PPP frame is encapsulated with
the L2TPv3 data header followed by the optional Default L2-Specific
Sublayer and Offset Padding (Ref [6] section 4.2) fields, and
forwarded over the session.
The version switch may involve a transport change i.e. L2TPv3-IP to
L2TPv2-UDP. TSA MUST be able to adapt to such change.
3. AVP Behavior
An AVP negotiated by the First tunnel/session MUST be handled in four
ways - it could be relayed, dropped, regenerated, or stacked. They
are defined as follows.
- RELAYED AVP: (also known as pass-through AVP) AVP is forwarded
transparently if it was negotiated by the First tunnel/session.
Kelkar, et al. Expires December 22, 2006 [Page 4]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
- DROPPED AVP: AVP is dropped if it was negotiated by the First
tunnel/session.
- REGENERATED AVP: AVP negotiated by the First tunnel/session is
ignored upon receipt. A new AVP is regenerated for the Second
tunnel/session based on the local policy at the TSA. The local
policy may or may not use the received AVP to regenerate the new
value. The regenerated value MAY match with the received AVP value.
- STACKABLE AVP: Multiple instances of this AVP exist in the incoming
message, each representing a hop in the tunnel switched path in order
from first to last. When a TSA receives it, all the instances of AVP
are copied as-is for the negotiation of the next hop. A locally
generated AVP is appended to the outgoing message. If no value is
appropriate then an AVP with a null value, as determined by the AVP
definition, MUST be appended. However, If TSA couldn't copy all of
incoming AVPs then it MUST not copy any one of them and drop all of
the instances. If this is an AVP required to establish the tunnel or
session and TSA cannot copy all of the stacked AVPS, then TSA MUST
terminate the connection or session as appropriate.
3.1. IETF Vendor AVPs
This section defines the behavior of AVPs according to the guidelines
in section 3. It describes the behavior of AVPs defined in [1], [2],
[3], [4], [5], [6], and [8]. All the future AVP extensions MUST
define AVP behavior for tunnel switching.
An optional AVP whose behavior is defined as RELAYED, MUST be RELAYED
only if the AVP is negotiated by the First tunnel/session. Hence the
behavior for such AVP is stated as 'RELAYED if negotiated by the
first tunnel/session'.
An optional AVP whose behavior is defined as REGENERATED, could be
DROPPED from the negotiation of the Second tunnel/session at the
TSA's discretion. Hence the behavior for such AVP is stated as
'REGENERATED or DROPPED'
In its default behavior TSA needs to be as transparent as possible.
However, TSA shouldn't prevent local policies to override the default
behavior and allow regeneration of the AVPs mentioned as
'REGENERATED'.
Message Type (All Messages) - MUST be REGENERATED
Result Code (CDN, StopCCN) - MUST be either RELAYED or REGENERATED
based on recommendations discussed in section 5. In case of version
Kelkar, et al. Expires December 22, 2006 [Page 5]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
switch, if L2TPv3 Result Codes and Error Codes are RELAYED then they
MUST be translated into general error (Result Code 2, Error Code 0).
Protocol Version (SCCRQ, SCCRP) - MUST be REGENERATED. This would
allow TSA to switch sessions when the First and Second tunnels use
different versions of the L2TP protocol.
Framing Capabilities (SCCRQ, SCCRP) - MUST be REGENERATED.
Bearer Capabilities (SCCRQ, SCCRP) - MUST be either REGENERATED or
DROPPED.
Tie Breaker (SCCRQ) - MUST be either REGENERATED or DROPPED.
Firmware Revision (SCCRP, SCCRQ) - MUST be either REGENERATED or
DROPPED.
Host Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.
Vendor Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.
Assigned tunnel ID (SCCRP, SCCRQ, StopCCN) - MUST be REGENERATED.
Receive Window Size (SCCRQ, SCCRP) - MUST be either REGENERATED or
DROPPED.
Challenge (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.
Q.931 Cause Code (CDN) - MUST be either RELAYED if negotiated by the
First session or DROPPED.
Challenge Response (SCCCN, SCCRP) - MUST be either REGENERATED or
DROPPED.
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) - MUST be
REGENERATED.
Call Serial Number (ICRQ, OCRQ) - MUST be RELAYED. It would best
serve the intended purpose of this AVP and facilitate easier
debugging.
Minimum BPS (OCRQ) - MUST be RELAYED if negotiated by the First
session. In case of version switch, TSA should relay it as a Tx
Minimum Speed AVP (Ref [6])
Kelkar, et al. Expires December 22, 2006 [Page 6]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Maximum BPS (OCRQ) - MUST be RELAYED if negotiated by the First
session. In case of version switch, TSA should relay it as a Tx
Maximum Speed AVP (Ref [6])
Bearer Type (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First
session.
Framing Type (ICCN, OCCN, OCRQ) - MUST be RELAYED.
Called Number (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the
First session.
Calling Number (ICRQ) - MUST be RELAYED if negotiated by the First
session.
Sub-Address (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First
session.
Tx Connect Speed (ICCN, OCCN) - MUST be RELAYED. In case of version
switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type
74).
Physical Channel ID (ICRQ, OCRP) - MUST be either RELAYED if
negotiated by the First session, REGENERATED, or DROPPED.
Proxy LCP AVPs (ICCN) - All the Proxy LCP AVPs (Initial Received LCP
CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be
either all RELAYED, all REGENERATED or all DROPPED. If an AVP is
REGENERATED then it would mean the LCP was renegotiated; whereas,
RELAYED conveys the fact that it was passed along and was not
renegotiated.
Proxy Authentication AVPs (ICCN) - All the Proxy Authentication AVPs
(Proxy Authen Type, Proxy Authen Name AVP, Proxy Authen Challenge
Proxy Authen ID and Proxy Authen Response AVP) MUST be either all
RELAYED, all REGENERATED, or all DROPPED. If an AVP is REGENERATED
then it would mean the Authentication was renegotiated; whereas,
RELAYED conveys the fact that it was passed along and was not
renegotiated.
Call Errors (WEN) - MUST be RELAYED.
ACCM (SLI) - MUST be RELAYED.
Random Vector (All Messages) - MUST be either REGENERATED or DROPPED.
Kelkar, et al. Expires December 22, 2006 [Page 7]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Private Group ID (ICCN) - MUST be RELAYED if negotiated by the First
session.
Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED if negotiated by the
First session. In case of version switch, TSA should relay it as a
Rx Connect Speed AVP (Attribute Type 75).
Sequencing Required (ICCN, OCCN) - MUST be either REGENERATED or
DROPPED. In case of version switch, TSA should regenerate it as a
Data Sequencing AVP (Attribute Type 70).
Rx Minimum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by
the First session. In case of version switch, TSA should relay it as
a Rx Minimum Speed AVP (Ref [6]).
Rx Maximum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by
the First session. In case of version switch, TSA should relay it as
a Rx Maximum Speed AVP (Ref [6]).
PPP Disconnect Cause AVP (CDN) (Ref [3])- MUST be either RELAYED if
negotiated by the First tunnel/session or DROPPED if it's not
supported.
Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either
RELAYED if negotiated by the First tunnel or DROPPED if it's not
supported. The value of this AVP could be chosen based on 'PHB Code'
used (or to be used) on the tunnels, which the TSA is going to be
switching tunnels to. TSA need not use same PHB-to-DSCP mappings on
a First tunnel and Second tunnel.
Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either
RELAYED if negotiated by the First session or DROPPED if it's not
supported. The value of this AVP could be chosen based on 'PHB Code'
used (or to be used) on the sessions, which the TSA is going to be
switching sessions to. TSA need not use same PHB-to-DSCP mappings on
a First session and Second session.
LCP Want Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
negotiated by the First session or DROPPED if it's not supported.
LCP Allow Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
negotiated by the First session or DROPPED if it's not supported.
Extended Vendor ID AVP (Version 3) (All Messages) - MUST be either
REGENERATED or DROPPED.
Kelkar, et al. Expires December 22, 2006 [Page 8]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Message Digest AVP (Version 3) (All Messages) - MUST be either
REGENERATED or DROPPED.
Router Id AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED
or DROPPED.
Assigned Control Connection Id AVP (Version 3) (SCCRQ, SCCRP,
StopCCN) - MUST be either REGENERATED or DROPPED.
Pseudowire Capabilities List AVP (Version 3) (SCCRQ, SCCRP) - MUST be
either REGENERATED or DROPPED.
Local Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN,
CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED.
Remote Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP,
OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED.
Assigned Cookie AVP (Version 3) (ICRQ, ICRP, OCRQ, OCRP) - MUST be
either REGENERATED or DROPPED.
Remote End Id AVP (Version 3) (ICRQ, OCRQ) - MUST be either
REGENERATED or DROPPED.
Session Tie Breaker AVP (Version 3) (ICRQ, OCRQ) - MUST be either
REGENERATED or DROPPED.
Pseudowire Type AVP (Version 3) (ICRQ, OCRQ) - MUST be either
REGENERATED or DROPPED.
L2-specific Sublayer AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP,
OCCN) - MUST be either REGENERATED or DROPPED.
Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
- Data sequencing AVP (Attribute Type 70) is a L2TPV3 AVP equivalent
to the Sequencing required AVP (Attribute Type 39) in L2TPv2. In
L2TPv3, any endpoint (LAC or LNS i.e. LCCE) can send the Data
Sequencing AVP with the value 0 (no sequencing), 1 (sequencing only
for non-ip packets) or 2 (sequencing for all the packets). In L2TPv2,
only LAC can send the Sequencing Required AVP that requests the
sequencing for all the packets. If data sequencing is enabled on the
First session, then TSA should enable it on the Second session by
sending the appropriate AVP (i.e. REGENERATED). If data sequencing
is enabled on the First session, then TSA MAY choose (as decided by
the local policy) not to enable the sequencing on Second session i.e.
DROPPED. TSA SHOULD not enforce the sequencing but should send the
data sequencing AVP on the Second session, if it's enabled on the
Kelkar, et al. Expires December 22, 2006 [Page 9]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
First session. There is no requirement to have all hops use the
consistent sequencing configuration. As always TSA's local policy
would take precedence over the default behavior of "REGENERATED or
DROPPED"
Circuit Status AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN,
SLI) - MUST be either REGENERATED or DROPPED.
Preferred Language AVP (Version 3) (SCCRQ, SCCRP) - MUST be either
REGENERATED or DROPPED.
Tx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
- MUST be either RELAYED, REGENERATED or DROPPED. In case of version
switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type
24). If value is greater than 4 octets, it SHOULD be dropped.
Rx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
- MUST be either RELAYED if negotiated by the First session,
REGENERATED or DROPPED. In case of version switch, TSA should relay
it as a Rx Connect Speed AVP (Attribute Type 38). If value is
greater than 4 octets, it SHOULD be dropped.
Offset Size (Version 3) (ICRQ, ICRP, ORCQ, OCRP) (Ref [6]) - MUST be
either REGENERATED or DROPPED.
Tx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
RELAYED, REGENERATED or DROPPED. In case of version switch, TSA
should relay it as a Minimum BPS AVP (Attribute Type 16). If value
is greater than 4 octets, it SHOULD be dropped.
Tx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
RELAYED, REGENERATED or DROPPED. In case of version switch, TSA
should relay it as a Maximum BPS AVP (Attribute Type 17). If value
is greater than 4 octets, it SHOULD be dropped.
Rx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
RELAYED, REGENERATED or DROPPED. In case of version switch, TSA
should relay it as a Rx Minimum BPS AVP (Attribute Type 40). If
value is greater than 4 octets, it SHOULD be dropped.
Rx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
RELAYED, REGENERATED or DROPPED. In case of version switch, TSA
should relay it as a Rx Maximum BPS AVP (Attribute Type 41). If
value is greater than 4 octets, it SHOULD be dropped.
Failover Capability AVP (SCCRQ, SCCRP) (Ref [9]) - MUST be
REGENERATED based on the TSA's capabilities
Kelkar, et al. Expires December 22, 2006 [Page 10]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Tunnel Recovery AVP (SCCRQ) (Ref [9]) - MUST be REGENERATED based on
failover negotiations with the peer on an individual tunnel.
Suggested Control Sequence AVP (SCCRP) (Ref [9]) - MUST be
REGENERATED based on failover negotiations with the peer on an
individual tunnel.
Failover Session State AVP (FSQ, FSR) (Ref [9]) - MUST be REGENERATED
based on failover negotiations with the peer on an individual tunnel.
TSA ID AVPs (defined in this document) - MUST be STACKED. The local
TSA ID AVP is stacked to the incoming set of TSA ID AVPs.
4. Loop Detection
The Tunnel Switching Aggregator (TSA) ID AVP, Attribute Type 93,
could be used to detect if a session is looping in an L2TP tunnel
switched network. This AVP MUST be STACKED.
If this AVP was received in an incoming control packet (ICRQ, OCRQ)
then the TSA MUST check to see if it's own TSA ID (a configured
value) is present in the stack of incoming TSA ID AVPs. Upon finding
a match, the TSA MUST respond with a CDN carrying a Result Code
indicating 'Loop Detected' 26, and optionally a description
indicating the loop condition. A match comparison MUST only be
performed if TSA has configured non-null TSA ID.
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSA ID ... (maximum 64 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSA ID is a configured value (human readable string) with a maximum
length of 64 octets. It is administratively controlled to ensure its
uniqueness among all the inter-connected LACs, LNSs and TSAs. If no
value is configured then the AVP value MUST be of length 0.
This AVP MUST be either hidden (the H-bit can be either 0 or 1). The
M-bit for this AVP MUST be set to 0.
Kelkar, et al. Expires December 22, 2006 [Page 11]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
5. CDN Messages and L2TP tunnel Switching
To identify error conditions explicitly in the multi-TSA environment,
new error codes are defined. Existing error codes are not used
because they might trigger an unwarranted behavior depending upon why
it was generated. Error codes are defined as follows:
Next hop unreachable (Result Code 2, Error Code 10) - TSA MUST
disconnect the First tunnel/session with this Error Code, if next hop
is unreachable and no other alternative paths are available as
determined by the local policy.
Next hop busy (Result Code 2, Error Code 11) - TSA MUST disconnect
the First tunnel/session with this Error Code, if next hop
disconnects the Second tunnel/session with an error code 'TSA Busy'
or other indications from next hop indicate that it is too busy to
take more tunnels/sessions and no other alternative paths are
available as determined by the local policy
TSA busy (Result Code 2, Error Code 12) - TSA MUST disconnect the
first tunnel/session with this Error Code, if it is congested or
temporarily running out of resources.
In the case of multiple levels of TSAs, error code SHOULD be
propagated back until it reaches either the original LCCE or an
intermediate TSA, which has an alternate path. On the receipt of
error code, local policy on the LCCE or the intermediate TSA should
handle the fallback and use it for the congestion recovery design.
6. IANA Considerations
6.1. Control Message Attribute Value Pairs (AVPs)
This number space is managed by IANA as per section 2.1 of [10].
A summary of the new AVPs follows:
Control Message Attribute Value Pairs
Attribute
Type Description
--------- ------------------
93 Tunnel Switching Aggregator ID AVP
Kelkar, et al. Expires December 22, 2006 [Page 12]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
6.2. Result Code AVP Values
New L2TP Result Codes appear in section 4 and 5, which need
assignment by IANA as described in section 2.3 of [10].
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
Defined Result Code values for the CDN message are:
26 - Loop Detected
General Error Codes
10 - Next hop unreachable
11 - Next hop busy
12 - TSA busy
7. Security Considerations
TSA ID AVP could reveal the set of nodes that a given L2TP session is
traversing in the network.
If the AVPs described in this document are of concern then AVP
hiding, described in [1] MAY be used to help mitigate the security
threat; though it is not widely regarded as cryptographically secure,
[11] describes a more robust method for securing L2TP in general, and
should be used to encrypt all L2TP messages.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
Kelkar, et al. Expires December 22, 2006 [Page 13]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9. Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
10. Acknowledgments
Authors gratefully acknowledge the valuable contributions of: Mark W.
Townsley, Reinaldo Penno, Ly Loi and Marc Eaton-Brown. We would like
to thank Carlos Pignataro for a thorough review.
Kelkar, et al. Expires December 22, 2006 [Page 14]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
11. References
11.1. Normative References
[1] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G.
Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999.
[2] RFC 3931, J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
Protocol (Version 3)", March 2005.
[3] RFC 3145, Verma, et. al. "L2TP Disconnect Cause Information",
July 2001.
[4] RFC 3308, P. Calhoun, W. Luo, D. McPherson, K. Peirce, "Layer
Two Tunneling Protocol (L2TP) Differentiated Services
Extension", November 2002.
[5] RFC 3437, W. Palter, W. Townsley, "Layer-Two Tunneling Protocol
Extensions for PPP Link Control Protocol Negotiation", December
2002.
[6] C. Pignataro, Ed, "PPP Tunneling Using Layer Two Tunneling
Protocol Version 3" work in progress, draft-ietf-l2tpext-l2tp-
ppp-04.txt, May 2006.
[7] RFC 1661, W. Simpson, "The Point-to-Point Protocol (PPP)", STD
51, July 1994.
[8] RFC 3301, Y. T'Joens, B. Sales, P. Crivellari, "Layer Two
Tunnelling Protocol (L2TP): ATM access network extensions",
June 2002
[9] V. Jain, Ed, "Fail Over extensions for L2TP failover" work in
progress, draft-ietf-l2tpext-failover-06.txt, October 2005.
11.2. Informative References
[10] BCP0068, Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations
Update" RFC3438, BCP0068, December 2002
[11] RFC 3193, B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth,
"Securing L2TP using IPsec", November 2001
Kelkar, et al. Expires December 22, 2006 [Page 15]
Internet-Draft PPP over L2TP Tunnel Switching June 2006
Author's Addresses
Mahesh Kelkar
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: mkelkar@juniper.net
Tom Mistretta
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: tmistretta@juniper.net
Paul Howard
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: phoward@juniper.net
Vipin Jain
Riverstone Networks
5200 Great America Parkway
Santa Clara, CA 95054
Email: vipinietf@yahoo.com
Kelkar, et al. Expires December 22, 2006 [Page 16]
