Layer two tunneling protocol (L2TP) merging and management

• US 6,094,437 A
• Filed: 02/19/1999
• Issued: 07/25/2000
• Est. Priority Date: 10/09/1998
• Status: Expired due to Fees

• Current Assignee: TNC Co. (Nokia Corporation)
• Original Assignee: ASC - Advanced Switching Communications
• Inventors: Hsu, Chang-Shan, Loehndorf, James R. Jr., Miller, D. Richard Jr., Naudus, Stanley T. Jr.
• Primary Examiner(s): VU, HUY DUY
• Application Number:
  US09/251,915
• Time in Patent Office: 522 Days
• Field of Search: 370/400, 370/401, 370/410, 370/420, 370/462, 370/463, 370/422, 370/352, 370/353, 370/354, 709/223, 709/224, 709/225, 709/226, 709/227, 709/228, 709/229, 709/230, 709/231, 709/250
• US Class Current: 370/420
• CPC Class Codes: H04L 12/4641 Virtual LANs, VLANs, e.g. virtual private networks [VPN] LAN interconnection over a bridge based backbone H04L12/462; encapsulation techniques H04L12/4633; routing of packets H04L45/00; packet switches H04L49/00; virtual private networks for security H04L63/0272

Abstract

A system is provided for creating a tunneling service from the use of a traditional tunneling protocol, such as the layer two tunneling protocol (L2TP). In particular, the L2TP tunneling protocol, which is designed to go point-to-point between an L2TP Access Concentrator (LAC) and an L2TP Network Server (LNS), is abstracted so that L2TP becomes an access protocol to a tunneling service. A new L2TP tunnel merger and management (LTM) service is created which severs the tight configuration relationships between LAC and LNSs. Only a tight configuration between an LAC and its LTM edge device and between an LNS and its LTM edge device is required. An internal trunk protocol (INT protocol) carries needed information between LTM edge devices to establish ingress/egress L2TP access calls inside of separate L2TP access tunnels on opposite LTM edge devices. The addition of another LAC is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs, and the addition of another LNS is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs. The LTM service determines the need for both additional trunk and access resources and establishes both new trunk/access tunnels to provide additional resources. The LTM service also determines excess resources on both trunk and access entities and releases trunk/access tunnels to provide the needed additional resources.

Claims

1. A system for establishing connections between a plurality of access concentrators connected to respective ones of a like plurality of Network Access Servers (NASs) and a plurality of network servers connected to a plurality of Service Providers (SPs) in a network using a point-to-point tunneling protocol, comprising a tunneling merger and management service having a plurality of tunneling merger and management edge devices, each said access concentrator being connected to a tunneling merger and management edge device and each said network servers being connected to a tunneling merger and management edge device, the tunneling merger and management service abstracting the point-to-point tunneling protocol to become an access protocol so that direct connections are not required between access concentrators and network servers by simulating to an access concentrator a connection to a network server and simulating to a network server a connection to an access concentrator.

2. The system recited in claim 1, wherein the plurality of SPs is less in number than the plurality of NASs.

3. The system recited in claim 1, wherein the tunneling protocol is a Layer two Tunneling Protocol (L2TP) and the access concentrators are L2TP Access Concentrators (LACs) and the network servers are L2TP Network Servers (LNSs), the tunneling merger and management service being an L2TP Tunneling Merger and Management (LTM) service and the tunneling merger and management edge devices being LTM edge devices.

4. The system recited in claim 3, wherein the addition of another LAC is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs.

5. The system recited in claim 3, wherein the addition of another LNS is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs.

6. The system recited in claim 3, wherein the addition of another LAC is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs and the addition of another LNS is accomplished by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs.

7. The system recited in claim 3, wherein an internal trunk protocol (INT protocol) is used to carry needed information between LTM edge devices to establish ingress/egress L2TP access calls inside of separate L2TP access tunnels on opposite LTM edge devices.

8. The system recited in claim 3, wherein the LTM services perform a coordinated and even distribution of L2TP tunnel resources including bandwidth, Access/Trunk calls, and Access/Trunk tunnels.

9. The system recited in claim 8, wherein the LTM services determine a need for both Trunk and Access resources and establishing new Trunk/Access tunnels or new multi-Virtual Channels (VCs) inside existing tunnels to provide needed additional resources.

10. The system recited in claim 8, wherein the LTM services determine excess resources on both Trunk and Access entities and release Trunk/Access Tunnels and multi-VCs inside tunnels to provide the needed additional resources.

11. The system recited in claim 7, wherein the LTM service appears to terminate the network layer of the ingress L2TP Access tunnels, ingress L2TP Access calls, and associated ingress L2TP access payloads at an LTM edge device, thereby allowing the LTM service to transparently route the Access L2TP calls and associated payloads to a proper egress Access L2TP tunnel.

12. The system recited in claim 11, wherein routing of L2TP access calls and associated data is based on information provided by an L2TP tunnel layer.

13. The system recited in claim 12, wherein the LTM service passes the Internet Protocol (IP) header and User Datagram Protocol (UDP) header information and performs as needed updating of UDP and IP check sums.

14. The system recited in claim 3, wherein an LAC communicates a desired destination service provider to the LTM service by the use of Incoming Call Tunnel (ICT) addressing.

15. The system recited in claim 14, wherein the LTM service uses the ICT addressing and selects the appropriate destination LNS based on the service provider selected by the ICT addressing.

16. The system recited in claim 3, wherein the LTM service provides a coordinated directory service in which the LTM service selects an appropriate LAC that should be used to make an outgoing call.

17. The system recited in claim 16, wherein the selection of different processing is based on a type of communication fabric a destination subscriber is attached to.

18. The system recited in claim 3, wherein the LTM service changes its addressing method depending if it is attached to another LTM, LAC or LNS.

19. The system recited in claim 1, wherein the tunneling merger and management service establishes a single access/trunk tunnel over an Asynchronous Transfer Mode (ATM) Virtual Path (VP) instead of a Virtual Channel (VC), thereby allowing individual access/trunk calls to be established over a VC instead of all calls being established inside of a single tunnel/VC.

20. The system recited in claim 19, wherein a single access/trunk call is established by the tunneling merger and management service within a single ATM VC, thereby ensuring no access/trunk call interaction QoS between multiple access/trunk calls.

21. The system recited in claim 19, wherein multiple access/trunk calls are established by the tunneling merger and management service inside of a single ATM VC, thereby avoiding using as many network resources as if each access/trunk call were assigned to a single ATM VC while still improving access/trunk call interaction of Quality of Service (QoS) between multiple access/trunk calls in a single VC.

22. The system recited in claim 19, wherein the tunneling merger and management service dynamically realigns access/trunk calls between multiple VCs in a single VP to ensure optimal Quality of Service (QoS) for all calls.

23. The system recited in claim 19, wherein the tunneling merger and management service groups multiple access/trunk calls into a single ATM VC dependent on a specified Quality of Service (QoS) of the access/trunk call.

24. The system recited in claim 3, wherein the LTM service further comprises an L2TP access call watchdog state processing means to detect a loss of a tunnel control message.

25. The system recited in claim 24, wherein the LTM service clears an access/trunk call to ensure that an L2TP access call is not hung for a time exceeding a predetermined period of time.

26. The system recited in claim 24, wherein the LTM service dynamically regenerates a lost tunnel control message to compensate for a hung access call.

27. The system recited in claim 3, wherein the LTM service coordinates network services.

28. The system recited in claim 27, wherein the LTM service coordinates planned system maintenance, administration and reconfiguration.

29. The system recited in claim 27, wherein the LTM service provides coordinated security for tunnel access.

48. The method recited in claim 29, further comprising the step of establishing by the tunneling merger and management service a single access/trunk tunnel over an Asynchronous Transfer Mode (ATM) Virtual Path (VP) instead of a Virtual Channel (VC), thereby allowing individual access/trunk calls to be established over a VC instead of all calls being established inside of a single tunnel/VC.

49. The method recited in claim 48, further comprising the step of establishing by the tunneling merger and management service a single access/trunk call within a single ATM VC, thereby ensuring no access/trunk call interaction Quality of Service (QoS) between multiple access/trunk calls.

50. The method recited in claim 48, further comprising the step of establishing by the tunnel merger and managing service multiple access/trunk calls are inside of a single ATM VC, thereby avoiding using as many network resources as if each access/trunk call were assigned to a single ATM VC while still improving access/trunk call interaction of Quality of Service (QoS) between multiple access/trunk calls in a single VC.

51. The method recited in claim 48, further comprising the step of dynamically realigning by the tunnel merger and management service access/trunk calls between multiple VCs in a single VP to ensure optimal Quality of Service (QoS) for all calls.

52. The method recited in claim 48, further comprising the step of grouping by the tunnel merger and management service multiple access/trunk calls into a single ATM VC dependent on a specified Quality of Service (QoS) of the access/trunk call.

53. The method recited in claim 29, further comprising the step of detecting by the LTM service a loss of a tunnel control message by the use of watch dog state processing.

54. The method recited in claim 53, further comprising the step of clearing by the LTM service an access/trunk call to ensure that an L2TP access call is not hung for a time exceeding a predetermined period of time.

55. The method recited in claim 53, further comprising the step of dynamically regenerating by the LTM service a lost tunnel control message to compensate for a hung access call.

30. A method for establishing connections between a plurality of access concentrators connected to respective ones of a like plurality of Network Access Servers (NASs) and a plurality of network servers connected to a plurality of Service Providers (SPs) in a network using a point-to-point tunneling protocol, comprising the steps of:

providing a tunneling merger and management service having a plurality of tunneling merger and management edge devices, each said access concentrator being connected to a tunneling merger and management edge device and each said network servers being connected to a tunneling merger and management edge device; and

abstracting by the tunneling merger and management service the point-to-point tunneling protocol to become an access protocol so that direct connections are not required between access concentrators and network servers by simulating to an access concentrator a connection to a network server and simulating to a network server a connection to an access concentrator.

31. The system recited in claim 30, wherein the plurality of SPs is less in number than the plurality of NASs.

32. The method recited in claim 30, wherein the tunneling protocol is a Layer two Tunneling Protocol (L2TP) and the access concentrators are L2TP Access Concentrators (LACs) and the network servers are L2TP Network Servers (LNSs), the tunneling merger and management service being an L2TP Tunneling Merger and Management (LTM) service and the tunneling merger and management edge devices being LTM edge devices.

33. The method recited in claim 32, further comprising the step of adding another LAC by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs.

34. The method recited in claim 32, further comprising the step of adding another LNS by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs.

35. The method recited in claim 32, further comprising the steps of:

adding another LAC by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs; and

adding another LNS by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs.

36. The method recited in claim 32, further comprising the step of using an internal trunk protocol (INT protocol) to carry needed information between LTM edge devices to establish ingress/egress L2TP access calls inside of separate L2TP access tunnels on opposite LTM edge devices.

37. The method recited in claim 32, further comprising the step of performing by the LTM services a coordinated and even distribution of L2TP tunnel resources including bandwidth, Access/Trunk calls, and Access/Trunk tunnels.

38. The method recited in claim 37, further comprising the steps of:

determining by the LTM services a need for both Trunk and Access resources; and

establishing by the LTM services new Trunk/Access tunnels or new multi-Virtual Channels (VCs) inside existing tunnels to provide needed additional resources.

39. The method recited in claim 37, further comprising the steps of:

determining by the LTM services excess resources on both Trunk and Access entities; and

releasing by the LTM services Trunk/Access Tunnels and multi-VCs inside tunnels to provide the needed additional resources.

40. The method recited in claim 36, further comprising the step by the LTM of appearing to terminate the network layer of the ingress L2TP Access tunnels, ingress L2TP Access calls, and associated ingress L2TP access payloads at an LTM edge device, thereby allowing the LTM service to transparently route the Access L2TP calls and associated payloads to a proper egress Access L2TP tunnel.

41. The method recited in claim 40, further comprising the step of routing of L2TP access calls and associated data based on information provided by an L2TP tunnel layer.

42. The method recited in claim 41, further comprising the step of passing the LTM service Internet Protocol (IP) header and User Datagram Protocol (UDP) header information with as needed processing of updating UDP and IP check sums.

43. The method recited in claim 32, further comprising the step of communicating by an LAC a desired destination service to the LTM service by the use of Incoming Call Tunnel (ICT) addressing.

44. The method recited in claim 43 wherein the LTM service uses the ICT addressing and selects the appropriate destination LNS based on the service provider selected by the ICT addressing.

45. The method recited in claim 32, further comprising the steps of:

providing by the LTM service a coordinated directory service; and

selecting by the LTM service an appropriate LAC that should be used to make an outgoing call.

46. The method recited in claim 45, further comprising the step of selecting different processing based on a type of communication fabric a destination subscriber is attached to.

47. The method recited in claim 32, further comprising the step of changing by the LTM service its addressing method depending if it is attached to another LTM, LAC or LNS.

56. The method recited in claim 30, wherein the tunneling protocol is a Layer two Tunneling Protocol (L2TP) and the access concentrators are L2TP Access Concentrators (LACs) and the network servers are L2TP Network Servers (LNSs), the tunneling merger and management service being an L2TP Tunneling Merger and Management (LTM) service and the tunneling merger and management edge devices being LTM edge devices.

57. The method recited in claim 56, further comprising the step of adding another LAC by re-routing L2TP tunnels within the LTM service without reconfiguration of the LNSs.

58. The method recited in claim 56, further comprising the step of adding another LNS by re-routing L2TP tunnels within the LTM service without reconfiguration of the LACs.

59. The method recited in claim 32, wherein the LTM service coordinates network services.

60. The method recited in claim 59, wherein the LTM service coordinates planned system maintenance, administration and reconfiguration.

61. The method recited in claim 59, wherein the LTM service provides coordinated security for tunnel access.