In cnBNG, the L2TP performs the hand-off task of the subscriber traffic to the Internet service provider (ISP). To do this, L2TP uses two network components:

• L2TP Access Concentrator (LAC)—The L2TP enables subscribers to dial into the L2TP access concentrator (LAC), which extends the PPP session to the LNS. cnBNG provides LAC.

• L2TP Network Server—The L2TP extends PPP sessions over an arbitary netowrk to a remote network server that is, the L2TP network server (LNS). The ISP provides LNS.

The overall network deployment architecture is also known as Virtual Private Dial up Network (VPDN). The overall topology of LAC and LNS is depicted as follows:

The CP for LAC and LNS depend on the L2TP session termination. Developing these two control planes in a single cnBNG microservice has the following benefits:

Simplified Single L2TP Control Plane

• Reduces the configuration complexity of the current XR L2TP

  vpdn-groups, vpdn-templates, l2tp-class and so on are simplified.

• Supports LC subscriber (not supported on the physical BNG)

• Avoids Ns/Nr checkpointing issues of pBNG to support RPFO

Collocated LAC and LNS

• Supports LAC and LNS in the same cnBNG CP, with different User Plane (UPs)

• Enables sharing of the same AAA and Policy Plane

• Simplifies management and troubleshooting

Flexible Deployment Options

The integration of LAC and LNS into a centralized cnBNG CP provides highly flexible deployments options to suit different customer use-cases and needs. For example, the cnBNG CP can host the CP functionality either for a LAC or LNS UP. Also, the same CP cluster can act as a CP for both LAC and LNS UPs from different data centers (or even from the same user-plane, if the user-plane supports it) except for the same session at the same time.

Both LAC and LNS sessions use L2TP protocol for negotiation and creation of L2TP sessions. However for LAC sessions, there is additional PPPoE handling. This section focuses on the L2TP protocol handling.

LAC Sessions

For LAC sessions, the PPP sessions are terminated on a different network node from where the PPPoE sessions are terminated. The PPPoE sessions are terminated on the LAC, but the PPP session is terminated on an LNS upstream, over an L2TP tunnel. Initial PPP negotiations are done on the LAC to determine the appropriate LNS to tunnel the session. When the tunnel has been established, all PPP handling is handed off to the LNS.

• The PPPoE protocol is negotiated in the same way as a PTA session.

• PPPoE service handles all PPPoE packets and the nitial LCP and authorization packets.

• After authentication , if the user-profile contains service=outbound, PPPoE service decides to tunnel the sessions.

• It reaches out the L2TP pod to initiate a L2TP tunnel . The L2TP tunnel pod creates the tunnel and returns the L2TP session ID.

• The PPPoE service continues to handle the L2TP session FSM and bring-up the LAC session and program the UP via the Subscriber Manager.

LNS Sessions

LNS sessions are similar to PTA sessions in the overall functionality. Instead of PPPoE protocol, here the First-Sign-Of-Life (FSOL) packets are the L2TP Incoming-Call-Request (ICRQ) messages. When the L2TP session protocol is up, then the existing PPP protocol finite state machines (FSM) is triggered to bring up and program the session on the UP.

• L2TP Tunnel pod receives tunnel-create request from the remote LAC.

• After Tunnel is up, PPPoE Pod receives ICRQ to create a session.

• PPPoE pod communicates with the L2TP to get L2TP session-id for the given tunnel ID.

• L2TP generates the session ID and checks the session count.

• PPPoE pod checks if there is forced renegotiation configured for the session. Else, it proceeds with the session programming to the UP.

This section includes the following high-level call flows.

The L2TP Subscriber Management feature is aligned with the following standard:

• RFC 2661: Layer Two Tunneling Protocol "L2TP"

The LT2P Subscriber Management feature has the following limitations:

• LAC and LNS Control Plane (CP) functionality is not supported on the same cluster at the same time.

• On-the-fly changes to L2TP profile is not supported.

• L2TP attributes should be configured only for session-activate event.

• Tunnel load balancing with Tunnel-Assignment-ID is not supported.

• Weighted Tunnel load balancing can be configured only in the profile.

• The TCP maximum segment size (TCP-MSS) is supported at the global User Plane Function (UPF) chassis level and not at the tunnel or session level. It must be configured on the ASR 9000 UPF.

Use the following commands to create the Layer2 Tunnelling Protocol (L2TP) profile and provide the L2TP specific parameters.

config 
   profile l2tp l2tp_profile_name 
      authentication 

      encrypt-avp 
      hello-interval interval_in_seconds 
      hostname local_hostname 
      ip-tos { ip_tos_value | reflect } 
      ipv4 { df-bit { reflect | set } | source ip_address } 
      mode lac 
         domain domain_name [ tun-assign-id tunnel_id ] 
         dsl-info-forwarding  
         ipv4 { destination ip_address | df-bit { reflect | set } |  
              source ip_address } 
         rx-connect-speed kbps  
         tunnel-load-balancing { equal | weighted }  
         tx-connect-speed kbps  
      mode lns 
         force-lcp-renegotiation 
         mtu mtu_value  
         terminate-from remote_hostname 
      password password 
      receive-window number_of_packets 
      retransmit { retries number_of_retries |  
      timeout { max max_timeout | min min_timeout } 
      tcp adjust-mss mss_value 
      tunnel { session-limit number_of_sessions |  
      timeout { no-session timeout_value | busy value } 
      vrf vrf_name 
      exit 

NOTES:

• profile l2tp l2tp_profile_name : Specifies the PPPoE profile name and enters the Profile L2TP mode.

• authentication : Enables L2TP tunnel authentication.

• congestion-control :Enables L2TP congestion control.

• encrypt-avp : Hides attribute-value pair (AVPs) in outgoing control messages.

• hello-interval interval_in_seconds : Sets the hello interval in seconds. The valid values range from 10 to 1000 seconds.

• hostname local_hostname : Specifies the local hostname of the tunnel. The valid value is an alphanumeric string ranging from 1 to 256. The name of the Control Plane (CP) is the default local hostname.

• ip-tos { ip_tos_value | reflect } : Sets the IP Type of Service (ToS) value for tunneled traffic. The ToS valid values range from 1 to 255. The control packets use 0xC0 as the default value.

• ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } : Specifies the IPv4 settings for the tunnel:

  • df-bit { reflect | set } : Specifies the IPv4 Don't Fragment (DF) bit.

    reflect : Reflects the DF bit from the specified inner IP address.

    set : Sets the DF bit.

  • source ip_address : Specifies the source IP address of the tunnel.

• mode { lac | lns } : Configures LAC or LNS.

  • mode lac { domain domain_name [ tun-assign-id tunnel_id ] | dsl-info-forwarding | ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } | rx-connect-speed kbps | tunnel-load-balancing { equal | weighted } | tx-connect-speed kbps : Configures a L2TP Access Concentrator (LAC) to request the establishment of an L2TP tunnel to an L2TP Network Server (LNS).

    • domain domain_name [ tun-assign-id tunnel_id ] : Specifies the domain name to match. The valid values range from 1 to 255. The control packets use 0xC0 as the default value.

      tun-assign-id tunnel_id : Specifies the domain name with a tunnel ID.

    • dsl-info-forwarding : Forwards DSL line information attributes.

    • ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } : Specifies the IPv4 settings for the tunnel:

      • destination ip_address: Specifies the destination IP address of the tunnel.

      • df-bit { reflect | set } : Specifies the IPv4 Don't Fragment (DF) bit.

        reflect : Reflects the DF bit from the specified inner IP address.

        set : Sets the DF bit.

      • source ip_address: Specifies the source IP address of the tunnel.

    • rx-connect-speed kbps : Specifies the receiving (Rx) connection speed in kbps. The valid values range from 9 to 100000000 kbps.

    • tunnel-load-balancing { equal | weighted } : Specifies equal or weighted load sharing of the tunnel.

    • tx-connect-speed kbps : Specifies the transmitting (Tx) connection speed in kbps. The valid values range from 9 to 100000000 kbps.

  • mode lns { force-lcp-renegotiation | mtu | terminate-from remote_hostname : Configures a LNS to accept requests from LAC to establish L2TP tunnel:

    • force-lcp-renegotiation : Forces Link Control Protocol (LCP) and Authorisation renegotiation.

      mtu mtu_value : Specifies the MTU for LCP negotiation. The mtu_value valid values range from 500 to 2000. The default value is 1492.

    • terminate-from remote_hostname : Specifies the hostname of the remote peer to accept tunnels.

• password password : Specifies the password for tunnel authentication.

• receive-window number_of_packets : Specifies the receive window size for the tunnel. The valid values range from 1 to 5000 packets. The default value is 4.

• retransmit { retries number_of_retries | timeout { max max_timeout | min min_timeout } : Specifies the control message retransmission parameters.

  • retries number_of_retries : Specifies the maximum number of retries for control packets.

  • timeout { max max_timeout | min min_timeout } : Specifies the control packet retransmission timeout parameters.

    max max_timeout : Specifies the control packet retransmission maximum timeout parameters. The valid values range from 1 to 8 seconds. The default value is 8.

    min min_timeout : Specifies the control packet retransmission minimum timeout parameters. The valid values range from 1 to 8 seconds. The default value is 1.

• tcp adjust-mss mss_value : Adjusts the TCP Maximum Segment Size (MSS) value of TCP SYN (synchronize) packets. The valid values range from 500 to 1500 packets.

• tunnel { session-limit number_of_sessions | timeout { no-session timeout_value | busy value } : Limits the sessions for a tunnel or deletes the tunnel after timeout

  • session-limit number_of_sessions : Specifies the maximum number of L2TP sessions per tunnel. The valid values range from 1 to 64000 sessions.

  • timeout { no-session timeout_value } : Specifies the following parameters :

    timeout no-session : No-session timeout for the tunnel. The default value is 0 seconds.

    timeout timeout_value : Timeout value in seconds. The valid values range from 1 to 86400 seconds.

  • timeout busy value : Specifies the timeout period before marking an LNS server as busy. The valid values range from 60 to 65535 seconds.

• vrf vrf_name : Specifies the Virtual routing and forwarding (VRF) name of the tunnel.