Background of the Invention Ethernet has emerged as the standard of choice for local area networks (LAN).

With speeds of 10 Mbps, 100 Mbps, 1 Gbps and soon 10 Gbps, Ethernet capacity has grown to meet the need for increased network bandwidth. Consequently, the conception of Optical Ethernet networks whose optical wavelengths are used as backbone carriers with content as encapsulated Ethernet packets marries the ubiquitous Ethernet with the enormous bandwidth of optical networks. Despite the inherent elegance of this conceptual network, actual implementation of such networks must devise physical and or logical arrangements to ensure optimal performance, scalability, and operability.

In view of the Ethernet presence in LAN and high speed LAN, it is desirable to use Ethernet for metropolitan access networks. However, scaling potentially hundreds of thousands of customers challenges such an approach. Also by the very nature of metro access a large number of different customers'LANs, separation of customer traffic must be provided to prevent security risks such as spoofing, where one customer could impersonate another customer by using that customer's MAC address.

Trying to provide an Ethernet solution in metro access would also require centralized administration of all MAC addresses for the entire metro access network.

The administrative overhead and inconvenience to each customer's network administration would likely be unacceptable.

Not only direct access LAN clients, but also dial-up and remote access to corporate LAN must be provided in any metropolitan access solution.

Summary of the Invention An object of the present invention is to provide an improved metropolitan access via tunnel transport.

Accordingly the present invention provides a method of providing a Layer 2 tunneling protocol (L2TP) tunnel over a multi-protocol label switching (MPLS) label switched path (LSP). Advantageously, using MPLS reduces complexity and allows higher throughput. Since L2TP add a header to each packet, if viewed as being a label, then the transition form L2TP tunnel to MPLS tunnel can be advantageously effected by swapping the L2TP"label"for an MPLS label, thereby eliminating any need to translate between protocols.

Conveniently, to put into effect the transport of an L2TP tunnel over an MPLS label switched path requires a change of bits in signaling messages.

Preferably, the MPLS LSP is carried on an Ethernet network.

Advantageously, the use of an Ethernet network allows the customer facing device to cost effectively include an L2TP Access Concentrator function (LAC), as the LAC only needs to deal with one label and need not be MPLS aware.

In accordance with an aspect of the present invention there is provided a method of accessing a service network via a Layer 2 transport having a entity-facing device through which an entity gains access to the Layer 2 transport and a core-facing

device coupled to the service network, the method comprising the steps of providing multi-protocol label switching (MPLS) label switched path between the entity-facing device and the core-facing device and establishing a Layer 2 tunneling protocol (L2TP) tunnel over the label switched path to transport traffic between the entity and the service network.

In accordance with another aspect of the present invention there is provided a device for providing access to service networks for third entities via an entity-facing device through which an entity gains access to a Layer 2 transport, comprising a core- facing device for coupling to the service network, a module for establishing at least one label switched path between the entity-facing device and the core-facing device, and a module for establishing an L2TP tunnel over the label switched path.

Brief Description of the Drawings The present invention will be further understood from the following detailed description with reference to the drawings in which: Fig. 1 illustrates a network reference model for accessing service networks; Fig. 2 illustrates a portion of the network of Fig. 1 ; Fig. 3a illustrates a portion of the network of Fig. 2 including a first embodiment of the present invention; Fig. 3b illustrates a packet for the tunnel of Fig. 3a according to a first embodiment of the present invention; Fig. 4a illustrates a portion of the network of Fig. 2 including a second embodiment of the present invention; and

Fig. 4b illustrates a packet for the tunnel of Fig. 4a according to a second embodiment of the present invention.

Detailed Description of the Preferred Embodiment Referring to Fig. 1 there is provided a network reference model for accessing service networks. The network reference model includes IP, MPLS backbones as represented by 100 and a plurality of provider internal devices 102,104, 106,108.

Connected to the backbones is a plurality of provider edges (PE) core-facing devices as represented by devices 110,112, and 114. The PE core-facing devices 110,112 and 114 are connected to customer-facing devices 120,122, and 124, respectively.

Logical PE are defined for each of the PE core-facing devices 110,112, and 114 as logical PE 130,132 and 134, respectively. As can be seen from the network reference model. Coupled to each logical PE are customer edge (CE) devices. Customer edge (CE) devices 140 and 142 are shown coupled directly to PE core device 114.

Customer edge (CE) devices 144 and 146 are coupled to the logical PE 130.

Customer edge (CE) devices 148 and 150 are coupled to the logical PE 132.

Customer edge (CE) devices 152 and 154 are coupled to the logical PE 134.

A logical provider edge (LPE) provides a way to organize network components in a hierarchy in order to deliver virtual private LAN segment (VPLS) service. A VPLS is a type of virtual private network in which packets forwarded between VPN sites are Ethernet packets. VPLS service is also known as transparent LAN service (TLS). A LPE includes a Core-PE and an Edge-PE and the connectivity that links the two. This may be in the form of, but not limited to, a switched Ethernet transport (SET). A Core-PE is a core-facing device through which traffic of a switched Ethernet transport (SET) passes on its way to a core network. The Edge-PE is a customer-facing device through which traffic from a customer edge (CE) device passes in order to access the SET and ultimately other sites in the customer's VPN.

The CE device is the device through which traffic of a VPN at a particular site passes

on its way to other sites of a VPN. A CE device thus represents a site of a VPN. The switched Ethernet transport (SET) provides Layer 2 transport between a plurality of Edge-PE and a Core-PE.

Each CE device is shown coupled to a virtual private network. Hence CE devices 140 and 142 are coupled to instances of VPNB 160 and VPNA 162, respectively. CE devices 144 and 146 are coupled to instances of VPNA 164 and VPNB 166, respectively. CE devices 148 and 150 are coupled to instances of VPNC 168 and VPND 170, respectively. CE devices 152 and 154 are coupled to instances of VPNC 172 and VPND 172, respectively.

As can be appreciated from the network reference model, the actual form of the access network between the client edge device and the provider edge core is transparent once logical PEs are defined.

As a consequence, CE devices directly connected to the PE core, for example CE devices 140 and 142 are provisioned at the same point (the PE core 114) as CE devices 152 and 154. Hence, there is a single point of provisioning. Interworking of the logical provider edge with the IP/MPLS backbones 100 enhances scalability and resiliency of optical Ethernet implementations incorporating this use of logical PE.

Finally, use of logical PE provides flexibility in the L2 transport network.

The Providers Metro optical network is assumed to be composed of a number of Switched Ethernet Transport (SET) networks. The LPE organization ties together a group of Edge-PEs and one, or a small number, of Core-PEs by interconnecting them with one or more SETs. Note that in the trivial case the SET is a point-to-point link that serves just one Edge-PE and one Core-PE. Other instances of SETS include, but are not restricted to, a resilient packet ring (RPR) as defined by the IEEE 802.17 committee and hierarchical RPRs with links connected by Ethernet switches. It is a characteristic of a SET that it deals only with the MAC addressing of the equipment in attached directly to it via the Edge-PE and Core-PEs.

Referring to Fig. 2, there is illustrated a portion of the network of Fig. 1. In Fig. 2, the logical provider edge (LPE) 130 includes a PE-Core 1101, an Edge-PE 120'and a switched Ethernet transport (SET) 180. The SET 180 provides Layer 2 transport between the PE-Core 110 and the Edge-PE 1201. For each VPN (for example VPNA and VPNB), a two-way tunnel is established between the Edge-PE 120 and the PE-Core 1101. These tunnels are instantiated as multi-protocol label switching (MPLS) label switched paths (LSP). Hence, for the present example, a first tunnel 182 is provided for VPNA and a second tunnel 184 is provided for VPNB.

Referring to Fig. 3a, there is illustrated a portion of the network of Fig. 2 including a first embodiment of the present invention.

The Edge-PE 1201 and the PE-Core 1101 of Fig. 2 include the functions needed to support VPN service for Ethernet based customer networks. However there is a need to provide access to VPN services for remote users via dial-up or other non- dedicated links, such as ADSL. In Fig. 3a, the Edge-PE 12011 is modified to include a Layer 2 tunneling protocol access concentrator based on Ethernet packets (eLAC) module 190. Similarly, the PE-Core 11011 is modified to include a Layer-2 tunneling protocol network server module based on Ethernet packets (eLNS) module 192. The eLAC module 190 and the eLNS 192 use MPLS label switched path (LSP) to carry a L2TP tunnel 194.

Referring to Fig. 3b, there is illustrated a packet for the tunnel of Fig. 3a according to a first embodiment of the present invention.

In a first embodiment, a label 196 is attached to every packet and has predetermined fields. When the packets reaches the PE-Core 110"from the Edge-PE 120", the label 196 is swapped for an MPLS label for an MPLS tunnel across the core network 100. When a packet is received by the PE-Core 110"for the Edge-PE 120li the MPLS label is swapped for the MPLS/L2TP label of Fig. 3b.

Referring to Fig. 4a, there is illustrated a portion of the network of Fig. 2 including a second embodiment of the present invention.

In the second embodiment of Fig. 4a, Extensible Authentication Protocol (EAP) is used between the customer edge 144 and the Edge-PE 12011. This ensures the customer edge 144 is known to the server 198. The remote customer edge device 144 initiates the access by sending an"EAPOL-start"to the Edge-PE 120 which replies with an"EAPOL-Request ID". The remote CE device 144 replies with an <BR> <BR> "EAP-Response (My ID) "that identifies the CE device, selects the eLNS 192 and may also name desired service, e. g. acme3 (ivpe. 0ESP. The eLAC 190 forwards the identify in L2TP as"L2TP-ICRQ (MyID)". The eLNS 192 of PE-Core 11011 forwards the identity to the server 198 as a"Server-Access-Request". The server 198 responds with a"Server-Access-Challenge", which the eLNS 192 relays as an"LT2P- ICRP (challenge)". The eLAC 190 forwards the challenge as an"EAP-Request MD5 (Challenge)". The CE device 144 replies with an"EAP-Request MD5 (Response)". This is forwarded as an"L2TP-ICCN (Response) "by the theeLAC 190 and passed to the server 198 as a"server-Access-Request". The server 198 accepts the request with a"Server-Access-Accept". The eLNS 192 forwards the acceptance as an"L2TP-ICRP (Success)". Finally the eLAC 190 sends an"EAP- Success"message to the CE device 144. In this way authenticated access is provided between the CE device 144 and the server 198.

Referring to Fig. 4b, there is illustrated a packet for the tunnel of Fig. 4a according to a second embodiment of the present invention.

The packet extension used in Fig. 4a is shown in Fig. 4b. The extension has the same format as that of Fig. 3b, however the label 200 has its fields set by the L2TP exchange of Fig. 4a, rather than using fixed fields as in Fig. 3b.

In operation, after authentication/tunnel set-up (or provisioned) each access port on eLAC is mapped to a tunnel. Tunnel forwarding information consists of Service/VC label, and the address of the terminating eLNS. A Service label is

pushed in front of incoming Ethernet packet, which is then forwarded to the terminating eLNS. The eLNS may be known by any of several identities which may require local resolution for forwarding on the SET: 1) By an IP address. Which can be resolved to a MAC address (+VLAN tag if used) in a SET via an ARP.

2) Via configuration of the eLNS MAC address (+VLAN tag if used) at the eLAC.

While the exemplary embodiments of Figs 1-4b are described in the context of providing virtual private network services (VPN), the PE-Core can provide access to any of the following service edge functional types: VPE Services Point-to-point Ethernet.

(Virtual) Bridge (multi-point to multi-point) providing: direct ports (e. g. to HQ or Service Providers in same co-located data center) -eL2TP/MPLS ports over Metro Martini/Kompella ports over long haul.

This technique would work in conjunction with any defined MPLS-VPN mechanisms that distributed labels between PEs across a core for VPLS/TLS type services. This would include the proposed Martini or Kompella techniques for label distribution and other derivative works that used label distribution protocols such as LDP or BGP for VPN applications.

Internet Access Use MPLS label as"un-spoofable"customer identifier for personal Internet services.

Metro transport for"Internet Protocol (IP) "Digital Subscriber Line Access Multiplexers (DSLAMs), Cable Modem Termination System (CMTS), as well as small to medium enterprises (SME's) served by eLAC Ethernet switches.

IP VPN PE MPLS service label provides customer separation-authentication helps security Wireless -GGSN (L2TP tunnels switched to new SCSN as mobile moves) Additional embodiments of the present invention include the following: 1. Use MPLS LSP as the tunnel transport method within the L2TP method of tunneling customer traffic to a service network.

2. As 1 with options selected from those available, or proposed, in an L2TP deployment, so that the resulting encapsulation of Layer 2 packets is identical to any emerging standard (e. g. that proposed by Martini et al) for Layer 2 packets over MPLS.

3. With 1 or 2, the implementation of an LNS (L2TP Network Server) with Layer 2 (or alternatively Layer 3) VPN PE (Virtual Private Network Provider Edge) function.

4. With 1,2 or 3 the use of straight label swapping in a VPN PE to achieve higher operational throughput and higher scalability in the number of VPN customer sites served.

5. As 1 where the MPLS is carried over an Ethernet network, such that the LAC and LNS are MPLS adjacent routes and use penultimate hop label stack popping to reduce the number of labels in the stack to a single label.

6. As 5 where the operator deploying the L2TP over MPLS over an Ethernet infrastructure uses the VLAN capability to secure and separate the traffic of a plurality of owners of LNSs.

7. As 3,4 or 5 where the L2TP payload is also Ethernet and Layer 2 VPN services realized bye the PE are LAN extension, Transparent LAN service, VLAN switched services or like Virtual Private Ethernet services.

8. As 7, where individual ports on a LAC are only allowed to pass traffic after the customer has authenticated himself using EAPOE protocol (Extensible Authentication Protocol over Ethernet) or similar.

9. As 7 or 8, where individual customers choose the Service Network that their traffic will be tunneled to by using an EAPOE my-ID field that is a qualified domain name (where the domain name is mapped by the LAC terminating the EAPOE to an LNS of the Service Network with the specified domain name.

10. As an addition to 9 where the individual customer chooses the type of service his traffic will receive fro the service network by including a qualifier before the domain name that is interpreted by the LNS. This identifier may identify a VPN that the customer belongs to, but its use is not restricted to this application.

Numerous other modifications, variations and adaptations may be made to the particular embodiments of the invention described above without departing from the scope of the invention as defined in the claims.