Patent Publication Number: US-2009225660-A1

Title: Communication device and operation management method

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2008-054240, filed on Mar. 5, 2008, the disclosure of which is incorporated herein in its entirety by reference. 
     The present invention generally relates to a communication device and an operation management method used in the communication device and particularly relates to an operation management method concerned with a multicast topology at Layer 2. 
     2. Description of the Related Art 
     Frame Relay, Asynchronous Transfer Mode (ATM), Internet Protocol Virtual Private Network (IP-VPN), arid others have been used as network technologies for providing data communications services. At present, full proliferation of Layer-2 Virtual Private Network (L2-VPN) services realized by Ethernet™ technologies, or wide-area Ethernet™ services, has begun with a trend to higher speed, lower equipment costs, and the like as a backdrop. 
     Moreover, standardization organizations such as Institute of Electrical and Electronics Engineers, Inc. (IEEE) and International Telecommunication Union Telecommunication Standardization Sector (ITU-T) have been proceeding the establishment of Operations, Administration and Maintenance (OAM) protocols, the application of which is expected to enhance the reliability of Layer-2 networks and to reduce operation costs. 
     For example, according Lo ITU-T Y.1731 (OAM functions arid mechanisms for Ethernet™ based networks) and IEEE 802.1ag (Connectivity Fault Management), Loop-back test makes it possible to check connectivity on an arbitrary segment within an Ethernet™ network, and Link Trace test makes it possible to retrieve a route for forwarding. 
     However, these OAM tools are premised on point-to-point uses or uses on those segments that are statically set in a broadcast domain, and are not assumed to be used on dynamically varying segments. 
     On the other hand, in a multicast network, to reduce the load on a delivery router, to use the bandwidth of a link more efficiently, and to ensure the confidentiality of data, dynamic formation of a topology varying with the delivery group is generally performed using a multicast routing protocol. 
     For example, a Layer-2 switch has a function of passing multicast data on only to one or more appropriate port, with a forwarding table dynamically constructed on a multicast-delivery-group basis by utilizing a snooping function, which is a function of looking into a packet of a multicast routing protocol, such as Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD), exchanged between an IP router and a terminal (see, for example, Japanese Patent Application Unexamined Publication No. 2006-087014). 
     Therefore, a multicast network has the characteristic treat network topologies at Layer 2 dynamically vary with delivery groups, depending on the states of participation by terminals in each multicast delivery group. Accordingly, in the case where, as shown in  FIG. 1 , a plurality of multicast traffics on topologies varying from delivery group to delivery group (multicast delivery groups # 1  and # 2 ) are handled in a Layer-2 network  60 , an OAM function is required that can dynamically identify a topology as described above. 
     Particularly in the case where multicast deliveries are made over a Layer-2 network implemented by Ethernet™ technologies, Layer-2 switches in the network use the snooping function in order to reduce the load on a delivery router, to use a link bandwidth more efficiently, and to ensure the confidentiality of data. The snooping function is a function of looking into a multicast routing packet exchanged between an IP router and a terminal and determining a forwarding destination (see RFC 4541, Considerations for Internet Group Management Protocol and Multicast Listener Discovery Snooping Switches). 
     In this case, a forwarding topology in the Layer-2 network dynamically varies with the delivery group, depending on the states of participation by terminals in each multicast delivery group. Therefore, in operations and management, required are a function of checking connectivity and a function of retrieving a route, on the basis of a function of identifying such a network topology. 
     However, the OAM function at Layer 2, which are premised on maintenance and operations on point-to-point communications or on statically set segments in a broadcast domain, do not have a method for dealing with such network topologies and therefore cannot perform appropriate operation management in a multicast network. Moreover, the forwarding destination of an OAM frame cannot be controlled with the technologies described in Japanese Patent Application Unexamined Publication No. 2006-087014 and RFC 4541. Therefore, similarly, appropriate operation management cannot be performed in a multicast network. 
     SUMMARY OF THE INVENTION 
     Accordingly, an object of the present invention is to provide a communication device and an operation management method used in the communication device that can solve the above-described problems and that can check connectivity along an appropriate route and can retrieve a route even in a case where different network topologies are structured for different multicast groups. 
     According to the present invention, a communication device includes: a communication section for receiving or transmitting an Operation Administration and Maintenance (OAM) frame from or to a Layer-2 network; and a controller for providing a destination Media Access Control (MAC) address to the OAM frame when the OAM frame is transmitted in the Layer-2 network, wherein the destination MAC address is associated with an Internet Protocol (IP) multicast address. 
     According to the present invention, an operation management method in a communication device includes: providing a destination Media Access Control (MAC) address to an Operation Administration and Maintenance (OAM) frame to be transmitted, wherein the destination MAC address is associated with an Internet Protocol (IP) multicast address; and transmitting the OAM frame to the Layer-2 network. 
     The present invention is configured arid operates as described above. Thereby, the effect can be obtained that it is possible to check connectivity along an appropriate route and to retrieve a route even in a case where different network topologies are structured for different multicast groups. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram showing a network on which different multicast delivery groups are formed. 
         FIG. 2  is a block diagram showing a configuration of a switch device according to an exemplary embodiment of the present invention. 
         FIG. 3  is a block diagram showing a network structure according Lo the exemplary embodiment of the present invention. 
         FIG. 4  is a diagram showing a frame format of an OAM frame used in the exemplary embodiment of the present invention. 
         FIG. 5  is a diagram showing a network for describing operations in the network according to the exemplary embodiment of the present invention. 
         FIG. 6  is a diagram showing a sequence of table construction operations in the network according to the exemplary embodiment of the present invention. 
         FIG. 7  is a sequence chart showing a sequence of loop-back test operations in the network according to the exemplary embodiment of the present invention. 
         FIG. 8  is a sequence chart showing a sequence of link trace test operations in the network according to the exemplary embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     According to an exemplary embodiment of the present invention, in a Layer-2 network where different network topologies are structured for different multicast groups, a function of checking connectivity and a function of retrieving a route are provided. 
     Specifically, a communication device (here, a switch device) according to the present exemplary embodiment transmits an Operation, Administration and Maintenance (OAM) frame in a Layer-2 network, the OAM frame including a destination Media Access Control (MAC) address associated with an Internet Protocol (IP) multicast address. 
     More specifically, the communication device previously constructs a multicast forwarding table by snooping multicast routing packets and, by referring to the multicast forwarding table, determines the content of processing and a forwarding destination of a received OAM frame including required multicast group information. 
     Accordingly, even when a forwarding route varies with the multicast group in the Layer-2 network, an appropriate output port can be determined for each OAM frame, so that it is possible to check connectivity and to retrieve a route. 
     Hereinafter, an example of the exemplary embodiment of the present invention will be described with reference to the drawings. 
     1. Communication Device 
     Referring to  FIG. 2 , a switch device  1  is connected to an operation management device  2 . The switch device  1  includes line termination sections  11   a  to  11   c  each accommodating a terminal or neighboring switch, OAM processing sections  12   a  to  12   c,  multicast control sections  13   a  to  13   c,  a switch section  14 , a multicast forwarding table  15 , a unicast forwarding table  16 , arid a Central Processing Unit (CPU)  17 . In this figure, although the switch device  1  has three ports as an example, the number of ports is not restricted to three. The switch device  1  may be provided with two or more ports. 
     Each of the line termination sections  11   a  to  11   c  is connected to a terminal or neighboring switch through optical fiber, twisted pair cable, or the like and is a block which implements functions at Layer-1 and Layer-2, such as optical/electrical conversion, frame synchronization, and error correcting control. The line termination sections  11   a  to  11   c  are constructed of physical (PHY) devices or MAC devices in conformity with the Ethernet™ standards. 
     Each of the OAM processing sections  12   a  to  12   c  is a block which performs generating, relaying, or terminating of an OAM frame at Layer 2, which will be described later. The OAM processing sections  12   a  to  12   c  may be implemented by hardware circuits or software processing performed with the CPU  17 . 
     Each of the multicast control sections  13   a  to  13   c  is a block which, when a multicast routing protocol packet is periodically exchanged between a terminal and a delivery router, duplicates the multicast routing protocol packet for extraction, and transfers the duplicated packet to the CPU  17 . This extraction processing is performed by referring to the protocol type field in the IP header and can be easily implemented by a hardware circuit. The CPU  17  updates the multicast forwarding table  15  based on the information in this duplicated packet. 
     The switch section  14  is a packet switch that forwards a frame received from any one of the line termination sections  11   a  to  11   c  to an appropriate one of the line termination sections  11   a  to  11   c  and is structured generally by a combination of a hardware circuit and a buffer memory. This switch section  14  determines an output port for a received frame by referring to the unicast forwarding table  16  when the destination MAC address of the received frame is a unicast address, but by referring to the multicast forwarding table  15  when the destination MAC address of the received frame is a multicast address. 
     The CPU  17  controls the operations of the switch device  1  including OAM-related operations as described later under control of the operation management device  2 . Further, the CPU  17 , the multicast control sections  13   a  to  13   c,  and the OAM processing sections  12   a  to  12   c  may be implemented by a program-controlled processor on which computer programs run. 
     As described above, in the switch device  1  included in a Layer-2 network, a multicast routing packet received at any one of ports (link termination sections)  11   a  to  11   c  is duplicated by a corresponding one of multicast control sections  13   a  to  13   c  and then transferred to the CPU  17 . The CPU  17  identifies the forwarding destination of a multicast packet based on the information in this packet and updates the multicast forwarding table  15 . 
     When the switch device  1  has received an OAM frame, any one of the OAM processing sections  12   a  to  12   c  performs relay processing, including loopback of the frame and rewriting of the contents of the frame for each multicast group, by referring to the multicast forwarding table  15  via the CPU  17 . Moreover, when the switch device  1  transparently transmits an OAM frame, a switch section  14  determines an output port for the frame by referring to the multicast forwarding table  15  as in the case of a user frame. 
     As described above, according to the present invention, even in a case where a route for forwarding varies with the multicast group in a Layer-2 network, an appropriate output port can be determined for an OAM frame, so that it is possible to check connectivity and to retrieve a route for forwarding. 
     In other words, the present invention provides a function of checking connectivity and a function of retrieving a route for forwarding in a case where different network topologies are structured for different multicast groups in a Layer-2 network over which Internet Protocol (IP) multicast traffic is transmitted by using, for example, Ethernet™ technologies. 
     2. Network Structure 
     Referring to  FIG. 3 , it is assumed that a multicast delivery network includes the operation management device  2 , subscriber terminals  10   a - 10   c,  delivery server  20 , delivery router  30  and a Layer-2 network  60  including switch devices according to the present exemplary embodiment of the present invention. Each of the terminals  10   a  to  10   c  is provided with a function of receiving multicast traffic. The delivery server  20  delivers multicast traffic by IP multicast. 
     In the Layer-2 network  60 , for simplicity, it is assumed that subscriber accommodation switches  40   a  to  40   c  are connected to a center accommodation switch  41  through a plurality of relay switches  50   a  and  50   b.  The subscriber accommodation switches  40   a  to  40   c  accommodate the terminals  10   a  to  10   c  respectively, and the center accommodation switch  41  accommodates the delivery router  30 . The operation management device  2  operates and manages the subscriber accommodation switches  40   a  to  40   c,  the center accommodation switch  41 , and the relay switches  50   a  and  50   b  in the Layer-2 network  60 . 
     The structure of physical links providing the connections between each of the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  and  50   b  is of little concern in the present exemplary embodiment. Accordingly, any topology such as hub-and-spoke topology or mesh topology can be applied to the physical topology of the Layer-2 network  60 . Incidentally, each of the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  and  50   b  is configured similarly to the above-described switch device  1 . 
     In the present exemplary embodiment, it is assumed that multicast communication is performed on the premise that routing information is dynamically exchanged between the delivery router  30  and each of the terminals  10   a  to  10   c.  For the multicast routing protocol used for this communication, IPv4 Internet Group Management Protocol (IGMP) (see RFC 1112 and others) or IPv6 Multicast Listener Discovery (MLD) (see RFC 2719 and others) is typically used. However, the present invention is not limited to the use of these protocols. 
     3. OAM Frame Format 
     Referring to  FIG. 4 , an OAM frame format which is used ill the present exemplary embodiment is obtained by extending the destination MAC address field and OAM Protocol Data Unit (OAMPDU) field of an ordinary Layer-2 OAM frame. 
     In the loop-back test prescribed by IEEE 802.1ag, the reserved multicast address of a fixed value (or a unicast address value) is used as the destination MAC address. 
     However, according to the present exemplary embodiment, a multicast address value varying with the delivery group can be used in this field. Specifically, it is assumed that, with the application of a mapping scheme of IP multicast address and MAC address (see RFC 1112 and RFC 1972), a destination MAC address value equivalent to that of a user multicast frame is used. In the case of an IPv4 packet, “01-00-5e-**-**-**” is used as the destination MAC address. 
     In Link Trace test prescribed by IEEE 802.1ag, similarly, the reserved multicast address of a fixed value (or a unicast address value) is used as the destination MAC address, and a destination unicast address, which is the search target, is used in the OAMPDU field. 
     However, according to the present exemplary embodiment, a multicast address value varying with the delivery group can be used in these fields (the destination MAC address field and the OAMPDU field). More specifically, a multicast MAC address is used in the destination MAC address field. A multicast MAC address is used as the Target MAC address in the OAMPDU field for Link Trace. Incidentally, the VLAN (Virtual Local Area Network) tag shown in  FIG. 3  may be any one of C-Tag, S-Tag, B-Tag, and the like prescribed by IEEE 802.Q, IEEE 802.1ad, and IEEE 802.1ah. Additionally, according to the present invention, these VLAN tags may be used in combination in a stacked multistage form. 
     4. Operation Management 
     Assuming that the subscriber terminals  10   a  and  10   b  participate in a multicast group, the operation management according to the present exemplary embodiment will be described with reference to FIGS.  2  and  5 - 8 . 
     Note that, in the present exemplary embodiment, it is assumed that the OAM processing sections  12   a  to  12   c  of each of the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  arid  50   b  are set in advance such that the center accommodation switch  41  and subscriber accommodation switches  40   a  to  40   c  serve as termination points which terminate an OAM frame, and that the relay switches  50   a  and  50   b  serve as relaying points which relay OAM frames. 
     4.1) Construction of Multicast Forwarding Table 
     Referring to  FIG. 6 , a description will be given of a sequence of operations in which the multicast forwarding table  15  is constructed in the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  arid  50   b  in the Layer-2 network  60 . 
     The delivery router  30  periodically inquires of every one of the terminals  10   a  to  10   c,  through transmission of a query packet, whether or not it will participate in a multicast group in question (step  201  in  FIG. 6 ). In response to this query, each of those terminals that will participate in the group (here, the terminals  10   a  and  10   b ) transmits a group membership report packet to the delivery router  30  (steps  203   a  and  203   b  in  FIG. 6 ). 
     In this event, in each of the subscriber accommodation switches  40   a  and  40   b  that have received this group membership report packet through links  66  and  67 , respectively, the packet is duplicated by a corresponding one of the multicast control sections  13   a  to  13   c,  and packet analysis is performed by the CPU  17 . From the result of this analysis, each of the subscriber accommodation switches  40   a  and  40   b  knows that there is a terminal that will participate in the group in the direction of the link  66  or  67 , and then registers the group address into the multicast forwarding table  15  (steps  202   a  and  202   e  in  FIG. 6 ). 
     Each of the relay switches  50   a  and  50   b  and center accommodation switch  41  similarly knows that there is a terminal (or terminals) that will participate in the group in the direction of a link  61 ,  62 ,  64 , or  65 , and then registers the group address (steps  202   b  to  202   d  and steps  202   f  to  202   h  in  FIG. 6 ). 
     On the other hand, the subscriber accommodation switch  40   c  that receives no response from the terminal  10   c  does not perform registration of the group address in the direction of a link  68 . Similarly, the relay switch  50   b  does not perform registration of the group address in the direction of a link  63 . 
     In this manner, the multicast forwarding table  15  is dynamically constructed with respect to the multicast group address in question in each of the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  and  50   b  in the Layer-2 network  60 . 
     4.2) Loop-Back Test 
     Next, with reference to  FIG. 7 , a description will be given of a case where a loop-back test is performed in the state where the multicast forwarding tables  15  have been dynamically constructed through the above-described procedure. 
     The operation management device  2  instructs the center accommodation switch  41  to initiate a loop-back test for the multicast group in question (step  211  in  FIG. 7 ). The OAM processing section ( 12   a,    12   b  or  12   c ) of the center accommodation switch  41  sends out a loop-back test frame in which the multicast group address is given to the destination MAC address (step  212  in  FIG. 7 ). 
     In the relay switch  50   b,  a corresponding one of the OAM processing sections  12   a  to  12   c  transparently transfers this OAM frame to the switch section  14 . The switch section  14 , referring to the multicast forwarding table  15 , forwards the OAM frame only toward the link  62  (step  213   a  in  FIG. 7 ). 
     Moreover, in the relay switch  50   a,  a corresponding one of the OAM processing sections  12   a  to  12   c  transparently transfers this OAM frame to the switch section  14 . The switch section  14 , referring to the multicast forwarding table  15 , forwards the OAM frame toward each of the links  64  and  65  (step  213   b  in  FIG. 7 ). 
     In each of the subscriber accommodation switches  40   a  and  40   b,  a corresponding one of the OAM processing sections  12   a  to  12   c  transfers the received OAM frame to the CPU  17 , which then searches the multicast forwarding table  15 . Here, if the multicast group in question is registered in the multicast forwarding table  15 , the CPU  17  generates a loop-back test response frame in which the MAC address (unicast address) of the center accommodation switch  41  is set as the destination MAC address thereof and the loop-back test response frame is sent back to the center accommodation switch  41  (steps  214   a,    214   b,    215   a,  and  215   b  in  FIG. 7 ). 
     The center accommodation switch  41  collects the results of this loop-back test by receipts of the loop-back test response frames and transmits a report on these results to the operation management device  2  (step  216  in  FIG. 7 ). 
     According to the present exemplary embodiment, through the above-described procedure, it is possible to check the connectivity to every one of the termination points for each multicast delivery group. 
     4.3) Link Trace Test 
     Next, with reference to  FIG. 8 , a description will be given of a case where a link trace test is performed in the state where the multicast forwarding tables  15  have been dynamically constructed through the above-described procedure. 
     The operation management device  2  instructs the center accommodation switch  41  to initiate a link trace test for the multicast group in question (step  221  in  FIG. 8 ). An appropriate one of the OAM processing sections  12   a  to  12   c  of the center accommodation switch  41  sends out a link trace test frame in which the multicast group address is given in its OAMPDU field as shown in  FIG. 4  (step  222  in  FIG. 8 ). 
     In the relay switch  50   b,  a corresponding one of the OAM processing sections  12   a  to  12   c  transfers this received OAM frame to the CPU  17 , which then searches the multicast forwarding table  15 . Here, the relay switch  50   b  forwards the OAM frame whose TTL (Time To Live) field is decremented toward the link  62  for which the multicast group in question is registered (step  223   a  in  FIG. 8 ). At the same time, the relay switch  50   b  sends back a link trace test response frame to the center accommodation switch  41 , the link trace test response frame having its destination MAC address set to the MAC address (unicast address) of the center accommodation switch  41  (step  225   a  in  FIG. 8 ). 
     Moreover, in the relay switch  50   a,  a corresponding one of tile OAM processing sections  12   a  to  12   c  transfers the received OAM frame to the CPU  17 , which then searches the multicast forwarding table  15 . The relay switch  50   a  forwards the OAM frame in which its TTL field is decremented toward each of the links  64  and  65  for which the multicast group in question is registered (step  223   b  in  FIG. 8 ) and, at the same time, sends back a link trace test response frame (step  225   b  in  FIG. 8 ). 
     In each of the subscriber accommodation switches  40   a  and  40   b,  a corresponding one of the OAM processing sections  12   a  to  12   c  transfers the received OAM frame to the CPU  17 , which then searches the multicast forwarding table  15 . Here, if the multicast group in question is registered in the multicast forwarding table  15 , a link trace test response frame is sent back (steps  224   a,    224   b,    225   c,  and  225   d  in  FIG. 8 ). 
     The center accommodation switch  41  collects the results of this link trace test by receipts of the link trace test response frames and transmits a report on these results to the operation management device  2  (step  226  in  FIG. 8 ). 
     5. Advantages 
     As described above, according to the present exemplary embodiment, it is possible to retrieve forwarding routes for each multicast delivery group. Accordingly, it is possible to keep track of a current network topology for each multicast delivery group even when the network topology varies. 
     In the case where the loop-back test is performed, according to tile present exemplary embodiment, the same destination MAC address as in a user multicast frame is used in a loop-back test frame, whereby each of the subscriber accommodation switches  40   a  to  40   c,  center accommodation switch  41 , and relay switches  50   a  and  50   b  in the Layer-2 network  60  can refer to this field value. Thus, it is possible to check connectivity by forwarding the loop-back test frame along the same Layer-2 routes as the user frames for this multicast group follow. 
     In the case where the link trace test is performed, according to the present exemplary embodiment, the same MAC address as in a user multicast frame is used in the OAMPDU field of a link trace test frame, whereby, similarly, it is possible to retrieve the same Layer-2 routes as the user frames for this multicast group follow. 
     Thus, according to the present exemplary embodiment, even in a case where different topologies are structured for different multicast groups, it is possible to check connectivity along an appropriate route and to retrieve a route. 
     The above-described processing of terminating, routing, and transparently transmitting an OAM frame can be easily implemented without adding any new resources such as a table memory, because used for reference is the multicast forwarding table  15  which is constructed by using the snooping function according to a technology related to the present invention, composed of multicast forwarding destinations that are the same as those used in user multicast frames. Therefore, the present exemplary embodiment has the effect that scalability is not affected even when an increase occurs in the number of accommodation ports and/or the number of entries. 
     Moreover, the extension applied to the format shown in  FIG. 4  is minor one and therefore can be easily implemented. Additionally, even if a Layer-2 switch that does not incorporate the configuration according to the present exemplary embodiment is present in the Layer-2 network  60 , it is possible to transparently transmit a frame appropriately. Accordingly, high compatibility with existing networks can be accomplished. 
     Further, according to the present exemplary embodiment, there is another effect that easy implementation can be accomplished without exerting influence on the delivery server  20 , delivery router  30 , terminals  10   a  to  10   c,  and other Layer-3 devices. 
     Furthermore, the center accommodation switch  41  also can be configured to periodically initiate the loop-back test shown at steps  212  to  215  in  FIG. 7  in such a manner that a loop-back test is autonomously initiated upon detection of the query packet shown at step  201  in  FIG. 6 . The ID of a multicast delivery group used in the network is determined between Layer-3 devices (the delivery server  20 , delivery router  30 , and terminals  10   a  to  10   c ). Therefore, if the operation and management of this delivery group is performed in the Layer-2 network  60 , it is necessary to specify the group ID to each Layer-2 switch individually. However, the complexity of the maintenance and operation can be reduced by automatically initiating the test as described above. 
     The present invention can be applied to a Layer-2 network over which IP multicast traffic is transmitted through switches by using Ethernet™ technologies, as well as to a communication device such as a Layer-2 switch for implementing the Layer-2 network. 
     The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The above-described exemplary embodiment is therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by tile foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.