WO2007051300A1 - Method and apparatus for transporting ethernet services - Google Patents

Method and apparatus for transporting ethernet services Download PDF

Info

Publication number
WO2007051300A1
WO2007051300A1 PCT/CA2006/001797 CA2006001797W WO2007051300A1 WO 2007051300 A1 WO2007051300 A1 WO 2007051300A1 CA 2006001797 W CA2006001797 W CA 2006001797W WO 2007051300 A1 WO2007051300 A1 WO 2007051300A1
Authority
WO
WIPO (PCT)
Prior art keywords
mim
network
vpls
frame
encapsulated
Prior art date
Application number
PCT/CA2006/001797
Other languages
French (fr)
Inventor
Dinesh Mohan
Hamid Ould Brahim
Original Assignee
Nortel Networks Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nortel Networks Limited filed Critical Nortel Networks Limited
Publication of WO2007051300A1 publication Critical patent/WO2007051300A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • H04L12/2858Access network architectures
    • H04L12/2859Point-to-point connection between the data network and the subscribers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645Details on frame tagging
    • H04L12/465Details on frame tagging wherein a single frame includes a plurality of VLAN tags
    • H04L12/4658Details on frame tagging wherein a single frame includes a plurality of VLAN tags wherein a VLAN tag represents a service provider backbone VLAN, e.g. B-Tag, S-Tag
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645Details on frame tagging
    • H04L12/465Details on frame tagging wherein a single frame includes a plurality of VLAN tags
    • H04L12/4662Details on frame tagging wherein a single frame includes a plurality of VLAN tags wherein a VLAN tag represents a service instance, e.g. I-SID in PBB

Definitions

  • the present invention relates to communication networks and, more particularly, to a method and apparatus for transporting Ethernet services, where the Ethernet service itself might be used to carry other native services.
  • Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as "network elements.” Data is communicated through the data communication network by passing protocol data units, such as frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
  • protocol data units such as frames, packets, cells, or segments
  • the various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols.
  • Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
  • Large communication networks generally include subscriber networks, provider- based access networks, and core networks.
  • Subscriber networks are commonly referred to as Local Area Networks (LANs), such as may be implemented by a corporation or university, or even in a residence.
  • LANs Local Area Networks
  • Access networks are used to aggregate traffic from a large number of subscribers, and generally encompass an area such as a metropolitan area or regional geographic area.
  • Core networks are generally used to transport data between access networks. Access and core networks may exist in many different geographic areas and may be connected in myriad different ways.
  • Ethernet is a well known networking protocol that has been defined by the Institute of Electrical and Electronics Engineers (IEEE) 802 Groups.
  • IEEE Institute of Electrical and Electronics Engineers
  • Ethernet has been used to implement networks in enterprises such as businesses and campuses, and other technologies have been used to transport network traffic in the access and core networks.
  • network providers such as carriers that sell bandwidth to subscribers on the access and core networks were reluctant to deploy networks based on Ethernet technology, since Ethernet was designed to provide best efforts service and did not support various control and management functions that were deemed necessary by network providers.
  • Networks may be viewed as having three layers - a data layer, a control layer, and a management layer.
  • the data layer is related to how data is actually transmitted on the network.
  • the control layer is related to how the network elements on the network interoperate.
  • the management layer is related to how operation of the network may be monitored so that faults may be detected and corrected in a timely manner.
  • a network provider may own access networks in multiple cities and may want them to be commonly managed and to share control information.
  • a network provider may own access networks in multiple cities and may want them to be commonly managed and to share control information.
  • Frames of customer traffic may be encapsulated using Mac-in-Mac (MiM) encapsulation and the MiM encapsulated traffic may be further encapsulated using Virtual Private LAN Service (VPLS) encapsulation.
  • the MiM encapsulation uses provider network MAC addressing and include service tags to identify service instances associated with the encapsulated frame.
  • the MiM encapsulated frames are mapped to VPLS service instances and encapsulated using VPLS encapsulation for transportation over the core network.
  • the MiM encapsulation is added when the customer service frames are transported over the MiM network. As frames arrive at the edge of MiM network, the service provider MAC addresses are used as part of the MiM encapsulation.
  • MiM encapsulation also includes a tag which identifies the MiM tunnel over which various MiM service instances can be carried. This tag is used to identify the correct VPLS service instance and the service provider MAC addresses are used to identify the correct path within the VPLS network. Or in other words, the service provider MAC address space is used for VPLS MAC learning. A pseudowire tag is assigned for each MiM tunnel so that multiple MiM tunnels may use the same VPLS path in the core network.
  • the encapsulation methods described herein may be used to transport Ethernet services, which may be point-to-point, point-to-multipoint, and multipoint, and which may be used to carry frames belonging to other services such as IP frames.
  • Fig. 1 is a functional block diagram of an example communication network configured to transport data using MiM and VPLS encapsulations according to an embodiment of the invention
  • Fig. 2 is a functional block diagram of a portion of the example communication network of Fig. 1 showing portions of the networks in greater detail according to an embodiment of the invention
  • Fig. 3 is a functional block diagram of the encapsulation used in each part of the communication network of Fig. 1 according to an embodiment of the invention
  • Fig. 4 is a flowchart illustrating a process of using MiM and VPLS encapsulation to transport data across a network according to an embodiment of the invention
  • Fig. 5 is a functional block diagram graphically illustrating an encapsulation process for a particular service instance
  • Fig. 6 is a functional block diagram of a network element that may be used to perform encapsulation/decapsulation according to an embodiment of the invention.
  • Fig. 1 illustrates an example network 10 in which customer traffic from a customer LAN 12A may be transported across an access network 14 A, a core network 16, back through a second access network 14B, and then to another customer network 12B.
  • the Ethernet services from the customer network may be encapsulated using Mac-in-Mac (MiM) encapsulation in the access networks 14 A, 14B.
  • MiM Mac-in-Mac
  • This MiM encapsulation may be carried out using the procedures set forth in IEEE 802.1 ah draft standard, although other encapsulation processes may be used as well. For example, as changes are made to the draft standard, the changes may be implemented to cause the encapsulation process to continue to comply with the standard.
  • the MiM encapsulated traffic may be further encapsulated using Virtual Private LAN Service (VPLS) encapsulation in the core network.
  • VPLS Virtual Private LAN Service
  • the particular way in which MiM encapsulation and VPLS encapsulation is implemented (as discussed in greater detail below) enables the data planes, control planes, and management planes of the access and core networks to be independent so that interworking of these planes is minimized.
  • Fig. 2 illustrates a portion of the network of Fig. 1 in greater detail.
  • each network area e.g. each access and core network
  • PE Provider Edge
  • the network areas also have network elements that only are connected to other network elements within the network area. These network elements are referred to herein as P network elements 20.
  • a provider may set up a MiM tunnel between a first edge PE 18A on access network A to a second Edge PE on access network B 18B. Since there may be many edge PEs on the access networks, many MiM tunnels may be established. Once these MiM tunnels are established, customer traffic associated with customer service instances may be mapped to the MiM service instances. This may be accomplished by selecting an I-SID value for the service instance via end-to-end control plane between the access networks without input from the core network. These MiM service instances are then mapped to MiM tunnels. This may be accomplished by selecting a tag for the tunnel, again via end- to-end control plane between the access networks without input from the core network, or by selecting pre-established MiM tunnels.
  • the MiM tunnels need to be mapped to VPLS service instances over the core network.
  • the core network has a number of edge PEs 22.
  • the core network may establish paths (e.g. MPLS Label Switched Paths or other types of paths) through the core network via P network elements 24 that may be used to carry traffic belonging to VPLS service instances through the core network.
  • paths through the core network may be used by many different VPLS service instances, and traffic belonging to different VPLS service instance may be differentiated using tags (e.g. pseudo wire tags) as discussed in greater detail below.
  • tags e.g. pseudo wire tags
  • the service instance will be assigned to a particular MiM service instance which is mapped to a specific MiM tunnel through the access network A.
  • the MiM encapsulation uses source and destination MAC addresses which are MAC addresses in the access networks A and B. Multiple services instances identified by I-SID may be carried on a given MiM tunnel.
  • the core edge PE 22 will perform MAC address learning on its ingress PE by looking at the MAC addresses of the MiM encapsulated frame.
  • the core network will determine which VPLS service instance should be used to carry the traffic for the MiM tunnel and assign a tag to the MiM tunnel so that multiple MiM tunnels may be multiplexed across a given VPLS path between core edge PEs 22.
  • the traffic When traffic is received at the core network ingress, the traffic will be encapsulated by applying the tag to identify the VPLS instance and another tag to identify the VPLS path. In this manner the
  • MiM traffic from the access network may be carried transparently across the core network.
  • Fig. 3 illustrates the format of the headers that may be used to perform MiM and
  • VPLS encapsulation as described herein.
  • client frames are carried without modification as the client payload 30 of a Mac-in-Mac encapsulated frame.
  • Mac- in-Mac encapsulation is being defined in IEEE draft 802.1 ah, the content of which is hereby incorporated herein by reference.
  • other encapsulation processes may be used as well, for example as the 802. lah draft standard continues to evolve.
  • the MiM encapsulation causes a MiM encapsulation fields 32 to be applied to the client payload 30 so that the access network is able to use its own MAC address space to forward traffic across the access network.
  • a physical transport header 34 may also be applied to enable the traffic to be handled by the network.
  • the format of the physical transport header 34 will depend on the particular technology that has been deployed in the access network.
  • the physical transport header 34 may be a SONET header, a Generic Framing Procedure (GFP) header, or another type of header.
  • GFP Generic Framing Procedure
  • the MiM encapsulation fields 32 include the source and destination MAC addresses which are the end-points within the MiM tunnel.
  • the Destination MAC Address (B-DA) 38 is the MAC address in access network B which is the destination address of the MiM tunnel end-point.
  • B-DA is based on the access network MAC address space and may be, for example, the MAC address of the ingress port of the egress PE in access network B. Since the MiM encapsulated frames are addressed in a manner that does not rely on the customer MAC address space, the customer's MAC address space is hidden from both the access network and the core network so it is not necessary to ensure that the customers use globally unique MAC addresses.
  • the Source MAC Address (B-SA) 40 is the source address of the MiM tunnel end- point.
  • B-SA is based on the source MAC address in access network A where the MiM tunnel originates. For example, this may be the MAC address of the egress port of the ingress PE in access network A.
  • a given MiM tunnel will extend between one or more pairs of SA/DA MAC addresses. Since many subscribers may need to send traffic between those endpoints, it would be good to enable the traffic to be multiplexed onto the MiM tunnels. To do this, service instances are used.
  • a given MiM tunnel may carry multiple MiM service instances. The MiM service instances may be distinguished on the MiM tunnels using the
  • the I-Tag 44 includes the 802.1 ah Ethertype value.
  • a B-Tag (802. lad Ethertype) is included to limit the broadcast domain for MiM tunnels.
  • the MiM encapsulation fields 32 may also include a payload Ethertype field 36 indicating the particular Ethertype of the client payload.
  • the portions of the MiM encapsulation fields may be used as follows. Initially, the access network provider may establish tunnels between end points on the access network.
  • MiM service instances will be mapped to the MiM tunnels and client traffic will be mapped to the MiM service instances. Traffic belonging to different MiM service instances may be identified by the I-Tag values so that the traffic may be separated at within the MiM tunnels.
  • the ingress PE may use the client frame's VLAN ID to set the I-Tag which contains the I-SID.
  • the ingress PE may determine which MiM tunnel should be used to carry the frame and set the set the B-SA,
  • the MiM encapsulation fields include the correct MAC addresses for the MiM tunnel.
  • the physical transport header may then be applied and the packet will be transported across the access network.
  • the access network payload may be encapsulated by applying a VPLS encapsulation fields 50 to the frame.
  • the VPLS payload in the core network 52 is the entire MIM encapsulated frame, including the MIM encapsulation fields and the client payload.
  • the physical header 34 will be stripped from the MiM frame before VPLS encapsulation.
  • the core network ingress PE maps MiM frames to particular VPLS service instances. Each VPLS service instance extends between a particular pair of ingress and egress PE network elements on the core network and will extend along a path through the network between those PE network elements. Depending on the number of PE network elements on the core network there may therefore be many service instances.
  • the ingress PE on the core network performs mapping of MiM tunnels, identified by the MiM tunnel tag, to VPLS service instance and MAC learning for MiM tunnels to learn the VPLS path that is to be used to carry MiM encapsulated traffic from each of the MiM tunnels that send traffic to the ingress PE. Since the MiM encapsulated frames contains MAC addresses that have been assigned by access network A and access network B, the MAC learning in VPLS is based on access network MAC address space. The MAC address space associated with the access networks is more likely to be stable, compared to customer MAC address space, and thus MAC learning of provider MAC addresses may be expected to be more robust than if customer address space was used.
  • VPLS is defined by the IETF L2VPN working group, and is intended to be compliant with standards proposed by that working group.
  • the core network will also assign a physical transport header 58 to the frame to enable the core network to transport the frame across the network.
  • the format of the physical transport header 58 in the core network will depend on the technology being used to implement the core network.
  • the pseudowire tag 56 is used by the egress PE to route the frame to the correct egress port/interface.
  • the VPLS header 50 and core network physical header 58 will be removed at the core network egress PE so that the MiM frames that were transported as the access network payload 52 may be transmitted to the ingress PE on access network B.
  • the frame may be forwarded by the ingress PE on access network B to the intended egress PE on access network B as defined by the access network B destination address B-DA 38.
  • a new physical transport header will be added at the ingress PE on access network B, the format of which will depend on the particular technology used to implement the access network B.
  • the egress PE on access network B will use the I-SID in the I-TAG to identify the VLAN associated with the frame. This value may be used to forward the frame to the correct customer LAN without requiring the egress PE to perform an inspection of customer frame header.
  • the MiM header 32 and physical transport header 34B will be removed before the frame is forwarded to the customer LAN.
  • the frame that was received from the customer LAN by access network A was directly carried as the client payload, the frame that is received by the customer LAN will contain all of the original header information, etc. that was included with the frame when it was received at access network A.
  • transportation of the client frames over the access and core networks may be transparent to the client.
  • the MiM frame output from the core network is the same as the MiM frame that was input to the core network, which makes transportation of the frames over the core network transparent to the access networks.
  • control plane From a control plane perspective, the core network will treat all frames received from the access network as ordinary data frames. Thus, control frames that are being used to exchange control information in the access network will be transported transparently across the core network. This enables the control planes for the access network to be end- to-end. Stated differently, access network A and access network B may share a common control plane.
  • the control plane may be anything, for example Multiple Registration Protocol (MRP), Generalized MPLS (GMPLS), provisioned, and the invention is not limited to the particular control plane selected to implement the access network control plane.
  • MRP Multiple Registration Protocol
  • GPLS Generalized MPLS
  • the core network may maintain its own control plane independently. Thus, interworking between the access network and core network at the control level is not required.
  • the access network and core network may exchange control information with each other if desired, in ordinary operation the core network may transport control packets just like any other data packets and may not treat the access network control packets in a special manner.
  • Network management may be used to monitor network conditions to identify network problems and optionally to isolate the location of network problems once they occur.
  • One way to do this is to inject Operation, Administration and Maintenance (OAM) frames at selected points in the network and then look for the OAM frames at another point or points in the network.
  • OAM Operation, Administration and Maintenance
  • Monitoring OAM flows may enable parts of the network to be monitored for faults, and for faults to detected and isolated.
  • access network OAM flows may exist between the access networks. Stated another way, the core network treats the end-to-end access network OAM frames as regular data packets and thus, the core network treatment of OAM frames is no different than the data plane frames.
  • the transparent transmission of OAM frames across the core network enables a common management plane to be used for access network A and access network B, so that management flows may exist end-to-end within the access network.
  • management entities may be defined within each of access network A and access network B, so that the access networks may independently be managed.
  • the core network may also implement its own management plane without requiring the core network management plane to be interworked with the access network management plane(s).
  • Ethernet OAM flows may be used to perform network management as described in greater detail in co-pending U.S. Patent Application 10/880,876, entitled “Ethernet OAM Domains and Ethernet OAM Frame Format", the content of which is hereby incorporated herein by reference. Ethernet OAM flows are also defined in ITU standard Y.1731, the content of which is hereby incorporated herein by reference.
  • Fig. 4 illustrates a process of transporting a customer frame across a communication network in which MiM encapsulation is used in the access network and VPLS encapsulation is used in the core network.
  • Fig. 5 illustrates graphically the encapsulation process for a particular service instance.
  • the ingress PE 8OA When a service frame is received at the access network ingress PE (100) the ingress PE 8OA will look at the provider VLAN ID (also referred to as the S-VID contained in the S-TAG) associated with the frame and use the provider VLAN ID to identify a MiM service instance 82 for that frame.
  • the MiM service instance (reference 82 in Fig. 5) is a construct in the access network which extends end-to-end across the access network so that the access network may maintain VLAN traffic isolated to enable it to provide VPN service to its customers.
  • the MiM service instance is identified by the I- Tag 44 and may extend, for example, between the input port 84A on the access network ingress PE 80Aand the output port 88B on the access network egress PE 9OB
  • the MiM service instance will be carried in a MiM tunnel defined between end points (B-SA 40 and B-DA 38) in the access network. Unlike the MiM service instance, the MiM tunnel may extend between the output port 88A on the access network ingress PE 8OA and the input port 84B on the access network egress PE 9OB. Since the MiM service instances extend from the input ports 84A of the access network input PE 80A rather than the output port 88 A of the access network input PE 80A, many MiM service instances may be carried on one MiM tunnel. As described above, the I-TAG 44 is included in the MiM header (see Fig. 3) so that the access network egress PE may identify the service instance associated with the frame without looking at the client payload.
  • the customer frame When the frame is received (100) the customer frame will be encapsulated for transmission over the access network as a MiM encapsulated frame (102). The encapsulated frame will then be transported over the MiM tunnel from the access network A ingress PE 8OA to the access network A egress PE 9OA (104). The access network A egress PE will then transmit the MiM encapsulated frame to the core network ingress PE 92 (106).
  • the core network ingress PE 92 will use the entire MiM encapsulated frame as a payload in a VPLS encapsulated frame. Specifically, the core network ingress PE 92 will remove the physical transport header from the frame and encapsulate the MiM encapsulated frame to form a VPLS encapsulated frame. The core network ingress PE 92 will use the B-TAG 38 to determine which VPLS service instance, represented by the pseudowire tag 56, should be used to carry the frame and select the appropriate VPLS tunnel tag 54 based on B-DA. Once the frame has been encapsulated, the VPLS encapsulated frame will be transported over the core network (1 10) to the core network egress PE 94.
  • the core network egress PE 94 will remove the VPLS encapsulation fields to extract the MiM encapsulated frame.
  • the core network egress PE 94 will use the pseudowire tag 56 to identify the interface for the MiM tunnel and forward the frame out over a port associated with the MiM tunnel to the access network B (114).
  • the access network ingress PE 80B will receive the MiM encapsulated frame and transport the MiM encapsulated frame over the access network B (116). Since the MiM encapsulation has been transported over the core network without modification, it is only necessary to attach the appropriate physical header for access network B before forwarding the MiM encapsulated frame on the access network B.
  • Fig. 6 illustrates one embodiment of a network element that may be configured to implement an embodiment of the invention. The network element may be used to implement one of the PE network elements 80A, 80B, 9OA, 9OB, 92, and/or 94 of Fig. 5.
  • the invention is not limited to a network element configured as illustrated, however, as the invention may be implemented on a network element configured in many different ways.
  • the discussion of the specific structure and methods of operation of the embodiment illustrated in Fig. 5 is intended only to provide one example of how the invention may be used and implemented in a particular instance.
  • the invention more broadly may be used in connection with any network element configured to handle Ethernet frames and other types of protocol data units in a communications network.
  • the network element generally includes Input/Output (I/O) cards 150 configured to connect to links in the communications network.
  • the I/O cards 150 may include physical interfaces, such as optical ports, electrical ports, wireless ports, infrared ports, or ports configured to communicate with other conventional physical media, as well as configurable logical elements capable of operating as MAC (layer 2) ports.
  • One or more forwarding engines 152 are provided in the network element to process frames received over the I/O cards 150.
  • the forwarding engines 152 forward frames to a switch fabric interface 154, which passes the packets to a switch fabric 156.
  • the switch fabric 156 enables a frame entering on a port on one or more I/O cards 150 to be output at one or more different ports in a conventional manner.
  • a frame returning from the switch fabric 156 is received by one of the forwarding engines 152 and passed to one or more I/O cards 50.
  • the frame may be handled by the same forwarding engine 152 on both the ingress and egress paths.
  • a given frame may be handled by different forwarding engines on the ingress and egress paths.
  • the invention is not limited to any particular forwarding engine 152, switch fabric interface 154, or switch fabric 156, but rather may be implemented in any suitable network element configured to handle Ethernet frames and/or other protocol data units on a network.
  • One or more Application Specific Integrated Circuits (ASICs) 158, 160 and processors 162, 164 may be provided to implement instructions and processes on the forwarding engines 152.
  • a memory 166 may be included to store data and instructions for use by the forwarding engines.
  • One or more of the components in the data plane is configured, according to an embodiment of the invention, to handle the Ethernet frames by adding or removing the MiM encapsulation fields 32, access network physical transport headers 34A, 34B, VPLS encapsulation fields 40, and/or core network physical transport headers 58, as discussed above.
  • the particular headers to be added will depend on whether the network element is being used as an access network PE 18, or as a core network PE 22.
  • the network element also has a control plane configured to exchange control packets with other network elements so that the correct encapsulation fields may be applied to frames as they are received.
  • the control plane includes at least one processor 170 containing control logic 172.
  • the processor may interface a memory 174 to retrieve data and instructions that will enable the control logic to execute control software 176 configured to enable the network element to perform control functions on the network.
  • the memory may also include management software 178 configured to enable the network element to participate in OAM management flows on the network as discussed in greater detail above. Actions to be taken by the data plane may be programmed into the data plane by the control plane so that the data plane may operate on frames in the manner described above.
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • Programmable logic can be fixed temporarily or permanently in a tangible medium such as a read-only memory chip, a computer memory, a disk, or other storage medium.
  • Programmable logic can also be fixed in a computer data signal embodied in a carrier wave, allowing the programmable logic to be transmitted over an interface such as a computer bus or communication network. All such embodiments are intended to fall within the scope of the present invention and the invention is not limited to a particular implementation.

Abstract

Frames of customer traffic may be encapsulated by adding Mac-in-Mac (MiM) encapsulation fields for transportation of the frames over a portion of provider network. The MiM encapsulated traffic may be further encapsulated using VPLS by adding VPLS encapsulation fields for transportation of the frames over another portion of the provider network. The MiM encapsulations use provider network MAC addresses which enables VPLS MAC learning to occur using provider network MAC address space. MiM tunnels are mapped to VPLS service instances which are assigned pseudowire tags for transportation over the VPLS portion of provider network. The MiM header is retained when the MiM encapsulated frames are transported over the VPLS portion of the provider network. As VPLS frames exit the core network, the VPLS encapsulation fields are removed to extract the original MiM encapsulated frames for further transportation over the MiM portion of the provider network.

Description

METHOD AND APPARATUS FOR TRANSPORTING ETHERNET SERVICES
Background of the Invention
Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for transporting Ethernet services, where the Ethernet service itself might be used to carry other native services.
Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as "network elements." Data is communicated through the data communication network by passing protocol data units, such as frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
Large communication networks generally include subscriber networks, provider- based access networks, and core networks. Subscriber networks are commonly referred to as Local Area Networks (LANs), such as may be implemented by a corporation or university, or even in a residence. Access networks are used to aggregate traffic from a large number of subscribers, and generally encompass an area such as a metropolitan area or regional geographic area. Core networks are generally used to transport data between access networks. Access and core networks may exist in many different geographic areas and may be connected in myriad different ways.
Traditionally, Local Area Networks (LANs) have implemented a network protocol such as Ethernet to enable network elements on the LAN communicate with each other. Ethernet is a well known networking protocol that has been defined by the Institute of Electrical and Electronics Engineers (IEEE) 802 Groups. Conventionally, Ethernet has been used to implement networks in enterprises such as businesses and campuses, and other technologies have been used to transport network traffic in the access and core networks. Specifically, network providers such as carriers that sell bandwidth to subscribers on the access and core networks were reluctant to deploy networks based on Ethernet technology, since Ethernet was designed to provide best efforts service and did not support various control and management functions that were deemed necessary by network providers. As the Ethernet specifications have evolved, however, and as advancements have been made to Ethernet technology, some of these issues are being resolved. Consequently, many service providers are starting to use Ethernet to implement portions of their networks networks.
It is not uncommon for networks to be connected to enable packets to flow from a subscriber's LAN over access and core networks (which may be provided by a service provider or another entity), and then back onto a different portion of the subscriber's LAN. To enable this to happen, the particular manner in which the packet is handled may make a large difference as to the amount of coordination required between the various networks.
Networks may be viewed as having three layers - a data layer, a control layer, and a management layer. The data layer is related to how data is actually transmitted on the network. The control layer is related to how the network elements on the network interoperate. The management layer is related to how operation of the network may be monitored so that faults may be detected and corrected in a timely manner.
Depending on who owns which portions of the network, it may be desirable for one or more of the network areas to have shared control or management planes. For example, a network provider may own access networks in multiple cities and may want them to be commonly managed and to share control information. Depending on the particular way in which the networks are connected, it may be necessary for the networks to work together so that control and data may be passed between the networks. This type of interworking may require significant coordination and may be difficult to implement in situations where one service provider does not own all sections of the network. Summary
Frames of customer traffic may be encapsulated using Mac-in-Mac (MiM) encapsulation and the MiM encapsulated traffic may be further encapsulated using Virtual Private LAN Service (VPLS) encapsulation. The MiM encapsulation uses provider network MAC addressing and include service tags to identify service instances associated with the encapsulated frame. The MiM encapsulated frames are mapped to VPLS service instances and encapsulated using VPLS encapsulation for transportation over the core network. The MiM encapsulation is added when the customer service frames are transported over the MiM network. As frames arrive at the edge of MiM network, the service provider MAC addresses are used as part of the MiM encapsulation. In addition, MiM encapsulation also includes a tag which identifies the MiM tunnel over which various MiM service instances can be carried. This tag is used to identify the correct VPLS service instance and the service provider MAC addresses are used to identify the correct path within the VPLS network. Or in other words, the service provider MAC address space is used for VPLS MAC learning. A pseudowire tag is assigned for each MiM tunnel so that multiple MiM tunnels may use the same VPLS path in the core network. The encapsulation methods described herein may be used to transport Ethernet services, which may be point-to-point, point-to-multipoint, and multipoint, and which may be used to carry frames belonging to other services such as IP frames.
Brief Description of the Drawings
Aspects of the present invention are pointed out with particularity in the appended claims. The present invention is illustrated by way of example in the following drawings in which like references indicate similar elements. The following drawings disclose various embodiments of the present invention for purposes of illustration only and are not intended to limit the scope of the invention. For purposes of clarity, not every component may be labeled in every figure. In the figures: Fig. 1 is a functional block diagram of an example communication network configured to transport data using MiM and VPLS encapsulations according to an embodiment of the invention; Fig. 2 is a functional block diagram of a portion of the example communication network of Fig. 1 showing portions of the networks in greater detail according to an embodiment of the invention;
Fig. 3 is a functional block diagram of the encapsulation used in each part of the communication network of Fig. 1 according to an embodiment of the invention;
Fig. 4 is a flowchart illustrating a process of using MiM and VPLS encapsulation to transport data across a network according to an embodiment of the invention;
Fig. 5 is a functional block diagram graphically illustrating an encapsulation process for a particular service instance; and Fig. 6 is a functional block diagram of a network element that may be used to perform encapsulation/decapsulation according to an embodiment of the invention.
Detailed Description
The following detailed description sets forth numerous specific details to provide a thorough understanding of the invention. However, those skilled in the art will appreciate that the invention may be practiced without these specific details. In other instances, well- known methods, procedures, components, protocols, algorithms, and circuits have not been described in detail so as not to obscure the invention.
Fig. 1 illustrates an example network 10 in which customer traffic from a customer LAN 12A may be transported across an access network 14 A, a core network 16, back through a second access network 14B, and then to another customer network 12B. As discussed in greater detail below, the Ethernet services from the customer network may be encapsulated using Mac-in-Mac (MiM) encapsulation in the access networks 14 A, 14B. This MiM encapsulation may be carried out using the procedures set forth in IEEE 802.1 ah draft standard, although other encapsulation processes may be used as well. For example, as changes are made to the draft standard, the changes may be implemented to cause the encapsulation process to continue to comply with the standard. The MiM encapsulated traffic may be further encapsulated using Virtual Private LAN Service (VPLS) encapsulation in the core network. The particular way in which MiM encapsulation and VPLS encapsulation is implemented (as discussed in greater detail below) enables the data planes, control planes, and management planes of the access and core networks to be independent so that interworking of these planes is minimized. Fig. 2 illustrates a portion of the network of Fig. 1 in greater detail. As shown in Fig. 2, each network area (e.g. each access and core network) has Provider Edge (PE) network elements 18 configured to interconnect the area of the network with another network or customer. The network areas also have network elements that only are connected to other network elements within the network area. These network elements are referred to herein as P network elements 20.
A provider may set up a MiM tunnel between a first edge PE 18A on access network A to a second Edge PE on access network B 18B. Since there may be many edge PEs on the access networks, many MiM tunnels may be established. Once these MiM tunnels are established, customer traffic associated with customer service instances may be mapped to the MiM service instances. This may be accomplished by selecting an I-SID value for the service instance via end-to-end control plane between the access networks without input from the core network. These MiM service instances are then mapped to MiM tunnels. This may be accomplished by selecting a tag for the tunnel, again via end- to-end control plane between the access networks without input from the core network, or by selecting pre-established MiM tunnels.
The MiM tunnels need to be mapped to VPLS service instances over the core network. The core network has a number of edge PEs 22. The core network may establish paths (e.g. MPLS Label Switched Paths or other types of paths) through the core network via P network elements 24 that may be used to carry traffic belonging to VPLS service instances through the core network. These paths through the core network may be used by many different VPLS service instances, and traffic belonging to different VPLS service instance may be differentiated using tags (e.g. pseudo wire tags) as discussed in greater detail below. In operation, customer traffic will be carried on a particular service instance that is negotiated end-to-end by the access networks. The service instance will be assigned to a particular MiM service instance which is mapped to a specific MiM tunnel through the access network A. The MiM encapsulation uses source and destination MAC addresses which are MAC addresses in the access networks A and B. Multiple services instances identified by I-SID may be carried on a given MiM tunnel.
The core edge PE 22 will perform MAC address learning on its ingress PE by looking at the MAC addresses of the MiM encapsulated frame. The core network will determine which VPLS service instance should be used to carry the traffic for the MiM tunnel and assign a tag to the MiM tunnel so that multiple MiM tunnels may be multiplexed across a given VPLS path between core edge PEs 22. When traffic is received at the core network ingress, the traffic will be encapsulated by applying the tag to identify the VPLS instance and another tag to identify the VPLS path. In this manner the
MiM traffic from the access network may be carried transparently across the core network.
Fig. 3 illustrates the format of the headers that may be used to perform MiM and
VPLS encapsulation as described herein. As shown in Fig. 3, client frames are carried without modification as the client payload 30 of a Mac-in-Mac encapsulated frame. Mac- in-Mac encapsulation is being defined in IEEE draft 802.1 ah, the content of which is hereby incorporated herein by reference. As mentioned above, other encapsulation processes may be used as well, for example as the 802. lah draft standard continues to evolve.
As shown in Fig. 3, the MiM encapsulation causes a MiM encapsulation fields 32 to be applied to the client payload 30 so that the access network is able to use its own MAC address space to forward traffic across the access network. A physical transport header 34 may also be applied to enable the traffic to be handled by the network. The format of the physical transport header 34 will depend on the particular technology that has been deployed in the access network. For example, the physical transport header 34 may be a SONET header, a Generic Framing Procedure (GFP) header, or another type of header.
The MiM encapsulation fields 32 include the source and destination MAC addresses which are the end-points within the MiM tunnel. The Destination MAC Address (B-DA) 38 is the MAC address in access network B which is the destination address of the MiM tunnel end-point. B-DA is based on the access network MAC address space and may be, for example, the MAC address of the ingress port of the egress PE in access network B. Since the MiM encapsulated frames are addressed in a manner that does not rely on the customer MAC address space, the customer's MAC address space is hidden from both the access network and the core network so it is not necessary to ensure that the customers use globally unique MAC addresses.
The Source MAC Address (B-SA) 40 is the source address of the MiM tunnel end- point. B-SA is based on the source MAC address in access network A where the MiM tunnel originates. For example, this may be the MAC address of the egress port of the ingress PE in access network A.
A given MiM tunnel will extend between one or more pairs of SA/DA MAC addresses. Since many subscribers may need to send traffic between those endpoints, it would be good to enable the traffic to be multiplexed onto the MiM tunnels. To do this, service instances are used. A given MiM tunnel may carry multiple MiM service instances. The MiM service instances may be distinguished on the MiM tunnels using the
I-Tag 44. The I-Tag includes the 802.1 ah Ethertype value. A B-Tag (802. lad Ethertype) is included to limit the broadcast domain for MiM tunnels. The MiM encapsulation fields 32 may also include a payload Ethertype field 36 indicating the particular Ethertype of the client payload.
The portions of the MiM encapsulation fields may be used as follows. Initially, the access network provider may establish tunnels between end points on the access network.
These are the MiM tunnels. MiM service instances will be mapped to the MiM tunnels and client traffic will be mapped to the MiM service instances. Traffic belonging to different MiM service instances may be identified by the I-Tag values so that the traffic may be separated at within the MiM tunnels.
When a client frame is received at an ingress PE, the ingress PE may use the client frame's VLAN ID to set the I-Tag which contains the I-SID. The ingress PE may determine which MiM tunnel should be used to carry the frame and set the set the B-SA,
B-DA and B-VID fields so that the MiM encapsulation fields include the correct MAC addresses for the MiM tunnel. The physical transport header may then be applied and the packet will be transported across the access network.
When the frame arrives at a core network ingress PE, the access network payload, including the client payload 30 and the MiM encapsulation fields, may be encapsulated by applying a VPLS encapsulation fields 50 to the frame. The VPLS payload in the core network 52 is the entire MIM encapsulated frame, including the MIM encapsulation fields and the client payload. The physical header 34 will be stripped from the MiM frame before VPLS encapsulation. The core network ingress PE maps MiM frames to particular VPLS service instances. Each VPLS service instance extends between a particular pair of ingress and egress PE network elements on the core network and will extend along a path through the network between those PE network elements. Depending on the number of PE network elements on the core network there may therefore be many service instances.
The ingress PE on the core network performs mapping of MiM tunnels, identified by the MiM tunnel tag, to VPLS service instance and MAC learning for MiM tunnels to learn the VPLS path that is to be used to carry MiM encapsulated traffic from each of the MiM tunnels that send traffic to the ingress PE. Since the MiM encapsulated frames contains MAC addresses that have been assigned by access network A and access network B, the MAC learning in VPLS is based on access network MAC address space. The MAC address space associated with the access networks is more likely to be stable, compared to customer MAC address space, and thus MAC learning of provider MAC addresses may be expected to be more robust than if customer address space was used. VPLS is defined by the IETF L2VPN working group, and is intended to be compliant with standards proposed by that working group.
The core network will also assign a physical transport header 58 to the frame to enable the core network to transport the frame across the network. The format of the physical transport header 58 in the core network, like the physical transport header 34 in the access network, will depend on the technology being used to implement the core network.
At the core network egress PE, the pseudowire tag 56 is used by the egress PE to route the frame to the correct egress port/interface. The VPLS header 50 and core network physical header 58 will be removed at the core network egress PE so that the MiM frames that were transported as the access network payload 52 may be transmitted to the ingress PE on access network B.
Since the MiM header was transported transparently across the core network, the frame may be forwarded by the ingress PE on access network B to the intended egress PE on access network B as defined by the access network B destination address B-DA 38. A new physical transport header will be added at the ingress PE on access network B, the format of which will depend on the particular technology used to implement the access network B. When the frame arrives at the egress PE on access network B, the egress PE on access network B will use the I-SID in the I-TAG to identify the VLAN associated with the frame. This value may be used to forward the frame to the correct customer LAN without requiring the egress PE to perform an inspection of customer frame header. The MiM header 32 and physical transport header 34B will be removed before the frame is forwarded to the customer LAN.
Since the frame that was received from the customer LAN by access network A was directly carried as the client payload, the frame that is received by the customer LAN will contain all of the original header information, etc. that was included with the frame when it was received at access network A. Thus, transportation of the client frames over the access and core networks may be transparent to the client. Similarly, the MiM frame output from the core network is the same as the MiM frame that was input to the core network, which makes transportation of the frames over the core network transparent to the access networks.
From a control plane perspective, the core network will treat all frames received from the access network as ordinary data frames. Thus, control frames that are being used to exchange control information in the access network will be transported transparently across the core network. This enables the control planes for the access network to be end- to-end. Stated differently, access network A and access network B may share a common control plane. The control plane may be anything, for example Multiple Registration Protocol (MRP), Generalized MPLS (GMPLS), provisioned, and the invention is not limited to the particular control plane selected to implement the access network control plane.
Since the access network control plane frames are transported transparently across the core network, and are not processed or used by the core network, the core network may maintain its own control plane independently. Thus, interworking between the access network and core network at the control level is not required. Although the access network and core network may exchange control information with each other if desired, in ordinary operation the core network may transport control packets just like any other data packets and may not treat the access network control packets in a special manner.
Network management may be used to monitor network conditions to identify network problems and optionally to isolate the location of network problems once they occur. One way to do this is to inject Operation, Administration and Maintenance (OAM) frames at selected points in the network and then look for the OAM frames at another point or points in the network. Monitoring OAM flows may enable parts of the network to be monitored for faults, and for faults to detected and isolated.
Since the core network will transparently transport any frame it receives from the access network, access network OAM flows may exist between the access networks. Stated another way, the core network treats the end-to-end access network OAM frames as regular data packets and thus, the core network treatment of OAM frames is no different than the data plane frames. The transparent transmission of OAM frames across the core network enables a common management plane to be used for access network A and access network B, so that management flows may exist end-to-end within the access network. Similarly, management entities may be defined within each of access network A and access network B, so that the access networks may independently be managed. The core network may also implement its own management plane without requiring the core network management plane to be interworked with the access network management plane(s). Where the core network and access network are owned by the same service provider, it may be desirable to interwork the management planes of these two networks, for example by defining management flows that span across boundaries between the network areas. The invention is not limited to an embodiment in which there is no interworking between the core and access networks. Rather, as noted above, the solution described herein enables the two networks to be independently managed if desired, so that interworking between the core and access networks is not a prerequisite to management of any one of them. Ethernet OAM flows may be used to perform network management as described in greater detail in co-pending U.S. Patent Application 10/880,876, entitled "Ethernet OAM Domains and Ethernet OAM Frame Format", the content of which is hereby incorporated herein by reference. Ethernet OAM flows are also defined in ITU standard Y.1731, the content of which is hereby incorporated herein by reference.
Fig. 4 illustrates a process of transporting a customer frame across a communication network in which MiM encapsulation is used in the access network and VPLS encapsulation is used in the core network. Fig. 5 illustrates graphically the encapsulation process for a particular service instance.
When a service frame is received at the access network ingress PE (100) the ingress PE 8OA will look at the provider VLAN ID (also referred to as the S-VID contained in the S-TAG) associated with the frame and use the provider VLAN ID to identify a MiM service instance 82 for that frame. The MiM service instance (reference 82 in Fig. 5) is a construct in the access network which extends end-to-end across the access network so that the access network may maintain VLAN traffic isolated to enable it to provide VPN service to its customers. The MiM service instance is identified by the I- Tag 44 and may extend, for example, between the input port 84A on the access network ingress PE 80Aand the output port 88B on the access network egress PE 9OB
The MiM service instance will be carried in a MiM tunnel defined between end points (B-SA 40 and B-DA 38) in the access network. Unlike the MiM service instance, the MiM tunnel may extend between the output port 88A on the access network ingress PE 8OA and the input port 84B on the access network egress PE 9OB. Since the MiM service instances extend from the input ports 84A of the access network input PE 80A rather than the output port 88 A of the access network input PE 80A, many MiM service instances may be carried on one MiM tunnel. As described above, the I-TAG 44 is included in the MiM header (see Fig. 3) so that the access network egress PE may identify the service instance associated with the frame without looking at the client payload.
When the frame is received (100) the customer frame will be encapsulated for transmission over the access network as a MiM encapsulated frame (102). The encapsulated frame will then be transported over the MiM tunnel from the access network A ingress PE 8OA to the access network A egress PE 9OA (104). The access network A egress PE will then transmit the MiM encapsulated frame to the core network ingress PE 92 (106).
The core network ingress PE 92 will use the entire MiM encapsulated frame as a payload in a VPLS encapsulated frame. Specifically, the core network ingress PE 92 will remove the physical transport header from the frame and encapsulate the MiM encapsulated frame to form a VPLS encapsulated frame. The core network ingress PE 92 will use the B-TAG 38 to determine which VPLS service instance, represented by the pseudowire tag 56, should be used to carry the frame and select the appropriate VPLS tunnel tag 54 based on B-DA. Once the frame has been encapsulated, the VPLS encapsulated frame will be transported over the core network (1 10) to the core network egress PE 94. The core network egress PE 94 will remove the VPLS encapsulation fields to extract the MiM encapsulated frame. The core network egress PE 94 will use the pseudowire tag 56 to identify the interface for the MiM tunnel and forward the frame out over a port associated with the MiM tunnel to the access network B (114).
The access network ingress PE 80B will receive the MiM encapsulated frame and transport the MiM encapsulated frame over the access network B (116). Since the MiM encapsulation has been transported over the core network without modification, it is only necessary to attach the appropriate physical header for access network B before forwarding the MiM encapsulated frame on the access network B.
When the MiM encapsulated frame arrives at the access network B egress PE 9OB, it will be unencapsulated. Specifically, the access network B egress PE 9OB will remove the MiM encapsulation to recreate the customer frame (1 18). The I-SID contained in the I-Tag may then be used to identify the correct VLAN and port over which the customer frame should be forwarded (120) without requiring the egress PE to perform a lookup on the header of the customer frame to identify the VLAN ID of the customer frame. Fig. 6 illustrates one embodiment of a network element that may be configured to implement an embodiment of the invention. The network element may be used to implement one of the PE network elements 80A, 80B, 9OA, 9OB, 92, and/or 94 of Fig. 5. The invention is not limited to a network element configured as illustrated, however, as the invention may be implemented on a network element configured in many different ways. The discussion of the specific structure and methods of operation of the embodiment illustrated in Fig. 5 is intended only to provide one example of how the invention may be used and implemented in a particular instance. The invention more broadly may be used in connection with any network element configured to handle Ethernet frames and other types of protocol data units in a communications network. As shown in Fig. 6, the network element generally includes Input/Output (I/O) cards 150 configured to connect to links in the communications network. The I/O cards 150 may include physical interfaces, such as optical ports, electrical ports, wireless ports, infrared ports, or ports configured to communicate with other conventional physical media, as well as configurable logical elements capable of operating as MAC (layer 2) ports.
One or more forwarding engines 152 are provided in the network element to process frames received over the I/O cards 150. The forwarding engines 152 forward frames to a switch fabric interface 154, which passes the packets to a switch fabric 156. The switch fabric 156 enables a frame entering on a port on one or more I/O cards 150 to be output at one or more different ports in a conventional manner. A frame returning from the switch fabric 156 is received by one of the forwarding engines 152 and passed to one or more I/O cards 50. The frame may be handled by the same forwarding engine 152 on both the ingress and egress paths. Optionally, where more than one forwarding engine 152 is included in the network element, a given frame may be handled by different forwarding engines on the ingress and egress paths.
The invention is not limited to any particular forwarding engine 152, switch fabric interface 154, or switch fabric 156, but rather may be implemented in any suitable network element configured to handle Ethernet frames and/or other protocol data units on a network. One or more Application Specific Integrated Circuits (ASICs) 158, 160 and processors 162, 164 may be provided to implement instructions and processes on the forwarding engines 152. Optionally, a memory 166 may be included to store data and instructions for use by the forwarding engines.
The I/O cards 150, forwarding engine 152, switch fabric interface 154 and switch fabric 156, form a data plane for the network element. One or more of the components in the data plane is configured, according to an embodiment of the invention, to handle the Ethernet frames by adding or removing the MiM encapsulation fields 32, access network physical transport headers 34A, 34B, VPLS encapsulation fields 40, and/or core network physical transport headers 58, as discussed above. The particular headers to be added will depend on whether the network element is being used as an access network PE 18, or as a core network PE 22.
The network element also has a control plane configured to exchange control packets with other network elements so that the correct encapsulation fields may be applied to frames as they are received. To do this, the control plane includes at least one processor 170 containing control logic 172. The processor may interface a memory 174 to retrieve data and instructions that will enable the control logic to execute control software 176 configured to enable the network element to perform control functions on the network. The memory may also include management software 178 configured to enable the network element to participate in OAM management flows on the network as discussed in greater detail above. Actions to be taken by the data plane may be programmed into the data plane by the control plane so that the data plane may operate on frames in the manner described above.
It should be understood that all functional statements made herein describing the functions to be performed by the methods of the invention may be performed by software programs implemented utilizing subroutines and other programming techniques known to those of ordinary skill in the art. When the functions described herein are implemented in software, the software may be implemented as a set of program instructions configured to operate in control logic on a network element that are stored in a computer readable memory within the network element and executed on a microprocessor. Alternatively, all or some of the functions described herein be implemented in hardware, firmware, or a combination of hardware, software, and firmware. For example, it will be apparent to a skilled artisan that all or many of the functions described herein can be embodied using discrete components, integrated circuitry such as an Application Specific Integrated Circuit (ASIC), programmable logic used in conjunction with a programmable logic device such as a Field Programmable Gate Array (FPGA) or microprocessor, or any other device including any combination thereof. Programmable logic can be fixed temporarily or permanently in a tangible medium such as a read-only memory chip, a computer memory, a disk, or other storage medium. Programmable logic can also be fixed in a computer data signal embodied in a carrier wave, allowing the programmable logic to be transmitted over an interface such as a computer bus or communication network. All such embodiments are intended to fall within the scope of the present invention and the invention is not limited to a particular implementation.
It should be understood that various changes and modifications of the embodiments shown in the drawings and described in the specification may be made within the spirit and scope of the present invention. Accordingly, it is intended that all matter contained in the above description and shown in the accompanying drawings be interpreted in an illustrative and not in a limiting sense. The invention is limited only as defined in the following claims and the equivalents thereto.

Claims

CLAIMS:
1. A method of transporting Ethernet services in a network, the method comprising the steps of: receiving by a network element a Mac-in-Mac (MiM) encapsulated client frame; encapsulating the MiM encapsulated client frame with Virtual Private LAN Service (VPLS) encapsulation fields; and transmitting the VPLS frame in the network.
2. The method of claim 1, wherein the MiM encapsulated client frame includes a client payload field containing the client frame, and MiM encapsulation fields.
3. The method of claim 2, wherein the MiM encapsulated fields include a destination MAC address field, a source MAC address field, a B-Tag field and an I-Tag field.
4. The method of claim 3, wherein the destination MAC address field contains a first MAC address on a provider network; and wherein the source MAC address field contains a second MAC address on the provider network.
5. The method of claim 4, further comprising the step of performing VPLS MAC learning based on the MAC addresses of the provider network.
6. The method of claim 3, wherein VPLS instances are assigned based on the B-Tag field of the MiM encapsulated client frames identifying MiM tunnels.
7. The method of claim 3, wherein the B-Tag is used to identify a MiM tunnel on the access network.
8. The method of claim 1, wherein the step of encapsulating the MiM encapsulated client frame with Virtual Private LAN Service (VPLS) encapsulation fields comprises adding a pseudowire tag corresponding to a VPLS service instance to the MiM encapsulated client frame, and adding a tunnel tag corresponding to the VPLS path to the MiM encapsulated client frame.
9. The method of claim 8, wherein the pseudowire tag corresponds to a MiM tunnel.
10. The method of claim 8, where in the tunnel tag corresponds to the destination MAC address of the MiM encapsulated frame.
1 1. The method of claim 1 , wherein the client frame is an Ethernet frame including an Ethernet header and client data.
12. A network, comprising: a plurality of MiM network portions configured to transport Mac-in-Mac (MiM) encapsulated frames, said MiM encapsulated frames including a client frame and MiM encapsulation fields; a VPLS network portion configured to interconnect the MiM network portions and configured to receive MiM encapsulated client frames from the first network portion and encapsulate the MiM encapsulated client frames for transportation by adding VPLS encapsulation fields to the MiM encapsulated client frames without modifying the MiM encapsulation fields or the client frames.
13. The network of claim 12, wherein the plurality of MiM network portions are virtualized as a single MiM network portion by connecting them using the VPLS network portion.
14. The network of claim 12, wherein the plurality of MiM network portions share a common management plane.
15. The network of claim 14, wherein the common management plane enables management entities to be defined across the MiM network portions, said management entities comprising flows of OAM frames, and wherein the VPLS network portion is configured to transport the OAM frames as ordinary data frames to avoid interworking a management plane of the VPLS network portion with the management plane of the MiM network portions.
16. The network of claim 12, wherein the MiM network portions share a common control plane.
17. The network of claim 16, wherein the common control plane enables common control information to be shared between the MiM network portions, and wherein the VPLS network portion is configured to transport the control frames as ordinary data frames to avoid interworking a control plane of the VPLS network portion with the control plane of the MiM network portions.
18. The network of claim 12, wherein the MiM network portions define a non- overlapping MAC address space; and wherein the VPLS network portion is configured to perform MAC learning based on the non-overlapping MAC address space of the MiM network portions.
19. A method of transporting Ethernet services, the method comprising the steps of: encapsulating an Ethernet frame by adding Mac-in-Mac (MiM) encapsulation fields to the Ethernet frame, so that the Ethernet frame is contained in a MiM payload of a MiM encapsulated frame; and encapsulating the MiM encapsulated frame by adding VPLS encapsulation fields to the MiM encapsulated frame, so that the MiM encapsulated frame, including the Ethernet frame and MiM encapsulation fields, is contained in a VPLS payload of a VPLS encapsulated frame.
20. The method of claim 19, wherein the MiM encapsulation fields comprise a source address field, a destination address field, an I-tag field, and a B-tag field.
21. The method of claim 20, wherein the VPLS encapsulation fields include a tunnel tag and a pseudowire tag.
22. The method of claim 21, wherein a value of the tunnel tag is dependent on a value of the destination address field, and wherein a value of the pseudowire tag is dependent on a value of the B-tag field.
PCT/CA2006/001797 2005-11-02 2006-11-02 Method and apparatus for transporting ethernet services WO2007051300A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US73289505P 2005-11-02 2005-11-02
US60/732,895 2005-11-02
US11/540,023 US7746892B2 (en) 2005-11-02 2006-09-30 Method and apparatus for transporting ethernet services
US11/540,023 2006-09-30

Publications (1)

Publication Number Publication Date
WO2007051300A1 true WO2007051300A1 (en) 2007-05-10

Family

ID=38005390

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2006/001797 WO2007051300A1 (en) 2005-11-02 2006-11-02 Method and apparatus for transporting ethernet services

Country Status (2)

Country Link
US (6) US7746892B2 (en)
WO (1) WO2007051300A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009109824A1 (en) 2008-03-04 2009-09-11 Telefonaktiebolaget Lm Ericsson (Publ) A system and method of automatically configuring i-sids in gmpls controlled eternet provider backbone bridged networks
WO2009141385A2 (en) * 2008-05-23 2009-11-26 Nokia Siemens Networks Oy Providing station context and mobility in a wireless local area network having a split mac architecture
JP5303644B2 (en) * 2009-06-25 2013-10-02 株式会社日立製作所 Transport control system and transport control server
WO2014118174A1 (en) * 2013-01-29 2014-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for qos differentiation of vpn traffic across domains
US9276768B2 (en) 2008-05-23 2016-03-01 Nokia Solutions And Networks Oy Providing station context and mobility in a wireless local area network having a split MAC architecture

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7986937B2 (en) 2001-12-20 2011-07-26 Microsoft Corporation Public access point
US7188364B2 (en) * 2001-12-20 2007-03-06 Cranite Systems, Inc. Personal virtual bridged local area networks
US7120791B2 (en) 2002-01-25 2006-10-10 Cranite Systems, Inc. Bridged cryptographic VLAN
CN1780193B (en) * 2004-11-25 2010-08-11 华为技术有限公司 ADM method, device and system based on universal framing protocol
US7746892B2 (en) * 2005-11-02 2010-06-29 Nortel Networks Limited Method and apparatus for transporting ethernet services
JP4593484B2 (en) * 2006-02-03 2010-12-08 アラクサラネットワークス株式会社 Data communication system and method
CN100521653C (en) * 2006-05-18 2009-07-29 华为技术有限公司 Method and system for nesting group network by skeleton bridging technology
CN101123570B (en) * 2006-08-09 2011-05-18 华为技术有限公司 Data forward method and system between multiple operator Ethernet
JP5106545B2 (en) * 2007-01-12 2012-12-26 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Control frame processing by provider backbone bridge
CN101584162B (en) * 2007-01-17 2013-05-29 北方电讯网络有限公司 Method and apparatus for interworking Ethernet and MPLS networks
US8416789B1 (en) * 2007-02-05 2013-04-09 World Wide Packets, Inc. Multipoint packet forwarding using packet tunnels
US8416790B1 (en) 2007-02-05 2013-04-09 World Wide Packets, Inc. Processing Ethernet packets associated with packet tunnels
US8531941B2 (en) 2007-07-13 2013-09-10 Cisco Technology, Inc. Intra-domain and inter-domain bridging over MPLS using MAC distribution via border gateway protocol
US7751399B2 (en) * 2007-08-06 2010-07-06 Cisco Technology, Inc. Scalable virtual private local area network service
US7903676B2 (en) * 2008-02-05 2011-03-08 Cisco Technology, Inc. Transportation of IEEE 802.1ah frames over multiprotocol label switching pseudowires for virtual private LAN services
GB0804920D0 (en) * 2008-03-17 2008-04-16 Ericsson Telefon Ab L M Method and apparatus for ethernet re-routing
IL192140A0 (en) * 2008-06-12 2009-02-11 Ethos Networks Ltd Method and system for transparent lan services in a packet network
US8045570B2 (en) * 2008-09-30 2011-10-25 Nortel Networks Limited Extended private LAN
JP5287481B2 (en) * 2009-05-01 2013-09-11 日立電線株式会社 Network relay device, network, and network maintenance operation method
IL202067A0 (en) * 2009-11-12 2010-11-30 Eci Telecom Ltd Ethernet network within mpls network
CN102291320B (en) * 2011-09-29 2015-03-18 杭州华三通信技术有限公司 MAC (media access control) address learning method and edge device
CN102355424B (en) * 2011-10-20 2016-06-15 神州数码网络(北京)有限公司 A kind of method and system realizing MIM and VPLS intercommunication forwarding
WO2013157256A1 (en) * 2012-04-18 2013-10-24 日本電気株式会社 Interworking device, method, and non-transitory computer-readable medium storing a program
CN103973825B (en) * 2013-02-01 2017-12-22 中兴通讯股份有限公司 Method, node device and the sending method of MAC Address accessibility are noticed in stacking network
EP3407950B1 (en) * 2016-01-28 2021-08-11 Invent Medical Corporation System for preventing cross-contamination in flow generation systems

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030142674A1 (en) * 2002-01-30 2003-07-31 Nortel Networks Limited Label control method and apparatus for virtual private LAN segment networks
WO2004008696A1 (en) * 2002-07-16 2004-01-22 Enterasys Networks, Inc. Apparatus and method for a virtual hierarchial local area network
US20040184408A1 (en) * 2003-03-22 2004-09-23 Sbc Properties, L.P. Ethernet architecture with data packet encapsulation
US20050027782A1 (en) * 2003-08-01 2005-02-03 Rajkumar Jalan Method for providing scalable multicast service in a virtual private LAN service

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7152115B2 (en) * 2001-07-12 2006-12-19 Nortel Networks Limited Virtual private networks
US20030174706A1 (en) * 2002-03-15 2003-09-18 Broadcom Corporation Fastpath implementation for transparent local area network (LAN) services over multiprotocol label switching (MPLS)
US7478167B2 (en) * 2002-03-18 2009-01-13 Nortel Networks Limited Resource allocation using an auto-discovery mechanism for provider-provisioned layer-2 and layer-3 virtual private networks
US7525960B2 (en) * 2002-05-09 2009-04-28 Alcatel-Lucent Canada Inc. Methods and systems preventing frame mis-ordering in explicitly routed networks
US7411904B2 (en) * 2002-07-22 2008-08-12 Lucent Technologies Inc. Multiprotocol label switching (MPLS) edge service extraction
JP4069383B2 (en) * 2003-03-18 2008-04-02 富士ゼロックス株式会社 Surface emitting semiconductor laser and manufacturing method thereof
US20040184407A1 (en) * 2003-03-21 2004-09-23 Sbc Knowledge Ventures, L.P. Operations, administration, and maintenance data packet and related testing methods
US7440438B2 (en) * 2003-10-24 2008-10-21 Nortel Networks Limited Refresh and filtering mechanisms for LDP based VPLS and L2VPN solutions
US20050147104A1 (en) * 2003-12-29 2005-07-07 Hamid Ould-Brahim Apparatus and method for multihop MPLS/IP/ATM/frame relay/ethernet pseudo-wire
US8190772B2 (en) * 2003-12-29 2012-05-29 Nortel Networks Limited Apparatus and method for layer-2 and layer-3 VPN discovery
US7593395B2 (en) * 2003-12-29 2009-09-22 Nortel Networks Limited Apparatus and method for distributing layer-2 VPN information
US7423980B2 (en) * 2004-07-01 2008-09-09 Nortel Networks Limited Full mesh status monitor
US8422500B2 (en) * 2004-07-02 2013-04-16 Rockstar Consortium Us Lp VLAN support of differentiated services
US7733856B2 (en) * 2004-07-15 2010-06-08 Alcatel-Lucent Usa Inc. Obtaining path information related to a virtual private LAN services (VPLS) based network
US7889681B2 (en) * 2005-03-03 2011-02-15 Cisco Technology, Inc. Methods and devices for improving the multiple spanning tree protocol
US8194656B2 (en) * 2005-04-28 2012-06-05 Cisco Technology, Inc. Metro ethernet network with scaled broadcast and service instance domains
US7961621B2 (en) * 2005-10-11 2011-06-14 Cisco Technology, Inc. Methods and devices for backward congestion notification
US7697528B2 (en) * 2005-11-01 2010-04-13 Nortel Networks Limited Multilink trunking for encapsulated traffic
US7746892B2 (en) * 2005-11-02 2010-06-29 Nortel Networks Limited Method and apparatus for transporting ethernet services
US20070286204A1 (en) * 2006-06-12 2007-12-13 Hamid Ould-Brahim Supporting Multi-Protocol Label Switching (MPLS) Applications Over Ethernet Switch Paths
EP2104896B1 (en) * 2007-01-17 2013-03-06 Nortel Networks Limited Border gateway protocol procedures for mpls and layer-2 vpn using ethernet-based tunnels
EP2104897A4 (en) * 2007-01-17 2010-12-22 Nortel Networks Ltd Border gateway protocol extended community attribute for layer-2 and layer-3 virtual private networks using 802.1ah-based tunnels
CN101584162B (en) * 2007-01-17 2013-05-29 北方电讯网络有限公司 Method and apparatus for interworking Ethernet and MPLS networks
US8144715B2 (en) * 2007-08-10 2012-03-27 Rockstar Bideo LP Method and apparatus for interworking VPLS and ethernet networks
US8854982B2 (en) * 2007-08-30 2014-10-07 Rockstar Consortium Us Lp Method and apparatus for managing the interconnection between network domains

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030142674A1 (en) * 2002-01-30 2003-07-31 Nortel Networks Limited Label control method and apparatus for virtual private LAN segment networks
WO2004008696A1 (en) * 2002-07-16 2004-01-22 Enterasys Networks, Inc. Apparatus and method for a virtual hierarchial local area network
US20040184408A1 (en) * 2003-03-22 2004-09-23 Sbc Properties, L.P. Ethernet architecture with data packet encapsulation
US20050027782A1 (en) * 2003-08-01 2005-02-03 Rajkumar Jalan Method for providing scalable multicast service in a virtual private LAN service

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ARCO ET AL.: "Layer 2 VPN architectures and operation", COMMUNICATION SYSTEM AND NETWORK, INTERNATIONAL CONFERENCE ON COMMUNICATIONS SYSTEMS AND NETWORKS, PONENCIA, SPAIN, 4 September 2004 (2004-09-04), pages 208 - 213, XP008080629 *
RADOACA ET AL.: "GVPLS/LPE - Generic VPLS Solution based on LPE Framework", INTERNET DRAFT, October 2002 (2002-10-01), XP015004932, Retrieved from the Internet <URL:http://www.tools.ietf.org/html/draft-radoaca-ppvpn-gvpls-01> *
SODDER: "Hierarchical LAN Services - Providing Scalability in L2 Virtual Private Networks by using a MAC-n-MAC Frame Encapsulation and a Larger Service-tag", IEEE 802.1 INTERIM MEETING, January 2003 (2003-01-01), pages 5 - 9, AND 18, XP003012761 *
TANCEVSKI ET AL.: "Evolution of Ethernet for data transport networks", ALCATEL TELECOMMUNICATIONS REVIEW, 2005, pages 216 - 221, XP003012760 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009109824A1 (en) 2008-03-04 2009-09-11 Telefonaktiebolaget Lm Ericsson (Publ) A system and method of automatically configuring i-sids in gmpls controlled eternet provider backbone bridged networks
US8842667B2 (en) 2008-03-04 2014-09-23 Telefonaktiebolaget L M Ericsson (Publ) System and method of automatically configuring I-SIDS in GMPLS controlled ethernet provider backbone bridged networks
US9325623B2 (en) 2008-03-04 2016-04-26 Telefonaktiebolaget L M Ericsson (Publ) System and method of automatically configuring I-SIDs in GMPLS controlled ethernet provider backbone bridged networks
EP3119042A1 (en) 2008-03-04 2017-01-18 Telefonaktiebolaget LM Ericsson (publ) A system and method of automatically configuring i-sids in gmpls controlled ethernet provider backbone bridged networks
WO2009141385A2 (en) * 2008-05-23 2009-11-26 Nokia Siemens Networks Oy Providing station context and mobility in a wireless local area network having a split mac architecture
WO2009141385A3 (en) * 2008-05-23 2010-01-28 Nokia Siemens Networks Oy Providing station context and mobility in a wireless local area network having a split mac architecture
US8422513B2 (en) 2008-05-23 2013-04-16 Nokia Siemens Networks Oy Providing station context and mobility in a wireless local area network having a split MAC architecture
US9276768B2 (en) 2008-05-23 2016-03-01 Nokia Solutions And Networks Oy Providing station context and mobility in a wireless local area network having a split MAC architecture
JP5303644B2 (en) * 2009-06-25 2013-10-02 株式会社日立製作所 Transport control system and transport control server
WO2014118174A1 (en) * 2013-01-29 2014-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for qos differentiation of vpn traffic across domains
US9942159B2 (en) 2013-01-29 2018-04-10 Telefonaktiebolaget Lm Ericsson Method and arrangement for QOS differentiation of VPN traffic across domains

Also Published As

Publication number Publication date
US7746892B2 (en) 2010-06-29
US9083646B2 (en) 2015-07-14
US20140023081A1 (en) 2014-01-23
US20130272308A1 (en) 2013-10-17
US20100226376A1 (en) 2010-09-09
US20120044939A1 (en) 2012-02-23
US8085811B2 (en) 2011-12-27
US20070116045A1 (en) 2007-05-24
US20140023078A1 (en) 2014-01-23
US8588237B2 (en) 2013-11-19

Similar Documents

Publication Publication Date Title
US7746892B2 (en) Method and apparatus for transporting ethernet services
EP2417735B1 (en) Enabling an ethernet ring network to scalably support a hub-and-spoke connectivity model
US8144715B2 (en) Method and apparatus for interworking VPLS and ethernet networks
US8504727B2 (en) Method and apparatus for interworking ethernet and MPLS networks
US8098656B2 (en) Method and apparatus for implementing L2 VPNs on an IP network
US9338052B2 (en) Method and apparatus for managing the interconnection between network domains
US8917731B2 (en) Multi-protocol support over Ethernet packet-switched networks
US8531941B2 (en) Intra-domain and inter-domain bridging over MPLS using MAC distribution via border gateway protocol
US8005081B2 (en) Evolution of ethernet networks
EP2541841B1 (en) Method for sending ethernet frames in ethernet tree service and provider edge device
US7693164B1 (en) Configuring a packet tunnel network
US8416789B1 (en) Multipoint packet forwarding using packet tunnels
US9853833B2 (en) Individual virtual private local area network service conversion to a different virtual private network service
US8416790B1 (en) Processing Ethernet packets associated with packet tunnels
GB2451738A (en) Method and apparatus for interworking VPLS and Ethernet networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06804672

Country of ref document: EP

Kind code of ref document: A1