Subject: [L2tpext] Comments on draft-ietf-l2tpext-tunnel-switching-01.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 19 Feb 2002 15:34:12 +0100

I think that this Tunnel Switch document needs some work before we can move
forward. 

Tunnel switching is certainly being used today, in multivendor environments,
without any formal standardization. We have been doing this for a while, so
documenting this as a "Best Current Practices," for tunnel switching is
certainly a reasonable start. The advantages/disadvantages sections in this
document are a good beginning, though they still read a bit like a marketing
document selling tunnel switches. I think we need to be a little more objective
with the technology, pointing out all of the potential pitfalls as well as the
advantages.

As for protocol work, I think we should limit ourselves to how and what
information we should propogate through a tunnel switch. Perhaps one step would
be to identify whether an AVP is to be propogated exactly as received, altered
with a new value at the tunnel switch, "stacked" in a list at each tunnel switch
node (providing a logical traceback), or is left up in that air as
implementation-specific. A realistic beginning might be to simply identify these
classes of AVPs and give them names. Then, we can worry about which AVPs fall
into which categories. New messages and L2TP state machine events should be
addressed in a general manner as well.

As an aside, a good portion of this document details LAC/LNS load balancing and
session limits that I think is quite applicable with or without a tunnel switch.
We might want to simply move this to a different document, or at least relegate
it to a "load-balancing considerations" section.

Please see WMT inline for more specific comments.

Thanks,

- Mark

Network Working Group                                           V. Jain
Internet-Draft                                                 R. Penno
Expires: March 2002                                          S. McGeown
                                                        Nortel Networks

                                                                 Ly Loi
                                                          TahoeNetworks
 
                                                            Mark Rayson
                                                 BT Network and Systems

                                                       Marc Eaton-Brown 
                                                  FrontRunner Solutions

                                                        September, 2001 

                          L2TP Tunnel Switching
               draft-ietf-l2tpext-tunnel-switching-01.txt

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.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   For some time now several equipment manufactures have been 
   implementing what is called L2TP tunnel switching or L2TP multihop.
   Although this technology has several applications and is quite 
   widespread, there has been no effort to standardize the nomenclature 
   and methods associated with it. 
   The goal of this document is to achieve a common denominator in what
   is tunnel switching, its advantages and nomenclature associated with
   it.

WMT The abstract could use some work to read a little better... What about
something like:

L2TP "Tunnel Switching" or "Multihop" is the process of forwarding an L2TP
tunneled data link from the logical termination point of one L2TP session onto
another at an L2TP-aware intervening node. This action has the affect of
directing a session, or groups of sessions, based on L2TP or tunneled data link
characterisics. This document will provide some examples of where this technique
might be useful in various network environments, offer guidelines to Tunnel
Switch implementors, and define associated tunnel switching nomenclature, and
provide protocol extensions to help facilitate tunnel switching.

Penno, et al.                                                  [Page 1]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

Specification of Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [3].

Table of Contents

   1.      What is L2TP Tunnel Switching. . . . . . . . . . . . . . . 3
   2.      Tunnel Switching Nomenclature . . . . . . . . . . . . . . .3
   3.      Why L2TP Tunnel Switching. . . . . . . . . . . . . . . . . 4
   4.      Disadvantages of Tunnel Switching. . . . . . . . . . . . . 5
   5.      Extensions to enhance tunnel switching support. . . . . . .6
   6.      References . . . . . . . . . . . . . . . . . . . . . . . .11
   7.      Acknowledgments. . . . . . . . . . . . . . . . . . . . . .11
   8.      Author's Addresses. . . . . . . . . . . . . . . . . . . . 11 
           Full Copyright Statement. . . . . . . . . . . . . . . . . 12

Penno, et al.                                                  [Page 2]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

1. What is L2TP Tunnel Switching

   L2TP tunneling allows processing of layer2 packets to be divorced 
   from the termination of layer2 circuit. L2TP tunnel switching 
   facilitates moving the termination of a layer2 session further to 
   another LNS potentially unknown to the first LAC. It does so by re-
   tunneling the layer2 session over another L2TP tunnel to a different 
   LNS. The knowledge of whether to switch a layer2 session to another 
   L2TP tunnel can be static or dynamic (for example when a PPP session 
   is established). 

 _______           _______            _______ _______          _______
|  L2   |         |       |          |       |       |        |       |
| User  |         | LAC A |          | LNS A | LAC B |        | LNS B |
|_______|         |_______|          |_______|_______|        |_______|

|------ L2- ------|

                  |---- L2/L2TP ----|

                                     |-- L2 --|

                                              |------ L2/L2TP -------|

                                     |------- tunnel switching ------|

   The figure above presents a typical tunnel switching scenario. The 
   user opens a layer2 (for example PPP) session to LAC A, which puts 
   the layer2 session into a L2TP tunnel that terminates on LNS A. If 
   LNS A decides to further tunnel the layer2 session, it puts the 
   layer2 session on another L2TP tunnel originating on LAC B and 
   terminating on LNS B. LNS A and LAC B reside on the same device.  

   The process of getting the layer2 session terminating on LNS A and 
   further tunneling it to another LNS, in the example above LNS B, is 
   called tunnel switching. 

2. Tunnel Switching Nomenclature

   Ingress Tunnel Aggregator (ITA): These devices are represented by 
   the first layer of LACs, represented in the picture by LAC A. This 
   is he node which terminates layer2 circuit and initiates the first 
   L2TP tunnel.

Penno, et al.                                                  [Page 3]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

   Tunnel Switching Aggregator (TSA): These are the devices that act as 
   LNS as well as LAC for a particular layer2 session therefore it 
   typically re-tunnels layer2 session to another LNS. The TSA is 
   composed of two parts: the TSA-LAC and the TSA-LNS.

   Egress Tunnel Aggregator (ETA): These are devices that terminate the 
   layer2 session. They are represented in the picture by LNS B.

3. Why L2TP Tunnel Switching

WMT Please make the title of this section analogous to that in Section 4. e.g
section 4 reads: "Disadvantages of L2TP tunnel switching" So, this should simply
read "Advantages of L2TP Tunnel Switching" and the following line deleted (as 
it is then made obvious and redendant). 

   This section discusses the advantages of L2TP tunnel switching. 

WMT General comment on this section: It seems a little too much like a marketing
document selling a tunnel switch. I think it should focus a little more on the
protocol issues.

 * Often, the administrative domain of a LAC, an ILEC or CLEC, is not  
   same as that of LNS, typically an ISP terminating subscriber's    
   Layer2 connection. In such situations, a multi tier deployment with
   tunnel switching helps the LEC (ILEC or CLEC) mask its internal 
   network architecture from the ISPs. In particular, it eases the 
   configuration across different administrative domain. For example,
   for every new ITA added in the system, ISP doesn't need to 
   reconfigure its LNSs  - for them LACs are always same (TSAs).

 * L2TP tunnel switching divorces the location of "decision-maker" LNS.
   Certain deployments do not have decision-making capabilities on LAC 
   For example PC based LACs might not have mechanisms to be configured
   with policies a service provider wants to adopt; On other hand, it
   might not be desirable to expose such policies to every customer LAC 
   CPE. The decision to choose the right LNS, for load balancing or 
   other administrative purposes, when multiple LNSs are available, 
   might not be done best by the first LAC always. Not all LACs should 
   be expected to exhibit such rich functionality, features and 
   flexibility. 

WMT Rather than "decision-making" could we say "policy"? From a protocol
perspective, the above two points below might simply be collapsed into a
reference that a TSA is quite useful if one's policy is distributed across
management domains or various equipment. Suggesting that an LAC should or should
not exhibit a given set of rich functionality might be going a bit too far...
It's pretty easy for the equipment to include the software to *make* the policy
decision, quite another thing for an administrative domain to *have* the
necessary information to make the decision. The latter I think is a reasonable
guidelines for vendors to build equipment and protocols for, the former strikes
me a bit as laziness :-)

 * L2TP tunnel switching allows using a common L2TP tunnel on LAC for 
   sessions that are actually destined to different LNSs. This enables
   wholesaling layer2 sessions destined to any LNS go over a few 
   tunnels.

WMT The above point is somewhat obvious, and is certainly redundant with the
exhaustive tunnel reduction analysis that follows, I think it may be omitted.

 * L2TP tunnel switching might reduce the total number of tunnels in a 
   meshed environment. The advantage of fewer tunnels would primarily 
   be in a configuration and provisioning ease. The reduction of 
   tunnels can be seen from three different angles, from the entire 
   system, from the ITA and from the last ETA point of view. 

WMT I would suggest something like this for the point above:

"L2TP tunnel switching may be used to reduce the number of tunnels in a fully
meshed environment. An advantage here may be reflected in a lesser number of
LAC to LNS relationships one has to manage by providing an aggregate point
for configuration, network management, and provisioning.  This could be of
particular concern when tunnels cross administrative boundaries. An analysis of
the this point is given from three different perspectives: Entire System, ITA,
and ETA."

 * Entire System

   In a traditional deployment, the total number of L2TP sessions   
   between N LACs (ITA) and M LNSs (ETA) is N*M, assuming there is 
   at least one layer2 session from every LAC that needs to be 
   terminated on each LNS. With tunnel switching, this number can be
   reduced to (#ETA + #ITA) * (#TSA).

Penno, et al.                                                  [Page 4]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

     Of course the advantage on the reduction of tunnels in the system 
     only holds when the (#TSA)is less than the number of LNS1s (see 
     picture below). 

   * ITA

     From the first layer of LACs point of view, the reduction in the 
     number of tunnels holds whenever ITA*TSA < TSA*ETA, which is true 
     for most deployments.

   * ETA

     On the other hand, the advantage on the reduction of tunnels from 
     the last LNS (LNS2) point of view in comparison with LNS1 is 
     considerable, since the M*(#TSA) is usually much less than M*N. 

 ____           ______            ______ ______                ______
| PC |         | LAC1 |__________| LNS1 | LAC2 |______________| LNS2 | 
|____|         |______|\      ___|______|______|              |______|
                        \    /
                         \__/
                        ___/\                        
 ____           ______ /     \    ______ ______                ______
| PC |         | LAC1 |_______\__| LNS1 | LAC2 |______________| LNS2 | 
|____|         |______|          |______|______|              |______|  
                   .       .             .                        .        
                   .                     .                        .
                   .     /   \           .                        .
 ____           ______  /     \   ______ ______                ______
| PC |         | LAC1 |/       \_| LNS1 | LAC2 |______________| LNS2 |  
|____|         |______|          |______|______|              |______|

4. Disadvantages of L2TP tunnel switching:

 * Focal point of failure: As TSA aggregates more and more tunnels, 
   it becomes a focal point for failure, as compared to if ITAs had 
   tunnels to ETAs directly. 

 * Multiple Negotiations: Subscriber might be authenticated/LCP 
   multiple times because each TSA might have its own criteria to 
   determine if subscriber should be authenticated or if LCP parameters 
   negotiated (proxy-LCP) are appropriate. 

WMT I might call this "increased signalling" or some such. "Negotiation" is
fairly PPP specific, and is OK for the example that follows. But, this is also
true for L2TP signalling (or any other protocol that L2TP might carry which has
to complete before forwarding may occur).

Penno, et al.                                                  [Page 5]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

 * Session limit within an L2TP tunnel: Bundling sessions within a 
   single L2TP tunnel makes one deployment more likely to hit the 65k 
   limit inherent of the L2TP protocol faster than if you have unique 
   tunnels. Care should be taken while deploying L2TP tunnel switching 
   to not exceed this limit due to aggregation of various sessions in 
   limited number of tunnels.

WMT Other disadvantages:

* Packet switching performance may be inhibited. Unless the TSA is operating at
line rate, or at least as fast as the native packet switching performance of the
underlying network the L2TP packets are traversing, then there may
be a performance degredation at the TSA.

* Routing may be non-optimal. Passing through the TSA may require a packet to
traverse more hops than is optimal before reaching its final destination. Note
that this is an issue with tunneling in general, that is simply further
mitigated 
by the fact that there are more tunnels to steer through.

* Session source tracing. A session which passes through a TSA loses much of its
source destination information from an L2TP perspective. Thus, if there is a
problem with a given session at an LNS, it becomes more difficult to trace the
session back to the original LAC from which it began.

* L2TP parameters lossed in TSA transit. RFC2661 does not specify how exactly to
propogate information arriving in L2TP AVPs from one session or control
connection to another at a TSA. Thus, there may be inconsistency in what
information is propogated, omitted, or replaced at each TSA. (This document
should probably address this concern specifically).

5. Extensions to enhance tunnel switching support

   In this section we present new AVPs (and motivation behind them) 
   that can enhance tunnel switching support beyond what is usually 
   deployed today. These extensions are only applicable for L2TP tunnel 
   switching.

5.1 Problem Statement

   When an TSA <-> ETA tunnel collapses for one reason or another (link 
   failure, etc), the initial ITA<->TSA link continues to function 
   normally, even though there is nowhere for the layer2 traffic to go 
   once it gets to this TSA point. This causes a major disruption of 
   service impact, as several subscribers who were knocked off the 
   network will not be able to get back on the network.  This creates a 
   "black hole" condition, which directs all new sessions to the TSA, 
   which has no path to the ETA. All new session attempts for this ETA 
   fail.

WMT Given that this is a "Problem Statement" shouldn't it at least be defined as
a disadvantage? Perhaps with a forward reference to how we are going propose
fixing it later in the document.

5.2 Tunnel Set Dependency

   A new object L2TP Dependency should be defined to maintain a 
   relationship between the ITA to TSA tunnels and the TSA to ETA 
   tunnels. 

   This object can be utilized by ITA to route away L2TP sessions from 
   failures in the TSA to ETA connection. Information about failures 
   between TSA and ETA should be provided to ITA through a new set of 
   AVPs defined below. 

5.3 Tunnel Dependency Load AVP (All Control Messages)
 
   The Tunnel Dependency Load AVP, Attribute Type XS, indicates the 
   capacity to carry L2TP sessions from TSA to ETA for certain 
   "service profile" (e.g., a ISP or Domain Name)

Penno, et al.                                                  [Page 6]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Number of Services Profiles                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SPN Length    | Service Profile Name ... (arbitrary length)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Maximum  Load                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Current Load                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Number of Services Profiles indicates the number of 
      occurrences of the tuple (Service Profile Name, Maximum Load, 
      Current Load).

      The Service Profile Name is up to 256 bytes long, but MUST be at 
      least 1 octet. This name should be as broadly unique as possible, 
      because the tunnels between ITA to TSA can contain sessions for 
      different service profiles. 

      The Maximum Load indicates the Maximum reference capacity for a 
      service profile. It could be the number of maximum tunnels 
      supported by the system at a point in time, maximum amount of 
      bandwidth, or some other metric that reflects ratio 

      The Current Load indicated the current capacity of the system, it 
      could be the number of active tunnels at a point in time, amount 
      of utilized bandwidth, or some other metric that reflects ratio. 

WMT It's not entirely clear how this new AVP will be used, and what a "Service
Profile Name" is... This sounds a lot like the "Private Group ID" which still is
difficult to quantify. Also, what is Tunnel Switching specific about it? From
what I do gather from the description, it seems that this could be used in an
environment which didn't have a TSA at all.

      This AVP MAY be be hidden (the H-bit can be either 0 or 1). The 
      M-bit for this AVP MUST be set to 0.  

5.4. Loop Prevention AVP

   The Loop Prevention AVP, Attribute Type TBD, can be used to detect 
   the existence of loops in the TSA network.  

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Number of Nodes                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | HN Length     |          HostName ... (arbitrary length)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IP address of the Node                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

WMT The AVP identified here makes a lot of assumptions about identifying an
L2TP node. For instance, this doesn't seem to work if you have more than one IP
address for a given L2TP node, or you have a stack of L2TP nodes with different
IP addresses operating as a logical group to load balance across. Not to mention
that L2TP may no be operating over IPv4 (could be FR, ATM, IPv6...).

WMT If one is truly just concerned about an L2TP session crossing a given TSA 
(as this AVP seems to address) rather than a logical group, a better solution 
might be to combine the Vendor ID that we all have a unique value for, together 
with a "serial number" that I am sure we all have in our boxes somewhere. The
combination of the two of these should certiainly yield a unique box identifier
which would be better suited for loop prevention through a given piece of 
equipment. 

WMT If you want to prevent loops across logical nodes, there is no easy solution 
to this as it requires a logical, unique, value to be managed across the VPN. 
In the PWE3 L2VPN space we resort to a  "VPN ID", which in L2TPv3 we are 
including in the "End Identifier" AVP. This might be a better loop prevention 
value, though it is something new to be configured and managed.

Penno, et al.                                                  [Page 7]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

      The Number of Nodes indicates the occurrences of the tuple (Host
      Name, IP Address). Each tuple identifies a node in the tunnel-
      switched-path.

      The Hostname is MUST be same as used on the Hostname AVP when the 
      tunnel was established.

      The IP address field represents the IP address which was used to
      establish the tunnel.
      
      This AVP is updated by LAC when a new tunnel is being 
      established. It adds (Hostname, IP address) tuple to the existing 
      AVP and increments Number of Nodes.

5.5 CDN Messages and L2TP Tunnel Switching

   The Call-Disconnect-Notify (CDN) message is an L2TP control message 
   sent either by the LAC or LNS to request disconnection of a specific 
   call within the L2TP tunnel. Its purpose is to inform the peer of 
   the disconnection and the reason why it occurred.

   As an indication to its use, an Incoming-Call-Request message is  
   generated by the LAC when the subscriber's call is detected. The LAC 
   selects a Session ID and sends the Incoming-Call-Request to the LNS; 
   it then waits for a response from the LNS - keeping the subscribers 
   call waiting. It is at this point that the LNS may decline to accept 
   the call 

WMT The above text is summarizing RFC2661. The reader is expected to be familiar
with L2TP, so I think most of this is unnecessary. 

   It is also understood that if the call is terminated before the LNS 
   accepts it, a Call-Disconnect-Notify is sent by the Calling LAC to 
   indicate this condition, and is understood to be catered for within 
   current L2TP implementation. Any CDN messages originating from the 
   LAC are therefore omitted from the scope of this proposal, however 
   the Calling LAC must interpret the CDN messages received from the   
   LNS correctly, and must take the appropriate steps to ensure that 
   the intention of the CDN messages are carried out as expected.

WMT I don't see why we need to omit any CDN events from this proposal. It's
certainly possible for the TSA to have begun setting up a secondary tunnel upon
receipt of the ICRQ, thus, the CDN must be propogated in a similar manner.

   In the case where an L2TP Tunnel Switch has successfully extended 
   the Control Connection to the ETA, and it returns general CDN 
   messages during session establishment, any such messages may be 
   passed transparently through to the ITA or may be interpreted by the 
   TSA; such scenarios are included.

WMT The above (run-on) sentence seems to essentially say: "If the TSA receives a
CDN, it can interpret it or pass it through transparently." 

Penno, et al.                                                  [Page 8]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

   The following is proposed with regards of tunnel switching and CDN 
   messages:

   o  To define the circumstances that warrants the ETA to send general 
      protocol CDN messages to the LAC over and above all other 
      signaling mechanisms defined in RFC2661.
   o  To include decisions that may be undertaken by an TSA.
   o  To include assurances that multiple TSA peering is supported.

WMT I would avoid the use of the word "peering." This term generally has far
more connotations among service providers in the routing world than I think is
intended in this document. 

5.6 Scenarios for generating CDN messages

   The proposed causes and recommended LNS generated CDN messages for 
   each scenario are documented here.

5.6.1 LNS specific CDN Message

   Here the TSA-LNS or Peering LNS cannot accept another Session and 
   signals to the downstream LAC.

   o The TSA-LNS or Peering LNS reaches a pre-determined threshold, 
     this may be administrative or it may be a system function. As a 
     result, CDN Code-7 is generated by the LNS and passed to the 
     downstream LAC.

   The downstream LAC should change the state of the upstream peer to 
   'busy' and apply an administrative hold-down. Thereafter the TSA-LAC 
   or ITA should try all possible LNS peers - if there are no 
   available LNS peers the CDN Code should be passed to the downstream 
   LAC by the TSA-LNS only. The Calling LAC may choose to clear the 
   call.

WMT All of this max-session logic applies generally as well as to tunnel
switching. I'm not sure this is the correct home for all of this. 

5.6.2 TSA-LAC specific CDN Message

   This scenario only affects the TSA-LAC, which cannot establish 
   another session due to it reaching the aggregate session limit.

   o If the TSA-LAC exceeds max-sessions then it may signal to the 
     TSA-LNS to generate a CDN Code-4 for the downstream LAC. 

WMT Do we really need to model the internal state between the "TSA-LAC" and
"TSA-LNS" ? This might be more complexity than is necessary to provide
implementation guidance.

   The downstream LAC should change the state of the upstream peer to  
   'busy' and apply an administrative hold-down. Thereafter the TSA-LAC 
   or Calling LAC should try all possible LNS peers - if there are no 
   available LNS peers the CDN Code should be passed to the downstream 
   LAC by the TSA-LNS only. The Calling LAC may choose to clear the 
   call.

Penno, et al.                                                  [Page 9]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

5.6.3 Calling LAC Control Connection failures

   If there is a problem for the LAC to establish an L2TP tunnel,   
   because the Control Connection to the LNS is down, then a general 
   CDN message may or may not be appropriate depending upon the LAC 
   type. Three scenarios are mentioned here.

   o The Calling LAC cannot establish a Control Connection with the 
     Peering LNS.

   If the Calling LAC cannot continue with a session because there is   
   no Control Channel then it should try another L2TP peer. The Calling 
   LAC should record the unavailability of the Peering LNS and mark it 
   as unavailable for a period of time that is determined by the 
   Administrator.

   o The TSA-LAC cannot establish a Control Connection with the 
     upstream LNS

   If the TSA-LAC cannot continue with a session because there is no 
   Control Channel then a CDN Code-1 message may be generated by the 
   TSA-LNS to signal to the upstream LAC to try another L2TP peer. 

   The TSA-LAC should change the state of the upstream peer to 'dead'    
   and apply an administrative hold-down. Thereafter the TSA-LAC should 
   try all possible LNS peers - if there are no available LNS peers the 
   CDN Code should be passed to the downstream LAC by the TSA-LNS only. 

   o Calling LAC receives CDN Code-1

   If the Calling LAC receives CDN Code-1, then it should try another 
   L2TP peer. The Calling LAC should record the unavailability of the 
   upstream LNS and mark it as unavailable for a period of time that is 
   determined by the Administrator. The Calling LAC will thereafter 
   clear the call.

WMT More load-balancing specific text that I am not sure is primarily applicable
to tunnel switching.

5.6.4 LNS Session Failure

   Unable to accept the incoming call the peer LNS may return the  
   correct CDN message defined above or it may be unaware of these 
   requirements.

   The following are therefore best provided by implementation since 
   there are a number of options that may be selected.

   * The Administrator may choose to interpret all CDN messages 
     generated by the upstream LNS. This is typically because the LNS 
     employs the CDN Codes defined above (and may be implemented as the 
     default option).

Penno, et al.                                                 [Page 10]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

   * The Administrator may choose to ignore the CDN messages generated 
     by the upstream LNS, and by so doing may alert the downstream LAC 
     to mark it as unavailable for a period of time. This is typically 
     due to the upstream LNS being unaware of the CDN Codes defined 
     above.

   * The Administrator may choose to relay any CDN messages generated  
     by the upstream LNS transparently through to the downstream LAC. 
     This caters for the scenario where the TSA is not interpreting the 
     CDN Codes correctly or the topology does not lend itself to the 
     TSA intercepting CDN messages.

6. 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.
    
7. Acknowledgments 
    
   Thanks to W. Mark Townsley for his valuable comments 

8. Author's Addresses 
    
   Vipin Jain
   Nortel Networks, Inc. 
   2305 Mission College Boulevard
   Building SC9  
   Santa Clara, CA 95054
   Email: [email-masked]

   Reinaldo Penno
   Nortel Networks, Inc. 
   2305 Mission College Boulevard
   Building SC9  
   Santa Clara, CA 95054
   Email: [email-masked] 

Penno, et al.                                                 [Page 11]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

   Ly Loi
   Tahoe Networks, Inc. 
   3052 Orchard Drive 
   San Jose, CA 95134 
   Phone: +1 408.944.8630 
   Email: [email-masked]

   Mark Rayson
   British Telecom, Inc. 
   B67 Room 106
   BT Research Laboratories
   Martlesham Heath
   IPSWITCH, Suffolk IP5 3RE
   Phone: (01473) 649770
   Email: [email-masked]

   Marc Eaton-Brown 
   FrontRunner Solutions, Ltd.
   131 Finsbury Pavement
   Moorgate
   London EC2A 1NT
   Phone: +44 7989 498337
   Email: [email-masked]

Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Penno, et al.                                                 [Page 12]

Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext