Network Working Group Reinaldo Penno Internet-Draft Nortel Networks Expires Dec 2003 Vipin Jain Riverstone Networks Ly Loi Tahoe Networks Marc Eaton-Brown Devoteam FrontRunner June 2003 L2TP Tunnel Switching draft-ietf-l2tpext-tunnel-switching-04.txt 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 and expires Dec 2003. Please send comments to the L2TP mailing list (l2tpext@ietf.org). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 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 layer2 characteristics or administrative policies, to a different LNS. This document introduces the L2TP tunnel switching nomenclature, defines the behavior of standard AVPs [L2TP] in tunnel switching deployment, and proposes protocol extensions for inter-operable tunnel switching implementation. Jain, et al. expires Dec 2003 [Page 1] INTERNET DRAFT L2TP Tunnel Switching August 2002 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 1 2. Purpose of tunnel switching............................... 1 3.0 AVP Behavior.......................................... 1 4. Proposed Extensions for tunnel switching.................. 1 5. StopCCN/CDN Messages and L2TP tunnel Switching............ 1 4. IANA Considerations....................................... 1 5. Security Considerations................................... 1 6. Author's Addresses........................................ 1 7. Acknowledgments........................................... 1 8. References................................................ 1 Appendix A................................................... 1 Terminology Tunnel Switching Aggregator (TSA): These are the devices that switch the PPP packets on an incoming L2TP session/tunnel on to another L2TP session/tunnel. TSA functions as an LNS for the inbound tunnel and as a LAC for the outbound tunnel. Inbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LNS. Outbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LAC. 1. Introduction [L2TP] allows processing of PPP packets to be divorced from the termination of the layer2 circuit. L2TP tunnel switching facilitates moving the termination point of a PPP session further on to another LNS that is possibly unknown to the first LAC. It does so by re- tunnelling the PPP session within another L2TP tunnel to a different LNS. The knowledge of whether to switch a PPP session to another L2TP tunnel can be static or dynamic (for example, during PPP session is establishment). PPP User LAC TSA LNS [LNS LAC] |---- PPP----| |---- PPP/L2TP ----| |-- PPP --| |----- PPP/L2TP -----| |------ tunnel switching ------| Jain, et al. expires Dec 2003 [Page 2] INTERNET DRAFT L2TP Tunnel Switching August 2002 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]. The TSA, based on the local policies, determines if the incoming session should be further tunnelled. 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 Id, Session Id) pair to a corresponding outgoing (Tunnel Id, Session Id). 2. Purpose of tunnel switching Tunnel switching enables redirection of PPP sessions in an L2TP network based on administrative policies as described below. - L2TP tunnel switching divorces the location of the LAC that implements administrative policies. LAC may not always have the administrative control/capability to know the LNS that would be most appropriate to terminate a PPP session. For example, PC based LACs might not be aware of the service provider's policies. It may not be desirable to expose such policies to the LAC that resides on the customer premises, or a LAC might not such exhibit such a rich functionality. Administrative policies could be based on traffic (for example, to balance the traffic across multiple LNSs), class of service (for example, to allow preferred sessions onto distinguished LNSs), or PPP parameters (for example, to direct traffic for different ISPs to different LNS based on PPP user information). - Some deployments, where the administrative domain of a LAC are not the same as that of an LNS, tunnel switching helps hide the internal network connectivity from one another. For example, if a PPP connection provider, an ILEC or a CLEC would like to expose only a set of LACs (that are actually TSA devices) to the ISP (that terminates PPP connections). It also eases the configuration/manageability across different Jain, et al. expires Dec 2003 [Page 3] INTERNET DRAFT L2TP Tunnel Switching August 2002 administrative domains. For example, for every new LAC added in the ILEC's network, an ISPs do not need to reconfigure their LNSs. Since for them the LAC could always be the TSA. - Layer2 sessions wholesaling: L2TP tunnel switching allows using a common L2TP Tunnel on the LAC for sessions that are eventually destined to different LNSs (ISPs). This enables the PPP connection provider to bundle PPP sessions belonging different ISPs on to a single L2TP tunnel. 3.0 AVP Behavior An incoming AVP may be handled in four ways - it could be relayed, dropped, regenerated, or stacked. They are defined as follows. - RELAYED AVP: AVP value is forwarded transparently if it was present in the incoming message. To respond with an accurate value to be RELAYED, TSA MAY defer defer the reply to an incoming message (inbound side) until it gets the response for a corresponding reuqest on the outbound side. For example, Bearer Capabilities in SCCRP message sent on inbound tunnel could be derived from what was obtained in SCCRP from outbound tunnels. - DROPPED AVP: AVP is dropped if it was present in the incoming message. - REGENERATED AVP: AVP value is ignored upon receipt and a new vlaue is regenerated as defined by [L2TP] for the outbound message. Though the value of an AVP in the outbound message could result in the same value that arrived in, it happens with TSA knowing it. - STACKED AVP: In a tunnel switched environment, TSAs makes it transparent for the LNS to know if a session was tunnel switched. However, some situations might require the participating nodes to know the AVP Values that were encoded by nodes along the tunnel switched path. Under such circumstances TSA might append a new value of an existing AVP thereby creating multiple instances of a given AVP. When stacking its own AVP, typically all incoming AVPs in the stack are copied, however if TSA couldn't copy all AVPs then it SHOULD not copy any one of them. As an example, TSA Id AVP, a new AVP defined later in this document, helps prevent loops in L2TP Tunnel Switched Network. To detect a loop it must know TSA Id AVPs generated by nodes in the tunnel switched path. And so while regenerating this AVP, TSA preserves the incoming set of AVPs and stack its own value in it when transmitting a control Jain, et al. expires Dec 2003 [Page 4] INTERNET DRAFT L2TP Tunnel Switching August 2002 messsage (ICRQ, OCRQ) out. 3.1 IETF Vendor AVPs This section defines the behavior of AVPs according to the guidelines in section 3.0. It describes the behavior of AVPs defined in [L2TP], [RFC3437], [RFC3308], and [RFC3145]. Message Type (All Messages) - MUST be REGENERATED Random Vector (All Messages) - MUST be REGENERATED Result Code (CDN, StopCCN) - SHOULD be REGENERATED based on recommendations discussed in section 5. Protocol Version (SCCRQ, SCCRP) - MUST be REGENERATED. This would allow TSA to switch sessions when inbound and outbound tunnels use different versions of the L2TP protocol. Framing Capabilities (SCCRQ, SCCRP) - On outbound tunnels, the TSA SHOULD REGENERATE this AVP based upon Framing Capabilities of one or more inbound tunnels whose sessions could be switched to the outbound tunnel. Similarly, the inbound tunnel AVP SHOULD be REGENERATED by the TSA based upon the Framing Capabilities of the outbound tunnel. Bearer Capabilities (SCCRQ, SCCRP) - For the outbound tunnel, the AVP SHOULD be REGENERATED based upon Bearer Capabilities of one or more inbound tunnels whose sessions may be switched to the outbound tunnel. Similarly, the inbound tunnel AVP SHOULD be REGENERATED by the TSA based upon the Bearer Capabilities of the outbound tunnel. Tie Breaker (SCCRQ) - MUST be REGENERATED Firmware Revision (SCCRP, SCCRQ) - MUST be REGENERATED. Host Name (SCCRP, SCCRQ) - MAY be RELAYED, REGENERATED, or DROPPED. Vendor Name (SCCRP, SCCRQ) - SHOULD be REGENERATED. Assigned tunnel ID (SCCRP, SCCRQ, StopCCN) - MUST be REGENERATED. Receive Window Size (SCCRQ, SCCRP) - MUST be REGENERATED. The value of this AVP could be choosen based on Receive Window Sizes of the tunnels the TSA is going to be switching sessions to. Appendix A has more information on congestion control in L2TP tunnel switching environments. Jain, et al. expires Dec 2003 [Page 5] INTERNET DRAFT L2TP Tunnel Switching August 2002 Challenge (SCCRP, SCCRQ) - MUST be REGENERATED. Challenge Response (SCCCN, SCCRP) - MUST be REGENERATED. Q.931 Cause Code (CDN) - MUST be either RELAYED or DROPPED. Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) - MUST be REGENERATED. Call Serial Number (ICRQ, OCRQ) - SHOULD be RELAYED. It would best serve the intended purpose of this AVP and facilitate easier debugging. Minimum BPS (OCRQ) - MUST be RELAYED. Maximum BPS (OCRQ) - MUST be RELAYED. Bearer Type (ICRQ, OCRQ) - MUST be RELAYED. Framing Type (ICCN, OCCN, OCRQ) - MUST be RELAYED. Called Number (ICRQ, OCRQ) - SHOULD be RELAYED. Calling Number (ICRQ) - SHOULD be RELAYED. Sub-Address (ICRQ, OCRQ) - SHOULD be RELAYED. (Tx) Connect Speed (ICCN, OCCN) - MUST be RELAYED Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED Physical Channel ID (ICRQ, OCRP) - MAY be RELAYED, REGENERATED, or DROPPED. Private Group ID (ICCN) - MAY be RELAYED, REGENERATED, or DROPPED. Sequencing Required (ICCN, OCCN) - SHOULD be REGENERATED. Initial Received LCP CONFREQ (ICCN) - MAY be RELAYED, REGENERATED, or DROPPED. Proxy LCP AVPs (Initial Received LCP CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be all RELAYED, all REGENERATED or all DROPPED. Last Sent LCP CONFREQ (ICCN) - MUST be either RELAYED or DROPPED. Last Received LCP CONFREQ (ICCN) - MUST be either RELAYED or DROPPED. Proxy Authen Type (ICCN) - MAY be RELAYED, REGENERATED, or DROPPED. Proxy Authentication AVPs (Proxy Authen Name AVP, Proxy Authen Challenge Proxy Authen ID and Proxy Authen Response AVP) Jain, et al. expires Dec 2003 [Page 6] INTERNET DRAFT L2TP Tunnel Switching August 2002 MUST be all RELAYED, all REGENERATED, or all DROPPED. Proxy Authen Name (ICCN) - MUST be either RELAYED or DROPPED. Proxy Authen Challenge (ICCN) - MUST be either RELAYED or DROPPED. Proxy Authen ID (ICCN) - MUST be either RELAYED or DROPPED. Proxy Authen Response (ICCN) - MUST be either RELAYED or DROPPED. Call Errors (WEN) - MUST be either RELAYED or DROPPED. ACCM (SLI) - MUST be either RELAYED or DROPPED. PPP Disconnect Cause AVP (defined by [RFC 3145]) - MUST be either RELAYED or DROPPED. LCP Want Options (defined by [RFC 3437]) - MUST be either RELAYED or DROPPED LCP Allow Options (defined by [RFC 3437] - MUST be either RELAYED or DROPPED Control Connection DS AVP (defined by [RFC 3308]) - MUST be REGENERATED. The value of this AVP could be chosen based on 'PHB Code' (section 6.0 [RFC 3308]) used (or to be used) on the tunnels the TSA is going to be switching sessions to. TSA need not use same PHB-to-DSCP mappings on an incoming tunnel and outgoing tunnel. Session DS AVP (defined by [RFC 3308]) - MUST be REGENERATED. The value of this AVP could be chosen based on 'PHB Code' (section 6.0 [RFC 3308]) used (or to be used) on the tunnels the TSA is going to be switching sessions to. TSA need not use same PHB-to-DSCP mappings on an incoming tunnel and outgoing tunnel. TSA Id AVPs (defined in this document) - MUST be REGENERATED. The value of this AVP is regenerated by stacking the local TSA Id AVP to the incoming set of TSA Id AVPs. 4. Proposed Extensions for tunnel switching In this section we present new AVPs that simply permits enhanced and interoperable tunnel switching support. Additionally proposing to solve some trade-offs that arise by deploying L2TP tunnel switching. 4.1 Tunnel Capacity AVP (All Messages) Jain, et al. expires Dec 2003 [Page 7] INTERNET DRAFT L2TP Tunnel Switching August 2002 The tunnel Capacity AVP, Attribute Type TBD, indicates the sesion capacity of the sender over an L2TP tunnel. LAC/LNS could interpret this AVP to know if the peer it is connected to has capacity of receive any more sessions. The absolute value in this AVP is opaque to the peer, however relative (current to maximum) could be interpreted as a measure of peer's capacity. It could be an indicative of bandwidth, session capacity, administrative limit, etc. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Profile Name ... (arbitrary length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Service Profile Name is a configured (e.g. ISP or Domain name) unique name between the TSA and its peer. It is up to 256 bytes long, but MUST be at least 1 octet. Assuming that a tunnel might carry sessions for multiple Service Profiles, this AVP allows specifying the capacity for an individual Service Profile. The Maximum Capacity indicates the maximum (reference) capacity of the TSA for a service profile. Its value is opaque to the TSA's peer. For example, an implementation could choose to use this to be an indicative of maximum number of sessions, maximum bandwidth, etc. The Current Capacity indicates the current capacity of the TSA. Like Maximum Capacity AVP its value is also opaque to the TSA's peer. The value of this AVP indicates the relatively (relative to Maximum Capacity) how many more sessions the TSA could handle. This AVP MAY be hidden (the H-bit can be either 0 or 1). The M-bit for this AVP MUST be set to 0. 4.2 TSA ID AVP (ICRQ, OCRQ) The TSA ID AVP, Attribute Type TBD, 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 then the Jain, et al. expires Dec 2003 [Page 8] INTERNET DRAFT L2TP Tunnel Switching August 2002 TSA MUST check to see if its 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' TBD, and optinally a description indicating the loop condition. 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 ... (arbitrary length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSA Id is a configured value (human readable string) that is administratively controlled to ensure its uniqueness (for every TSA) in an L2TP network. This AVP MAY be hidden (the H-bit can be either 0 or 1). The M-bit for this AVP MUST be set to 0. 5. StopCCN/CDN Messages and L2TP tunnel Switching The administrative policies on the TSA would always supersede how a TSA should be interpreting or not interpreting the CDN/StopCCN messages generated by it's peer. However, the recommended behavior is that, if a TSA receives a StopCCN/CDN message from a peer, it SHOULD convey the same message received on inbound or outbound tunnel. The Result Code AVP, which is an indicative of the type of error, should be relayed as well. The following sections recommends the more specific situations and on how the StopCCN/CDN Error Codes are to be interpreted. 5.1 TSA receiving CDN Error Code-7 from an LNS The TSA should try to establish the session on one of the remaining LNS peers as determined by the configured policies on the TSA - if there are none available it should generate a CDN message for the LAC with the Error Code-7. 5.2 TSA reaching the aggregate session limit. In this situation the TSA SHOULD generate a CDN message with Error Code-4 for the LAC. 5.3 TSA failing to establish an outbound tunnel Jain, et al. expires Dec 2003 [Page 9] INTERNET DRAFT L2TP Tunnel Switching August 2002 The TSA should try to establish the session on one of the remaining LNS peers as determined by the configured policies on the TSA - if there are none available it should generate a CDN message for LAC with the Error Code-1. 4. IANA Considerations This document requires two new "AVP Attributes" to be assigned through IETF Consensus [RFC2434] as indicated in Section 5 of [RFC2661]. These are: Tunnel Capacity AVP (section 4.1) Loop Prevention AVP (section 4.2) This document defines no additional number spaces for IANA to manage. 5. Security Considerations L2TP tunnel switching introduces following security issues: - Tunnel Capacity AVP could reveal the capacity of various nodes in the network. Someone can abuse this AVP to give false impressions regarding current capacity to the neighboring nodes there by launching denial of service attack. - TSA Id AVP could reveal the set of nodes a given L2TP session is traversing in the network. AVP hiding, described in [L2TP] MAY be used to help mitigate this, though it is not widely regarded as cryptographically secure. [RFC3193] describes a more robust method for securing L2TP in general, and should be used to encrypt all L2TP messages if access to the information sent within the AVPs described in this document is of concern. 6. Author's Addresses Reinaldo Penno Nortel Networks 2305 Mission College Blvd Santa Clara, CA 95054 Phone: +1 408.565.3023 Email: rpenno@nortelnetworks.com Ly Loi Tahoe Networks 3052 Orchard Drive San Jose, CA 95134 Jain, et al. expires Dec 2003 [Page 10] INTERNET DRAFT L2TP Tunnel Switching August 2002 Phone: +1 408.944.8630 Email: lll@tahoenetworks.com Marc Eaton-Brown Devoteam FrontRunner Ltd. Union House 182-194 Union Street London SE1 OLH Phone: +44 7989 498337 Email: mebrown@devoteam-frontrunner.com Vipin Jain Riverstone Netowrks 2903 Bunker Hill Ln #210 Santa Clara, CA 95054 Phone: +1 408.878.0464 Email: vipin@riverstonenet.com 7. Acknowledgments Thanks to W. Mark Townsley of Cisco Systems for guiding and and providing useful feedback. Tom Mistretta, Mark Townsley, and Neil McGill suggested providing support to stack AVPs. Mark Llacuna of Nortel Networks provided input to handle congestion in Tunnel Swiched environment. 8. References [L2TP] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661, August 1999. [PPP] RFC 1661, Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC 3145] RFC 3145, Verma, et. al. "L2TP Disconnect Cause Information", July 2001 Appendix A Considerations for Congestion Avoidance [L2TP] recommends slow start and congestion avoidance techniques be used on the control connection. However, that alone may not be sufficient to deal with congestion problems in tunnel switched deployments. Primarily because a TSA terminates the control connection and initiates another one. For example, while switching incoming calls, outbound tunnel might be more congested than inbound tunnel, in which case even if two tunnels are implementing slow start Jain, et al. expires Dec 2003 [Page 11] INTERNET DRAFT L2TP Tunnel Switching August 2002 and congestion avoidance procedures, the effectiveness of congestion control in L2TP Tunnel Switched path (first LAC to last LNS) might not be achieved. For example if an outbound tunnel (for outgoing calls) is not able to accept any more sessions, then TSA should stop accepting new sessions that would be tunnel switched to that outbound tunnel. Because if it does not do so, it might waste its resources processing the session connects and disconnects (due to timeouts). If those sessions are switched then it could be worsening the congestion (and tunnel's reliable delivery mechanism for control packets), by queueing unwanted ICRQs and CDNs to the outbound tunnel. To avoid congestion, if a tunnel stops accpeting any more calls (incoming/outgoing) or if a particular LNS is experiencing congestion, then TSA could limit the rate of incoming connections on the inbound tunnel. It is recommended that a TSA utilize following mechanisms to mitigate the congestion in the network and have acceptable rate of L2TP session establishment in the tunnel switched environment: - It could stop accepting new ICRQs and issue the CDNs with Result Code 2 with Error Code 4, indicating it is temporarily running out of resources. This would relieve the TSA from accepting more sessions till the tunnel could accept more sessions up. - A better way to avoid congestion would be to detect the problem before it becomes worse. Tunnel Capacity AVP, defined in section 4.1 allows TSA, LAC or LNS to indicate its current capacity, which could be utilized by TSA to reconstruct the same AVP to pass on to its neighbors so they can control the rate at which sessions get established. For example, consider following setup: [ LAC-1 ] <------> [ ] [ LAC-2 ] <------> | TSA | <------> [ LNS-1 ] [ ] <------> [ LNS-2 ] During tunnel establshment LNS-1, LNS-2, and TSA advertises their current capacity (via Tunnel Capacity AVP) to be 100 out of a Maximum Capacity of 100. Say, over the period some sessions get established and TSA switches them to LNS-1 or LNS-2 and TSA reaches its 50% of total capacity. LNS-1 and LNS-2 starts current capacity as 50 to the TSA. And TSA starts advertising its Currnet Capacity as 50% to LAC-1 and LAC-2. Assume, now LNS-2 experiences resource crunch (cpu, memory, etc.) and it concludes it will be in its best interest to not accept any more L2TP sessions. Or assume, TSA experiences congestion which it deduces based on number of control packets retransmitted in a given time or transmit control queues building up beyond high water mark. In such situations LNS-2 could advertise its current capacity to be 0%, which TSA can interpret as to not switch any more sessions to Jain, et al. expires Dec 2003 [Page 12] INTERNET DRAFT L2TP Tunnel Switching August 2002 LNS-2. Further, the TSA could advertise its 'Currnet Capacity' to be 75 (based on the fact that it can switch sessions to only two LNSs and they are at 0% capacity and 50% capacity) to LAC-1 and LAC-2. This could result into following improvements: + LAC-1 and/or LAC-2, if they interpret Tunnel Capacity AVP, can defer establishing sessions to the TSA, till TSA has more capacityi, i.e. as soon as the congested LNSs' network opens up. + TSA itself can start switching sessions to LNS-1 instead of LNS-2 knowing LNS-2 has reached its maximum capacity. If LNS-1 is also experiencing the congestion, then TSA might stop accpeting new sessions till all of the outbound tunnels opens up. Jain, et al. expires Dec 2003 [Page 13]