Diagnostic tool and method for troubleshooting multicast connectivity flow problem(s) in a layer 2 aggregation network

A diagnostic tool and method are described herein that are capable of diagnosing and localizing a multicast connectivity flow fault within a layer 2 aggregation network. In one application, the diagnostic tool and method can be used by a customer service representative to diagnose why a customer cannot receive a television channel even though they can receive other television channels within an IPTV network.

TECHNICAL FIELD

The present invention relates to a diagnostic tool and a method for diagnosing and localizing a multicast connectivity flow fault within a layer2aggregation network.

BACKGROUND

The following abbreviations are herewith defined, at least some of which are referred to in the ensuing description of the prior art and the present invention.AN Access NodeCC Continuity CheckCO Central OfficeDSLAM Digital Subscriber Line Access MultiplexerFDB Forwarding DatabaseGDA Group Destination AddressIGMP Internet Group Management ProtocolIP Internet ProtocolIPTV Internet Protocol TelevisionIO Intermediate OfficeMAC Media Access ControlMEP Maintenance End PointMIP Maintenance Intermediate PointRGW Residential GatewaySAI Service Area InterfaceSHE Super HeadendSNMP Simple Network Management ProtocolSTB Set-Top BoxTV TelevisionTLV Type Length ValueVHO Video Hub OfficeVLAN Virtual Local Area NetworkVOD Video-On-Demand

A diagnostic tool is needed today that can be used to troubleshoot a multicast connectivity flow fault along a path between a given source (source MEP) and a given destination (destination MEP) within a layer2aggregation network. The multicast connectivity flow fault occurs when a member/user wants to be a part of a multicast group and has issued an IGMP Join from the destination MEP towards the source MEP requesting to join that multicast group but for whatever reason does not become part of that particular multicast group. This can happen if the IGMP Join was dropped or not updated properly by one of the intermediate nodes/bridges (MIPs) located between the source MEP and the destination MEP. For example, this may happen if: (1) the IGMP Join was dropped by an intermediate node due to an overflow; (2) the IGMP proxy function within an intermediate node did not work properly; (3) the forwarding database (FDB) within an intermediate node was not properly updated; or (4) the FDB overflowed within an intermediate node. In such a situation, the layer3multicast could still be functional even though there is a problem at layer2.

In one application, an IPTV network (which is a layer2aggregation network) can suffer from this problem when a customer does not receive a particular television channel (which is part of a particular multicast group) even though they switched to that particular television channel (issued an IGMP Join) and they can still receive and watch other television channels. In this case, the customer would call a customer service representative and the representative would have to pin-point the location of the multicast connectivity flow fault within the IPTV network. The customer service representative would do this by interacting with a console to log into a bridge (via a serial port, SNMP over IP, web server over IP) and retrieve the status of individual intermediate nodes. Plus, the customer service representative would have to manually inspect the status of each intermediate node one-by-one by browsing large databases (FDBs) to diagnose and correct the multicast connectivity flow fault. This process is very tedious and not very efficient. Accordingly, there is a need for a new diagnostic tool and a method which can be used to effectively and efficiently troubleshoot a multicast connectivity flow fault within a layer2aggregation network (IPTV network). This need and other needs are solved by the diagnostic tool and method of the present invention.

BRIEF DESCRIPTION OF THE INVENTION

The present invention includes a diagnostic tool and a method which are capable of diagnosing and localizing a multicast connectivity flow fault within a layer2aggregation network. In one embodiment, the diagnostic tool can troubleshoot the multicast connectivity flow fault within the layer2aggregation network by performing the following steps: (1) discovering a MAC address associated with a target device (or another device associated with the target device) (2) sending a request message which contains the discovered MAC address via one or more intermediate nodes directly towards the target device; (3) receiving one or more reply messages from the intermediate bridges and the target device; and (4) analyzing the one or more received reply messages to determine whether any of the intermediate node(s) or the target device had failed to update their forwarding database(s) because of the multicast connectivity flow/fault.

DETAILED DESCRIPTION OF THE DRAWINGS

Referring toFIGS. 1-4, there are several diagrams which are described herein to help explain how a diagnostic tool100and method200can be used to troubleshoot a multicast flow fault that occurred within a layer2aggregation network102in accordance with the present invention. InFIG. 1, there is shown a block diagram of an exemplary layer2aggregation network102which has a source MEP104that is connected to a first MIP106a(which includes ports1,2. . . n). The first MIP106ais connected to a second MIP106b(which includes ports1,2. . . n) which in turn is connected to a destination MEP108. The diagnostic tool100(which implements the method200) is shown connected to the source MEP104. For clarity, the layer2aggregation network102which has been shown herein has a relatively simple architecture however in practice it would likely have a far more complex architecture which would include a large number of interconnected MEPs and MIPs.

The diagnostic tool100is used to diagnose and localize a multicast connectivity flow fault111which occurred somewhere along a path within a given VLAN between the source MEP104and the destination MEP108(in this example the fault111occurred within MIP106a). The multicast connectivity flow fault111can occur when a member/user110(associated with destination MEP108) wants to be a part of a multicast group and has issued an IGMP Join114towards the source MEP104requesting to join that multicast group but for whatever reason does not become part of that particular multicast group. For instance, this may happen if the IGMP Join114was dropped or not updated properly by one of the MIPs106aor106blocated between the source MEP104and the destination MEP108. In particular, this may happen if: (1) the IGMP Join114was dropped by an intermediate node106aor106bdue to an overflow; (2) the IGMP proxy function within an MIP106aor106bdid not work properly; (3) a FDB112aor112bwithin MIP106aor106bwas not properly updated; or (4) the FDB112aor112boverflowed within MIP106aor106b.

To help illustrate an IGMP Join failure, assume the member/user110wanted to be part of a multicast group and issued an IGMP Join114from the destination MEP108which was received by MIP106b. The MIP106bwould then update the FDB112btherein to include a multicast identifier116(which identifies the desired multicast group) and a local port “p1” (the particular port which received the IGMP Join114). Then, MIP106awould receive the IGMP Join114and for whatever reason the corresponding FDB112atherein was not properly updated to show the multicast identifier116and a local port “p2” (the particular port which did or should have received the IGMP Join114). In this situation, there is an IGMP Join failure and MIP106awould not be able to forward the desired multicast traffic118(originated from the source MEP104) to the next MIP106b, the destination MEP106bor the user110. This is not desirable.

The diagnostic tool100can diagnose and localize this multicast flow fault111(and other types of multicast flow faults) by implementing the method200as discussed hereinafter with respect toFIGS. 2-4. Basically, a person120(customer service representative120) would interface with and use the diagnostic tool100to troubleshoot the multicast flow fault111. However, before the person120would be able to troubleshoot the multicast flow fault111, the user110needs to contact that person120and let them know they are experiencing a multicast flow fault (e.g., they are not receiving a particular television channel like CNN). The person120would then know the multicast identifier116(associated with the failed IMGP Join114) and would also be able to look-up a port ID (at the destination MEP108) which is associated with user110.

The person120would input the port ID into the diagnostic tool100(shown including an operator interface/computer122) which then performs a discovery process to: (1) learn a MAC address of the destination MEP108; and (2) learn the direct path through the MIPS106aand106bto the destination MEP108(see step202inFIG. 2). As shown inFIG. 3, the diagnostic tool100can perform this discovery process by having the source MEP104flood a MAC discover message124(which contains the user's port ID) through-out the entire layer2aggregation network102. In particular, the source MEP104sends the MAC discover message124towards MIP106awhich then forwards the MAC discover message124out-off every one of it's local ports1,2. . . n. Then, MIP106breceives and forwards the MAC discover message124out-off every one of its local ports1,2. . . n.

The destination MEP108is going to eventually receive the MAC discover message124and then it is going to send a MAC reply message126directly back towards the source MEP104via MIPs106aand106b. Once, the MIP106breceives the MAC reply message126it now knows which one of it's local ports1,2. . . n (e.g., port1) behind which resides the destination MEP108. Then, the MIP106bcreates an entry127bwhich includes [destination MEP's MAC address, local port] within the FDB112b(or another type of database). Likewise, when the MIP106areceives the MAC reply message126it now knows which one of it's local ports1,2. . . n (e.g., port2) behind which resides the destination MEP108. The MIP106aalso creates an entry127awhich includes [destination MEP's MAC address, local port] within the FDB112a(or another type of database). Lastly, the MIP106aforwards the MAC reply message126to the source MEP104. This discovery process is known in the art as Ethernet MAC learning.

As shown inFIG. 4, the diagnostic tool100after performing the discovery process instructs the source MEP104to send a request message128(e.g., based on 802.1ag LinkTrace standard—the contents of which are incorporated by reference herein) which contains the recently learned MAC address (of the destination MEP108) and the multicast identifier116/port ID directly towards the destination MEP108via the MIPs106aand106b(step204inFIG. 2). The first MIP106aupon receiving the request message128takes the recently learned MAC address located therein and then inspects element127ain the FDB112ato learn which port1,2. . . n (e.g., port2) it needs to use to forward another request message128′ to the next MIP106b. In addition, the first MIP106aupon receiving the request message128takes the multicast identifier116located therein along with the recently learned port (e.g., port2) and inspects the FDB112ato determine if there is an element which has a corresponding multicast identifier116stored therein that is associated with the recently learned port (e.g., port2). The FDB112awould have had this particular element with the multicast number116and the local port stored therein if there was a successful IGMP Join operation.

However, in this exemplary layer2aggregation network102, the MIP106awas where the multicast flow fault111occurred since the IGMP Join operation did not for whatever reason result in an updating of the FDB112awith the requested multicast number116and local port (e.g., port2) (seeFIG. 1). In this case, the first MIP106awould send a reply message130(e.g., based on the 802.1ag LinkTrace standard) back to the diagnostic tool100(step206inFIG. 2). The reply message130would have a parameter stored therein indicating that there was a multicast flow fault111at MIP106a. Then, the first MIP106asends a new request message128′ out of the recently learned local port (e.g., port2) directly to the second MIP106b.

Upon receiving the request message128′, the second MIP106bwould perform the same operations associated with steps204and206and send a reply message130′ (indicating in this example that the corresponding FDB112bhad the appropriate multicast identifier116and local port stored therein) back to the diagnostic tool100. Thereafter, the second MIP106bwould send another request message128″ out off the recently learned local port (e.g., port1) directly to the destination MEP108. The destination MEP108would perform the same operations associated with steps204and206and send a reply message130″ (indicating whether or not their corresponding FDB had the appropriate multicast identifier116and local port stored therein) back to the diagnostic tool100. The diagnostic tool100would analyze the reply messages130,130′ and130″ to diagnose and localize the multicast flow fault111(see step208inFIG. 2).

In one application, the diagnostic tool100and method200can be used to troubleshoot why a customer110′ cannot receive a particular television channel (or be part of a particular multicast group) even though they switched to that particular television channel (issued a IGMP Join114′) and they can still receive and watch other television channels which were broadcast by an IPTV network102′ (which is a layer2aggregation network102).FIG. 5is a block diagram that illustrates the architecture of an exemplary IPTV network102′ which is used to help explain how the diagnostic tool100and method200can be used to troubleshoot a multicast flow fault in accordance with the present invention.

As shown, the exemplary transport network102′ includes two super head-ends502, a backbone network504, multiple VHOs506, multiple IOs508, multiple COs510, multiple SAIs512and multiple RGWs514. In operation, each super head-end502receives international TV feeds and supplies those international TV feeds via the backbone network504to each VHO506. Then, each VHO506receives local TV feeds and multicasts all of the TV feeds to their respective IOs508(which has a router509). And, each IO508multicasts all of the TV feeds to their respective COs510(which has the diagnostic tool100attached to a bridge/router511) (note: the diagnostic tool100if desired could be connected to the router509located in the IO508). Then, each CO510multicasts all of the TV feeds to their respective SAIs512(which includes a DSLAM513). And, each SAI512then multicasts all of the TV feeds to their respective RGWs514(which are associated with STBs516). In this way, the users110′ can interface with their STB516and select one of the multicast TV channels to watch on their TV. The transport network102′ may also provide voice (telecommunications) and data (Internet) to the homes via the DSL phone lines.

If the IPTV network102′ has a multicast connectivity flow fault, then the customer110′ would not receive a particular television channel like CNN (which is part of the TV feed's multicast group) even though they switched to that particular television channel (issued an IGMP Join114′) and they can still receive and watch other television channels. In this example, the diagnostic tool100is shown attached to the bridge/router511′ which is located within the CO510′. Plus, the diagnostic tool100troubleshoots a multicast flow fault that occurred within either the bridge/router511′ (associated with the CO510′), the DSLAM513′ (associated with the SAI512′) or the RGW514′ (associated with the STB516′) which is used by customer110′. The multicast flow fault can occur when a FDB located within the bridge/router511′, the DSLAM513′ or the RGW514′ has not been properly populated during the IGMP Join operation. Each multicast FDB would be properly populated if it contained the MCAST Channel No. (which identifies the queried television channel) and the local port (behind which resides the RGW514′). In this embodiment, the MCAST Channel No. could be represented as an IP address, an Ethernet MAC address or a GDA.

When there is a multicast flow fault, the customer110′ would call a customer service representative120′ and then the representative120′ would have to interface with the diagnostic tool100to locate, diagnose and correct the particular multicast flow fault so the customer110′ can receive and watch that particular television channel. To accomplish this, the customer service representative120′ would ask the customer110′ what is the problematical TV channel (to obtain the MCAST Channel No.) and then they would look-up the port ID (at the target RGW514′) associated with the customer110′. Thereafter, the customer service representative120′ would instruct the diagnostic tool100to perform a discovery process to: (1) learn a MAC address of a line card520′ in the DSLAM513′ behind which resides the target ring514′ (note: the MAC address of the RGW514′ or the MAC address of a bridge522within the DSLAM513′ could also be learned so long as the MAC address learned is associated with the target RGW514′); and (2) learn the direct path through the bridge/router511′ and the DSLAM513′ to the target RGW514′ (see step202inFIG. 2).

In one embodiment, the diagnostic tool100can perform this discovery process as follows (see step202inFIG. 2):

1. The bridge/router511′ floods a MAC discover message124′ out of all of it's ports1,2. . . n (seeFIG. 5).

FIG. 6Ais a diagram that illustrates the format of an exemplary MAC discover message124′ (e.g., based on 802.1ag Connectivity Check—the contents of which are incorporated by reference herein) (note: some fields are not shown). The new portions associated with this MAC discover message124′ have been identified by BOLD letters to highlight the new portions when compared to the traditional 802.1ag Connectivity Check message. The new portions include: (1) an OpCode (instructions to look at an organization specific TLV602a); and (2) an organization specific TLV602a(which includes an AN_discover and a port ID of target RGW514′).

2. Each DSLAM513(three shown associated with CO510′) and in particular a bridge522located therein receives the MAC discover message124′ and broadcasts it to all of the line cards520located therein.

3. Each line card520(associated with the DSLAMs513connected to CO510′) upon receiving the MAC discover message124′ looks at this message to see if it has a port ID associated with the target RGW514′.

4. Only the line card520′ that is associated with the port ID of the target RGW514′ will respond to the MAC discover message124′ by sending a MAC reply message126′ which contains that particular line card's MAC address.

FIG. 6Bis a diagram that illustrates the format of an exemplary MAC reply message126′ (e.g., based on 802.1ag Connectivity Check) (note: some fields are not shown). The new portions associated with the MAC reply message126′ have been identified by BOLD letters to highlight the new portions when compared to the traditional 802.1ag Connectivity Check message. The new portion includes an organization specific TLV604a(which includes (a) an AN_discover; (b) a port ID of target RGW514′; and (c) the MAC address of the line card520′ behind which resides the the target RGW514′).

5. As a result of sending the MAC reply message126′, all of the intermediate nodes which in this example include the bridge522′ in DSLAM513′ and the bridge/router511′ learn the local port behind which resides the target RGW514′. Each of these intermediate nodes creates an entry in their FDB which has [DSLAM line card's MAC address, local port].

*Note 1: The discovery process would not be needed if the bridge/router511′, DSLAM513etc . . . knew the MAC address of the line card520′ and the local port behind which resides the target RGW514′.

Note 2: The frames associated with the exemplary MAC discover message124′ (FIG. 6A) and the exemplary MAC reply message126′ (FIG. 6B) happen to be based on a draft of the 802.1ag specification. As such, it should be appreciated that the locations of the various fields in these messages124′ and126′ could change and this change or other changes would not affect the scope of the present invention.

After the discovery process, the diagnostic tool100perform as follows (see steps204,206and208inFIG. 2):

1. The diagnostic tool100generates a request message128′ which is sent out the local port of the bridge/router511′. The request message128′ contains the recently learned MAC address (of the line card520′ in the DSLAM513′) and the multicast identifier116′/port ID associated with the target RGW514′.

FIG. 7Ais a diagram that illustrates the format of an exemplary request message128′ (e.g., based on 802.1ag LinkTrace standard—the contents of which are incorporated by reference herein) (note: some fields are not shown). The new portions associated with the request message128′ have been identified by BOLD letters to highlight the new portions when compared to the traditional 802.1ag LinkTrace message. The new portions include: (1) an OpCode (instructions to look at an organization specific TLV606a); and (2) the organization specific TLV606a(which includes a MLINK_request, a MCAST Channel # and the port ID of the target RGW514′.

2A. The DSLAM513′ and in particular the bridge522′ therein receives the request message128′ inspects the learned MAC address located therein and then inspects it's FDB to learn which local port1,2. . . n it needs to use to forward another request message128″ to the correct line card520′. For instance, the new request message128′ can be forwarded to the correct line card520′ in one of two ways: (1) the bridge522′ gets the port ID from the TLV606ain the received request message128′ and determines the local port out which the new request message128″ is to be forwarded to the correct line card520′ behind which resides the target RGW514′; or (2) this information may have been learnt in the discovery process (step202inFIG. 2).

2B. The DSLAM613′ and in particular the bridge522′ receives the request message128′ inspects the multicast identifier116/port ID located therein and then inspects it's FDB to determine if there is a corresponding multicast number stored therein that is associated with the local port which leads to the target RGW514′. The particular FDB would have the multicast number116and the local port stored therein if the IGMP Join operation was properly performed.If there is a corresponding multicast number/local port stored in the FDB, then the bridge522′ sends a reply message130′ which indicates the television channel is reachable back to the diagnostic tool100.If there is not a corresponding multicast number/local port stored in the FDB, then the bridge522′ sends a reply message130′ which indicates the television channel is not reachable back to the diagnostic tool100.

FIG. 7Bis a diagram that illustrates the format of an exemplary reply message130′ (e.g., based on 802.1ag LinkTrace standard) (note: some fields are not shown). The new portions associated with the reply message130′ have been identified by BOLD letters to highlight the new portions when compared to the traditional 802.1ag LinkTrace message. The new portions include an organization specific TLV608a(which includes a MLINK_reply, a MCAST Channel # and a Channel Status (whether the channel is reachable or not reachable).

3. The line card520′ receives and inspects the request message128″ and then sends a reply message130″ back to the diagnostic tool100. In addition, the line card520′ forwards a new request message128′″ to the target RGW514′.

4. The target RGW514′ receives and inspects the request message128′″ and then sends a reply message130′″ (back to the diagnostic tool100).

5. The diagnostic tool100analyzes the received reply messages130,130′ and130″ and diagnoses and localizes the multicast flow fault within the IPTV network102′. Then, the customer service representative120′ can correct the multicast flow fault at the bridge/router511′, the DSLAM513′ or the RGW514′ so the customer110′ can receive and watch the desired television channel (which is associated with MCAST Channel #).

Note 1: The frames associated with the exemplary request message128′ (FIG. 7A) and the exemplary reply message130′ (FIG. 7B) happen to be based on a draft of the 802.1ag specification. As such, it should be appreciated that the locations of the various fields in these messages128′ and130′ could change and this change or other changes would not affect the scope of the present invention.

Although one embodiment of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.