HK1161011B - Reducing cc message transmission in a provider network - Google Patents

Description

Reducing CC messaging in a provider network

Technical Field

Embodiments of the invention relate to the field of network processing; and more particularly to the transmission of CC (connection check) messages.

Background

The CC (connection check) message described in the Institute of Electrical and Electronics Engineers (IEEE) Standard 802.1ag-2007 "IEEE Standard for Local and regional Area Networks-Virtual bridge Local Area Networks evaluation 5: Connectivity Fault Management" (12, 17, 2007) is used to detect the status between points in the network, such as Maintenance End Points (MEPs). CC messages are multicast messages sent between endpoints at a periodic rate (e.g., every 3.3 milliseconds). CC messages are sent by each endpoint being monitored within each service instance (e.g., Virtual Private LAN Service (VPLS), Provider Backbone Bridge (PBB) network) in the ethernet service network. Service instances may include endpoints across a wide area, such as a Metropolitan Area Network (MAN) or a Wide Area Network (WAN). CC messages for service instances may be transmitted across MAN or WAN links to reach the corresponding endpoints.

Typically, CC messages in an ethernet service network are transmitted over a transport network (e.g., over a MAN or WAN link) in a similar manner to any other frame received over the service network. Thus, since CC messages are typically sent at a high periodic rate, and as the number of service instances increases, the bandwidth of the transport network may be used to transport a large number of CCs.

Drawings

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the figure.

Fig. 1 illustrates an exemplary network with a reduced periodic transmission rate of CC messages in an ethernet service network according to one embodiment of the present invention.

Fig. 2 illustrates an exemplary VPLS network with reduced periodic delivery rate of CC messages in a transport network connection, wherein the customer edge network elements are dual homed, according to one embodiment of the invention.

Fig. 3A is a block diagram illustrating an exemplary network element that reduces the periodic transmission rate of CC messages, according to one embodiment of the invention.

Fig. 3B is a block diagram illustrating an exemplary network element receiving the reduced periodic transmission rate and transmitting CC messages at the original periodic transmission rate of the CC messages of fig. 3A, according to one embodiment of the invention.

Fig. 4 is a flow diagram illustrating an exemplary method for reducing the periodic transmission rate of CC messages in accordance with one embodiment of the present invention.

FIG. 5 is a flow diagram illustrating an exemplary method for determining CC message timeouts and triggering explicit service instance failure (down) CC messages, according to one embodiment of the invention; and (c) and (d).

Fig. 6A and 6B are flow diagrams illustrating exemplary methods for processing the CC messages received at a reduced periodic transmission rate of fig. 4 and processing the explicit service instance failure CC messages of fig. 5 according to one embodiment of the invention.

Detailed Description

In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the following description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "coupled" is used to indicate that two or more elements that may or may not be in direct physical or electrical contact with each other interact or cooperate with each other. "connected" is used to indicate the establishment of communication between two or more units coupled to each other.

The techniques illustrated in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., computer end stations, network elements, etc.). Such electronic devices store and communicate code and data using machine-readable media, such as machine storage media (e.g., magnetic disks, optical disks, random access memory, read only memory, flash memory devices) and machine communication media (e.g., electrical, optical, acoustical or other form of propagated signals-such as carrier waves, infrared signals, digital signals, etc.) (both internally and over a network to other electronic devices). Additionally, such electronic devices typically include a collection of one or more processors coupled to one or more other components, such as a storage device, one or more user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and a network connection. The coupling of the set of processors to other components is typically through one or more buses and bridges (also referred to as bus controllers). The storage devices and the signals carrying the network traffic represent one or more machine-readable media and machine-communication media, respectively. Thus, the storage device of a given electronic device typically stores code and/or data for execution on a set of one or more processors of the electronic device. Of course, one or more portions of embodiments of the invention may be implemented using different combinations of software, firmware, and/or hardware.

As used herein, a network element (e.g., a router, switch, bridge, etc.) is a piece of networking equipment, including hardware and software that communicatively interconnects other equipment on the network (e.g., other network elements, computer end stations, etc.). Some network elements are multi-service network elements that provide support for multiple networking functions (e.g., routing, bridging, switching, layer 2 aggregation, and subscriber management, or any combination and/or support for multiple services (e.g., data, voice, and video)). Subscriber computer end stations (e.g., workstations, laptops, palmtops, mobile phones, smart phones, multimedia phones, portable media players, etc.) access content/services provided over the internet and/or content/services provided over a Virtual Private Network (VPN) overlaid on the internet. Content and/or services are typically provided by one or more server computing end stations belonging to a service or content provider and may include public web pages (free content, store front (store front), search services, etc.), private web pages (e.g., username/password accessed web pages providing email services, etc.), enterprise networks over VPNs, and so forth. Typically, a subscriber computing end station is coupled (e.g., by customer premise equipment coupled to an access network (wired or wireless)) to an edge network element, which is coupled to a server computing end station by one or more core network elements.

Some network elements support the configuration of multiple contexts. As used herein, each context includes one or more instances of a virtual network element (e.g., a virtual router, a virtual switch, or a virtual bridge). Each context typically shares one or more computing resources (e.g., memory, processing cycles, etc.) with other contexts configured on the network element, but can still be managed independently. For example, where multiple virtual routers are used, each virtual router shares computing resources, but is separate from those other virtual routers with respect to its administrative domain, authentication, authorization, and accounting (AAA) namespace, IP address, and routing database.

A method and apparatus for reducing the number of CC messages transmitted in an ethernet service network is now described. In one embodiment of the invention, a first ethernet service provider network element (e.g., Provider Edge (PE) network element, Provider Backbone Edge Bridge (PBEB)) receives CC messages for a first endpoint of a service instance at a first periodicity. The first ethernet service provider network element caches the received CC messages and adds a replication count to the CC messages to be transmitted across the ethernet service provider link (e.g., MAN or WAN link) to the second ethernet service provider network element. The first ethernet provider network element transmits the modified CC message to the second ethernet service provider network element at a second periodicity that is less than the first periodicity. The second ethernet provider network element buffers the modified CC message, generates a repetition count number for the CC message and transmits it to the second endpoint of the service instance at the first periodicity rate.

In another embodiment of the invention, upon determining that a CC message has not been received from the first endpoint, the first ethernet service provider network element triggers the second ethernet service provider network element to stop transmitting CC messages to the second endpoint.

Fig. 1 illustrates an exemplary network with a reduced periodic transmission rate of CC messages in an ethernet service network according to one embodiment of the present invention. Fig. 1 will be described with reference to the exemplary operation of fig. 4. However, it should be understood that FIG. 1 can be performed by embodiments of the present invention that differ from those discussed with reference to FIG. 4, and that the embodiments discussed with reference to FIG. 4 can perform operations that differ from those described with reference to FIG. 1.

Fig. 1 shows an exemplary VPLS (virtual private LAN service) network with two ethernet service instances, service instance 125 and service instance 135. Although fig. 1 illustrates an exemplary VPLS network, it should be understood that other networks are within the scope of the invention (e.g., networks including Provider Backbone Bridges (PBBs)). VPLS provides a framework for provisioning layer 2 virtual private networks (L2 VPNs). For example, in a VPLS network, the Local Area Network (LAN) at each site extends to the edge of the provider network. A provider network emulation switch (or bridge) connects customer LANs to create a single bridged LAN. For example, Customer Edge (CE) network element 110 and CE network element 130 connect through a provider network (e.g., Provider Edge (PE) network element 150 and PE network element 160) to create a single service instance 125. Similarly, CE network element 120 and CE network element 140 connect over a provider network to create a single service instance 135.

Customer Edge (CE) network element 110 is coupled to Provider Edge (PE) network element 150 via attachment circuit 179. Although not shown for purposes of simplicity, CE network element 110 may be coupled with PE network element 150 through one or more access network elements. CE network element 110 is coupled with a bridge module of PE network element 150. PE network element 150 connects the bridge module to the emulated LAN for CE network element 110. For example, the service instance 125 is an emulated LAN between the CE network element 110 and the CE network element 130. The CE network element 130 is coupled with the PE network element 160 through an attachment circuit 174. Although not shown in fig. 1 for purposes of simplicity, one or more subscriber computing end stations are coupled with CE network element 110 and CE network element 130. Additionally, CE network elements 110 and 130 may be geographically separated but belong to the same organization (e.g., CE network elements 110 and 130 are in branch offices of the same company, respectively). For example, CE network element 110 may be located in a branch office in san francisco, while CE network element 130 may be located in a branch office in new york city.

Similarly, CE network element 110 is coupled with the bridge module of PE network element 150 (through zero or more access network elements) through attachment circuit 172. PE network element 150 connects the bridge module to the emulated LAN for CE network element 120. For example, service instance 135 is an emulated LAN between CE network element 120 and CE network element 140. CE network element 140 is coupled to PE network element 160 through attachment circuit 176. Although not shown in fig. 1 for purposes of simplicity, one or more subscriber computing end stations are coupled with CE network element 120 and CE network element 140.

PE network element 150 is coupled to PE network element 160 via transport network connection 180. PE network elements 150 and 160 are each of a type belonging to an ethernet service provider network element. In addition, CE network elements 110, 120, 130, and 140 are each of a type that belongs to an ethernet customer network element. According to one embodiment of the invention, the ethernet service provider network element is under the control of an ethernet service provider and the ethernet customer network element is under the control of a customer of the service provider.

In one embodiment of the present invention, transport network connection 180 may include one or more intra-ethernet service provider network links, such as MAN links and/or WAN links. Additionally, transport network connection 180 may include one or more links designed for service instance 125 and one or more links designed for service instance 135. According to one embodiment of the invention, transport network connection 180 is more expensive than attachment circuit 170, attachment circuit 172, attachment circuit 174, or attachment circuit 176. The CE network element 110 transmits and receives network traffic and CC messages through the attachment circuit 170. Similarly, CE network element 130 transmits and receives network traffic and CC messages through attachment circuit 174.

Maintenance Endpoints (MEPs) 112 associated with the service instances 125 are configured on the CE network element 110. Similarly, MEPs 132, which are also associated with service instances 125, are configured on CE network elements 130. Thus, MEP 112 and MEP 132 are part of the same service instance 125. CE network element 110 transmits CC messages to PE network element 150 for MEPs 112 at a periodic rate of R1 (e.g., one MEP message every 3 milliseconds). In one embodiment of the invention, the transmitted CC message is a Connection Check Message (CCM) compliant with IEEE Standard 802.1ag (hereinafter "802.1 ag"). Each CC message includes a transmission interval rate, hereinafter referred to as a periodic rate. In fig. 1, the periodicity rate between CE network element 110 and PE network element 150 is R1 (e.g., one CC message is transmitted every 3.3 milliseconds) (thus, PE network element 150 expects CC messages from CE network elements at this rate R1).

MEPs 122 associated with service instances 135 are configured on CE network element 120. Similarly, MEPs 142 associated with service instances 135 are configured on CE network element 140. Thus, MEP 122 and MEP 142 are part of the same service instance 135. CE network element 120 transmits CC messages to PE network element 150 at a periodic rate of R2 for MEP 122 (e.g., one CC message every 10 milliseconds).

PE network element 150 includes an ingress service delimitation module 190 and a transport module 191. According to one embodiment of the invention, the ingress service delineation module 190 reduces the transmission rate of CC messages sent over the transport network connection 180. For example, PE network element 150 transmits CC messages associated with MEP 112 (of CE network element 110) and MEP 122 (of CE network element 120) at a periodic rate of (R1 + R2)/RC (where RC is a repetition count, which will be described in more detail later herein). Thus, PE network element 150 transmits CC messages over transport network connection 180 at a cycle rate that is less than the cycle rate at which PE network element 150 receives CC messages. In addition, as will be described in greater detail later herein, PE network element 160 transmits CC messages to the endpoints of the service instance (e.g., MEPs 132 of CE network element 130) at the same periodic rate at which CE network element 110 transmits CC messages to PE network element 150. Thus, even though the number of CC messages transmitted over the transport network is reduced, the nodes in the service instance that monitor the MEPs do not notice the reduction because CC messages continue to be transmitted and received at the endpoints (e.g., MEPs 112 and MEPs 132) at the expected periodic rate.

Fig. 3A is an exploded view of PE network element 150 according to one embodiment of the invention. The PE network element 150 includes an ingress service delimitation module 190 coupled with a transport module 191. The portal service definition module 190 includes a CCM module 310 and a memory 312. Memory 312 stores a CCM data structure 314, a CCM reception counter 316, and a CCM timeout timer 318. Fig. 3A will be described with reference to the exemplary operation of fig. 4. However, it should be understood that fig. 3A can perform operations with embodiments of the invention that are different from those discussed with reference to fig. 4, and that the embodiments discussed with reference to fig. 4 can perform operations different from those described with reference to fig. 3A.

Fig. 4 is a flow diagram illustrating an exemplary method for reducing the periodic transmission rate of CC messages in accordance with one embodiment of the present invention. At block 410, ingress service delineation module 190 of PE network element 150 receives the CC message. For example, the ingress service delimitation module 190 receives a CC message from a CE network element 110 or a CE network element 120. For purposes of illustration, it will be assumed for further discussion of fig. 4 that ingress service delimitation module 190 receives CC messages from CE network elements 110 associated with MEPs 112. Referring to fig. 3A, the CC module 310 receives CC messages from MEPs 112 of CE network elements 110. According to one embodiment of the invention, the CC messages include a periodic rate of R1 (thus, CC messages are expected to be received from CE network element 110 at a rate of R1). It should be understood that the received CC message may optionally include a sequence number.

From block 410, flow moves to block 412 where the entry service delimitation module 190 buffers the CC message. For example, referring to fig. 3A, CCM module 310 buffers the CC messages in CCM data structure 314. Any number of mechanisms may be used to manage CCM data structure 314, including caching only a certain number of messages per MEP (e.g., per MEPID). In one embodiment of the invention, CCM data structure 314 stores one or more CC messages associated with a single MEP. According to one embodiment of the invention, the CCM data structure 314 is a CCM database as defined by the 802.1ag standard. From block 412, flow passes to block 414.

At block 414, ingress service delineation module 190 decrements the CCM reception counter associated with MEP 112. For example, referring to fig. 3A, CCM module 310 decrements CCM reception counter 316 associated with MEP 112. Thus, according to one embodiment of the present invention, each MEP that transmits CC messages to PE network element 150 has a separate CCM reception counter. According to one embodiment of the invention, CCM reception counter 316 is a value associated with a Repetition Count (RC) used to reduce the number of CC messages transmitted over the transport network. For example, according to one embodiment of the invention, CCM reception counter 316 is equal to the repetition count minus X (where RC > X > = 1). According to one embodiment of the invention, the CCM reception counter indicates the number of CC messages that a PE network element (e.g., ingress service delineation module 190 on PE network element 150) receives from a particular MEP (e.g., MEP 112 on CE network element 110) before transmitting the CC messages for that MEP over the transport network (e.g., before transmitting the CC messages for MEP 112 over transport network connection 180 to PE network element 160).

According to one embodiment of the invention, the repetition count is a value indicating the number of CC messages that the oral service delimiting module 192 should transmit to the CE network element before receiving another CC message from the PE network element, as will be described in more detail later herein. While the repeat count is configured (e.g., by a network administrator) in one embodiment of the invention, in an alternative embodiment of the invention, the repeat count is automatically specified based on the status of network resources (e.g., based on the load of the transport network).

From block 414, flow passes to block 416. At block 416, ingress service delineation module 190 adds an explicit failure notification (EDN) field (set to 0), a Repetition Count (RC), and a transaction ID (e.g., MAC address of PE network element 150) to the CC message. In one embodiment of the invention, the CCM data structure 314 is extended to support the EDN field, the RC field, and the transaction ID field. Each of these fields is used by the egress service delimitation module 192, which will be described in more detail later herein. From block 416, flow passes to block 418.

At block 418, the ingress service delineation module 190 determines whether the EDN field of the previous CC message sent to the PE network element 160 for the associated MEP (e.g., MEP 12) is set (e.g., to 1) (the last CC message sent to the PE network element 160 for MEP 112). If the received CC message is the first CC message received from a CE network element 110 associated with MEP 112 (e.g., CCM data structure 314 does not include any entries for MEP 112) or the previous CC message sent to PE network element 160 is unset (e.g., set to 0), flow passes to block 422. If the previous CC message sent to PE network element 160 is set for the MEP (e.g., to 1), flow passes to block 420. Referring to fig. 3A, in one embodiment of the invention, the CCM module 310 determines from the CCM data structure 314 whether the previous CC message includes an EDN field of 1. As will be described in more detail later herein, the CCM module 310 sets the EDN field to 1 when it detects a CCM reception timeout (e.g., if the CCM module 310 does not receive any CC messages from the MEPs 112 with the periodicity rate, the CCM module 310 sets the EDN field to 1). Additionally, if the ingress service demarcation module 190 determines that the MEP 112 failed and/or that the connection between the PE network element 150 and the CE network element 120 failed, the CCM module 310 sets the EDN field to 1. For example, if a port coupling the PE network element 150 and the CE network element 120 fails and the MEP 112 is associated with the port, the CCM module 310 sets the EDN field to 1.

At block 420, the CC message with the EDN field cleared (e.g., the EDN field is 0) is transmitted over the transport network (e.g., over transport network connection 180). For example, referring to fig. 3A, the CCM module 310 generates a CC message from the information in the CCM data structure 314 (e.g., from the CC message buffered in block 412 and the field added to the message in block 416) and passes the generated CC message to the transmission module 191. According to one embodiment of the invention, the last CCM module 310 generates CC messages from the last CC messages received and buffered in the CCM data structure 314. The transmission module 191 adds any required encapsulation (e.g., layer 2 encapsulation, tunnel encapsulation, etc.) for transmitting the network, performs any additional processing, and transmits the generated CC message (EDN of 0) to the PE network element 160. In addition, it should be understood that if the buffered CC message used to generate the transmitted CC message includes a sequence number, the transmitted CC message includes the sequence number. Flow passes from block 420 to block 430 where the CCM timeout timer is reset to its initial value (e.g., a periodicity value included in the received CC message).

At block 422, the ingress service delineation module 190 determines whether the CCM reception counter is zero. For example, referring to fig. 3A, CCM module 310 determines whether CCM reception counter 315 is 0 for MEP 112. If the CCM reception counter is zero, flow passes to block 424 where the CC message is transmitted over the transport network with additional fields (e.g., added in block 416). For example, referring to fig. 3A, if CCM module 310 determines that CCM reception counter 315 is 0 for MEP 112, CCM module 310 generates a CC message from the information in CCM data structure 314 (e.g., from the CC message cached in block 412 and the field added to the message in block 416) and sends it to transmission module 191. According to one embodiment of the invention, the last CCM module 310 receives and buffers the last CC message from the CCM data structure 314 to generate a CC message. In addition, it should be understood that if the buffered CC message used to generate the transmitted CC message includes a sequence number, the transmitted CC message includes the sequence number. The transport module 191 adds any required encapsulation for the transport network (e.g., layer 2 encapsulation, tunnel encapsulation, etc.). For example, in a VPLS network, transport module 191 may map the generated CC messages to a particular pseudowire (pseudowire) and a particular egress port of PE network element 150. It should be understood that different embodiments of the present invention may use different types of transmission modules 191, and that the transmission modules 191 may perform operations in different ways in some embodiments of the present invention. Thus, embodiments of the present invention are independent of the type and function of the transport network.

If the CCM reception counter is not zero (e.g., it is greater than 0), flow passes to block 426 where no CC messages are transmitted. It should be understood that in some embodiments of the present invention, PE network element 150 may continue to receive CC messages from a particular MEP (e.g., MEP 112), but it does not transmit CC messages associated with that MEP over the transport network until CCM reception counter 316 is 0. Accordingly, it should be appreciated that the number of CC messages transmitted by PE network element 150 over the transport network, e.g., over the intra-ethernet service provider network links (MAN and/or WAN links), is reduced. For example, PE network element 150 receives CC messages from MEPs 112 at a higher periodicity rate (e.g., R1) than the periodicity rate of CC messages it transmits over transport network connection 180 (e.g., R1/RC). Thus, the number of CC messages transmitted over the attachment circuit 170 for a particular endpoint of a service instance is greater than the number of CC messages transmitted over the transport network connection 180 for that endpoint of the service instance. It will therefore be appreciated that bandwidth of the transport network is saved. Additionally, it should be appreciated that as the number of service instances increases (and thus the number of CC messages received by PE network element 150 increases), the amount of bandwidth savings also increases. Thus, the scalability of the addition of service instances employing CCM mechanisms is improved (e.g., the number of service instances may be increased without a corresponding increase in CC message load on the provider network).

From block 424, flow passes to block 428, where the CCM receive counter is reset to its initial value, and flow passes to block 430. At block 430, the CCM timeout timer is reset to its initial value (e.g., a periodicity value included in the received CC message).

It should be understood that PE network element 150 performs similar operations as described in fig. 4 for CC messages received from MEPs 122 of CE network elements 120 of service instances 135. For example, PE network element 150 receives CC messages from MEPs 122 at a higher periodicity rate (e.g., R2) than the periodicity rate of CC messages it transmits over transport network connection 180 (e.g., R2/RC). Thus, according to one embodiment of the present invention, PE network element 150 transmits CC messages for MEPs 112 and MEPs 122 over transport network connection 180 at a periodic rate of (R1 + R2)/RC.

Fig. 2 illustrates an exemplary VPLS network with reduced periodic transmission rate of CC messages in a transport network connection, where the CE network elements are dual homed, according to one embodiment of the invention. Fig. 2 will be described with reference to the exemplary operation of fig. 5. However, it should be understood that fig. 2 is capable of performing operations with embodiments of the present invention that differ from those discussed with reference to fig. 5, and that the embodiments discussed with reference to fig. 5 are capable of performing operations that differ from those described with reference to fig. 2.

Fig. 2 includes CE network element 110 (and MEP 112) shown in fig. 1. In addition, CE network element 110 is coupled with PE network element 150 via attachment circuit 170, and PE network element 150 is coupled with PE network element 160 via transport network connection 180. In addition, CE network element 110 is dual-homed to PE network element 250. For example, if attachment circuit 170 fails for some reason (e.g., incorrectly configured spanning tree protocols operating on a PE network element incorrectly block the port coupling attachment circuit 170, the physical link carrying attachment circuit 170 fails, etc.), CE network element 110 switches to attachment circuit 210 to transmit data and CC messages to PE network element 150. In this manner, CE network element 110 has access to the VPLS network and has access to CE network element 130 even though attachment circuit 170 is disabled. The PE network element 250 includes an ingress service delimitation module 290 and a transport module 291 that operate in a similar manner as the ingress service delimitation module 190 and the transport module 191. PE network element 250 is coupled to PE network element 160 via transport network connection 220.

In fig. 2, the attachment circuit 170 has failed (as indicated by the large "X" on the attachment circuit 170), and the CE network element 110 has switched to its second (e.g., backup) attachment circuit 210 to transmit and receive CC messages. Thus, PE network element 150 does not receive CC messages from MEPs 112 through attachment circuit 170. It should be understood that while PE network element 150 may detect a CC message timeout fairly quickly (e.g., after not receiving a CC message at the time when period rate R1 expires), PE network element 160 does not detect a CC message timeout at the same time. For example, PE network element 160 expects to receive CC messages at a reduced periodicity rate (e.g., R1/RC). Thus, in one embodiment of the invention, upon detecting a CC message timeout for a particular MEP, the ingress service delimitation module generates a CC message with an EDN field value of 1 for that MEP and passes this message to the egress service delimitation module. The CC message with the EDN field set to a value of 1 informs the egress service delimitation module that the CC message is timed out and triggers the egress service delimitation module to stop transmitting CC messages for the MEP.

Fig. 5 is a flow diagram illustrating an exemplary method for determining CC message timeouts and triggering explicit service instance failure CC messages in accordance with one embodiment of the present invention. PE network element 150 determines that the CC message has timed out at block 510. For example, PE network element 150 has not received CC messages from MEPs 112 at an expected periodic rate (e.g., rate R1). For example, referring to fig. 3A, the CCM module 310 determines that the CCM timeout timer 318 has expired. From block 510, flow passes to block 520.

At block 520, PE network element 150 reads previously cached CC messages associated with the timed-out MEP (e.g., MEP 112). For example, referring to fig. 3A, CCM module 310 reads an entry of CCM data structure 314 to obtain a previously cached CC message for MEP 112. From block 520, flow passes to block 530 where one or more fields are added to the message. For example, the EDN field is added to the message and set to a value of 1. In addition, a transaction ID field is added to the message and populated with a unique identifier of PE network element 150 (e.g., a MAC address of PE network element 150). Flow passes to block 540 where the CC message with additional fields is transmitted to PE network element 160. For example, referring to fig. 3A, the CCM module 310 generates a CC message with the EDN field set to 1 and the transaction ID field uniquely identifying the PE network element 150 and passes this message to the transport module 191 for transmission to the PE network element 160.

Referring again to fig. 2, because CE network element 110 is dual-homed (e.g., CE network element 110 is coupled with backup PE network element 250 in the event of failure of attachment circuit 170 and/or PE network element 150), MEP 112 transmits CC messages to PE network element 250 through attachment circuit 210. According to one embodiment of the invention, the ingress service delimitation module 290 and the transport module 291 of the PE network element 250 perform in a similar manner as the ingress service delimitation module 190 and the transport module 191 of the PE network element 150. For example, PE network element 250 transmits CC messages to PE network element 160 via transport network connection 220 at a reduced rate (e.g., at a rate of R1/RC, where RC is a rate count value). In addition, each CC message transmitted by PE network element 250 to PE network element 160 includes a transaction ID (e.g., a MAC address of PE network element 250) that uniquely identifies the source of the CC message.

Thus, as shown in fig. 2, PE network element 160 receives a CC message for MEP 112 from PE network element 150 that includes an EDN field of 1. According to one embodiment of the invention, this CC message triggers PE network element 160 to stop transmitting CC messages associated with PE network element 150 to CE network element 130. In addition, PE network element 160 also receives a CC message (which does not include the EDN field of 1) for MEP 112 from PE network element 250. According to one embodiment of the invention, the PE network elements 160 process CC messages received from different ethernet service provider network elements separately (e.g., as identified from a transaction identifier). For example, explicit MEP failure notification messages sent by PE network element 150 for MEP 112 do not affect CC messages sent by PE network element 250 for MEP 112. In other words, even if PE network element 160 receives a message that triggers PE network element 160 to stop transmitting CC messages from PE network element 150 for a particular MEP, this MEP failure message applies only to those CC messages and not to CC messages received from PE network element 250 for that MEP.

Fig. 6A and 6B are flow diagrams illustrating exemplary methods for processing the CC messages received at a reduced periodic transmission rate of fig. 4 and processing the explicit service instance failure CC messages of fig. 5 according to one embodiment of the invention. For example, in one embodiment of the invention, the operations of fig. 6A and 6B may be performed by PE network element 160. At operation 610, the egress service delimitation module (e.g., the egress service delimitation module 192) receives a CC message associated with a particular MEP. According to one embodiment of the invention, the received CC message includes the EDN field, the repetition count field, and the transaction identifier field or any combination of the EDN field, the repetition count field, and the transaction identifier field. Additionally, in some embodiments of the present invention, received CC messages are transmitted at a reduced periodic transmission rate (i.e., received CC messages are not transmitted at the original periodic transmission rate included in the CC messages). From block 610, flow passes to block 612.

Fig. 3B is a block diagram illustrating an exemplary ethernet service provider network element receiving the reduced periodic transmission rate and transmitting CC messages at the original periodic transmission rate of the CC messages of fig. 3A, according to one embodiment of the present invention. The PE network element of fig. 3B includes an egress service delineation module 192 coupled to a transport module 193. The egress service definition module 192 includes a CCM module 370 coupled to the memory 352. Memory 352 stores a CCM data structure 364, a CCM transmission timer 366, and a CCM timeout timer 368. According to one embodiment of the invention, the CCM transmission timer 366 indicates the amount of time between transmissions of CC messages to the CE network element. For example, CCM transmission timer 366 may be equal to the periodicity rate included in the CC message (thus, for example, if the periodicity rate is R1, CCM transmission timer 366 may expire at time R1). According to one embodiment of the invention, CCM timeout timer 368 indicates an amount of time before egress service delineation module 192 determines a CC message timeout (e.g., a time at which a CC message timeout is declared for CC messages sent by PE network element 150).

At block 612, the egress service delimiting module buffers the received CC message. For example, referring to fig. 3B, egress service delineation module 192 caches CC messages (e.g., with added fields) received from PE network element 150 into CCM data structure 364. Flow then passes to block 614 where the egress service delimitation module determines whether the EDN field of the received CC message is set (e.g., whether the EDN field has a value of 1). If the EDN field has a value of 1, flow passes to block 616 where the egress service definition module 192 stops the CCM transport timer (e.g., the CCM module 370 stops the CCM transport timer 366) and no CC messages are transported for the transaction associated with the CC message. Thus, for example, referring to fig. 2, upon receiving a CC message for MEP 112 from PE network element 150 and including an EDN field with a value of 1 and a transaction identifier that uniquely identifies PE network element 150, PE network element 160 does not transmit any CC messages from PE network element 150 to CE network element 130 for MEP 112.

If the EDN field is not set (e.g., the EDN field has a value of 0), then flow passes to block 618. At block 618, in one embodiment of the invention, the repetition counter is set to the repetition count value in the CC message. In an alternative embodiment of the present invention, the repetition count field of the buffered CC messages (e.g., buffered during the operation of block 612) is used as a repetition counter. From block 618, flow passes to block 620.

At block 620, the CCM transmission timer is configured according to the periodicity included in the CC message. For example, referring to fig. 3B, CCM module 370 configures CCM transmission timer 366 according to the periodicity (e.g., R1) included in the CC message. Flow passes to block 622. At block 622, a determination is made whether the CCM transmission timer has expired. For example, referring to fig. 3B, the CCM module 370 determines whether the CCM transmission timer 366 has expired. If the CCM transmission timer has expired, flow passes to block 624. If the CCM transmission timer has not expired, flow returns to block 622.

At block 624, a determination is made whether the buffered CCM message includes a sequence number. For example, referring to fig. 3B, CCM module 370 accesses CCM data structure 364 to determine whether a newly buffered CC message associated with the MEP includes a sequence number. If the buffered CC message includes a sequence number, flow passes to block 626. If, however, the buffered CC message does not include a sequence number, flow passes to block 628. At block 626, the sequence number is incremented and the cached message is updated to reflect the incremented sequence number. From block 626, flow passes to block 628.

At block 628, a CC message is created from the cache with the additional fields (e.g., EDN field, repetition count field, and transaction identifier field) removed from the message. If the cached message includes a sequence number, the created CC message includes the sequence number. From block 628, flow passes to block 630 where the created CC message is transmitted. For example, referring to fig. 3B, the CCM module 370 accesses the CCM data structure 364 and generates a CC message without additional fields, and then passes the generated CC message to the transmission module 193. The transmission module 193 adds any required encapsulation for the attachment circuit (e.g., the attachment circuit 174), performs any additional processing, and transmits the generated CC message to the CE network element 130. From block 630, flow passes to block 632.

At block 632, the repetition counter is decremented. For example, in one embodiment of the invention, CCM module 370 decrements the value of the repetition count field by 1 as each CC message is transmitted. Flow passes to block 634 where it is determined whether the repetition counter is greater than 0. For example, the CCM module 370 determines whether the repetition counter is greater than 0. If the repetition counter is not greater than 0, flow passes to block 636 where alternative actions are taken (e.g., PE network element 160 may determine that the CC message times out, PE network element 160 may readjust the repetition counter, etc.). If the repetition counter is greater than 0, flow returns to block 622. Thus, for example, for a certain number of repetition counts (as shown in the repetition count field of a received CC message), PE network element 160 transmits the CC message to MEP 132 (for service instance 125) at the original cycle rate (e.g., rate R1). It should be noted that at any time during the operations of block 622-. In other words, a CC message associated with a particular MEP and with an EDN field of 1 associated with a particular ingress service delimitation module triggers the egress service delimitation module to stop transmitting CC messages for that MEP and the ingress service delimitation module.

Although embodiments of the present invention are described with respect to VPLS networks, in alternative embodiments of the present invention, different networks (e.g., standard ethernet networks, provider backbones, etc.) may be used. Additionally, while embodiments of the present invention describe reducing the periodicity of CC messages transmitted over an ethernet service provider network, in alternative embodiments of the present invention, the periodicity of CC messages may be reduced in an ethernet customer network (e.g., within a LAN). Additionally, while embodiments of the present invention have been described in terms of reducing the transmission rate of CC messages (e.g., 802.1ag CC messages), embodiments of the present invention described herein may also be used to reduce the transmission rate of different types of messages (e.g., other keep-alive messages, control messages, operation, administration and maintenance (OAM) messages, etc.).

It should be understood that CE network elements 130 and 140 transmit CC messages to MEPs 112 and 122 via MEPs 132 and 142, respectively. In addition, PE network element 160 supports an ingress service delimitation module and PE network element 150 supports an egress service delimitation module.

Additionally, in one embodiment of the present invention, PE network element 150 and PE network element 160 agree to support a reduced periodicity rate and add fields to CC messages. For example, in some embodiments of the invention, these capabilities are signaled (e.g., by Label Distribution Protocol (LDP), GMPLS, etc.). In other embodiments of the present invention, a network administrator supporting PE network elements 150 and 160 configures each PE network element to support a reduced periodicity rate and add fields to CC messages.

While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, and can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims (13)

1. A method for reducing the number of connection check, CC, messages transmitted in a provider network, wherein a first customer network element is coupled with a first service provider network element in the provider network, wherein the first service provider network element is coupled with a second service provider network element, and the second service provider network element is coupled with a second customer network element, the method comprising:

receiving, at the first service provider network element, a first plurality of CC messages from the first customer network element at a first periodicity, wherein the first plurality of CC messages are destined for the second customer network element and are associated with the first customer network element; and

transmitting a set of one or more second CC messages to the second service provider network element over the provider network at a second periodicity rate, wherein the second periodicity rate is less than the first periodicity rate, wherein the set of second CC messages are each associated with the first customer network element, and wherein each message of the set of second CC messages comprises a repetition count value indicating a number of CC messages associated with the first customer network element that the second service provider network element is to transmit to the second customer network element at the first periodicity rate.

2. The method of claim 1, further comprising:

storing the received plurality of first CC messages in a connection check message, CCM, data structure on the first service provider network element;

detecting that the first customer network element has not transmitted a CC message destined for the second customer network element for the time of the first periodicity;

obtaining a stored version of a CC message previously received from the first customer network element destined for the second customer network element;

adding an explicit failure notification field to the stored CC messages and setting the explicit failure notification field to indicate that the first service provider network element has stopped receiving CC messages from the first customer network element;

adding a transaction identifier field to the stored CC message and setting the transaction identifier field with a value that uniquely identifies the first service provider network element;

generating an explicit failure CC message from the stored CC message and the set explicit failure notification field; and

transmitting the explicit failure CC message to the second service provider network element through the provider network.

3. The method of claim 1, wherein the first customer network element is coupled with a third service provider network element in case of failure of an attachment circuit coupling the first customer network element with the first service provider network element and/or the first service provider network element, wherein the third service provider network element is coupled with the second service provider network element, the method further comprising:

receiving, at the third service provider network element, a plurality of third CC messages from the first customer network element at the first periodicity, wherein the plurality of third CC messages are destined for the second customer network element and are associated with the first customer network element;

storing the received CC message in a connection check message, CCM, data structure on the third service provider network element;

adding a repetition count field to a CC message stored in a CCM data structure on the third service provider network element;

adding a transaction identifier field to a CC message stored in said CCM data structure on said third service provider network element and setting said transaction identifier field with a value uniquely identifying said third service provider network element;

reducing the first periodicity to create a third periodicity, wherein the third periodicity is less than the first periodicity;

transmitting a set of one or more fourth CC messages to the second service provider network element through the provider network at the third cycle rate, wherein each transmitted CC message comprises the transaction identifier uniquely identifying the third service provider network element and a repetition count value in the repetition count field, the repetition count value indicating a number of CC messages that the third service provider network element is to transmit to the second customer network element at the first cycle rate.

4. A service provider network element for reducing the number of connection check, CC, messages transmitted in a provider network, comprising:

the portal service definition module includes, in combination,

a connection check message CCM module performing the following operations:

receiving CC messages from a first customer network element destined for a second customer network element at a first periodicity rate, and storing those CC messages in a CCM data structure,

reducing the first periodicity to create a second periodicity, wherein the second periodicity is less than the first periodicity, an

Adding a repetition count value to a set of one or more received CC messages, the repetition count value indicating a number of CC messages associated with the first customer network element that different service provider network elements are to communicate to the second customer network element at the first periodicity, and

a memory coupled with the CCM module, the memory storing the CCM data structure; and

a transmission module coupled with the ingress service delimitation module, the transmission module to transmit the aggregated CC messages to the different service provider network elements at the second periodicity.

5. The service provider network element of claim 4, wherein the CCM module is further to determine whether a CC message has not been received from the first customer network element in a time that exceeds a CCM timeout timer, wherein the CCM module is further to add an explicit failure notification field to the aggregated CC message and set a value for the explicit failure notification field to indicate whether the CCM timeout timer has expired.

6. The service provider network element of claim 4, wherein the second periodicity rate is to be configured by a network administrator.

7. A service provider network element handling connection check, CC, messages, comprising:

an egress service definition module, comprising,

a connection check message CCM module that receives CC messages transmitted from another service provider network element associated with a first customer network element and destined for a second customer network element, and stores those CC messages in a CCM data structure, wherein each received CC message comprises a first periodicity and a repetition count value, wherein each received CC message is received at a second periodicity lower than the first periodicity, wherein the CCM module is further to create a certain number of CC messages from the CCM data structure according to the repetition count value and cause those created CC messages to be transmitted at the first periodicity, and

a memory coupled with the CCM module, the CCM module storing the CCM data structure; and

a transport module coupled with the egress service delimitation module, the transport module to transmit the created CC message to the second customer network element.

8. The service provider network element of claim 7, wherein the CCM module is further to stop transmitting the created CC message to the customer network element if it is determined that the CC message associated with the first customer network element received from the other service provider network element indicates that the other service provider network element has stopped receiving CC messages associated with the first customer network element destined for the second customer network element.

9. The service provider network element of claim 7, wherein the CCM module is further to differentiate between processing of CC messages received from different sources based on a transaction identifier included in each received CC message.

10. The service provider network element of claim 7, wherein the number of created CC messages is equal to the repetition count value.

11. A method in a first service provider network element, wherein the first service provider network element is coupled with a second service provider network element, wherein the second service provider network element is itself coupled with a first customer network element, and wherein the first service provider network element is coupled with a second customer network element, the method comprising:

receiving a first connection check, CC, message from the second service provider network element, the first CC message being associated with the first customer network element and destined for the second customer network element, the first CC message comprising a periodicity rate and a repetition count value; and

in response to receiving the first CC message, transmitting a plurality of CC messages associated with the first customer network element to the second customer network element at a periodic rate included in the first CC message, wherein a number of the plurality of CC messages transmitted to the second customer network element is based on a repetition count value included in the first CC message.

12. The method of claim 11, further comprising:

ceasing transmission of the plurality of CC messages to the second customer network element in response to receiving a second CC message from the second service provider network element indicating that the second service provider network element has ceased receiving CC messages from the first customer network element destined for the second customer network element.

13. The method of claim 11, further comprising:

wherein the first CC message received from the second service provider network element includes a transaction identifier identifying the second service provider network element;

receiving a second CC message from a third service provider network element, the second CC message associated with the first customer network element and destined for the second customer network element, the second CC message comprising a cycle rate, a repetition count value, and a transaction identifier identifying the third service provider network element;

in response to receiving the second CC message, transmitting a plurality of CC messages associated with the first customer network element to the second customer network element at a periodic rate included in the second CC message, wherein a number of the plurality of CCs transmitted to the second customer network element is based on a repetition count value included in the second CC message;

in response to receiving a third CC message from the second service provider network element indicating that the second service provider network has stopped receiving CC messages from the first customer network element destined for the second customer network element, wherein the third CC message includes a transaction identifier identifying the second service provider network element, ceasing to transmit CC messages to the second customer network element for the second service provider network element and continuing to transmit CC messages to the second customer network element for the third service provider network element.