WO2007119635A1 - フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム - Google Patents

フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム Download PDF

Info

Publication number
WO2007119635A1
WO2007119635A1 PCT/JP2007/057357 JP2007057357W WO2007119635A1 WO 2007119635 A1 WO2007119635 A1 WO 2007119635A1 JP 2007057357 W JP2007057357 W JP 2007057357W WO 2007119635 A1 WO2007119635 A1 WO 2007119635A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
frame
node
network configuration
bit
Prior art date
Application number
PCT/JP2007/057357
Other languages
English (en)
French (fr)
Inventor
Masaki Umayabashi
Kazuo Takagi
Original Assignee
Nec Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nec Corporation filed Critical Nec Corporation
Priority to JP2008510908A priority Critical patent/JPWO2007119635A1/ja
Priority to CN200780011237.8A priority patent/CN101411138B/zh
Priority to US12/293,855 priority patent/US8218446B2/en
Publication of WO2007119635A1 publication Critical patent/WO2007119635A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645—Details on frame tagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4675—Dynamic sharing of VLAN information amongst network nodes

Definitions

  • the present invention relates to a frame in a regular flow, and in particular, to
  • Wide-area Ethernet VPN Virtual Private Network
  • WAN Wide-area Network
  • LAN Local Area Network
  • Wired Area Network Ether In WA, Operations, Administration and Maintenance: 0 function is required, but Ethernet which has been used in LAN has not been equipped with ⁇ function originally, and it has become a habit. Based on the background, in recent years, some standard organizations have been promoting the standard 2f 0 regarding 0M function in Ethernet translation.
  • One of the representative 0M functions is the Trace-route function widely used as one of the 0A functions in Internet.
  • the Trace-route function is used to acquire device information passed to a target device.
  • ITU-T Y. 17 ethoam's calling method for which a leak indication is underway
  • Fig. 33 shows the case where the terminal T2 executes LT in order to check transit device information to the terminal T1.
  • the net of Figure 3 is the existing layer 2 that performs frame transfer in the MAC (Media Access Control) address learning base on the topology by the Spanning Tree Protocol (SIP) / Rapid Spanning Tree Protocol (RSTP).
  • L2 This is a network (the link between the existing switches LS6 and LS7 is a blocking link). Tl or t2 marked on the port of each existing switch LS1 to LS8 The letter “” shows the MAC address learning situation at each point.
  • a Request frame containing a TTL (Time To Live) value is sent to the target device, and the relay node and target device decrement the Reply value minus 1 by the TTL value.
  • the transmission source can perform sorting based on the TTL value of the Reply frame, and acquire transit device information to the evening target device.
  • LT is checked in order for the terminal T to check the transit device 'I ⁇ g to the terminal T1.
  • the source terminal T2 transmits an LT Request frame (in this case, the initial value of TTL is 255).
  • an LT Reply frame containing the TTL value is sent back to the ReQuest source device.
  • the subsequent relay node existing switches LS3, LS2 and LSI perform the same operation. After that, when the LT Request frame arrives at the terminal T1 which is a uniform get device, the terminal T1 receives the LT Request frame addressed to the own device, and overrules the LT Request frame, and sends the Request request to the device.
  • the terminal T2 which is a Request originator, receives the LT Reply frame from the existing nodes LS1 to LS5, which are relay nodes, and the terminal T1 of the evening get. If T receives the Reply frame based on the stored TTL value.
  • T receives the Reply frame based on the stored TTL value.
  • the existing LT can confirm the transfer route at the normal time, but, as described above, [! There is a leak that it is not possible to identify the P jurisdiction in the jurisdiction.
  • Fig. 34 also describes LT from the terminal T2 (AC # t to terminal Tl (AC # tl).
  • Fig. 34 (1) shows a normal transfer state, and the existing switch is shown.
  • the link between LS6 and ZLS7 is a block link
  • MAC # tl and MAC # t2 are learned in each node by frame transfer between the terminal T1 and the terminal T2. If LT is performed from the terminal Tl to the terminal Tl, LT results are obtained along the learned route of MAC # tl along the learned route as shown in Fig. 33: LS5 ⁇ LS4 ⁇ LS3 ⁇ LS2 ⁇ LS1-T1 .
  • the key to be obtained here is the fiber cutting technology, and it is not a route that meets the purpose of “identifying P. P” p ⁇ ⁇ If identifying “if”, the route before switching However, in the normal Layer 2 network, the AC address before switching is changed when switching to a new transfer path after occurrence of the P section.
  • the entry is flashed, and the MAC address which has been learned on the new ⁇ S road of the apnea is 'L' to be conducted, so the LT is carried out on the pre-switchway, and the
  • the object of the present invention is that the P department has generated: ⁇ , while ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ In the above, it is necessary to identify the dew to the node in front of the p control occurrence point, and to identify the frame ⁇ «Confirmation method, node, its program and frame confirmation system ⁇ to enable identification of the control. Disclosure of the invention
  • a frame of a network that transfers an event frame transmitted from a transmission source terminal to a destination terminal is output to a forwarding table when the network configuration is updated. It is characterized in that an identification is given to the address which becomes a force (J information is added to leave the address, and the request message is subjected to route confirmation based on the address left by adding the identification information.
  • the route to the node before the P department generation ridge is specified on the route before the dew switching, and the P department location becomes the T function.
  • the forwarding table adds 3 ⁇ 43 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ⁇ 4 ”information to the address to which the output destination is added, and leaves a request message on the basis of the address left
  • FIG. 1 is a network model diagram in the first embodiment of the present invention.
  • FIG. 2 is a format of the Ethernet frame in the first embodiment.
  • FIG. 3 shows the format of the Ethernet ⁇ frame in the first embodiment.
  • FIG. 4 is a block diagram of a switch in the first embodiment.
  • FIG. 5 is a block diagram of a frame switching unit according to the first embodiment.
  • FIG. 6 is a block diagram of a focusing table in the first embodiment.
  • FIG. 7 is a MAC table in the first embodiment.
  • FIG. 8 is a VLA table in the first embodiment.
  • FIG. 9 is a block diagram of the 0AM controller in the first embodiment.
  • FIG. 10 is a block diagram showing the hardware configuration of the switch in the first embodiment.
  • FIG. 11 shows the processing of the 0AM controller at the time of generating the LT Request frame in the first embodiment.
  • FIG. 12 shows the processing flow upon reception of the LT Reply frame of the 0AM controller in the first embodiment.
  • FIG. 13 shows the processing of the 0AM controller at the time of receiving the LT Request frame in the first embodiment.
  • FIG. 14 is a MAC table in the first embodiment.
  • FIG. 15 is a network model diagram when a failure occurs in the first embodiment.
  • FIG. 16 is a MAC table immediately after the occurrence of P control in the first embodiment.
  • FIG. 17 is a MAC table after frame transfer in the first embodiment is opened.
  • FIG. 18 is a block diagram of a frame switching unit according to a second aspect of the present invention.
  • FIG. 19 is a MAC table in the second embodiment.
  • FIG. 20 shows an example of address conversion of the target address in the second embodiment.
  • FIG. 21 is a block diagram of the 0AM controller in the second embodiment.
  • FIG. 22 is a MAC table in the second embodiment.
  • FIG. 23 is a MAC table immediately after the occurrence of P control in the second embodiment.
  • FIG. 24 is an AC table after frame transfer is opened in the second embodiment.
  • FIG. 25 is a configuration diagram of a frame switching unit in the third embodiment of the present invention.
  • FIG. 26 shows an example of address conversion of the evening get address in the third embodiment.
  • FIG. 27 is a block diagram of a 0A controller in the third embodiment.
  • FIG. 28 is a MAC table in the third embodiment.
  • FIG. 29 is a MAC table immediately after a failure occurs in the third embodiment.
  • FIG. 30 is a MAC table after frame opening in the third embodiment.
  • FIG. 31 is a configuration diagram of a frame switching unit in a fourth embodiment of the present invention.
  • FIG. 32 is a block diagram of the 0AM controller in the fourth embodiment.
  • Fig. 33 is a diagram for explaining a normal LT leakage in a low-level Ethernet.
  • Fig. 34 is a diagram for explaining the LT orchid at the occurrence of P control in «Ethernet.
  • FIG. 1 shows an example of the physical network configuration of the first embodiment to which the present invention is applied. All of the switches S1 to S8 in FIG. 1 have a function according to the present invention in addition to the existing Ethernet function. The following is the state between each switch.
  • switches S1 and S5 are connected to the user terminal as follows.
  • Switch S1 port pi and user terminal T1 Switch S5 port pi and user terminal T2
  • FIG. 2 shows the format of Ethernet frame 400.
  • the Ethernet frame 400 includes a destination MAC address 410, a source MAC address 420, a VLAN tag 430, a Type 440, a payload 450, and an FCS (Frame Check Sequence) 460.
  • FCS Frae Check Sequence
  • FIG. 3 shows the format of the 0AM frame.
  • the Type field is added to the Type 510, OpCode 520, Transaction Ident if ier (TID) 530, TTL 540, Target address 550, LT mode 560 is inserted.
  • TID Transaction Ident if ier
  • VLA tag 430 is attached.
  • the Type 510 stores a Type value dedicated to 0A
  • the OpCode 520 stores a 3 ⁇ 48 value of a 0M frame.
  • TID Transaction Identi bomb
  • TTL stores the execution ID of the ⁇ control
  • TTL 540 stores the TTL value
  • the target address 550 The address of the LT evening equipment is stored
  • the LT mode 560 stores a value indicating whether it is normal mode or failure switching mode when performing LT. 01 Normal mode, failure switching mode I will hesitate to explain).
  • switches S1 to S8 will be described with reference to FIG.
  • the switch 600 in FIG. 4 includes PHYs 611, 612, 613, 614, MACs 621, 622, 623, 624, a frame switching unit 630, a memory 640, a CPU 650, a console 1/0660, and a P control unit 670.
  • PHY61 612, 613, 614 are read out to IF 60 K 602, 603, 60 respectively, MAC 621, 622, 623, 624 is connected to 611 611, 612, 613, 614, MAC 62 622, 623, 624 Frame switch link ⁇ ! 5 630 force connected.
  • Ethernet frames input from the IFs 60 602, 603, and 604 are input to the frame switching unit 630 via the PHYs 611, 612, 613, and 614 and the MACs 621, 622, 623, and 624, respectively, and the frame switching unit 630 Depending on the operation to be performed, an appropriate output IF is determined, and is output to I, 602, 603, 604 via MAC 621, 622, 623, 624 and ⁇ 11, 612, 613, 614, respectively.
  • P section information has a function to send to the P section management unit 670.
  • the P control unit 670 manages the status of each IF (normal ZP chapter harm).
  • Pf 3 ⁇ 4 information is received from the PHY 61 K 612, 613, or 614
  • the I frame is generated by either the frame switching unit 630 or the CPU 650. Has a function to notify.
  • the CPU 650 and the memory 640 store a program for controlling the operation of the frame switching unit 630 and necessary data, and have a function of controlling the frame switching unit 5630.
  • Console 1/0660 is an external interface related to setting management for each part in the device.
  • FIG. 5 shows the detailed configuration of the flame-tuning unit 630. As shown in FIG. 5
  • the frame switching unit 630 includes a frame resolver 700, a frame rewriter 710, a frame diverter 720, a table searcher 730, a forwarding table 740, a MAC learning module 750, a control frame distributor 760, an 0AM controller 770, and a SIP controller. It consists of 780, setting controller, and so on.
  • the frame switching unit 630 has a function to determine the output IF of the Ethernet frame input from the MACs 621 to 624, and to have the predetermined IF and MACs 621 to 624 available.
  • each part of the frame switching unit 630 will be described.
  • the frame solver interprets the frames input from the MACs 621 to 624, and if it is a main signal data frame of a normal Ethernet frame 400, it will decode the header information and the input port 'I Blue. It has the function of ⁇ 730 and MAC learning device 750, and the function of converting the whole frame or pay mouth to the frame document «710 and controlling the input frame to 0AM frame 500 or STP / RSTP. Bridge Protocol Data Unit (hereinafter referred to as BPDU, which is a frame) And other control frames, such as age, have the function of making the entire frame into a control frame distributor 760.
  • BPDU Bridge Protocol Data Unit
  • the frame square box 700 Since the frame square box 700 stores the Type value dedicated to the 0M frame in the Type field 510 for the 0AM frame 500, it can be identified as a 0A frame.
  • the frame * 710 710 is instructed from the table search unit 730 to the main signal data frame received from the frame processing unit 700: ⁇ has a function to rewrite the frame.
  • the frame document 710 has a function to insert and delete a VLA tag from and to the Ethernet frame 400 as a function of rewriting a frame, and to transfer a frame to the frame transfer unit 720 appropriately.
  • the main signal data frame is input from the frame paper crane 710 to the frame detector 720, and the control frame is input from the control frame distributor 760.
  • the frame sewing device 720 has a function of transferring the main signal data frame received from frame * ⁇ 0 to the output port received from the table searcher 730 to the frame 621 to 624 with respect to the main signal data frame. Also, with regard to control frames, it has a function of transferring to the MACs 621 to 624 corresponding to output ports that simultaneously receive control frames received from the control frame distributor 760.
  • the table search unit 730 has a function of acquiring output port information with reference to the feeding table 740 based on the header information and the input port information received from the frame finder 700.
  • the configuration of the forwarding table 740 will be described.
  • FIG. 6 is a block diagram showing an example of the configuration of the forwarding table 740. As shown in FIG.
  • the following table 740 is a table that stores information for ⁇ ! As Técare, there are a C-table 800 which obtains an output port from a MAC address and a VLA tag, and a VLA-table 810 which obtains an output port based on a VLA tag.
  • the recording table 740 is composed of the MAC table 800 and the VLA table 810, a tape write control unit 820, and a table i control unit 830. Writing of new data to each of the above-described tables is performed via the table writing control unit 820, and reading of data from each of the above-described tables is performed via the table control unit 830.
  • the configurations of the MAC table 800 and the VLA table 810 are as shown in FIG. 7 and FIG. 8, respectively, and the MAC table 800 stores the output points for the MAC address and VLAN (Virtual LAN) group. , LT flag field is provided.
  • a value of 0 is stored if the entry is an entry in a normal state, and a value of 1 is stored if the entry is an entry before switching at the time of failure switching.
  • the VLA table 810 stores the output port for the VLA tag.
  • the MAC table 800 is performed by the MAC learning device 750: ⁇
  • the rewrite of the LT flag field from a value of 0 to a value of 1 is performed by the SIP controller 780 and also the VLA table 810 by the S1P controller 780; It will be gff.
  • the output port described in the VLA tag of the VLA table 810 contains a port that is not in the STP blocking state for that VLAN.
  • the table configuration is not limited to the P-arm in Figures 7 and 8.
  • the table searcher 730 has a function of acquiring output port information for frame header information received from the frame resolver 700 by referring to the forwarding table 740.
  • the table search unit 730 refers to the MAC table 800 of the forwarding table 740, and receives an output port for the MAC—DA (Direction Address) (destination MAC address) and VLAN received from the framer 700. It has the function to acquire.
  • DA Direction Address
  • VLAN virtual local area network
  • table search unit 730 refers to MAC table 800 and, for MAC_DA and VLA, when there is an entry whose LT flag field value is 0, corresponding point information is It has the function of acquiring and then notifying the framer 720 of the output port information, while the MAC table 800 is not covered by the pair j 3 ⁇ 4 T entry: t refers to the VLA Técaré 810 and refers to the output port for the VLA. After that, the machine that sends the output port information to the framer 720 is sent.
  • the MAC learning device 750 When the MAC learning device 750 receives header information from the frame device, it refers to the MAC table 800 of the forwarding table 740, and receives MAC_SA (Source Address) (source MAC address) of the received header information. And the output port for the VLAN, and the entry is No: ti ⁇ is a function that stores MAC—SA in the MAC address field, stores VLA in the VLA field, stores the receiving port in the output port field, and sets the value of the LT flag field to 0. Have.
  • MAC_SA Source Address
  • ti ⁇ is a function that stores MAC—SA in the MAC address field, stores VLA in the VLA field, stores the receiving port in the output port field, and sets the value of the LT flag field to 0. Have.
  • the control frame distributor 760 transfers the control frame received from the frame divider 700 to a predetermined processor, and the control frame and output port information received from the processor as a frame transmitter 720 Function to transfer to
  • the processor includes an 0AM controller 770 and an STP controller 780, and each control frame includes an 0AM frame 500 and a BPDU.
  • control frame distributor 760 When the control frame distributor 760 receives the 0AM frame 500 from the frame resolver 700, it deciphers the received 0AM frame 500 to the 0AM controller 770, and receives the 0AM frame 500 from the 0AM controller 770 and the output point information. It has a function to transfer to the framer 720.
  • the 0AM frame 500 includes only the LT Request frame and the LT Reply frame.
  • control frame distributor when the control frame distributor receives a BPDU from the frame terminal 1, it makes the received BPDU the STP controller 780, and receives the BPDU and the output point information received from the STP controller 780 as the frame transmitter 720. Have the ability to forward to
  • the 0AM controller 770 generates an LT Request frame according to the LT implementation request from the setting controller 790, obtains an output point by referring to the focusing table 740, and causes the LT to the control frame distributor 760. It has a function of transmitting a request frame. ⁇ Also, the 0A controller 770 controls the LT Request frame from other nodes and controls the frame distributor.
  • the 0AM controller 770 When received from the 760, it processes TTL values etc., acquires the output port referring to the forwarding table 740, sends the LT Request frame to the control frame distributor 760 ⁇ ff) There is a function of generating an LT Reply frame, acquiring an output point with reference to a focusing table 740, and transmitting an LT Reply frame to a control frame distributor 760. Also, when the 0AM controller 770 receives an LT Reply frame from another node from the control frame distributor 760, it retains the frame source address and the TTL value, and sorts the T1L value of each LT Reply frame. It has a function of acquiring transit device information as a result of LT, and a function of notifying the setting controller 790 of the acquired result. The outline function of the OM controller 770 has been described above, and the detailed configuration of the 0 controller 770 will be described below using FIG.
  • FIG. 9 is a block diagram of the crucible controller 770.
  • the 0AM controller 770 is composed of a 0AM frame transcoder 1100, a target address filter mo, a table reference 1120, a frame generator 1130, an LT reply framer 1140, a TTL ⁇ ⁇ 1150 and a frame transmitter 1160. Configured
  • the 0 ⁇ frame filter 1100 determines the 0AM frame received from the control frame distributor 760 based on the Opcode 520 of the 0 frame, and if the 0A frame type is the LT Request frame, the target addressless filter of that frame is detected. When the type of 0AM frame is LT Reply frame, it is transmitted to 1110 and has a function to transmit the frame to LT Reply frame resolver 1140.
  • the LT Reply frame equipment 1140 When the LT Reply frame equipment 1140 receives the LT Reply frame from the 0AM frame type filter 1100, it acquires the source address of the LT Reply frame from the MAC-SA field 420 of the LT Reply frame, and the TTL value from the TTL field 540. It has a function to acquire, and a function to list source address and TTL value and to sort TTL value in descending order for LT Reply frame with equal Transaction-ID.
  • the LT Reply frame apparatus 1140 receives notification of timer expire from the frame source 1130, it sorts the list at that time as the LT result and notifies the setting controller 790 of the result. Have.
  • the addresses of passing devices are stored in order from the LT Request generation device to the target device.
  • Get address address for the evening 1110 gets the target address for the LT Request frame, and the target address for the 550 field, and the evening get address for the other node: ⁇ , table reference 1120 and TTL ⁇ ⁇ ⁇ ⁇ It has a function to transmit to 1150, and to transmit only to TTL ⁇ 1150, until the target address is its own node.
  • the TTL 1150 obtains the TTL value of the LT Request frame from the TTL field 540, sets the TTL value to 1, and sends the LT Request frame with the T1 L value to the frame transmitter 1160, and the LT Request frame. And a function to transmit the TTL value obtained by subtracting 1 to the frame generator 1130 and instruct generation of the LT Reply frame.
  • the frame storage 1130 Upon receiving the LT execution request from the setting controller 790, the frame storage 1130 stores the target address information received from the setting controller 790 in the target address field 550, and the mode information in either normal mode or P mode switching mode. Is stored in the LT mode field 560 to generate an LT Request frame, and the generated LT Request frame is transmitted to the frame transmitter 1160.
  • the normal mode is LT according to the MAC address learning situation at that time, and is a mode in which the current diversion path can be confirmed.
  • the P control mode is the LT according to the MAC address learning situation before the P control is performed, and is a mode that can identify the failure point.
  • the frame generator 1130 has a function of storing an ID for determining the mapping of the Reply frame to the Request frame in the LT Request frame, and a function of storing the ID in the Transaction-ID field (TID) 530. It has a function of sending the get address information and mode information to the table reference device 1120.
  • TID Transaction-ID field
  • the frame generator 1130 has a function of generating a 1 ⁇ 1 ⁇ frame when receiving a generation instruction from 111 ⁇ ⁇ 1150.
  • the frame raw 1130 when the frame raw 1130 receives a generation instruction from MM MM ⁇ 1150, it generates an LT Reply frame based on the destination address of the LT Reply frame 'I Blueberry, TTL value, and Transaction-ID. It has a function of transmitting an LT Reply frame to a frame transmitter 1160 and transmitting destination address information to a table reference 1120 at the same time as transmitting the generated LT Reply frame.
  • table reference 1120 receives the evening get address' I Blue Report and mode information of the LT Request frame from frame raw 1130, it refers to MAC table 800 of fording tape record 740. It has a function of acquiring output port information to be transmitted and transmitting the output port information to the frame transmitter 1160.
  • the table reference device 1120 When the table reference device 1120 receives the LT Request frame from the target address filter 1110, it extracts evening target address information and mode information from within the frame, and refers to MAC result of the matching table 740. It has a function of obtaining output port information corresponding to "iS" and transmitting the output port information to the frame transmitter 1160.
  • table referrer 1120 when table referrer 1120 receives the destination address information of the LT Reply frame from frame raw 1130, it refers to MAC table 800 of forwarding table 740, The corresponding output port information is obtained, and there is a mechanism for transmitting the output port information to the frame transmitter 1160.
  • the frame transmitter 1160 is an LT Request frame received from a frame raw 1130, or an LT Request frame received from a TTL 1 1150, or an LT Reply frame received from the frame generator 1130 and the corresponding output received from the table reference unit 1120. It has the function of pairing point information and transferring it to the control frame distributor 760.
  • the frame transmitter 1160 activates a timer that is valid for X seconds (for example, 5 seconds) for the Transaction ID of the LT Request frame, and the evening timer Once expired, it has a function to notify the LT Reply frame 1140.
  • the STP controller 780 performs M / f processing of STP / ftSlP port information based on the BPDU received from the control frame distributor 760, re-creates the BPDU, and outputs the BPDU to output it as an adjacent switch. It has a function of transferring port information to the control frame distributor 760.
  • the Mff processing of the port information and the re-creation of the BPDU conform to the IEEE 802. ID / w / s etc., so the detailed description will be omitted here.
  • the value of the LT flag field of the MAC table 800 is ⁇ f from 0 to 1 without flushing the address to be flushed when the top page message is received.
  • the setting controller 790 receives the setting information input via the console 1/0660 in FIG. 4 via the CPU 650, and performs a setting process on an appropriate processor.
  • the setting controller 790 when receiving the LT execution request input via console I / O, the setting controller 790 instructs the 0 ⁇ controller 770 to execute LT (instructs generation of an LT Request message). ) Function. This function is a function to pass the address of the target device and mode information of either the normal LT or the pre-failure switching LT to the 0A controller 770. Also, setting control The unit 790 has a function of receiving the LT result implemented by the 0M controller 770 when the LT control is completed, and outputting the received result of LT via the CPU 650 via console I / O.
  • the setting controller 790 also has a function to set parameters for the 0AM controller 770 and the STP controller 780.
  • FIG. 10 is a block diagram showing a hardware configuration of switches S1 to S8 on the physical network according to the present embodiment.
  • the switches S1 to S8 are difficult to implement due to the same hardware configuration as a computer device, such as a CPU (Cen tral P es c es i ng Un it) 1201 (figure 4, CPU 650), RAM (Random Access Memory), etc.
  • the main storage unit 1202 is used as a temporary storage area for data work area, data storage area, etc.
  • Communication control unit 1 203 (Fig. 4, IF601 to IF604, PHY61 1 to 614) that performs transmission and reception, input unit 1204 such as a keyboard or mouse, etc. (Fig.
  • the switches S1 to S8 are circuits consisting of hardware components such as LSI (Large Configuration), which incorporate programs for realizing such functions in the switches S1 to S8.
  • LSI Large Configuration
  • the CPU 1201 executes the program stored in the auxiliary storage unit 1206 on the main storage unit 1202 and executes the program, and controls the operations of switches S1 to S8 to execute the respective functions described above. Be realized.
  • the LT implementation method according to this embodiment will be described for performing LT from terminal to terminal T1.
  • ⁇ ⁇ it is possible to identify the ⁇ ⁇ path of the target device, as well as to identify the ⁇ point of ⁇ that was impossible with the technique.
  • the general functions and detailed configuration of the 0AM controller 770 have been described above, and the detailed operation of the 0AM controller 770 will be described below with reference to FIGS.
  • the 0AM controller 770 generates an LT Request frame from its own node for control of LT: Control of ⁇ , control when terminating an LT Reply frame at its own node, and LT Request frame from another node Control and force ffi to generate LT Reply frames. Each control will be described using the process flow.
  • Figure 11 generates a LT Request frame from its own node:
  • Figure 1 illustrates the processing of 1 ⁇ ⁇ control.
  • step S101 the frame unit 1130 receives an LT execution request from the setting controller 790 via the I / O console US.
  • the LT implementation request from the setting controller 790 includes address information on the evening device that implements LT and mode information on the normal mode / P mode.
  • the normal mode follows the address learning situation at that time.
  • the I »switching mode is the LT according to the AC address learning situation before mm ⁇ » it is the mode that can identify the fault location Ru.
  • step S 102 the frame generator 1130 generates an LT Request frame based on the target address information and the mode information, and transfers the generated LT Request frame to a frame transmitter.
  • step S 103 the frame creation unit 1130 transfers target address information and mode information to the table reference unit 1120.
  • step S104 the table reference device 1120 refers to the MAC table 800 of the forwarding table 740 to make an entry that matches the evening get address and the mode information, and obtains the corresponding output port information.
  • the frame transmitter 1160 In step S 105, the frame transmitter 1160 pairs the LT Request frame transmitted in step S 102 and the output port information transmitted in step S 104, and transfers the pair to the control frame distributor 760. Start the evening timer to measure the validity period of the sent LT Request frame. Thus, the generation process of the LT Request frame is completed.
  • the 0A frame filter 1100 When the 0A frame filter 1100 receives an LT Reply frame from the control frame distributor 760 in Step S 201, it determines the received frame as an LT Reply frame in Step S 202, and sends an LT Reply frame angle II comparator 1140 to the frame. Do.
  • step S 203 the LT Reply frame apparatus 1140 sends an address of an apparatus located midway from MAC_SA of the received LT Reply frame to a source apparatus of the LT Reply frame, that is, the evening acquisition apparatus performing LT.
  • a source apparatus of the LT Reply frame that is, the evening acquisition apparatus performing LT.
  • step S 204 the frame transmitter 1160 notifies the LT reply frame device 1140 of the timer exora concerning the corresponding Transaction-ID. This causes the LT Reply frame analyzer 1140 to make the sorted list at that time the result of LT.
  • step S205 the LT Reply frame apparatus 1160 notifies the setting controller 790 of the list of the results. Thus, the processing of the age for terminating the LT Reply frame is completed.
  • the 0AM frame AM U filter 1100 When the 0AM frame AM U filter 1100 receives the LT Request frame from the control frame distributor 760 in step S 301, it determines the received frame as an LT Request frame in step S 302 and uses it as a target address filter 1110. In step S303, the target address filter 1110 determines whether the evening request address of the LT Request frame is a self node or another node.
  • the target address filter 1110 transfers the target address information and the mode information to the remote control unit 1120 in step S304.
  • step S 305 the table reference device 1120 refers to the MAC table 800 of the forwarding table 740 to lock the entry where the first get address and the mode information match, and acquires the output port information for the pair. . Having obtained the output port information, table reference 1120 forwards the information to frame transmitter 1160.
  • the target address is the other nodes in step S 303, the target ⁇ address filter 1110, in step S 306, the LT Request frame m ' ⁇ vessels 1150 in the vehicle ⁇ 3 ⁇ 4 9 _ Ru.
  • step S 307 the TTL ⁇ 1150 increments the TIL value of the LT Request frame by 1, and sets the LT Request frame to the frame transmitter 1160.
  • step S308 the frame transmitter 1160 sends the output port information received in step S305 and the LT request frame received in step S307 to the control frame distributor 760. If it is above, the relay fiber processing of the Request frame is completed.
  • step S303 if the target address is the own node, in step S309, the destination address filter 1110 sets the LT Request frame to TTL ⁇ ⁇ 1 1150.
  • step S310 the TTL ⁇ 1150 sets the threshold value of the LT Request frame to 1 and transmits the LT Request frame to the frame transmitter 1160.
  • LT Reply frame production is performed.
  • step S 311 TTL ⁇ 1 1150 notifies the frame source 1130 of the source address and TTL value of the LT Request frame, and instructs generation of an LT Reply frame.
  • the frame processor 1130 generates an LT Reply frame based on the source address information and the m value, and transfers it to the frame transmitter 1160.
  • the frame raw ⁇ 1130 sets the first address (the source address of the LT Request frame) to the table reference 1120.
  • the table reference unit 1120 refers to the MAC table 800 of the feeding table 740 in step S 314 to obtain output port information for the destination address, and sends the obtained output point information to the frame transmitter 1160. Forward.
  • step S 3 the frame transmitter 1160 transfers the LT Reply frame received in step S 312 and the output port information received in step S 314 to the control frame distributor 760.
  • the processing in the case of generating the LT Reply frame is completed as well as relaying the LT Request frame from other nodes.
  • the MAC table 800 when MAC address learning is completed in the normal state in the network of FIG. 1 is shown in FIG.
  • VLA is X
  • switches S1 to S8 entries of MAC # tl & VLAN # X and MAC # t2 & VLM # X are stored. In each entry, the value of 0 is set because the LT flag is in the normal mode.
  • the setting condition II of the MAC table 800 in this process is shown in FIG.
  • the entry of the port receiving the topology message is not flushed as it is, but the LT flag is changed to 1 for the entry, and the entry is left.
  • port p2 of switch S1 receives the topology change message from switch S2, and at that time, it does not flush the entry of MAC # t2 & VLA #X learned on port p2, but the LT flag. Rewrite from 0 to 1 and leave the entry.
  • Switch S4 MAC # 11 & VLAN # entry switches S5 MAC # 11 & VLAN # X entry, Switch S6 MAC # tl & VLA #X entry and MAC # t2 & VLA #X entry, Switch T4 S7 MAC # t 1 & VLA # X entry and MAC # t 2 & VLA # X entry, switch S 8 C # tl & W
  • Fig. 17 The configuration of the MAC table 800 after frame transfer cut-off in the network of Fig. 15 is shown in Fig. 17.
  • each entry is managed including the LT flag.
  • the condition of the MAC table shown in Fig. 17 is as follows: In ⁇ in the network shown in Fig. 15, the target device is the terminal T2 to the terminal T1. Do.
  • the source terminal T2 transmits an LT Request frame (the initial value of TTL is set to 255).
  • Switch S4 which is the next stage node on the port p2 side of switch S5 is an entry device for the terminal T1 which is an evening device, the entry of the MAC flag tl of MAC # tl & VLA #X and which is the local switching mode 1 in FIG. ⁇ ⁇ From the MAC table 800.
  • the switch S5 when the address is sorted so that the TTL is lowered, the switch S5 ⁇ the switch S6 ⁇ the switch S7 ⁇ the switch S8 ⁇ the switch S8 ⁇ the switch Sl ⁇ the terminal T1.
  • the timer extension if the Reply frame is not received at the terminal T2, this is the result of LT, and it is possible to confirm the device on the road to the target device, the terminal T1.
  • LT Requested frame is sent to the node before the point of failure.
  • Request frames can be attached to ij, and it is T function to identify a simple point by returning an LT Reply frame at each node.
  • FIG. 18 shows a detailed configuration of the frame switching unit 630 according to the second embodiment.
  • the feeding table 740 is for the feeding table 1940
  • the 0AM controller 770 is for 0AM control.
  • the S1P controller 780 is changed to the S1P controller 1980
  • the setting controller 790 is changed to the setting controller 1990.
  • the second embodiment will be described focusing on the first embodiment and the second embodiment. First, the focusing table 1940 will be described.
  • a MAC table 800 is shown in the MAC table 2000 shown in FIG. That is, in the MAC table 2000, the LT flag field introduced in the MAC table 800 is deleted, and the determination of the normal mode / ⁇ switching mode performed by the LT flag field will be described later in this embodiment.
  • the S1P controller 1980 partially translates the MAC address of the MAC table 2000, the normal mode / IW switching mode is determined.
  • the SIP controller 1980 performs STP RSTP processing according to IEEE 802. 1D / w / s or the like.
  • the STP controller 780 does not flush the address to be flushed when a topology change message is received, as a characteristic processing of the present invention.
  • the flag field had a function of 5 ⁇ from 0 to 1.
  • the S1P controller 1980 in the present form of the function converts the MAC address of the MAC table 2000 ⁇ without flushing the address to be flushed when the topology change message is received.
  • the S1P controller 1980 has a function to convert an 8-bit bit, which is defined as a multi-pass bit, into a value of 1 in a normal MAC address. Yes.
  • the MAC address learned in the MAC table 2000 in the normal state is a stored address and the multicast bit has a value of 0, this bit is used to determine the normal mode / failure switching mode. Also, since a frame with a multicast MAC address refers to another table for multicast instead of MAC table 2000, even if the multicast bit in the entry of MAC table 2000 is converted, a frame malfunction occurs. Does not occur.
  • the configuration of the 0A controller 1970 is similar to that of the 0AM controller 770. The difference is that, as shown in FIG. 21, the table reference 1120 has been changed to the global reference 220, and the frame raw ⁇ 1130 has been changed to the frame 2230.
  • frame creation 1130 Upon receipt of the LT execution request from setting controller 790, frame creation 1130 receives an LT Get Request frame based on the evening get address information received from setting controller 790 or the mode information of either normal mode or ⁇ switching mode. It was generated.
  • the distinction between the normal mode and the P mode is determined by the multicast bit of the MAC address.
  • the frame authentication 2230 receives only the target address information from the setting controller 1990, and has a function of generating an LT Request frame.
  • LT mode field 560 for storing mode information of the normal mode / ⁇ switching mode in the LT Request frame, and the information is output to the target address itself.
  • the multicast bit of the target address When the multicast bit of the target address is 0, it indicates the normal mode, and the current route can be confirmed by performing LT according to the MAC address learning situation at that saddle point.
  • the multicast bit of the target address has a value of 1; ⁇ indicates P mode switching mode, and (by performing LT according to the MAC address learning situation before! It can be identified.
  • the table reference device 1120 When the table reference device 1120 receives the evening get address information and mode information of the LT Request frame from the frame generator 1130, it transmits the MAC table 800 of the forwarding table 740. By reference, it had a function to obtain output port information corresponding to the evening get address information & mode information.
  • the table reference device 2220 has a function of acquiring output port information for target address information including mode information with reference to the MAC table 2000 of the forwarding table 1940.
  • the setting controller 1990 is modified from the function of the setting controller 790 to notify the 0AM controller 770 of the LT execution request inputted through the console I / O.
  • the setting controller 790 notifies the 0AM controller 770 of the LT3 ⁇ 413 ⁇ 4 request, either the address mode or the normal mode or failure switching mode information of the evening gear unit can be used. I had it.
  • the setting controller 1990 has a function to notify the LT target mode as it is to the controller 0 as the LT hard mode of the LT ⁇ request is the normal mode: ⁇ LT execution mode of the LT execution request
  • the function is to notify the image controller 1970 of an address in which the multicast bit (the 8th pit) of the target address is converted to a value of 1 in the Pt ⁇ switching mode. Does not notify.
  • the mode information is included in the target address, and it is not necessary to send the mode information by converting the same time address according to the request mode in the setting controller 1990. It is a good idea to refer to only the get address and execute LT.
  • LT is applied from the terminal T2 to the terminal T1:
  • ⁇ LT method in the form of ⁇ ⁇ »» method Will be explained.
  • step S101 the LT execution request that the frame generation ⁇ 2230 receives from the setting controller 790 includes the address information of the target device that executes the LT.
  • step S 102 the frame raw 2230 executes LT based on target address information.
  • the frame generator 2230 uses the target address information as a blur reference device 2220.
  • step S104 the table reference device 2220 refers to the MAC table 2000 of the forwarding table 1940 to search for the entry to which the first get address matches, and the corresponding output point 'I blue report Acquire and forward to frame transmitter 1160.
  • the mode information in the “1 normal mode / P mode switching mode is referred to as independent information in the first embodiment
  • the mode information has a target address in the present embodiment. As it is included in the information, only evening get address information is exchanged.
  • Fig. 13 relays the LT Request frame from the other node, and also changes the processing aspect of the control in the case of generating the LT Reply frame as follows.
  • step S 303 If it is determined in step S 303 that the target address is another node, the match address filter 1110 sends target address information to the table reference unit 2220 in step S 304.
  • step S 305 the table reference device 2220 refers to the AC table 2000 of the forwarding table 1940 to search for an entry to which the match information information matches, and acquires output port information corresponding to J3 ⁇ 4T.
  • the information in the normal mode / p-mode switching mode is superior to the information in the second embodiment. Because it is included in target address information, only target address information is exchanged.
  • FIG. 1 a MAC table 2000 of the age at which MAC address learning has been completed normally is shown in FIG.
  • VLA is X
  • the MAC address of the terminal T1 is Ox 00 00 4c 00 00 01
  • the MAC address of the terminal T 2 is Ox 00 00 4c 00 00 02
  • MAC # 0x 00 00 4c 00 00 01 & VLA # X and MAC # 0x 00 00 4c 00 00 02 & VLAN # X entries are stored.
  • the link between switch S2 and switch S3 occurs as shown in FIG.
  • ⁇ BPDU force is built according to the procedure of STP / RSTP.
  • the multicast address (bit 8) of the MAC address is 1 for the entry. It is deceived by the value of and remains as an entry.
  • the switch p of the switch S1 receives the topology message from the switch S2, and at that time, the MAC # 0x 00 00 4c 00 00 02 & VLAN # X loop learning on the port p 2 is performed. Instead of flushing the resource, rewrite the multicast bit from a value of 0 to a value of 1 and leave it as an entry of MAC # 0x 01 00 4c 00 00 02 & VLA #X.
  • switch S4 MAC # 0x 00 00 4c 00 00 01 & VLA # entry switch S5 MAC # 0x 00 00 4 0c 00 00 01 & VLA #X entry, switch S6 MAC # 0x 00 00 4c 00 00 01 & VLAN # X entry and MAC # 0x 00 00 4c 00 00 02 & VLA # X entry, switch S7 MAC # 0x 00 00 4c 00 00 01 & VLAN # X entry and MAC # 0x 00 00 4c 00 00 02 & VLAN # X
  • This is done for the entries of MAC # 0x 00 00 4c 00 00 01 & VLA #X and the entries of MAC # 0x 00 00 4c 00 00 02 & VLANtX of switch S8, both of which are the multicast bit 1, ie, Ox 01 00 4c It
  • FIG. 15 the setting state of the MAC table 2000 after frame transfer is opened in the network of FIG. 15 is shown in FIG.
  • Figure 24 for MAC address entries learned on the new topology, as MAC address entries, MAC # 0x 00 00 4c 00 00 01 & VLA #X, MAC # 0x 00 00 4c 00 00 02 & VLA #
  • the MAC table 2000 of each node is stored.
  • the source terminal T2 sends an LT Request frame ifT (initial value of ⁇ is set to 255).
  • the target address of the terminal T1 is Ox 01 00 4c 00 00 01 because of LT in the global switching mode.
  • the switch S5 which has received the LT Request frame from the terminal T2 reads out the entry of the MAC # 0x 01 00 4c 00 00 01 & VLAN # X of the terminal T1 which is the evening device from the MAC table 2000 of FIG.
  • Switch S4 which is the node at the next stage on the side of port p2 of switch S5 is the get-a-end device terminal T1 addressless MAC # 0x 01 00 4c 00 00 01 & VLA #X entry shown in Figure 4 4 MAC table It will start from 2000.
  • switch S4 gets port pi, and the Request frame has a TTL value of 1.
  • Switch S3 which is the next stage node on the port pi side of switch S4 is the target device terminal T1 address AC # 0x 01 00 4c 00 00 01 & VLA # X entry shown in Figure 24 MAC table 2000; ⁇ et al. ; ⁇ .
  • switch S5 when the address is sorted so that the TTL is in descending order, switch S5 ⁇ switch S4 ⁇ switch S3 is obtained. If the result of timer expiring is that ⁇ Reply frame is not received at terminal T2, this is the result of LT.
  • the current crane can be confirmed by performing LT from the terminal T2 to the terminal T1 in the normal mode with the terminal as the evening get device.
  • the target address of the terminal O is Ox 00 00 4c 00 00 01 because of LT in the normal mode.
  • the switch S5 that has received the LT Request frame receives the address of the terminal T1, which is a get-at device, MACtOx 00 00 4c 00 00 01 ⁇ ⁇ ⁇ 3 ⁇ 4 entry of VLANt from MAC table 2000 in Fig.24.
  • the MAC address multicast bit (upper 8 bits) has been used as a bit to distinguish between the normal mode and the P mode switching mode.
  • Similar to MAC-iiriMC leak can be obtained by assigning an arbitrary bit to mode conversion to be able to freely set the MAC address.
  • the MAC address of the terminal T1 which is the target device in the above example becomes MAC # 0x 00 00 4c 00 00 01 in the normal mode, and the P mode switch mode
  • MAC # 0x 80 00 4c 00 00 01 is obtained, so replacing the address in the failure switching mode in the above example with MAC # 0x 01 00 4c 00 00 01 to MAC # 0x 80 00 4c 00 00 01
  • the LT Request frame is sent to the point where the failure occurred.
  • the LT equest frame can be attached to ij up to the node in front, and the reply of the LT Reply frame at each node gives ( ⁇ ⁇ ⁇ ⁇ ⁇
  • FIG. 25 shows a detailed configuration of the frame switching unit 630 according to the third embodiment.
  • FIG. 25 with respect to the frame switching unit 630 of the second embodiment shown in FIG. 18,
  • the 0AM controller 1970 is changed to the 0AM controller 2670, the STP controller 1980 to the STP controller 2680, and the setting controller 1990 to the setting controller 2690.
  • the present embodiment will be described focusing on the difference from the second embodiment.
  • the STP controller 680 like the STP controller 780 and the SIP controller 1980, has a function to process STP RS1P according to IEEE 802. 1D / w / s etc.
  • the S1P controller 2680 does not flush the address to be flashed upon reception of a topology message as a characteristic process of the present invention, and does not flush the MAC address. It has a function to convert ⁇ one VLAN 2000 VLAN tag.
  • the STP controller 2680 reserves the originally assigned Priori ty value for the Priori ty value (3 bits) of the normal VLA tag to "010", which is reserved. The ability to # convert.
  • the Priori ty value of the entry learned in the MAC table 2000 is “000” in the case of default, and uses all Priori ty values in accordance with Priori ty in accordance with ⁇ 802 ⁇ 1 ⁇ . Yes: ⁇ , “000”, “001”, “011”, “100”, “101”, “110”, “111” are used.
  • the STP controller 2680 converts the Priori ty value of the VLAN tag into "010"
  • the Priori ty value is usually used to determine the mode / P mode switching mode.
  • the 0AM controller 2670 is a frame raw 2230 of the 0A controller 1970.
  • the table reference 2220 is changed to the table reference 2820.
  • the function of the 0AM controller 2670 is substantially similar to that of the 0M controller 1970. The difference is that the 0AM controller 1970 has the function to distinguish between the normal mode and the P mode switching mode with the multicast bit of the MAC address, whereas the 0AM controller 2670 does not make the distinction of the VLA tag. It is a point that has a function to be performed by the Priority value.
  • a raw frame ⁇ 2830 has a function of receiving only evening address information from the setting controller 2690 and generating an LT Request frame.
  • VLA tag Priority value of the uniform get address is a value of "010” indicates the normal mode, and performing LT according to the MAC address learning situation at that time, the current If the loss path can be confirmed, and the target address's VLA tag Priori ty value is "010", it indicates P mode switching mode, and LT is performed according to the MAC address learning status before failure switching. Can identify where it is located.
  • the table reference device 2820 refers to the MAC table 2000 of the forwarding table 1940 and outputs port information for target address information (mode information is included in the Priority field of the VLA tag) including mode information. Have the ability to obtain target address information (mode information is included in the Priority field of the VLA tag) including mode information. Have the ability to obtain target address information (mode information is included in the Priority field of the VLA tag) including mode information. Have the ability to obtain target address information (mode information is included in the Priority field of the VLA tag) including mode information. Have the ability to obtain
  • the setting controller 2670 notifies the 0AM controller 2670 of the same get address as the setting controller 1970, and the LT difficult mode of the LT execution request is the normal mode.
  • the LT execution mode of the LT execution request is the P control mode: ⁇ has a function of converting the VLA evening Priori ty value of the get address into “010” and notifying the 0AM controller 2670 .
  • MAC table 2000 of the age at which MAC address learning has been completed normally in four states is shown in FIG.
  • the priority value is set to “000” by default, the CFI value is set to 0, and the VID is set to 0000 0000 0001. Note that the description of ⁇ ) 100 8100 is omitted.
  • the entry of the port that received the topology change message is not flushed as in the prior art, and the Priority value of the VLAN tag is the original setting value for that entry. It is changed from 000 "to" 010 "and remains as an entry.
  • point p2 of switch S1 receives the topology message from switch S2, and at that time, flushes the entry of AC # t2 & VLAN # 0000 0000 0001 learned on port p2. Instead, rewrite the VLAN Priory value from "000" to "010" and leave it as an ACttt2 & VLA t0100 0000 0000 0001 entry.
  • MAC # tl & VLANt0000 0000 0000 0001 For the MAC address learned on the new topology, MAC # tl & VLANt0000 0000 0000 0001, MAC # t2 & VLAN # 0000 0000 0001 are usually stored in the MAC table 2000 of each node as MAC addresses.
  • the condition of the MAC table in Fig. 30 is as follows: In ⁇ , in the network in Fig. 15, LT was performed in the switching mode with terminal T2 to terminal T1 as a sunset device: about ⁇ It will be described below.
  • the source terminal T2 transmits an LT Request frame (the initial value of TTL is set to 255).
  • the target address of the terminal T1 is MAC # tl & VLA # 0100 0000 0000 0001 because of the LT in the P control switching mode.
  • the switch S5 Upon receiving the LT Request frame from the terminal T2, the switch S5 receives an entry of the address MAC # tl & VLA # 0100 0000 0000 0001 of the terminal T1, which is a get-in device, from the MAC table 2000 of FIG.
  • Switch S4 which is a node on the side of port p2 of switch S5, makes an entry of the address MAC # tl & VLA # 0100 0000 0000 0001 of the terminal T1, which is a target device, from the MAC table 2000 in FIG. .
  • the switch S4 obtains the port pi, and transmits a Request frame (TTL-253) with the TTL value subtracted by 1 to the port pi.
  • Switch S3 which is the next stage node on the port pi side of switch S4 is the target device terminal T1 address MAC # tl & VLAN # 0100 0000 0000 0001 Enter the entry in Figure 30 from MAC Tef 2000; ⁇ .
  • terminal S2 when sorting the address so that the TTL is in descending order, terminal S2 becomes switch S5 ⁇ switch S4 ⁇ switch S3. As a result of timer expiring, if no other Reply frame is received at terminal T2, this is the result of LT.
  • the terminal T2 can confirm the current path by performing LT in the normal mode using the terminal T1 as a get device.
  • the target address of the terminal T1 is MAC # tl & VLAN # 0000 0000 0001.
  • the switch S5 which has received the LT Request frame is a terminal that is an evening get device.
  • the address of Tl's dress MAC # tl & VLA # 0000 0000 0001 From the MAC tape 2000 of Figure 3 0; ⁇ .
  • the switch S5 when the addresses are sorted so that the TTL is in descending order, the switch S5 ⁇ the switch S6 ⁇ the switch S7 ⁇ the switch S8 ⁇ the switch S1 ⁇ the terminal T1.
  • the Reply frame is not received at the terminal T2
  • LT is implemented at P jurisdiction break at P jurisdiction occurrence, whether it is normal mode to check the current diversion path at LT request or P jurisdiction switching mode to select P jurisdiction.
  • Perform LT by using the target address as the address for normal mode or the address for switching the address mode.
  • the LT Request frame is transferred before the P chapter damage occurrence point.
  • the LT Requess frame can be attached to ij up to the node, and the reply of the LT Reply frame at each node makes it possible to mark the P jurisdiction.
  • FIG. 31 shows a detailed configuration of the framing portion 630 of the fourth embodiment.
  • the framing portion 630 of the second embodiment shown in FIG. 31 shows a detailed configuration of the framing portion 630 of the fourth embodiment.
  • the 0AM controller 1970 is a 0AM controller 3270
  • the speech controller 1990 is a setting controller 790 of the first embodiment.
  • the target address address according to the mode is the mode of the second embodiment and the mode of the second embodiment.
  • the function to perform the conversion is not performed by the setting controller 1990 as in the second embodiment, but by 0 AM ⁇ II control 3270 power *.
  • the setting controller 1990 has a function of performing address conversion on the target address of the LT request and passing it to the 0AM controller 1970.
  • the setting controller 1990 is the setting controller 790 of the first embodiment, has a function of passing the mode information of the LT execution request to the 0AM controller 3270, and the 0A controller 3270 stores the mode information. 1) "L" function to generate LT Request frame.
  • the 0AM controller 3270 will be described.
  • the configuration of the 0AM controller 3270 is similar to that of the 0AM controller 1970. As shown in FIG. 32, the table reference 2220 is changed to a table reference 3320, and the frame generator 2230 is the frame generator 1130 of the first embodiment, as shown in FIG.
  • the table reference device 220 performs forwarding based on target address information including the mode information received from the frame raw 2230 and the evening get address filter 1110.
  • the BHT had a function to obtain output port information for uniform get address information by referring to the MAC table 2000 of B 1940.
  • the table reference device 3320 when the table reference device 3320 receives the LT Get Request frame address information and mode information from the frame raw ⁇ 1130 or the target address filter 1110, it converts the address information according to the mode information. Then, based on the destination address information after conversion, it refers to the MAC table 2000 of the forwarding table 1940 to obtain the output port information corresponding to jiTf.
  • the method of changing target address information according to the mode information is the same as the method performed by the setting controller 1990; in the second embodiment.
  • the target MAC address wins as it is for ⁇ supply when the mode information is the normal mode.
  • the mode information is the local switching mode, convert the multicast bit (upper 8 bits) of the target MAC address from the value of 0 to the value of 1.
  • the forwarding table 1940's MAC table 2000 is such that the STP controller 1980 holds the MAC address of the normal mode and the MAC address of the failure switching mode, and the IP address reference 3320 has an address.
  • the MAC table 2000 of the focusing table 1940 based on the converted address, it is possible to obtain an output point corresponding to the mode.
  • the processing point of control of generating an LT Request frame from its own node in Fig. 11 is the ⁇ E point of step S 104.
  • the table reference unit 1120 refers to the MAC table 11 of the forwarding table 740, locks the entry whose match address and mode information match, acquires the corresponding output port information, and The tape reference 3320 translates the target address according to the mode information while referring to the MAC table 2000 of the feeding table 1940 based on the translated target address, while transferring to the transmitter 1160.
  • the output port ⁇ 'I Blueberry is acquired, and the frame transmitter 1160 is received. (Control to generate LT Reply frame while relaying LT Request frame from other node)
  • step S305 the change point of the control process in the case of generating the LT Reply frame is step S305. This is similar to the operation of step S104 described above.
  • step S 305 the table reference unit 1120 refers to the MAC table 800 of the forwarding table 740, and acquires the output port information corresponding to the JiTT key that matches the evening get address and mode information. And the information was sent to the frame transmitter 1160.
  • the table reference device 3320 converts the target address according to the mode information, acquires the output port information by referring to the MAC table 2000 of the forwarding table 1940 based on the converted evening address, Turn on the frame transmitter 1160.
  • the address modification method according to the mode information has been described by applying the method using the multicast bit of the MAC address of the first address address described in the second embodiment.
  • the method using the Priori bit of the VLA tag of the evening get address described in the third embodiment is also applicable.
  • the STP controller 1970 of FIG. 31 is changed to the STP controller 2670 of the third embodiment.
  • the address reference of the table reference 3320 in Fig. 3 does not convert the multicast bit according to the mode information, and the mode information is the normal mode.
  • the information is in the P mode switching mode: By converting the VLAN tag Priority value of the target address into “010”, the address conversion according to the mode ⁇ ⁇ ⁇ as in the explanation of this embodiment. It is possible to implement LT specific to the P jurisdiction when P jurisdiction occurs by not using the setting controller of the issue node of the LT Request frame but using the flooding controller of each node in the network.
  • LT Request frame is sent to reach the node before the failure occurrence point.
  • the Request frame can arrive at ij, and the reply of the LT Reply frame at each node is a special feature of the jurisdiction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

フレームスイッチング部630は、フレーム解析器700と、フレーム書換器710と、フレーム転送器720と、テーブルサーチ器730と、フォワーディングテーブル740と、MACラーニング器750と、制御フレーム振分け器760と、設定制御器790と、トポロジー変更メッセージ受信時に、LTフラグを0から1に変換することで、切替前のエントリであることを明示して、エントリをテーブルに残すSTP制御器780と、障害切替前のLT実施要求の場合は、フォワーディングテーブル740のエントリの中で、LTフラグが1となっているエントリの出力ポートにしたがってLTフレームを転送するOAM制御器770とを有する。

Description

明細書 フレーム転 MM確認方法、 ノード、 そのプログラム及びフレーム転逸経路確認システム 翻分野
本発明は、 通画におけるフレーム に関し、 特に、 フレームの におけるフレ
—ム転 確認方法、 ノード、 フレーム転 経路確認プログラム及びフレーム転 路確 認システムに関する。 背景擺
近年、 安価な企業向けデータサ一ビスとして、 魏 LAN (Local Area Network) で広く使用 されてきたイーサネット擴を広棚 (Wide Area Network ： WAN) に展開した広域イーサネ ット VPN (Virtual Private Network) サービス （広域イーサ） が注目されている。 WA では、 運用保守 (Operations, Administration and Maintenance： 0 機能が要求されるが、 徹 LAN で使用されてきたイーサネット翻にはもともと■機能が具備されておらず、 麵となつ ていた。 このような背景のもと、 近年いくつかの標 匕団体において、 イーサネット翻に おける 0M機能に関する標 2 f匕が進められている。
代表的な 0M機能の一つに、 ィンタ一ネットにおける 0A 機能の一つとして広く用いられ ている Trace- route機能がある。 Trace-route機能は、 あるターゲット装置までの経由する装 置情報を取得するのに用いられる。
特開 2 0 0 4— 1 4 7 2 2 3号 （特許文献 1 ) を一例とする ¾έ¾のタ一ゲット装置までの 経由する装置情報を取得する方法として、 図 3 3を用いて、 イーサネット 0 漏の標 匕 が進められている ITU- T Y. 17ethoamにおける Trace-route機能 (以降、 ITU-T Y. 17ethoamの呼 び方に習い、 Link Trace (LT)と記す)について、 説明する。 図 3 3では、 端末 T2が端末 T1 までの経由装置情報を調べるために、 LTを実施する場合について示している。 図 3 3のネ ットヮ一クは SIP (Spanning Tree Protocol ) /RSTP (Rapid Spanning Tree Protocol ) によ るトポロジー上での MAC (Media Access Control ) アドレス学習べ一スでのフレーム転送を 行う既存レイヤー 2 (L2) ネットワークである （既存スィッチ LS6と LS7の間のリンクがブ ロッキングリンクとなっている） 。 各既存スィツチ LS1〜LS8のポー卜に記している tlか t2 の文字は各ポ一トにおける MACァドレス学習状況を示している。 ITU- T Y. 17ethoamの標準の 方法では、 ターゲットの装置に対して、 TTL (Time To Live) 値を格納した Requestフレーム を送信し、 中継ノードとターゲット装置が TTL値を 1減算した Replyフレームを送信元に返 信することで、 送信元は Replyフレームの TTL値をもとに並べ替えを行い夕ーゲット装置ま での経由装置情報を取得できる。
端末 T が端末 T1までの経由装置' I青幸 gを調べるために、 LTを»する場 について具体的 に説明する。 送信元の端末 T2は、 LT Requestフレームを送信する（ここでは、 TTLの初期値 を 255とする)。 受信した中継ノードである既存スィッチ LS5では、 ターゲット装置である 端末 T1の MACァドレス =MAC#tlの学習済みポ一トに対し、 TTL値を 1減算した Requestフレ —ム (TTL=254)を転送すると共に、 ReQues t発行元装置に対して、 TTL値を格納した LT Reply フレームを返信する。 既存スィツチ LS5の次段の中継ノードである既存スィツチ LS4でも既 存スィツチ LS5と同様に、 夕一ゲット装置である端末 T1の MACァドレス =MAC#tlの学習済 みポートに対し、 TTL値を 1 した Requestフレーム (ΤΊΙ=253)を すると共に、 Request 発行元装置に対して、 T1L値を格納した LT Replyフレームを返信する。 以降の中継ノ一ド既 存スィッチ LS3、 LS2、 LSIも同様の動作を行う。 その後、 夕一ゲット装置である端末 T1に LT Requestフレームが到達すると、 端末 T1では、 自装置宛の LT Requestフレームを受信す ると、 LT Requestフレームを麵し、 Request発 fi¾装置に対して、 1腿した TTL値を格納 した LT Replyフレーム (ΉΙ=249)を返 る。 Request発 ίΐ¾置である端末 T2では、 中継ノ ―ドである既存スィッチ LS1〜LS5、 および、 夕一ゲットの端末 T1からの LT Replyフレーム を受 ifTると、 格納された TTL値に基づき Replyフレームの送信元を並べ替えることにより、 夕一ゲット装置までの経由装置情報を LS5→LS4→LS3→LS2→LS1→T1と取得できる。
特許 1 特開 2 0 0 4—1 4 7 2 2 3号公報 しかし、 上記において説明したように、 既存の LTでは、 通常時の転送経路を確認できる のに対して、 [！轄時の P轄箇所を特定できないという漏がある。
図 3 4を用いて、 本課題を説明する。 図 3 4でも図 3 3と同様に端末 T2 ( AC#t から端末 Tl ( AC#tl)への LTについて記している。 図 3 4 ( 1 ) は通常転送状態を示しており、 既存ス ィツチ LS6ZLS7の間のリンクがプロックリンクとなっている。 また、 端末 T1と端末 T2の 間のフレーム転送により、 各ノードでは MAC#tl、 MAC#t2が学習されている。 ここで端末 T2 から端末 Tlに対して LTを実施すると、 図 3 3で説明したように MAC#tlの学習済み経路に 沿って、 LS5→LS4→LS3→LS2→LS1— T1の経路で LTの結果が得られる。 ここで、 図 3 4
( 2 ) に示すように、 既存スィッチ LS2ZLS3の間のリンクで P轄が発生すると、 STP/RSTP ヵ稱構築され、 既存スィッチ LS6/LS7の間のリンクがアクティブなリンクとなる。 その後、 図 3 4 ( 3 ) に示すように、 STP/ S1Pの再構築の過程においてトポロジー変更メッセ一ジを 受信したポートにおける学習済みの MACァドレスェントリ（図中の O印のェントリ）がフラッ シュされる。 その後、 MC#tlと MAC#t2の間のフレーム転送が再開されると、 各ノードでは 図 3 4 (4) で示すように切體の経路上の各ポ一トで各 MACァドレスが 学習される (図 中の口印のエントリ）。 この結果、 端末 T2から端末 T1に対して LTを実 » "ると、 端末 Tl ( AC#tl)に関する新たな学習結果に基づき、 LS5→L S6→LS7→LS8-→LS1→T1の »が得られ る。 ここで得られた鍵は、 繊切纖の であり、 P轄靜万特定という目的を満た す転 路ではない。 p章害箇戸 if特定のためには、 切替前の経路上で障害 ®mの手前のノード までの Replyが帰ってくることカ塑まれる。 しかしながら、 通常のレイヤ 2ネットワークで は、 P轄発生後に新たな転 経路に切り替えられると、 切替前の ACアドレスエントリはフ ラッシュされ、 切謝麦の新たな^ S路上で学習された MACァドレスェントリにしたが'つて LTが行なわれるため、 切替前鹏上で LTを実施して、 P轄麵を特^ Tることができない。 本発明の目的は、 P轄が発生した:^に、 纖切纖の 定をすると共に、 纖切替 前の, 上で p轄発生箇所の手前のノードまでの露を特定し、 轄«の特定を可能にす るフレーム^ «確認方法、 ノード、 そのプログラム及びフレーム 確認システム を ίΐ^することである。 発明の開示
本発明のフレーム 確認、方法は、 送信元端末から送信されるデ一夕フレームを宛先 端末に^ iするネットワークのフレーム 路廳忍方法において、 ネットワーク構厳更 時に、 フォヮ一ディングテ一ブルにおいて出力先力鞭となるァドレスに対し識 (J情報を付 与して前記ァドレスを残し、 前記要求メッセージを前記識別情報を付与して残したァドレス に基づいて して経路確認することを特徴とする。
(作用） 上記 敷によって、 ネットワーク構 j« ^後において、 ネットワーク構 前のアドレ スに基づいて、 フォヮ一ディングテーブルにおいて出力先が となるァドレスに対して経 路確認できる。
本発明によれば、 P轄が発生した に、 露切替前の経路上で P轄発生麵の手前のノ ードまでの経路を特定し、 P轄箇所の特定が T能となる。
その理由は、 ネットワーク構 時に、 フォワーディングテ一ブルにおいて出力先が 更となるァドレスに対し ¾¾情報を付与してァドレスを残し、 要求メッセージを su情報を 付与して残したァドレスに基づいて ¾ιして経路確認するため、 ネットワーク構 後に おいて、 ネットワーク構 «更前のァドレスに基づレゝて、 フォヮーディングテーブルにおい て出力先が 更となるァドレスに対して経路確認できるからである。 図面の簡単な説明
図 1は、 本発明の第 1の実施の形態におけるネットワークモデル図である。
図 2は、 第 1の実施の形態におけるイーサネットフレームのフォーマツトである。
図 3は、 第 1の実施の形態におけるイーサネット謹フレームのフォーマットである。 図 4は、 第 1の実施の形態におけるスィツチの構成図である。
図 5は、 第 1の実施の形態におけるフレームスィツチング部の構成図である。
図 6は、 第 1の実施の形態におけるフォヮ一ディングテーブルの構成図である。
図 7は、 第 1の実施の形態における MACテーブルである。
図 8は、 第 1の実施の形態における VLA テーブルである。
図 9は、 第 1の実施の形態における 0AM制御器の構成図である。
図 1 0は、 第 1の実施の形態におけるスィッチのハードウェア構成を示すブロック図であ る。
図 1 1は、 第 1の実施の形態における 0AM制御器の LT Requestフレーム生成時の処理フ口 一である。
図 1 2は、 第 1の実施の形態における 0AM制御器の LT Replyフレーム受信時の処理フ口一 である。
図 1 3は、 第 1の実施の形態における 0AM制御器の LT Requestフレーム受信時の処理フ口 一である。 図 1 4は、 第 1の実施の形態における MACテーブルである。
図 1 5は、 第 1の実施の形態における障害発生時のネットワークモデル図である。
図 1 6は、 第 1の実施の形態における P轄発生直後の MACテーブルである。
図 1 7は、 第 1の実施の形態におけるフレーム転送が ¾開された後の MACテーブルである。 図 1 8は、 本発明の第 2の難の形態におけるフレームスイッチング部の構成図である。 図 1 9は、 第 2の実施の形態における MACテ一ブルである。
図 2 0は、 第 2の実施の形態におけるターゲットアドレスのァドレス変換例である。 図 2 1は、 第 2の実施の形態における 0AM制御器の構成図である。
図 2 2は、 第 2の実施の形態における MACテーブルである。
図 2 3は、 第 2の実施の形態における P轄発生直後の MACテーブルである。
図 2 4は、 第 2の実施の形態におけるフレーム転送が 開された後の ACテーブルである。 図 2 5は、 本発明の第 3の実施の形態におけるフレームスイッチング部の構成図である。 図 2 6は、 第 3の実施の形態における夕一ゲットアドレスのァドレス変換例である。 図 2 7は、 第 3の実施の形態における 0A 制御器の構成図である。
図 2 8は、 第 3の実施の形態における MACテーブルである。
図 2 9は、 第 3の実施の形態における障害発生直後の MACテーブルである。
図 3 0は、 第 3の実拖の形態におけるフレ一ム¾¾カ稱開された後の MACテ一ブルである。 図 3 1は、 本発明の第 4の魏の形態におけるフレームスイッチング部の構成図である。 図 3 2は、 第 4の実施の形態における 0AM制御器の構成図である。
図 3 3は、 舰のイーサネットにおける通常時の LT漏を説明する図である。
図 3 4は、 «のイーサネットにおける P轄発生時の LT蘭を説明する図である。
400：ィーサネットフレーム、 410：宛先 MACァドレス、 420：送信元 ACアドレス、 430、 3500： VLANタグ、 440、 510： Type, 450：ペイロード、 460： FCS、 500： 0A フレーム、 520： Opcode, 530： Transaction Identifier, 540： TTL、 550：夕一ゲットァドレス、 560： LTモード、 600：スィ ツチ、 601、 602、 603、 604 : IF、611、 612、 613、 614 :丽、 621、 622、 623、 624： MA 630：フレ —ムスィツチング部、 640：メモリ、 650： CPU, 660：コンソー Jレ I/O、 670： P轄 部、 700：フ レーム餅斤器、 710：フレーム書麵、 720：フレーム転送器、 730：テ一ブルサーチ器、 740、 1940：フォヮ一ディングテ一ブル、 750： MACラーニング器、 760：制御フレーム振分け器、 770、 1970、 2670、 3270： 0AM制御器、 780、 1980、 2680： STP制御器、 790、 1990、 2690：設定制御器、 800、 2000： MACテ一ブル、 810： VLANテープフレ、 820：テーブル読込制御部、 830：テ一ブル書込 み制御部、 1100： 0AMフレーム ®Sリフィルタ、 1110：ターゲットアドレスフィル夕、 1120、 2220、 2820, 3320：テープレ参照器、 1130、 2230、 2830：フレーム生 β、 1140： LT Replyフレーム解 析器、 1150： TTL
Figure imgf000008_0001
1160：フレーム送信器、 1 2 0 1 : C P U, 1 2 0 2 :主記憶部、 1 2 0 3 :通信制御部、 1 2 0 4 :入力部、 1 2 0 5：ィンタフエース咅 1 2 0 6 :補助記'慮 咅 1 2 0 7：システムハ'ス、 LS1、 LS2、 LS3、 LS4、 LS5、 LS6、 LS7、 LS8：既存スィッチ、 Tl、 T2 :端末、 tl、 t2、 lsl、 ls2、 ls3、 ls4、 ls5、 ls6、 ls7、 ls8、 sl、 s2、 s3、 s4、 s5、 s6、 s7、 s8 : MACアドレス、 Sl、 S2、 S3、 S4、 S5、 S6、 S7、 S8 :スィッチ、 pl、 p2、 p3 :ポート番号
発明を実施するための最良の形態
(第 1の実施の形態）
以下、 本発明の第 1の難の形態について、 図面を用いて詳細に説明する。 の形態 では、 で説明した ITU- Τ Y. Hethoamにおける LT をべ一スに本発明の機能を説 明するが、 例えばィンターネットにおける Trace- route機能をィーサネット技術に適用した LT技術等をベースに本発明の機能を適用することも可能である。
(第 1の実施の形態の構成）
図 1は、 本発明を適用する第 1の実施の形態の物理ネットワーク構成例を示している。 図 1のスィッチ S1〜S8は、 いずれも既存のイーサネット機能に加えて、 本発明による機 能を備えている。 各スィツチ間は以下のような 態となつている。
スィッチ S1のポート p2とスィッチ S2のポート pi
スィツチ S2のポー卜 p2とスィツチ S3のポート pi
スィツチ S3のポ一ト p2とスィツチ S4のポート pi
スィツチ S4のポー卜 p2とスィツチ S5のポ一ト p2
スィツチ S5のポート p3とスィツチ S6のポート p2
スィツチ S6のポート piとスィツチ S7のポ一ト p2
スィツチ S7のポート piとスィツチ S8のポート p2
スィツチ S8のポート piとスィツチ S1のポ一ト p3
また、 スィッチ S1と S5は以下のようにユーザ端末と接続している。
スィツチ S1のポート piとユーザ端末 T1 スィツチ S5のポート piとユーザ端末 T2
図 2、 図 3を用いて、 本実施の形態の形態によるフレームフォーマットについて説明する。 図 2はイーサネットフレーム 400のフォーマツ卜である。
イーサネットフレーム 400は、 宛先 MACアドレス 410、 送信元 MACアドレス 420、 VLANタグ 430、 Type440、 ペイロード 450、 FCS (Frame Check Sequence) 460から構成される。
また、 図 3は、 0AMフレームのフォーマットである。
0AMフレーム 500は、 ィーサネットフレーム 400に対して、 VLA タグ 430の後に、 Typeフ ィ一ルドが Type510に ¾gされ、 OpCode 520、 Transact ion Ident i f ier (TID) 530、 TTL 540、 ターゲットアドレス 550、 LTモード 560が揷入される。
なお、 図 2、 図 3に関しては、 VLMタグ 430が働 Πされない齢もあるが、 本明細書では、
VLA タグ 430が付加されていることを前提として説明する。
Type510には 0A 専用の Type値が、格納され、 OpCode 520には 0Mフレームの ¾8リ値が格納 され (本明細書では、 LT制御のみを文像とするが、 実際には の麵制御をサポートす るため、 0AMフレームの籠 をこのフィールドの値で定義する)、 Transaction Identi fier (TID) 530には讓制御の実施 IDが格納され、 TTL 540には TTL値が格納され、 ターゲット ァドレス 550には LTの夕ーゲット装置のァドレスが格納され、 LTモ一ド 560には LTを実 施する際の通常モードか障害切替モードかを示す値が格納される 01常モード、 障害切替モ ードの説明は碰する)。
なお、 ィ一サネッ卜 0AMに関する標^ f匕の中では、 上記 J^Mこ Vers i onフィールド (0AMの ノージョンを格細や ffi Levelフィールド (0AMの管理エンティティのレベル値を格|¾等の フィールドが定義されているが、 本明細書では、 LT制御に必要なフィールドのみを記載し て説明することとする。
次いで、 スィッチ S1〜S8の構 について、 図 4を用いて説明する。
図 4のスィッチ 600は PHY611、 612、 613、 614と MAC621、 622、 623、 624とフレームスイツ チング部 630とメモリ 640と CPU650とコンソール 1/0660と P轄 部 670から構成される。
IF60K 602、 603、 60 にはそれぞれ PHY61 612、 613、 614が、擦読され、 丽 611、 612、 613、 614には MAC621、 622、 623、 624が接続され、 MAC62 622、 623、 624にはフレームスィッチ ンク^咅! 5 630力接続される。 IF60 602、 603、 604から入力されるイーサネットフレームは、 それぞれ PHY611、 612、 613、 614と MAC621、 622、 623、 624を経由してフレームスイッチング部 630に入力され、 フ レームスィツチング部 630において ί¾する動作により適切な出力 IFが、決定され、 それぞ れ MAC621、 622、 623、 624と應 11、 612、 613、 614を経由して、 I醒、 602、 603、 604に出 力される。
服 611、 612、 613、 614は、 "る IF601、 602、 603、 604で P轄を糊した：^、 P轄情 報を P轄管理部 670に删する機能を有する。
P轄管理部 670は、 各 IFの状態 （正常 ZP章害） を管理しており、 PHY61K 612、 613、 614 から Pf¾情報を受信すると、 フレームスィツチング部 630か CPU650かその両方に I»発生 を通知する機能を有する。
また、 CPU650およびメモリ 640は、 フレームスィツチング部 630の動作を制御するプログ ラムおよび必要なデータを格納し、 フレームスィツチング咅 |5630に制御^を行う機能を有 する。
また、 コンソール 1/0660は、 装置内の各部に対する設定管理に関する外部インタフエ— スとなっている。
図 5は、 フレ一ムスィツチング部 630の詳細構成を示している。
フレームスイッチング部 630は、 フレーム解斤器 700、 フレーム書換器 710、 フレーム転 720、 テーブルサーチ器 730、 フォワーディングテーブル 740、 MACラーニンク'器 750、 制御フレーム振分け器 760、 0AM制 器 770、 SIP制御器 780、 設定制御器，とから構成され る。
フレームスィツチング部 630は、 前述のように、 MAC621〜624から入力されたイーサネッ トフレームの出力 IFを決定し、 所定の IFと¾ ~る MAC621〜624に ¾1する機能を; る。 以降では、 フレームスィツチング部 630の各部について説明する。
フレーム解斤器■は、 MAC621〜624から入力されたフレームを解斤し、 通常のイーサネ ットフレーム 400の主信号データフレームである場合は、 ヘッダ情報と入力ポー卜' I青幸をテ —ブルサ一^^ 730と MACラーニング器 750に する機能と、 フレーム全体またはペイ口 —ド部分をフレーム書 « 710に ¾iする機能とを有し、 また、 入力フレームが 0AMフレー ム 500または STP/RSTPの制御フレームである Bridge Protocol Data Uni t (以降、 BPDUと記 す） 等のその他の制御フレームである齢は、 フレーム全体を制御フレーム振分け器 760に する機能を有する。
フレーム角科斤器 700は、 0AMフレーム 500については Typeフィールド 510に 0Mフレーム 専用の Type値が格納されるため、 0A フレームであることを識別できる。
なお、 0AMフレーム 500には様々な種類のフレームが^ ftするが、 本発明では LTのみを対 象とし、 LT Requestフレームと LT Replyフレームのみ力 送されることとする。
フレーム * § 710は、 フレーム角科斤器 700から受信した主信号データフレームに対して、 テーブルサーチ器 730から指示があった：^に、 フレームの書き換えを行う機能を^ Tる。 フレ一ム書 710は、 フレームの書き換えを行う機能としてイーサネットフレーム 400に 対して VLA タグの挿入や削除を行い、 適宜 «5；理を行ったフレームをフレーム転送器 720 に転送する機能を る。
フレーム ¾ϋ器 720には、 フレーム書鶴 710から主信号データフレームが入力され 制 御フレーム振分け器 760から制御フレ一ムが入力される。
フレーム縫器 720は、 主信号データフレームに関しては、 フレーム * § Ή0から受信 する主信号データフレームをテーブルサーチ器 730から受信する出力ポートに対 ii fる 應621〜624に転送する機能を有し、 また、 制御フレームに関しては、 制御フレーム振分け 器 760から受信する制御フレームを同時に受信する出力ポートに対応する MAC621〜624に転 送する機能を^ Tる。
テーブルサーチ器 730は、 フレ一ム斛斤器 700から受信したへッダ情報と入力ポ一ト情報 を基にフォヮ一ディングテ一ブル 740を参照して出力ポート情報を取得する機能を る。 ここで、 出力ポート情報の取得方法を説明する前に、 フォワーディングテーブル 740の構 成について説明する。
図 6は、 フォヮーディングテ一ブル 740の構成例を示すプロック図である。
フォヮーディングテ一ブル 740は、 フレームを^!するための情報を格納した各種テ一ブ ルを る。 テーカレとしては、 MACアドレスと VLA タグから出力ポートを取得する Cテ —ブル 800と VLA タグに基づいて出力ポートを取得する VLA テ一ブル 810がある。
フォヮ一ディングテ一ブル 740は、 上記 MACテーブル 800及び VLA テ一ブル 810と、 テー カレ書込制御部 820と、 テ—ブル^ i制御部 830とから構成される。 上記各テーブルへの新たなデータの書込みはテーブル書込制御部 820を介して行われ、 上 記各テーブルからのデータの読み出しはテーブル 制御部 830を介して行われる。
MACテ一ブル 800と VLA テーブル 810の構成は、 それぞれ図 7、 図 8に示す通りであり、 MACテーブル 800では、 MACアドレスと VLAN (Virtual LAN) 夕グの組に対する出力ポ一トが 格納され、 LTフラグフィールドを備える。
LTフラグフィールドには、 そのェントリが通常状態のェントリである場合には 0の値が、 そのェントリが障害切替実施時の切替前のェントリである場合には 1の値が格納される。 また、 VLA テーブル 810では、 VLA タグに対する出力ポートが格納される。
MACテーブル 800は MACラーニング器 750によって: ^され、 LTフラグフィ一ルドの 0の 値から 1の値への書き換えは SIP制御器 780によって実施され また、 VLA テ一ブル 810は S1P制御器 780によって; gffされる。
VLA テーブル 810の VLA タグに文すする出力ポートは、 その VLANに関する STPのブロツキ ング 態でないポートが格納される。 なお、 テーブルの構成については、 図 7、 図 8に P腕 されるわけではない。
テ一ブルサ一チ器 730は、 上述したように、 このようなフォワーディングテーブル 740を 参照して、 フレーム解斤器 700から受信したフレームヘッダ情報に対する出力ポート情報を 取得する機能を^ る。
すなわち、 テーブルサーチ器 730は、 フォヮ一ディングテーブル 740の MACテーブル 800 を参照して、 フレーム角浙器 700から受信した MAC— DA (Direction Address) (送信先 MA Cアドレス) と VLANに対する出力ポートを取得する機能を有する。
より詳細には、 テ一ブルサーチ器 730は、 MACテーブル 800を参照して、 MAC_DAと VLA に 対して、 LTフラグフィールドの値が 0であるェントリが する場合、 対応するポ一ト情 報を取得し、 その後、 フレーム 器 720に出力ポート情報を通知する機能を有し、 一方、 MACテーブル 800に対 j¾Tるェントリが被しない: t には、 VLA テーカレ 810を参照して VLA に対する出力ポートを取得し、 その後、 フレーム 器 720に出力ポート情報を删す る機 を^ Tる。
MACラーニング器 750は、 フレーム麟斤器■からヘッダ情報を受信すると、 フォヮーデ ィングテ一フレ 740の MACテーブル 800を参照して、 受信したへッダ情報の MAC_SA (Source Address) (送信元 MACアドレス） と VLANに対する出力ポートを機し、 エントリが被 しない： ti ^は、 MACアドレスフィールドに MAC— SAを格納し、 VLA フィールドに VLA を格納 し、 出力ポートフィールドに受信ポートを格納し、 また、 LTフラグフィールドの値を 0に 設¾ ~る機能を有する。
制御フレーム振分け器 760は、 フレ一ム角晰器 700から受信した制御フレ一ムを所定の処 理器に転送すると共に、 処理器から受信した制御フレームおよび出力ポート情報をフレ一ム 転送器 720に転送する機能を る。
冓成では、 処理器は、 0AM制御器 770と STP制御器 780があり、 各々の制御フレームと しては、 0AMフレーム 500と BPDUがある。
制御フレーム振分け器 760は、 0AMフレーム 500をフレーム解斤器 700から受信すると、 受信した 0AMフレーム 500を 0AM制御器 770に ¾tし、 0AM制御器 770からの 0AMフレーム 500および出力ポ一ト情報をフレーム 器 720に転送する機能を有する。
なお、 0AMフレーム 500は、 前述のように、 LT Requestフレームと LT Replyフレームのみ を としている。
また、 制御フレーム振分け器 は、 BPDUをフレーム餅斤器■から受信すると、 受信し た BPDUを STP制御器 780に し、 STP制御器 780から受信した BPDUおよび出力ポ一ト情報 をフレーム転送器 720に転送する機能を有する。
0AM制御器 770は、 設定制御器 790からの LT実施要求に応じて LT Reques tフレームを生成 し、 フォヮ一ディングテーブル 740を参照して出力ポ一トを取得し、 制御フレーム振分け器 760に LT Reques tフレームを送信する機能を有する。 · また、 0A 制御器 770は、 他ノードからの LT Reques tフレームを制御フレーム振分け器
760から受信すると、 TTL値等の処理を行い、 フォヮーディングテーブル 740を参照して出 力ポートを取得し、 制御フレーム振分け器 760に LT Requestフレームを送 {ffる機能と、 送 信と同時に LT Replyフレームを生成し、 フォヮ一ディングテーブル 740を参照して出力ポ一 トを取得し、 制御フレ一ム振分け器 760に LT Replyフレームを送信する機能とを有する。 また、 0AM制御器 770は、 他ノードからの LT Replyフレームを制御フレーム振分け器 760 から受信すると、 フレーム送信元ァドレスと TTL値を保持し、 各々の LT Replyフレームの T1L値をソーティングすることにより、 LTの結果としての経由装置情報を取得する機能と、 その取得した結果を、 設定制御器 790に通知する機能とを有する。 以上に OM制御器 770の概要機能を説明したが、 以下に図 9を用いて 0 制御器 770の詳 細構成を説明する。
図 9は籠制御器 770の構成図である。 0AM制御器 770は、 0AMフレーム翻 Uフィル夕 1100 とターゲットアドレスフィ レタ moとテーブル参照器 1120とフレーム生成器 1130と LT Replyフレーム角钟斤器 1140と TTL ΜΜ^ 1150とフレーム送信器 1160とから構成される。
0ΑΜフレーム フィル夕 1100は、 制御フレーム振分け器 760から受信する 0AMフレーム の を 0 フレームの Opcode 520に基づいて判定し、 0A フレームの種別が LT Reques tフ レームである場合、 当該フレームをターゲットァドレスフィルタ 1110に送信し、 0AMフレー ムの種別が LT Replyフレームである場合、 当該フレームを LT Replyフレーム解斤器 1140に 送信する機能を有する。
LT Replyフレーム餅斤器 1140は、 0AMフレーム種別フィルタ 1100から LT Replyフレーム を受信すると、 LT Replyフレームの MAC— SAフィールド 420から LT Replyフレームの送信元 アドレスを取得し、 TTLフィールド 540から TTL値を取得する機能と、 Transact ion- IDが等 しい LT Replyフレームに関して、 送信元ァドレスと TTL値をリスト化し、 TTL値を降順にソ 一ティングする機能とを有する。
また、 LT Replyフレーム麟斤器 1140は、 フレーム生 1130からタイマエクスパイアの 通知を受けると、 ソーティングしたその時のリストを LTの結果とし、 設定制御器 790に対 して当該結果を通知する機能を有する。
なお、 結果のリストには、 LT Request発生装置からターゲット装置に向けて、 経由する装 置のァドレスが順番に格納される。
夕ーゲットアドレスフィル夕 1110は、 LT Requestフレームの夕ーゲットアドレスをター ゲットァドレスフィールド 550力、ら取得し、 夕一ゲットァドレスが他ノードである:^、 フレームをテーブル参照器 1120と TTL § 1150に送信し、 ターゲットァドレスが自ノ一 ドである驗、 TTL ^ 1150のみに送信する機能を有する。
TTL 1150は、 LT Requestフレームの TTL値を TTLフィ一ルド 540から取得し、 TTL値 を 1 し、 T1L値が 1 された LT Requestフレームをフレーム送信器 1160に送信する機 能と、 LT Requestフレームの送信元ァドレス (=LT Replyフレームの送信先ァドレス）と 1減 算した TTL値をフレーム生成器 1130に送信し、 LT Replyフレームの生成を指示する機能と を有する。 フレーム生 1130は、 設定制御器 790から LT実施要求を受信すると、 設定制御器 790 から受信したターゲットァドレス情報をターゲットァドレスフィールド 550に格納し、 通 常モード /P轄切替モードのいずれかのモード情報を LTモードフィールド 560に格納して LT Requestフレームを生成し、 生成した LT Requestフレ一ムをフレーム送信器 1160に送信 する機能を る。
ここで、 通常モードとは、 その時点での MACアドレス学習状況に従った LTであり、 現在 の転逸経路を確認できるモ一ドである。 一方、 P轄切替モードとは、 P轄切觀施前の MAC ァドレス学習状況に従つた LTであり、 障害箇所を特定できるモードである。
また、 フレーム生成器 1130は、 LT Requestフレームには、 Requestフレームに対する Reply フレームの対応付けを判別するための IDを Transact ion- IDフィールド （TID) 530に格納す る機能と、 格納と同時に夕一ゲットアドレス情報とモ一ド情報をテーブル参照器 1120に送 信する機能とを る。
また、 フレーム生成器 1130は、 111 ^^§ 1150から生成指示を受けると1^ 1^ フレー ムを生成する機能を有する。
ここで、 フレーム生 1130は、 ΤΊΙ MM^ 1150から生成指示を受けると、 LT Replyフ レームの送信先ァドレス' I青幸と TTL値、 Transaction-IDに基づいて LT Replyフレームを生成 し、 生成した LT Replyフレ一ムをフレーム送信器 1160に送信し、 生成した LT Replyフレ一 ムの送信と同時に送信先ァドレス情報をテーブル参照器 1120に送信する機能を有する。 テ一ブル参照器 1120は、 フレ一ム生 1130から LT Requestフレームの夕一ゲットアド レス' I青報とモ一ド情報を受信すると、 フォヮーディングテープレ 740の MACテ一ブル 800を 参照して、 対 j»る出力ポート情報を取得し、 その出力ポート情報をフレーム送信器 1160 に送信する機能を有する。
テーブル参照器 1120は、 ターゲットァドレスフィルタ 1110から LT Requestフレームを受 信している場合、 フレーム内から夕ーゲットアドレス情報とモード情報を抽出し、 フォヮ一 ディングテーブル 740の MACテーカレ ,を参照して、 対 iS "る出力ポ一ト情報を取得し、 その出力ポート情報をフレーム送信器 1160に送信する機能を有する。
また、 テ一ブル参照器 1120は、 フレーム生 1130から LT Replyフレームの送信先アド レス情報を受信すると、 フォヮ一ディングテーブル 740の MACテーブル 800を参照して、 対 応する出力ポート情報を取得し、 その出力ポート情報をフレーム送信器 1160に送信する機 肓を有-する。
フレーム送信器 1160は、 フレーム生 1130から受信した LT Requestフレーム、 または TTL § 1150から受信した LT Requestフレーム、 またはフレーム生成器 1130から受信し た LT Replyフレームとテーブル参照器 1120から受信した対応する出力ポ一ト情報をペアに して、 制御フレーム振分け器 760に転送する機能を る。
さらに、 フレーム送信器 1160は、 送信した LT Requestフレームの有効期限を計測するた めに、 その LT Requestフレームの Transact ion IDに関して X秒間 (例えば 5秒間)有効なタイ マを起動し、 夕イマがエクスパイアしたら、 LT Replyフレーム 器 1140に通知する機能 を有する。
STP制御器 780は、 制御フレーム振分け器 760から受信した BPDUに基づいて STP/ftSlPのポ ート情報の M f処理などを行い、 BPDUを再作成し、 隣接のスィッチに すべく、 BPDUと 出力ポート情報を制御フレーム振分け器 760に転送する機能を有する。
上記ポート情報の Mff処理や BPDUの再作«理は、 IEEE802. ID/w/s等に従うため、 ここで は詳細な記述は省略する。
通常の STP/ STPの動作に従うと、 障害発生時に SIP/RSTPを再構築する«の過程におい て、 トポロジー変更メッセージを受信した場合、 そのメッセージを受信したポートにおいて 学習済みである MACアドレスエントリをフラッシュする。 これに対して、 本発明では、 トポ 口ジ一麵メッセージ受信時にフラッシュすべきァドレスに対して、 フラッシュせずに、 MACテーブル 800の LTフラグフィールドの値を 0から 1に^ fする。 この処理により、 » 観と同様に通常の MACァドレスェントリ (LTフラグフィ一ルド =0)と共に、 P轄切難施時 の切替前の MACァドレスェントリ（LTフラグフィ一ルド =1)を保持することができる。
設定制御器 790は、 図 4のコンソール 1/0660経由で入力された設定情報を、 CPU650を介 して受信し、 適切な処理器に対し設定処理を行う機能を ¾ る。
具体的には、 設定制御器 790は、 コンソール I/O経由で入力された LT実施要求を受信す ると、 0Μ制御器 770に対して LTの実施をキ する (LT Requestメッセージの生成を指示す る)機能を る。 この機能は、 ここでは、 ターゲット装置のアドレスおよぴ適常時 LTか障 害切替前 LTのいずれかのモード情報を 0A 制御器 770に渡す機能である。 また、 設定制御 器 790は、 LT制御が完了すると、 0M制御器 770によって実施された LTの結果を受信し、 受 信した LTの結果を CPU650を介してコンソール I/O経由で出力する機能を有する。
また、 設定制御器 790は、 0AM制御器 770や STP制御器 780に対して、 パラメ一夕設定も 行う機能を る。
ここで、 スィッチ S1〜S8の八一ドウエア構成の説明をする。
図 10は、 本実施の形態による物理ネットワーク上のスィツチ S1〜S8のノ、一ドウエア構 成を示すブロック図である。
図 10を参照すると、 本発明によるスィツチ S1〜S8は、 ~«的なコンピュータ装置と同 様のハードゥエァネ冓成によって難すること力 き、 CPU (Cen t r a l P r oc e s s i ng Un i t) 1201 (図 4、 CPU 650) 、 RAM (Random Ac c e s s Memo ry) 等のメインメモリであり、 データの作業領域ゃデ一夕の一時退應域 に用いられる主記憶部 1202、 ネットワークを介してデ一夕の送受信を行う通信制御部 1 203 (図 4、 I F601〜I F604、 PHY61 1〜ΡΗΥ614) 、 キーボードやマウス等 の入力部 1204 (図 4、 コンソール 1/0660) 、 周辺 βと «してデータの送受信を行う インタフェース咅 151205、 ROM (Re ad On l y Memo r y) 、 磁気ディスク、 半 ¾ (本メモリ等の不揮発性メモリから構成される八一ドディスク装置である補助記慮部 12 06 (図 4、 メモリ 640) 、 本情幸隨理装置の上記各構成要素を相互に るシステム ノス 1207等を備えている。
本発明によるスィッチ S1〜S8は、 その動作を、 スィッチ S1〜S8内部にそのような機能を 実現するプログラムを組み込んだ、 LS I (La r ge S c a l e I n t e g r a t i o n) 等のハードウエア部品からなる回路部品を難してハードウエア的に難することは 勿論として、 上記した各ネ冓 素の各機能を提供するプログラムを、 コンピュータ処理装置 上の CPU1201で実行することにより、 ソフトウェア的に^ ¾することができる。 すなわち、 CPU1201は、 補助記憶部 1206に格納されているプログラムを、 主記 隱部 1202に口一ドして実行し、 スィツチ S1〜S8の動作を制御することにより、 上述し 各機能をソフトウエア的に実現する。
(第 1の実施の形態の動作）
以上説明した構成を有するスィツチ S1〜S8からなる図 1のネットワークにおいて、 端末 から端末 T1に対して LTを実施する ¾^について、 本実施の形 の LT実施方法について 説明する。 Φ ^の形態の方法を用いると、 ターゲット装置までの^ ^路を確認すると共 に、 術では不可能であった^切■の ^箇所特定が 能となる。
(0ΑΜ制御器 770における処理フロー）
上記において 0AM制御器 770の概要機能及び詳細構成を説明したが、 以下に図 1 1〜図 1 3を用いて 0AM制御器 770の詳細動作を説明する。
0AM制御器 770は、 LTの制御に関して、 自ノードから LT Reques tフレームを発生する：^ の制御と、 自ノードで LT Replyフレ一ムを終端する場合の制御と、 他ノードからの LT Request フレームを中継すると共に、 LT Replyフレームを生成する場 の制御と力 ffiする。 各々の制御について、 処理フローを用いて説明する。
(自ノ一ドから LT Requestフレームを発生させる: ^の制御）
図 1 1は、 自ノ一ドから LT Requestフレームを発生させる： 1^·の制御の処理フ口一を示 している。
ステップ S 101において、 フレーム生 1130は、 I/Oコンソ一リ US由で、 設定制御器 790より LT実施要求を受信する。 設定制御器 790からの LT実施要求には、 LTを実 る夕 —ゲット装置のァドレス情報、 および、 通常モード /P轄切替モードのモード情報が含まれ る。
ここで、 上述したように、 通常モードとは、 その時点での アドレス学習状況に従った
LTであり、 現在の転藤路を確認できるモードであり、 また、 I»切替モードとは、 mm 切 »施前の ACァドレス学習状況に従つた LTであり、 障害箇所を特定できるモードであ る。
フレーム生成器 1130は、 ステップ S 102において、 ターゲットァドレス情報とモード情報 に基づき、 LT Requestフレームを生成し、 生成した LT Requestフレームをフレーム送信器 謂に転送する。
また、 フレーム生 1130は、 ステップ S 103において、 ターゲットアドレス情報とモ一 ド情報をテーブル参照器 1120に転送する。
その後、 ステップ S 104において、 テーブル参照器 1120は、 フォワーディングテーブル 740の MACテ一カレ 800を参照して、 夕一ゲットアドレスとモード情報が適合するェントリ を; ^し、 該当する出力ポート情報を取得し、 フレーム送信器 1160に ¾1する。 フレーム送信器 1160は、 ステップ S 105において、 ステップ S 102で送信された LT Requestフレームと、 ステップ S 104で送信された出力ポート情報をペアにして、 制御フレ ーム振分け器 760に転送すると共に、 送信した LT Requestフレームの有効期間を計測するた めの夕イマを起動する。 以上により、 LT Requestフレームの生成処理は完了する。
(自ノードで LT Replyフレームを終端する場合の制御）
次いで、 自ノ一ドで LT Replyフレームを終端する場合の制御について、 図 1 2を用いて 説明する。
0A フレーム觀リフィルタ 1100は、 ステツプ S 201において、 制御フレーム振分け器 760 より LT Replyフレームを受信すると、 ステツプ S 202において、 受信フレームを LT Replyフ レームと判別し、 LT Replyフレーム角 II斤器 1140に する。
ステップ S 203において、 LT Replyフレーム餅斤器 1140は、 受信した LT Replyフレームの MAC_SAから LT Replyフレームの送信元装置、 すなわち、 LTしている夕一ゲッ卜装置までの 中途に位置する装置のァドレスを取得する。 同時に、 LT Replyフレームに格納される ΤΊΙ値 を抽出する。 そして、 同一の Transaction- IDの LT Replyフレームに関して、 アドレス情報と TTL値をリスト化し、 TTL値に基づいて降順にソートする。
一方、 図 1 1のステップ S 105で起動したタイマがエクスパイアしたら、 ステップ S 204 において、 フレーム送信器 1160は、 LT Replyフレーム餅斤器 1140に対し、 該当する Transaction - IDに関するタイマエクスノ ァを通知する。 これにより、 LT Replyフレーム解 析器 1140は、 ソートされたその時点でのリストを LTの結果とする。
そして、 ステップ S 205において、 LT Replyフレーム應器 1160は、 当 結果のリストを 設定制御器 790に通知する。 以上により、 LT Replyフレームを終端する齢の処理は完了す る。
(他ノードからの LT Requestフレームを中継すると共に、 LT Replyフレームを生成する の制御）
他ノ一ドからの LT Requestフレームを中継すると共に、 LT Replyフレームを生成する場合 の制御について、 図 1 3を用いて説明する。
0AMフレーム觀 Uフィルタ 1100は、 ステツプ S 301において、 制御フレーム振分け器 760 より LT Requestフレームを受信すると、 ステツプ S 302において、 受信フレームを LT Requestフレームと判別し、 ターゲットアドレスフィル夕 1110に する。 ターゲットアドレスフィルタ 1110は、 ステップ S 303において、 LT Requestフレームの夕 ーゲットアドレスが自ノ―ドか、 他ノ一ドかを判 ¾Tる。
その結果、 ターゲットアドレスが他ノードである場合、 タ一ゲットアドレスフィルタ 1110は、 ステップ S 304において、 ターゲットァドレス情報とモード情報をテ一力渗照器 1120に転送する。
その後、 ステップ S 305において、 テーブル参照器 1120は、 フォワーディングテーブル 740の MACテーブル 800を参照して、 夕一ゲットアドレスとモード情報が適合するェントリ を鍵し、 対 J»る出力ポート情報を取得する。 出力ポート情報を取得すると、 テ一ブル参 照器 1120は、 その情報をフレーム送信器 1160に転送する。
また、 ステップ S 303においてターゲットアドレスが他ノードである場合、 ターゲットァ ドレスフィルタ 1110は、 ステップ S 306において、 LT Requestフレームを m' ^器 1150に 車 Κΐ¾ 9_る。
TTL ^§ 1150は、 ステップ S 307において、 LT Requestフレームの TIL値を 1禱し、 LT Requestフレームをフレーム送信器 1160に する。
フレーム送信器 1160は、 ステップ S 308において、 ステップ S 305で受信した出力ポート 情報とステップ S 307で受信した LT Requestフレームを制御フレーム振分け器 760に^ ¾す る。 以上でば Requestフレームの中継繊処理は完了する。
一方、 ステップ S 303における判定の結果、 ターゲットアドレスが自ノードである場合、 ステップ S 309において、 夕ーゲットァドレスフィルタ 1110は、 LT Requestフレームを TTL ^§1 1150に する。
TTL ^ 1150は、 ステップ S 310において、 LT Requestフレームの ΊΊΙ値を 1 し、 LT Requestフレームをフレーム送信器 1160〖こ する。
さらに、 ステップ S 311以降で、 LT Replyフレームの生 理が行なわれる。
ステップ S 311において、 TTL ^§ 1150は、 フレーム生 1130に対して、 LT Request フレームの発信元アドレスと TTL値を通知し、 LT Replyフレームの生成を指示する。
フレ一ム生 1130は、 ステツプ S 312において、 発信元ァドレス情報と m値に基づい て LT Replyフレームを生成し、 フレーム送信器 1160に転送する。
また、 フレーム生 β 1130は、 ステップ S 313において、 先ァドレス (LT Requestフ レームの発信元ァドレス）をテーブル参照器 1120に する。 テーブル参照器 1120は、 ステップ S 314においてフォヮ一ディングテ一ブル 740の MACテ —ブル 800を参照して、 先アドレスに対する出力ポート情報を取得し、 取得した出力ポ 一ト情報をフレーム送信器 1160に転送する。
フレーム送信器 1160は、 ステップ S 3 において、 ステップ S 312で受信した LT Replyフ レームとステップ S 314で受信した出力ポート情報を制御フレーム振分け器 760に転送する。 以上により、 他ノードからの LT Requestフレームを中継すると共に、 LT Replyフレームを 生成する場合の処理は完了する。
次いで、 本発明を用いた: ^の MACテーブル 800の設定例について説明する。
図 1のネッ卜ワークにおいて、 通常状態で MACァドレスラーニングが完了している場合の MACテ一ブル 800を図 1 4に示す。
ここで、 VLA は Xとし、 スィッチ S1〜S8において、 MAC#tl &VLAN#Xと MAC#t2&VLM#Xのェ ントリが格納されている。 各エントリでは、 LTフラグ〖雄常モードであるため、 0の値が設 定されている。
ここで、 図 1のネットワークにおいて、 図 1 5に示すようにスィッチ S2とスィッチ S3の 間のリンクに P轄が発生したとする。 このような齢、 S1P RS1 の手順に従って、 BPDUが が 構築される。
この過程における MACテーブル 800の設定状 IIを図 1 6に示した。
図 1 6では、 P ^を検知したスィツチ S2のポ一ト p2とスィツチ S3のポ一ト piのェント リがフラッシュされる。
また、 本発明の特徴として、 トポロジー メッセージを受信したポートのエントリが従 のようにフラッシュされるのではなく、 そのェントリについては LTフラグが 1に変 更され、 エントリとしては残される。
一例を説明すると、 スィツチ S1のポート p2ではスィツチ S2からのトポロジー変更メッ セージを受信し、 その際、 ポート p2で学習している MAC#t2&VLA #Xのエントリをフラッシ ュするのではなく、 LTフラグを 0から 1に書き換えて、 エントリは残す。
同様の処理は、 スィツチ S4の MAC# 11 &VLAN# のエントリ、 スィッチ S5の MAC# 11 &VLAN#X のエントリ、 スィッチ S6の MAC#tl &VLA #Xのエントリと MAC#t2&VLA #Xのエントリ、 スィ ツチ S7の MAC#t 1 &VLA #Xのエントリと MAC#t2&VLA #Xのエントリ、 スィッチ S8の C#tl & W
VLANtXのェントリと MAC#t2&VLA #Xのェントリについて行なわれており、 いずれも LTフラ グ =1のェントリとして残っている。
図 1 5のネットワークでフレーム転送カ稱開された後の MACテーブル 800の設定 態を図 1 7に示した。
新たなトポロジー上で学習された MACアドレスエントリに関しては、 LTフラグ =0として、 各ノードの MACテーブル 800に格納される。
ここで、 各エントリは LTフラグも含めて管理されており、 例えば、 スィッチ S1の MACテ 一ブル 800において、 MAC#t2&VLA #Xは 2エントリ;^ る力 もともとあったエントリは LTフラグ =1であり、 その後学習したエントリは LTフラグ =0として、 別エントリとしてテ 一ブルに格納される。
(P轄箇所の特定処理）
このような図 1 7の MACテ一ブルの扰態である:^に、 図 1 5のネットワークにおいて、 端末 T2から端末 T1をターゲット装置とした »切替モードにおける LTが実施された について以下に説明する。
送信元の端末 T2は、 LT Requestフレームを送信する (TTLの初期値を 255とする)。
端末 T2から LT Requestフレームを受信したスィツチ S5は、 夕ーゲット装置である端末 T1 のァドレス MAC#tl &VLA #Xでかつ障害切替モードである LTフラグ =1のェントリを図 1 7 の MACテーブル 800から^^する。
スィツチ S5は、 その結果、 ポート p2を取得し、 TTL値を 1體した Requestフレーム (TTL=254)をポー卜 p2に対して転送する。
また、 スィッチ S5は、 Request発 f¾¾装置である端末 T2に対して、 ΉΙ値 =254を格納した LT Replyフレームを返信する。
スィツチ S5のポート p2側の次段のノードであるスィツチ S4は、 夕ーゲット装置である 端末 T1のァドレス MAC#tl &VLA #Xでかつ轄切替モードである LTフラグ =1のェントリを 図 1 7の MACテーブル 800から^^する。
その結果、 スィッチ S4は、 ポート piを取得し、 ΤΊΙ値を Ι ^した Requestフレーム (TTL=253)をポー卜 piに対して ¾ する。
また、 スィッチ S4は、 Request発^¾装置である端末 T2に対して、 ΤΊΙ値 =253を格納した LT Replyフレームを返信する。 スィツチ S4のポート pi側の次段のノードであるスィツチ S3は、 ターゲット装置である 端末 T1のァドレス C#tl&VLAN#Xでかつ障害切替モードである LTフラグ =1のェントリを 図 1 7の MACテーブル 800から^^する。
その結果、 該当するエントリか存 しないため、 スィッチ S3は、 LT Requestフレームを i¾¾し、 Request発 装置である端末 T2に対して、 TTI値を 1 した LT Replyフレーム (TTL値 =252)を返信する。
一方、 LT Requestフレームの発 f¾装置である端末 T2を見てみると、 スィツチ S5からの LT Replyフレーム (TTL=254)、 スィッチ S4からの LT Replyフレーム (ΉΙ=253)、 スィッチ S3か らの LT Replyフレーム (TTL-252)を受信している。
端末 T2では、 これを ΤΊΙを降順になるよう、 アドレスをソートすると、 スィッチ S5→ イッチ S4→スィッチ S3となる。 タイマエクスパイアした結果、 それ の Replyフレーム が端末 T2で受信されないと、 これが LTの結果となる。
この結果には、 ターゲット装置である端末 T1が含まれないため、 端末 T1までの間で P轄 が起こったことが分かり、 Replyフレームのソ一ト結果により、 スィツチ S3までは生き残つ ており、 その先で何らかの が発生したことが ¾認できる。
このように、 本実施の形態の方法を用いると、 P章害発生時に P轄切替を行なった後に LT を実施したとしても、 切替前の経路上で LTを実 ίΤΤることが^ I能であり、 Ρ轄箇所を特定 することができる。
(現在の 経路の確認処理）
当然のことなが、ら、 現在の^ を確認することも可能である。 図 1 5のネットワーク において、 端末 Τ2から端末 T1をタ一ゲット装置とした通常モードにおける LTを行うと、 現在の転避路を確認できる。
送信元の端末 Τ2は、 LT Requestフレームを送信すると (TTLの初期値を 255とする)、 LT Requestフレームを受信したスィツチ S5は、 夕ーゲット装置である端末 T1のァドレス MAC#tl&VLA #Xでかつ通常モードである LTフラグ =0のェントリを図 1 7の MACテーブル 800から;^する。
スィツチ S5は、 その結果、 ポ一ト p3を取得し、 TTL値を 1腿した Requestフレーム (TTL=254)をポー卜 P3に対して する。 また、 スィッチ S5は、 Request発 ^装置である端末 T2に対して、 ΠΙ値 =254を格納した LT Replyフレームを返信する。
スィツチ S5のポート p3側の次段のノードであるスィツチ S6は、 夕一ゲット装置である 端末 T1のァドレス C#tl&VLAN#Xでかつ通常モ一ドである LTフラグ =0のェントリを^ ¾ すると、 ポート piが得られるため、 TTL値を 1減算した Requestフレーム (TTL 53)をポート Piに対して転送する。
また、 スィッチ S6は、 Request発 f¾装置である端末 T2に対して、 TTL値 =253を格納した LT Replyフレームを返信する。
同様に、 各スィッチで、 MAC# 11 c&VLA #X&LTフラグ #0のエントリを して、 Reques tフ レーム転送処理、 Replyフレーム生成処理を繰り返すことにより、 スィッチ S7(TIL=252)、 ス イッチ S8(TTL=251)、 スィッチ S1 (TTL=250)、 端末 T1 (ΉΙ=249)からの LT Replyフレームが端末 T2に到着する。
端末 T2では、 TTLを降 j噴になるよう、 アドレスをソートすると、 スィッチ S5→スィッチ S6→スィッチ S7→スィッチ S8→スィッチ Sl→端末 T1となる。 タイマェクスノ、°ィァした結果、 そ の Replyフレームが端末 T2で受信されないと、 これが LTの結果となり、 ターゲッ ト装置である端末 T1までの 路上の装置を確認できる。
(第 1の実施の形 ϋの 果）
以上説明したように、 本実施の开多^の方法を用いると、 ρ ^発生時に ^切替を行った場 合に、 切替前の MACアドレスエントリをフラッシュするのではなく、 切替前のエントリであ ることを示すフラグを ¾ロすることにより、 障害切替後にも切替前の Cアドレスエントリ を麟する。
そして、 P轄発生時の 切纖に LTを実 »る場合、 LT要求時に現在の ¾¾柽路を確 認する通常モードか、 Ρ轄箇所を特 るための IW切替モードかを指 ¾Τることで、 Ρ轄 切替モードを指定した； t給には、 MACテ一ブルにおいて、 切替前の MACアドレスエントリに したがつて、 LT Reques tフレームを することにより、 障害発生箇所の手前のノードまで LT Reques tフレームが ij着することができ、 各ノ一ドでの LT Replyフレームの返信により、 P«簡所を特^ることが T能である。
(第 2の実施の形態） 本発明の他の実施の形態について、 図面を用いて詳細に説明する。
(第 2の実施の形態の構成）
図 1 8は、 第 2の実施の形態のフレームスィツチング部 630の詳細構成を示している。 図 1 8では、 図 5で示した第 1の難の形態のフレ一ムスィツチング部 630に対して、 フ ォヮーディングテーブル 740がフォヮーディングテ一ブル 1940に、 0AM制御器 770が 0AM制 御器 1970に、 S1P制御器 780が S1P制御器 1980に、 設定制御器 790が設定制御器 1990に変 更されている。 以降では、 第 1の実施の形態との を中心に第 2の実施の形態の説明する。 まず、 フォヮ一ディングテーブル 1940について説明する。
フォヮーディングテーブル 1940は、 フォヮ一ディングテ一ブル 740に対して、 MACテープ ル 800が図 1 9に示す MACテーブル 2000に颜されている。 すなわち、 MACテーブル 2000は、 MACテーブル 800で導入された LTフラグフィールドが削除されており、 LTフラグフィール ドによって行っていた通常モード /^切替モ一ドの判別を、 本実施の形態では後ほど説明 する S1P制御器 1980が MACテーブル 2000の MACアドレスを一部変換することによって、 通 常モード /IW切替モードを判別することとなる。
続いて、 STP制御器 1980について説明する。
SIP制御器 1980は、 SIP制御器 780と同様に、 IEEE802. lD/w/s等に従った STP RSTPの処理 を行う。
STP制御器 780は、 通常の STP/RSTPの処理に加えて、 本発明の特徴的な処理として、 トポ ロジー変更メッセージ受信時にフラッシュすべきァドレスに対して、 フラッシュせずに、 MACテーブル 800の LTフラグフィールドの値を 0から 1に 5 ^する機能を有していた。
これに対して、 本難の形態の S1P制御器 1980は、 トポロジー変更メッセージ受信時に フラッシュすべきァドレスに対して、 フラッシュせずに、 MACテーブル 2000の MACアドレス を^^変換する機能を る。
具体的には、 S1P制御器 1980は、 図 2 0に示すように、 通常の MACアドレスにおいて、 マ ルチキャス卜ビットとして定義されている 8ビッ卜目のビッ卜を 1の値に変換する機能を有 する。
通常状態において MACテーブル 2000で学習されている MACァドレスはュニキヤストアド レスであり、 マルチキャストビットは 0の値であることから、 このビットを通常モード /障 害切替モードの判別に利用する。 また、 マルチキャスト MACアドレスを持ったフレームは MACテ一ブル 2000ではなくマル チキャスト用の別テ一ブルを参照するため、 MACテーブル 2000のェントリのマルチキャスト ビットを変換しても、 フレームの転 理において誤動作が生じることもない。
本実施の形態は、 この STP制御器 1980の機能により、 と同様に通常の MACアド レスェントリ (マルチキャストビット =0)を保持すると共に、 P轄切觀施時の切替前の MAC ァドレスェントリ（マルチキャストビット =1)を保持すること力 きる。
•続いて、 0AM制御器 1970について説明する。
0A 制御器 1970の¾^冓成は、 0AM制御器 770と同様である。 差分は、 図 2 1に示すよう に、 テーブル参照器 1120がテ一カレ参照器 220に、 フレーム生 β 1130がフレーム生藏 2230〖こ変更されている点である。
機能の差分は以下の通りである。
フレーム生 1130は、 設定制御器 790から LT実施要求を受信すると、 設定制御器 790 から受信した夕一ゲットアドレス情報、 通常モード /^切替モードのいずれかのモード情 報を元に LT Requestフレームを生成していた。
これに対して、 本実施の形態では、 通常モード/ P韓切替モードのモードの区別は MACァ ドレスのマルチキャストビットで判別される。
そのため、 フレーム生職 2230は、 設定制御器 1990からはターゲットアドレス情報のみ を受信し、 LT Requestフレームを生^ Tる機能を る。
つまり、 本実施の形 では、 LT Requestフレームには、 通常モード/^切替モードのモ ―ド情報を格納する LTモードフィ一ルド 560はなく、 ターゲットアドレス自体にその情報 力 まれる。
ターゲットアドレスのマルチキャストビットが 0の値である は、 通常モードを示して おり、 その啤点での MACァドレス学習状況に従つた LTを行うことで、 現在の 経路を確 認できる。
一方、 ターゲットアドレスのマルチキャストビットが 1の値である;^は、 P轄切替モー ドを示しており、 （！轄切替実施前の MACアドレス学習状況に従った LTを行うことで、 mm 箇所を特定できる。
テーブル参照器 1120は、 フレーム生成器 1130から LT Requestフレームの夕一ゲットアド レス情報とモ一ド情報を受信すると、 フォヮーディングテーブル 740の MACテーブル 800を 参照して、 夕一ゲットアドレス情報 &モ一ド情報に対応する出力ポート情報を取得する機能 を有していた。
これに対して、 テーブル参照器 2220は、 フォヮーディングテ一ブル 1940の MACテ一ブル 2000を参照して、 モード情報を含んでいるターゲットアドレス情報に対する出力ポート情 報を取得する機能を有する。
最後に、 設定制御器 1990について説明する。
設定制御器 1990は、 設定制御器 790の機能に対して、 コンソール I/O経由で入力された LT実施要求を 0AM制御器 770に通知する機能が 更される。
具体的には、 設定制御器 790は 0AM制御器 770に対して LT¾1¾求を通知する際、 夕一ゲ ット装置のァドレスおょぴ通常モードか障害切替モードのいずれかの情報を? 能を有し ていた。
これに対して、 設定制御器 1990は、 LT鎌要求の LT難モードが通常モードである:^、 そのままのターゲットアドレスを 0 制御器 1970に通知する機能を有し、 LT実施要求の LT 実施モードが Pt^切替モードである 、 ターゲットアドレスのマルチキャストビット (8 ピット目）を 1の値に変換したアドレスを画制御器 1970に通知する機能を "ることから、 いずれの場合にもモ一ド情報は通知しない。
本実施の形態では、 モード情報がターゲットアドレスに含まれており、 設定制御器 1990 において要求モードに応じて夕一ゲットァドレスを変換することにより、 モード情報を送る 必要はなく、 中継ノードはタ一ゲットアドレスのみを参照して LTを実; ればよい仕組み となっている。
(第 2の実施の形態の動作）
以上説明した構成を有するスィツチ S1〜S8からなる図 1、 図 1 5のネットワークにおい て、 端末 T2から端末 T 1に対して LTを る: ^について、 ： Φ^ΙΙの形態の LT実 »法 について説明する。 機包の形態の方法を用いると、 ターゲット装置までの を確認 すると共に、 では不可能であった P轄切觀の P轄箇所特定カ坷能となる。
0AM制御器 1970のテ一フレ参照器 2220とフレーム生 2230の構成及び機能の に伴い、 図 1 1、 図 1 3の処理フローも^ ¾変更となったことから、 第 1の実施の形態との 差分を中心に第 2の実施の形態における図 1 1、 図 1 3の処理フ口一の説明する。
(自ノードから LT Requestフレームを発生させる の制御） 図 1 1の自ノードから LT Requestフレームを発生させる場合の制御の処理フローの変更 点は以下の通りである。
ステツプ S 101において、 フレーム生 β 2230が設定制御器 790から受信する LT実施要 求には、 LTを実施するターゲット装置のアドレス情報が含まれる。
フレーム生 2230は、 ステップ S 102において、 タ一ゲットアドレス情報に基づき、 LT
Reques tフレームを生成し、 生成した LT Reques tフレームをフレーム送信器 1160に^!する。 また、 フレーム生成器 2230は、 ステップ S 103において、 ターゲットアドレス情報をテ一 フレ参照器 2220に する。
その後、 ステップ S 104において、 テーブル参照器 2220は、 フォワーディングテ一ブル 1940の MACテーブル 2000を参照して、 夕一ゲットアドレスが適合するェントリを検索し、 該当する出力ポ一卜' I青報を取得し、 フレーム送信器 1160に転送する。
このように、 第 1の実施の形態で《1常モ一ド /P轄切替モードの情報を独立した情報と して麟していたのに対し、 本難の形態では、 モード情報がターゲットアドレス情報に含 まれるため、 夕一ゲットアドレス情報のみを交換する。
(他ノードからの LT Requestフレームを中継すると共に、 LT Replyフレームを生成する: t の制御）
次いで、 図 1 3の他ノードからの LT Requestフレームを中継すると共に、 LT Replyフレー ムを生成する場合の制御の処理フ口一の変更点は以下の通りである。
ステツプ S 303の判定の結果、 ターゲットァドレスが他ノードである場合、 夕一ゲットァ ドレスフィルタ 1110は、 ステップ S 304において、 ターゲットアドレス情報をテ一ブル参照 器 2220に^する。
その後、 ステップ S 305において、 テーブル参照器 2220は、 フォワーディングテーブル 1940の ACテーブル 2000を参照して、 夕一ゲットァドレス情報が適合するェントリを検索 し、 対 J¾Tる出力ポート情報を取得する。
このように、 図 1 1の場合と同様に、 第 1の実施の形態では通常モード /P轄切替モード の情報を敝した情報として勝していたのに対し、 賴施の形態では、 モード情報がター ゲットァドレス情報に含まれるため、 ターゲットァドレス情報のみを交換する。
次いで、 本発明を用いた ^の MACテーブル 2000の設定例について説明する。 図 1のネットワークにおいて、 通常;]え態で MACァドレスラーニングが完了している齢の MACテーブル 2000を図 2 2に示す。
ここで、 VLA は Xとし、 また、 端末 T1の MACアドレスを Ox 00 00 4c 00 00 01、 端末 T2の MACアドレスを Ox 00 00 4c 00 00 02としており、 スィッチ S1〜S8において、 MAC#0x 00 00 4c 00 00 01&VLA #Xと MAC#0x 00 00 4c 00 00 02&VLAN#Xのェントリが格納されている。 ここで、 図 1のネットワークにおいて、 図 1 5に示すようにスィッチ S2とスィッチ S3の 間のリンクに が発生したとする。 このような：^、 STP/RSTPの手順に従って、 BPDUカ 力 構築される。
この過程における Cテーブル 2000の設定^態を図 2 3に示した。
図 2 3では、 障害を検知したスィツチ S2のポ一ト p2とスィツチ S3のポート piのェント リがフラッシュされる。
また、 本発明の體として、 トポロジー麵メッセージを受信したポートのエントリ力縦 *Mのようにフラッシュされるのではなく、 そのエントリについては、 MACアドレスのマ ルチキャストビット (8ビット目)が 1の値に颜され ェントリとしては残される。
一例を説明すると、 スィツチ S1のポ一ド p2ではスィツチ S2からのトポロジー^メッ セージを受信し、 その際、 ポート p2で学習している MAC#0x 00 00 4c 00 00 02&VLAN#Xのェ ン卜リをフラッシュするのではなく、 マルチキャス卜ビッ卜を 0の値から 1の値に書き換え て、 MAC#0x 01 00 4c 00 00 02&VLA #Xのエントリとして残す。
同様の処理は、 スィツチ S4の MAC#0x 00 00 4c 00 00 01&VLA # のェントリ、 スィツチ S5 の MAC#0x 00 00 4c 00 00 01&VLA #Xのエントリ、 スィッチ S6の MAC#0x 00 00 4c 00 00 01 & VLAN#Xのエントリと MAC#0x 00 00 4c 00 00 02&VLA #Xのエントリ、 スィッチ S7の MAC#0x 00 00 4c 00 00 01&VLAN#Xのェントリと MAC#0x 00 00 4c 00 00 02&VLAN#Xのェントリ、 スィッ チ S8の MAC#0x 00 00 4c 00 00 01&VLA #Xのェントリと MAC#0x 00 00 4c 00 00 02&VLANtXの ェントリについて行なわれており、 いずれもマルチキャストビット =1、 すなわち、 Ox 01 00 4c 00 00 01又は Ox 01 00 4c 00 00 0 のエントリとして残っている。
その後、 図 1 5のネットワークでフレーム転送が 開された後の MACテーブル 2000の設 定状態を図 2 4に示した。 図 2 4に示すように、 新たなトポロジー上で学習された MACァドレスェントリに関しては、 通常 MACァドレスェントリとして、 MAC#0x 00 00 4c 00 00 01 &VLA #X、 MAC#0x 00 00 4c 00 00 02&VLA # が、 各ノ一ドの MACテ一ブル 2000に格納される。
(轄箇所の特定処理）
このような図 2 4の MACテープレの状態である場合に、 図 1 5のネットワークにおいて、 端末 T2から端末 T1をターゲット装置とした! ^切替モードにおける LTが実施された：^ について、 以下に説明する。
送信元の端末 T2は、 LT Requestフレームを送 ifTる (ΉΙの初期値を 255とする)。 ここで、 Ρ轄切替モードの LTのため、 端末 T1のターゲットアドレスは Ox 01 00 4c 00 00 01となる。 端末 T2から LT Requestフレームを受信したスィツチ S5は、 夕ーゲット装置である端末 T1 のァドレス MAC#0x 01 00 4c 00 00 01 &VLAN#Xのエントリを図 2 4の MACテーブル 2000から 櫞する。
スィツチ S5は、 その結果、 ポート p2を取得し、 TTL値を 1濃した Requestフレーム (TTL=254)をポート p2に対して転送する。
また、 スィッチ S5は、 Request発 ¾¾置である端末 T2に対して、 ΤΊΙ値 =254を格納した
LT Replyフレームを返信する。
スィッチ S5のポート p2側の次段のノ一ドであるスィッチ S4は、 夕一ゲット装置である 端末 T1のァドレス MAC#0x 01 00 4c 00 00 01 &VLA #Xのエントリを図 2 4の MACテーブル 2000から する。
その結果、 スィツチ S4は、 ポート piを取得し、 TTL値を 1 した Requestフレーム
(TTL=253)をポート piに対して転送する。
また、 スィッチ S4は、 Request発 fi^装置である端末 T2に対して、 ΤΊΙ値 =253を格納した LT Replyフレームを返信する。
スィツチ S4のポート pi側の次段のノードであるスィツチ S3は、 ターゲット装置である 端末 T1のァドレス AC#0x 01 00 4c 00 00 01 &VLA #Xのエントリを図 2 4の MACテーブル 2000； ^ら; ^する。
その結果、 該当するエントリが 在しないため、 スィッチ S3は、 LT Requestフレームを 鶴し、 Request発 ff¾装置である端末 T2に対して、 TTI値を 1 した LT Replyフレ一ム (TTL値 =252)を返信する。 一方、 LT Requestフレームの発行元装置である端末 T2を見てみると、 スィツチ S5からの LT Replyフレーム (TTL=254)、 スィッチ S4からの LT Replyフレーム (TTL=253)、 スィッチ S3か らの LT Replyフレーム (TTL=252)を受信している。
端末 T2では、 これを TTLが降順になるよう、 アドレスをソ一トすると、 スィッチ S5→ イッチ S4—スィッチ S3となる。 タイマエクスパイアした結果、 それ^^の Replyフレーム が端末 T2で受信されないと、 これが LTの結果となる。
この結果には、 ターゲット装置である端末 T1が含まれないため、 端末 T1までの間で P轄 が起こったことが分かり、 Replyフレームのソート結果により、 スィッチ S3までは生き残つ ており、 その先で何らかの P轄が発生したことが ¾認できる。
このように、 本実施の形態の方法を用いると、 P轄発生時に P轄切替を行った後に LTを 実施したとしても、 切替前の経路上で LTを実施すること力河能であり、 p轄麵を特^ ることができる。
(現在の 経路の確認処理）
当然のことながら、 現在の を確認することも可能である。 図 1 5のネットワーク において、 端末 T2から端末 T1を夕一ゲット装置とした通常モードにおける LTを行うと、 現在の 鶴を確認できる。
ここで、 通常モードの LTのため、 端末 Ήのターゲットアドレスは Ox 00 00 4c 00 00 01 となる。 送信元の端末 T2は、 LT Requestフレームを送信すると (TTLの初期値を 255とする)、 LT Requestフレームを受信したスィツチ S5は、 夕一ゲット装置である端末 T1のァドレス MACtOx 00 00 4c 00 00 01 &VLANt のエントリを図 2 4の MACテ一ブル 2000から^ ¾する。 その結果、 スィッチ S5は、 ポート p3を取得し、 TTL値を 1減算した Requestフレーム (TTL=254)をポート p3に対して する。
また、 スィッチ S5は、 Request発行元装置である端末 T2に対して、 TTL値 =254を格納した LT Replyフレームを返信する。
スィツチ S5のポート p3側の次段のノードであるスィツチ S6は、 夕一ゲット装置である 端末 T1のァドレス MAC#0x 00 00 4c 00 00 01 &VLA #Xのエントリを^すると、 ポート piが 得られるため、 ΊΊΙ値を 1藤した Requestフレーム 011=253)をポ一ト piに対して する。 また、 スィッチ S6は、 Request発 ί玩装置である端末 T2に対して、 ΠΙ値 =253を格納した LT Replyフレームを返信する。 同様に、 各スィッチで、 MAC#0x 00 00 4c 00 00 01 &VLA #Xのエントリを検索して、 Request フレーム転送処理、 Replyフレーム生成処理を繰り返すことにより、 スィッチ S7(m=252)、 スィッチ S8(TTL=251)、 スィッチ S1 (T1L=250)、 端末 T1 (TTL= 9)からの LT Replyフレームが端 末 T2に到着する。
端末 T2では、 TTLを降順になるよう、 アドレスをソートすると、 スィッチ S5→スィッチ
S6→スィツチ S7→スィツチ S8→スィツチ Sl→端末 T1となる。
タイマエクスパイアした吉果、 そ の Replyフレームが端末 T2で受信されないと、 これが LTの結果となり、 夕一ゲット装置である端末 T1までの 怪路上の装置を確認でき る。
ここまでの説明では、 MACァドレスのマルチキャストビット (上位 8ビット目）を通常モ一 ドと P轄切替モードを区別するビットとして使用してきた。
MAC- iiriMC漏のように MACァドレスを自由に設定できる には、 任意のビットをモ一 ド調翻に割り当てることにより、 同様の効果を得ること力 きる。
例えば、 最上位ビットをモード識棚に割り当てると、 上記の例のターゲット装置である 端末 T1の MACアドレスは、 通常モードでは、 MAC#0x 00 00 4c 00 00 01となり、 P章害切替モ ードでは、 MAC#0x 80 00 4c 00 00 01となるため、 上記の例の障害切替モードにおけるアド レスを MAC#0x 01 00 4c 00 00 01から MAC#0x 80 00 4c 00 00 01と置き換えることで、 同様の 効果を得ることが" きる。
(第 2の実施の形態の効果）
以上説明したように、 ： の形態の方法を用いると、 Ρ轄発生時に Ρ轄切替を行った場 合に、 切替前の MACアドレスエントリをフラッシュするのではなく、 アドレスの一部ビ ットを変換して、 切替前のエントリであることを示すことにより、 障害切替後にも切替前の MACァドレスェントリを保持する。
そして、 P轄発生時の 切觀に LTを実; る:^、 LT要求時に現在の 経路を確 認する通常モードか、 轄麵を特¾1~るための P轄切替モードかを指 ¾Tることで、 ター ゲットアドレスを通常モード用ァドレスか、 障害切替モード用ァドレス.を使用して LTを行 ラ。
その結果、 »切替モードを指定した: t給には、 MACテーブルにおいて、 切替前の MACァ ドレスェントリにしたがって、 LT Requestフレームを^することにより、 障害発生箇所の 手前のノードまで LT eques tフレームが ij着することができ、 各ノ一ドでの LT Replyフレ ームの返信により、 （^箇所を特^ Tること力河能である。
(第 3の実施の形態）
本発明の他の実施の形態について、 図面を用いて詳細に説明する。
(第 3の実施の形態の構成）
図 2 5は、 第 3の実施の形態のフレームスィツチング部 630の詳細構成を示している。 図 2 5では、 図 1 8で示した第 2の実施の形態のフレームスィツチング部 630に対して、
0AM制御器 1970が 0AM制御器 2670に、 STP制御器 1980が STP制御器 2680に、 設定制御器 1990が設定制御器 2690に変更されている。 以降では、 第 2の実施の形態との差分を中心に 本実施の形態を説明する。
まず、 STP制御器 2680について説明する。
STP制御器 680は、 STP制御器 780、 SIP制御器 1980と同様に、 IEEE802. lD/w/s等に従った STP RS1Pの処理を行う機能を^ Tる。
S1P制御器 2680は、 通常の STP/RSIPの処理に加えて、 本発明の特徴的な処理として、 ト ポロジ一颜メッセ一ジ受信時にフラッシュすべきァドレスに対して、 フラッシュせずに、 MACテ一ブル 2000の VLANタグを"^変換する機能を有する。
具体的には、 STP制御器 2680は、 図 2 6に示すように、 通常の VLA タグの Priori ty値 (3 ビット）に関して、 もともと割り付けられている Priori ty値をリザーブされている 「010」 に 変換する機能を # "る。
通常状態において MACテーブル 2000で学習されているェントリの Priori ty値はデフオル トの場合、 「000」 であり、 ΙΕΕΕ802· 1ρに準拠して Priori ty対応して、 全ての Priori ty値を 使用している：^、 「000」 、 「001」 、 「011」 、 「100」 、 「101」 、 「110」 、 「111」 力使 用されている。
すなわち、 Priori ty値として 「010」 は使用されないことから、 P轄切替モードの場合、
STP制御器 2680が VLANタグの Priori ty値を 「010」 に変換することにより、 Priori ty値が通 常モ一ド /P轄切替モードの判別に利用される。 本実施の形態は、 この機能により、 と同様に通常の MACアドレスエントリ（VLAN タグ Priority 元々の割付戀を保持すると共に、 P轄切觀施時の切替前の MACァドレス ェントリ（VLA タグ Prior ity=010)を保持することができる。
続いて、 図 2 7を用いて 0A 制御器 2670について説明する。
図 2 7に示すように、 0AM制御器 2670は、 0A 制御器 1970のフレーム生 2230がフレ
—ム生成器 2830に、 テ一フレ参照器 2220がテ一ブル参照器 2820に変更される。
0AM制御器 2670の機能は、 0M制御器 1970の機能とほぼ同様である。 差分は、 0AM制御器 1970は、 通常モードと P轄切替モ一ドの区別を MACァドレスのマルチキャストビットで行う 機能を有していたのに対し、 0AM制御器 2670は、 その区別を VLA タグの Priority値で行う 機能を有する点である。
フレーム生 β 2830は、 設定制御器 2690からは夕ーゲットアドレス情報のみを受信し、 LT Requestフレームを生成する機能を有する。
： の形態において、 夕一ゲットアドレスの VLA タグ Priority値が「010」 の値で ある は、 通常モードを示しており、 その時点での MACアドレス学習状況に従った LTを 行うことで、 現在の転逸経路を確認でき、 一方、 ターゲットアドレスの VLA タグ Priori ty 値が 「010」 である場合は、 P轄切替モードを示しており、 障害切替実施前の MACアドレス 学習状況に従つた LTを行うことで、 P轄箇所を特定できる。
テーブル参照器 2820は、 フォヮーディングテーブル 1940の MACテ一ブル 2000を参照して、 モード情報を含んでいるターゲットアドレス情報 (モード情報は VLA タグの Priorityフィ一 ルドに含まれる)に対する出力ポート情報を取得する機能を有する。
最後に、 設定制御器 2690について説明する。
設定制御器 1990は、 コンソール I/O経由で入力された LT実纏求を 0AM制御器 1970に通 知する際、 LT実施要求の LT実施モードが通常モードである場合、 そのままのターゲットァ ドレスを 0AM制御器 1970に通知し、 LT実施要求の LT実施モードが障害切替モ一ドである場 合、 ターゲットアドレスのマルチキャストビット (8ビット目）を 1の値に変換したァドレス を 0AM制御器 1970に通知する機能を有していた。
これに対して、 設定制御器 2670は、 LT実施要求の LT難モードが通常モードである：^ は、 設定制御器 1970と同様にそのままの夕一ゲットァドレスを 0AM制御器 2670に通知し、 LT実施要求の LT実施モ一ドが P轄切替モードである:^は、 夕一ゲットアドレスの VLA 夕 グ Priori ty値を 「010」 に変換して、 0AM制御器 2670に通知する機能を有する。
(第 3の実施の形態の動作）
以上説明した構成及 能を^ Tるスィッチ S1〜S8からなる図 1、 図 1 5のネットヮー クにおいて、 端末 T2から端末 T 1に対して LTを実施する場合について、 本実施の形態の LT 実 »法について説明する。 本難の形態の方法を用いると、 ターゲット装置までの 路を確認すると共に、 術では^ J能であった P轄切難の P轄箇所特定が 能となる。 まず、 本実施の形態を用いた場合の MACテーブル 2000の設定例について説明する。
図 1のネットワークにおいて、 通常 4え態で MACァドレスラーニングが完了している齢の MACテーブル 2000を図 2 8に示す。
ここで、 VLA は、 Priori ty値がデフォルトの 「000」 、 CFI値が 0、 VIDが 0000 0000 0001と している。 なお、 ΊΡΠΜ)χ8100の記載は省略している。
また、 端末 T1の MACアドレスを tl、 端末 T2の MACアドレスを t2とし、 スィッチ S1〜S8 において、 MAC#il &VLAN#0000 0000 0000 0001と MAC#t2&VLA #0000 0000 0000 0001のエントリ が格,钠されている。
ここで、 図 1のネットワークにおいて、 図 1 5に示すようにスィッチ S2とスィッチ S3の 間のリンクに P轄が発生したとする。 このような齢、 STP RSTPの手順に従って、 BPDUが が¾構築される。 この過程における MACテーブル 2000の設定状態を図 2 9に示した。
図 2 9では、 |5轄を觀したスィツチ S2のポ一ト どスィツチ S3のポ一ト piのェント リがフラッシュされる。
また、 本実施の形態の特徴として、 トポロジー変更メッセージを受信したポートのェント リが従来技術のようにフラッシュされるのではなく、 そのエントリについては、 VLANタグ の Priori ty値が元々の設定値 「000」 から 「010」 に され、 エントリとしては残される。 一例を説明すると、 スィツチ S1のポ一ト p2ではスィツチ S2からのトポロジー メッ セージを受信し、 その際、 ポー卜 p2で学習している AC#t2&VLAN#0000 0000 0000 0001のェ ントリをフラッシュするのではなく、 VLAN Priori ty値を 「000」 から 「010」 に書き換えて、 ACttt2&VLA t0100 0000 0000 0001のエントリとして残す。 同様の処理は、 スィツチ S4の MAC#tl &VLA #0000 0000 0000 0001のェントリ、 スィツチ S5 の MAC#tl &VLAN#0000 0000 0000 0001のェン卜リ、 スィッチ S6の MAC#tl &VLA #0000 0000 0000 0001のェントリと MAC#t2&VLAN#0000 0000 0000 0001のェントリ、 スィツチ S7の MAC#tl & VLANtOOOO 0000 0000 0001のエントリと MAC#t2&VLA #0000 0000 0000 0001のェン卜リ、 スィ ツチ S8の MAC#tl &VLA #0000 0000 0000 0001のェン卜リと MAC#t2&VLA #0000 0000 0000 0001 のエントリについて行なわれており、 いずれも VLAN Priori ty=010、 すなわち、 VLAN#0100 0000 0000 0001のエントリとして残っている。
図 1 5のネットワークでフレーム 力稱開された後の MACテーブル 2000の設定状態を 図 3 0〖こ示した。
新たなトポロジー上で学習された MACァドレスェントリに関しては、 通常 MACァドレスェ ントリとして、 MAC#tl &VLANt0000 0000 0000 0001、 MAC#t2&VLAN#0000 0000 0000 0001が各ノ ―ドの MACテーブル 2000に格納される。
(P轄箇所の特定処理）
このような図 3 0の MACテ一ブルの优態である：^に、 図 1 5のネットワークにおいて、 端末 T2から端末 T1を夕ーゲット装置とした 切替モードにおける LTが実施された:^ について、 以下に説明する。
送信元の端末 T2は、 LT Requestフレームを送信する (TTLの初期値を 255とする)。
ここで、 P轄切替モードの LTのため、 端末 T1のターゲットアドレスは MAC#tl &VLA #0100 0000 0000 0001となる。
端末 T2から LT Requestフレームを受信したスィツチ S5は、 夕一ゲット装置である端末 T1 のアドレス MAC#tl &VLA #0100 0000 0000 0001のエントリを図 3 0の MACテーブル 2000から 職する。
その結果、 スィツチ S5は、 ポート p2を取得し、 TTL値を 1 した Requestフレーム (TIL=254)をポート p2に対して する。
また、 スィッチ S5は、 Request発 ί¾¾装置である端末 T2に対して、 TTL値 =254を格納した LT Replyフレームを返信する。
スィツチ S5のポート p2側の次段のノ一ドであるスィツチ S4は、 ターゲット装置である 端末 T1のァドレス MAC#tl &VLA #0100 0000 0000 0001のェントリを図 3 0の MACテーブル 2000から;^する。 その結果、 スィッチ S4は、 ポート piを取得し、 TTL値を 1減算した Requestフレーム (TTL-253)をポート piに対して転送する。
また、 スィッチ S4は、 Request発 fi¾装置である端末 T2に対して、 T 値 =253を格納した LT Replyフレームを返信する。
スィツチ S4のポート pi側の次段のノ一ドであるスィツチ S3は、 ターゲット装置である 端末 T1のァドレス MAC#tl &VLAN#0100 0000 0000 0001のェントリを図 3 0の MACテーフレ 2000から;^する。
その結果、 スィッチ S3は、 該当するエントリが 在しないため、 LT Requestフレームは 艇し、 Request発 f ^装置である端末 T2に対して、 TTI値を 1 した LT Replyフレーム (T1L値 =252)を返信する。
一方、 LT Reques tフレームの発行元装置である端末 T2を見てみると、 スィッチ S5からの LT Replyフレーム (TTL=254)、 スィッチ S4からの LT Replyフレーム (TTL=253)、 スィッチ S3か らの LT Replyフレーム (TTL=252)を受信している。
端末 T2では、 これを TTLが降順になるよう、 アドレスをソートすると、 スィッチ S5→ イッチ S4→スィッチ S3となる。 タイマエクスパイアした結果、 それ以外の Replyフレーム が端末 T2で受信されないと、 これが LTの結果となる。
この結果には、 ターゲット装置である端末 T1が含まれないため、 端末 T1までの間で P轄 が起こったことが分かり、 Replyフレームのソ一ト結果により、 スィッチ S3までは生き残つ ており、 その先で何らかの障害が発生したことが ϋ認できる。
このように、 本実施の形態の方法を用いると、 Ρ轄発生時に Ρ轄切替を行った後に LTを 実施したとしても、 切替前の経路上で LTを実 ることが 能であり、 Ρ轄箇所を特¾ ~ ることが、できる。
(現在の転纖路の確認処理）
当然のことながら、 現在の転逸怪路を確認することも可能である。 端末 T2は、 端末 T1を 夕一ゲット装置とした通常モードにおける LTを行うと、 現在の転 怪路を確認できる。 ここで、 通常モードの LTのため、 端末 T1のターゲットアドレスは MAC#tl &VLAN#0000 0000 0000 0001となる。 送信元の端末 T は、 LT Requestフレームを送信すると (TTLの初期値 を 255とする)、 LT Requestフレームを受信したスィツチ S5は、 夕一ゲット装置である端末 Tlのァドレス MAC#tl &VLA #0000 0000 0000 0001のェントリを図 3 0の MACテープリレ 2000か ら;^する。
その結果、 スィツチ S5は、 ポート p3を取得し、 TTL値を 1 した Requestフレーム (TTL=254)をポート p3に対して転送する。
また、 スィッチ S5は、 Request発 i ¾装置である端末 T2に対して、 TTL値 =254を格納した
LT Replyフレームを返信する。
スィツチ S5のポート p3側の次段のノ一ドであるスィツチ S6は、 夕一ゲット装置である 端末 T1のァドレス MAC#tl &VLA #0000 0000 0000 0001のエントリを;^すると、 ポート piが 得られるため、 TTL値を 1 した Requestフレーム (ΤΊΙ=253)をポート piに対して転送する。 また、 スィッチ S6は、 Request発行元装置である端末 T2に対して、 TTL値 =253を格納した
LT Replyフレームを返信する。
同様に、 各スィッチで、 1\^ 1 & #0000 0000 0000 0001のェン卜リを^¾して、 Request フレーム 理、 Replyフレーム生腿理を繰り返すことにより、 スィッチ S7 (TTL=252)、 スィッチ S8 (TTL=251)、 スィッチ SI (TTD=250)、 端末 Tl (TTL=249)からのば Replyフレームが端 末 T2に到着する。
端末 T2では、 TTLを降順になるよう、 アドレスをソートすると、 スィッチ S5→スィッチ S6→スィツチ S7→スィツチ S8—スィツチ Sl→端末 T1となる。 タイマエクスパイァした結果、 そ; の Replyフレームが端末 T2で受信されないと、 これが LTの結果となり、 ターゲッ ト装置である端末 T1までの転 路上の装置を確認できる。
(第 3の実施の形態の効果）
以上説明したように、 本 »の形態の方法を用いると、 P轄発生時に P轄切替を行った場 合に、 切替前の MACアドレスエントリをフラッシュするのではなく、 VLA タグの一部ビット を変換して、 切替前のエントリであることを示すことにより、 P轄切謝臭にも切替前の MAC アドレスエントリを保持する。
そして、 P轄発生時の P轄切纖に LTを実 る場合、 LT要求時に現在の転逸怪路を確 認する通常モードか、 P轄箇所を特¾1~るための P轄切替モードかを指 ¾τることで、 ター ゲットアドレスを通常モード用アドレスか、 Ρ章害切替モード用アドレスを使用して LTを行 。 その結果、 P轄切替モードを指定した齢には、 MACテ一カレにおいて、 切替前の MACァ ドレスエントリにしたがつて、 LT Reques tフレームを転送することにより、 P章害発生箇所の 手前のノードまで LT Reques tフレームが ij着することができ、 各ノ一ドでの LT Replyフレ —ムの返信により、 P轄箇所を特¾ ~ることが可能である。
(第 4の実施の形態）
本発明の第 4の実施の形態について、 図面を用いて詳細に説明する。
(第 4の実施の形 ϋの構成）
図 3 1は、 第 4の実施の形態のフレ一ムスィツチング部 630の詳細構成を示している。 図 3 1では、 図 1 8で示した第 2の実施の形態のフレ一ムスィツチング部 630に対して、
0AM制御器 1970が 0AM制御器 3270に され、 言婉制御器 1990が第 1の実施の形態の設定 制御器 790になっている。
の形態と第 2の魏の形態との は、 第 2の実施の形態と同様に、 通常モードと Ρ轄切替モードの判別は MACァドレスのマルチキャストビットで行うものの、 モードに応じ たターゲットアドレスのアドレス変換を行う機能を第 2の実施の形態のように設定制御器 1990力^ するのではなく、 0AM帘 II御器 3270力 *Τする; ¾である。
また、 第 2の実施の形態では、 設定制御器 1990は LT実廳求のターゲットアドレスをァ ドレス変換して 0AM制御器 1970に渡す機能を有していたのに対して、 本実施の形態では、 設定制御器 1990は第 1の実施の形態の設定制御器 790となっており、 LT実施要求のモード 情報を 0AM制御器 3270に渡す機能を有し、 0A 制御器 3270が、 モード情報を格納した LT Requestフレームを生^ 1 "る機能を "る。 以降では、 第 2の実施の形態との差分を中心に 本実施の形態を説明する。
0AM制御器 3270について説明する。
0AM制御器 3270の ¾φ冓成は、 0AM制御器 1970と同様である。 散は、 図 3 2に示すよう に、 テーブル参照器 2220がテーブル参照器 3320に変更され、 フレーム生 ¾ 2230が第 1の 実施の形態のフレーム生成器 1130となっている点である。
機能の差分〖¾¾下の通りである。
テーブル参照器 220は、 フレーム生 2230や夕一ゲットアドレスフィル夕 1110から受 信したモード情報を含んでいるターゲットァドレス情報に基づいて、 フォヮ一ディングテ一 ブル 1940の MACテーブル 2000を参照して、 夕一ゲットアドレス情報に対する出力ポート情 報を取得する機能を有していた。
これに対して、 テーブル参照器 3320は、 フレーム生 β 1130やターゲットアドレスフィ ルタ 1110から LT Requestフレームの夕一ゲットァドレス情報とモ一ド情報を受信すると、 モード情報に従って夕一ゲットアドレス情報を変換し、 変換後の夕ーゲットアドレス情報に 基づいて、 フォヮ一ディングテーブル 1940の MACテーブル 2000を参照して、 対 jiTfる出力 ポート情報を取得する機能を る。
モード情報に従ったタ一ゲットアドレス情報の変 »法は、 第 2の実施の形態において、 設定制御器 1990； ^行っていた方法と同様である。
具体的には、 モード情報が通常モードである ±給には、 ターゲットの MACアドレスはその まま勝する。 一方、 モード情報が轄切替モードである には、 ターゲットの MACアド レスのマルチキャストビット (上位 8ビット目）を 0の値から 1の値に変換する。
フォワーディングテ一ブル 1940の MACテーブル 2000は、 STP制御器 1980によって、 通常 モードの MACァドレスェントリと障害切替モードの MACァドレスェントリのヌ又方が、保持され るようになっており、 テーカレ参照器 3320がアドレス変換したアドレスによってフォヮ一 ディングテーブル 1940の MACテーブル 2000を すると、 モードに応じた出力ポ一トを得 ることができる。
(第 4の実施の形態の動作）
0AM制御器 3270のテ一ブル参照器 3320の構成及 «能の ~¾変更に伴い、 図 1 1、 図 1 3の処理フ口一も一部変更となる。
(自ノードから LT Requestフレームを発生する場合の制御）
図 1 1の自ノードから LT Requestフレームを発生する の制御の処理フ口一の^ E点 はステップ S 104である。
ステツプ S 104において、 テーブル参照器 1120は、 フォヮ一ディングテーブル 740の MAC テーカレ■を参照して、 夕一ゲットアドレスとモード情報が適合するエントリを鍵し、 該当する出力ポート情報を取得し、 フレーム送信器 1160に転送していたのに対し、 テープ ル参照器 3320は、 モード情報に従ってターゲットアドレスを変換し、 変換後のターゲット ァドレスを元にフォヮーディングテーブル 1940の MACテーブル 2000を参照して、 出力ポー 卜' I青幸を取得し、 フレーム送信器 1160〖こ する。 (他ノ一ドからの LT Requestフレームを中継すると共に、 LT Replyフレームを生成する の制御）
次いで、 図 1 3の他ノードからの LT Requestフレームを中継すると共に、 LT Replyフレー ムを生成する場合の制御の処理フ口一の変更点はステツプ S 305である。 これは上述のステ ップ S 104の動作と同様である。
ステツプ S 305において、 テーブル参照器 1120は、 フォヮ一ディングテーブル 740の MAC テーブル 800を参照して、 夕一ゲットアドレスとモ一ド情報が適合するェントリを鍵し、 対 JiTTる出力ポート情報を取得し、 その情報をフレーム送信器 1160に していた。
これに対し、 テーブル参照器 3320は、 モード情報に従ってターゲットアドレスを変換し、 変換後の夕ーゲットアドレスを元にフォヮーディングテーブル 1940の MACテーブル 2000を 参照して、 出力ポート情報を取得し、 フレーム送信器 1160に する。
なお、 以上説明した構成及 能を るスィッチ S1〜S8からなる図 1のネットワーク において、 端末 T2から端末 T 1に対して LTを ¾TTる齢の賴施の形態の LT実施例につ いては、 図 2 2〜図 2 4を用いた第 2の実施の形態の説明と同様となるため、 ここで 愛 する。
また、 本実施の形 は、 モード情報に応じたアドレス変 法を第 2の実施の形態で説 明したタ一ゲットァドレスの MACァドレスのマルチキャストビットを用いる方法を適用して 説明した。
ァドレス変換方法については、 第 3の実施の形態で説明した夕一ゲットアドレスの VLA タグの Priori tyビットを用いる方法も適用可能である。 その場合は、 図 3 1の STP制御器 1970が第 3の実施の形 fiの STP制御器 2670に変更される。
また、 図 3 2のテーブル参照器 3320のァドレス変 法がモ一ド情報に応じてマルチキ ャストビットを変換するのではなぐ モード情報が通常モードである は、 そのままの夕 一ゲットアドレスを麟し、 モード情報が P轄切替モードである： は、 ターゲットァドレ スの VLANタグ Priority値を 「010」 に変換することによって、 本 «の形態の説明と同様に、 モード Ί青幸に応じたァドレス変換を LT Requestフレームの発行ノ一ドの設定制御器が行う のではなく、 ネットワーク内の各ノードの謹制御器で行うことにより、 P轄発生時の P轄 箇所特定の LTを実施可能である。
(第 4の実施の形態の効果） 以上説明したように、 の形態の方法を用いると、 Ρ轄発生時に轄切替を行った場 合に、 切替前の MACァドレスェントリをフラッシュするのではなく、 MACァドレスの一部ビ ットを変換して、 切替前のエントリであることを示すことにより、 P章害切替後にも切替前の MACァドレスェン卜リを保持する。
そして、 IW発生時の P轄切纖に LTを実施する場合、 LT要求時に現在の転 路を確 認する通常モードか、 P轄箇所を特 るための P轄切替モードかを指^-ることで、 ター ゲットァドレスを通常モ一ド用ァドレスか、 障害切替モード用ァドレスを使用して LTを行 ラ。
その結果、 P轄切替モードを指定した: ^には、 MACテーブルにおいて、 切替前の MACァ ドレスエントリにしたがつて、 LT Requestフレームを することにより、 障害発生箇所の 手前のノ一ドまで LT Requestフレームが ij着することができ、 各ノードでの LT Replyフレ ームの返信により、 轄箇所を特^ Tること力河能である。

Claims

請求の範囲
1. 送信元端末から送信されるデ一夕フレームを宛先端末に^ iするネットワークのフレ ーム転逸怪路確認方法において、
ネットワーク構 j¾ 時に、 フォヮ一ディングテーブルにおいて出力先力鞭となるァド レスに対し ^j情報を付与して嫌己ァドレスを残し、
Mis要求メッセージを l己 f ¾ij情報を付与して残したァドレスに基づいて して経路確 認することを特徴とするフレーム転送経路確認方法。
2. 送信元端末から送信されるデータフレームを宛先端末に ¾iするネットワークにのフ レーム 確認方法おいて、
ネットワーク構 時に、 フォヮーディングテ一カレにおいて出力先が 更となるァド レスに対し識 U情報を付与して漏ァドレスを残し、
嫌腰求メッセージを通常アドレスに基づいて して経路確認するか、 または、 賺 3識 別情報を付与して残したァドレスに基づいて して 廳忍することを とするフレ一 ム転藤路確認方法。
3. 嫌己ネットワークが、 ノードがターゲットノードに対してホップ数を格納した要求メ ッセージを送信し、 中継ノードおよび嫌己ターゲットノードは婦己ホップ数を體した応答 メッセージを要求メッセージ送信元ノードに返信し、 嫌 H¾信元ノードが嫌 3ホップ数に従 つて編3応答メッセージの並べ替えを行うことにより、 編 3送信元ノードから Ι ΐ己夕ーゲッ トノードまでの経由ノ一ド情報を取得するネットワークであることを ¾とする請求項 1又 は請求項 2に記載のフレーム転逸経路確認方法。
4. 鎌己ネットワークは、 ノードがターゲットノードに対してホップ数を格納した要求メ ッセージを送信し、 中継ノードは嫌己夕一ゲットノードに対して嫌 3ホップ数を した前 記要求メッセージを ¾1すると共に前記ホップ数を減算した応答メッセージを要求メッセー ジ送信元ノードに返信し、 嫌 3夕ーゲットノードは嫌己ホップ数を した応答メッセージ を要求メッセージ送信元ノ一ドに返信し、 前言 3¾信元ノードは前記応答メッセージの前記ホ ップ数に従って降順または昇順に前記応答メッセージの並べ替えを行い、 前記応答メッセ一 ジの送信元アドレスによって、 ΙίίΕ送信元ノードから前記ターゲットノードまでの経由ノー ド情報を取得するネットワークであることを とする請求項 1又は請求項 2に記載のフレ
—ム 経路確認方法。
5. 嫌 3フォヮ一ディングテーブルにおいて出力先力鞭となるァドレスに対し識 IJ情報 を付与して嫌 Bァドレスを残す際に、
Ml己フォヮ一ディングテ一ブルにおいて、 ネットヮ一ク構 前と颜後を示すフラグ フィールドを設け、 ネットワーク構成変更時にフラグの値をオンに し、
鎌己要求メッセージに Ml己フラグ情報を格納して、 通常アドレスに従って するか、 ま たは、 前記 wi'青報を付与して残したァドレスにしたがって転送して経路確認するかを指定 して、 β確認することを體とする請求項 2から請求項 4のいずれか 1項に記載のフレー ム転避路確認方法。
6. 賺己フォヮーディングテ一カレにおいて出力先力鞭となるァドレスに対し調リ情報 を付与して嫌 3ァドレスを残す際に、
鎌 3フォヮ一ディングテ一カレにおいて、 ァドレスの^^ビットをネットワーク構成 ¾Μ 前と変更後を区別するビットとして、 ネットヮ一ク構成麵時にァドレス変換し、 編己要求メッセージに通常ァドレスまたは変換後ァドレスを格納して、 通常ァドレスに従 つて ¾1するか、 または、 ΙΐίΙ己変換後アドレスにしたがって転送して @¾確認するかを指定 して、 繊磁 ¾することを額とする請求項 2から請求項 4のいずれか 1項に記載のフレー ム¾¾経路確認方法。
7. 嫌 3フォワーディングテーブルにおいて出力先が数となるアドレスに対し識リ情報 を ί寸与して前記ァドレスを残す際に、
編 Sフォヮ一ディングテーブルにおいて、 ァドレスの"^ビットをネットワーク構 j¾ 前と ¾H後を区別するビットとして、 ネットワーク構成颜時にァドレス変換し、 嫌 3要求メッセージに嫌己フラグ情報を格納して、 通常アドレスに従って するか、 ま たは、 鎌^^情報を付与して残したァドレスにしたがって して纏確認するかを指定 して、 漏 3識 IJ情報を付与して残したァドレスに従う i給には嫌 3各中継ノードにおいてァ ドレス変換したァドレスにしたがって鎌3要求メッセージを転送して経路確認することを特 徴とする請求項 2から請求項 4のいずれか 1項に記載のフレーム転 怪路確認方法。 8. 嫌己フォワーディングテ一ブルにおいて、 嫌己ターゲットノードの MACアドレスの任 意のビットをネットワーク構 前と変更後を区別するビットとして、 ネットワーク構成 ¾S時にァドレス変換することを樹敷とする言青求項 6又は請求項 7に記載のフレーム^ S 路確認方法。 9 . 編 3フォワーディングテ一ブルにおいて、 謙己ターゲットノードの MACアドレスの上 位 8ビット目のマルチキャストビットをネットワーク構戯更前と ¾S後を区別するビット として、 ネットワーク構 β更時にアドレス変換することを とする請求項 8に記載のフ レーム転逸経路確認、方法。 1 0. 嫌己フォヮ一ディングテ一ブルにおいて、 漏己夕ーゲットノードの VLA 夕グの任 意のビットをネットワーク構 j¾ 前と麵後を区別するビットとして、 ネットワーク構成 変更時にァドレス変換することを iftl [とする請求項 6又は請求項 7に記載のフレーム^ ¾ 路確認方法。 1 1 . 嫌己フォヮ一ディングテーブルにおいて、 嫌己夕一ゲットノードの VLA タグの P r i o r i t yビットをネットワーク構 «更前と^後を区別するビットとして、 ネット ワーク^ 時にァドレス変換することを とする請求項 1 0に記載のフレーム^ S 路確認方法。 1 2. 編 3フォヮーディングテーブルにおいて、 編己夕一ゲットノードの VLANタグの P r i o r i t yビットをネットワーク構 « 前と^後を区別するビットとして、 ネット ワーク構 i«M時のアドレス変換時に割り当てられていた P r i o r i t y値を 「0 1 0」 に変換することを特徴とする請求項 1 1こ記載のフレーム転 怪路確認方法。
1 3. 送信元端末から送信されるデータフレームを宛先端末に ¾iするネットワーク上の ノードにおいて、
嫌 3データフレームのァドレスに対する出力ポートをィ娥するフォヮ一ディングテーブル と、
ネットワーク構 時に、 嫌己フォヮ一ディングテ一ブルにおいて出力先力鞭となる ァドレスに対し 情報を付与して嫌己ァドレスを残すテ一ブル書讓理部と、
夕ーゲットノードに対してホップ数を減算した前記要求メッセージを転送する際に、 前記 要求メッセージを通常アドレスに基づいて するか、 または、 編 atM青報を付与して残 したァドレスに基づいて する運用保守制御部とを備えることを特'徴とするノード。
1 4. ti信 31用保守制御部は、 ターゲットノードに対して Κΐ ホップ数を格納した要求メ ッセージを生成、 送信し、 ターゲットノードに対して嫌 3ホップ数を ¾^した嫌己要求 メッセージを繊し、 嫌 3ホップ数を した応答メッセージを要求メッセージ送信元ノー ドに返信し、 ΙϋΙ己応答メッセージを受 すると前記ホップ数に従って降順または昇順に嫌己 応答メッセージの並べ替えを行い、 嫌 3応答メッセージの送信元アドレスによって、 嫌 3送 信元ノ一ドから嫌 3夕一ゲットノードまでの経由ノ一ド情報を取得することを とする請 求項 1 3に記載のノード。
1 5. 編己フォワーディングテーブルは、 さらに、 ネットヮ一ク構 前と颜後を示 すフラグ情報を ί 寺し、
|&|己テーブル 理部は、 ネットワーク構 時に、 編己フォワーディングテーブル において出力先が となるァドレスに対し、 前記フラグ情報を して前記ァドレスを残 し、
Ι Ι3フラグ情報を含むフレーム 確認要求を f^Slffl保守制御部に対して発行する 設定制御部を備え、
ItilSi用保守制御部は、 嫌 3夕一ゲットノードに対して婦 Sホップ数を »した編 3要求 メッセージを縫する際に、 編己要求メッセージをネットワーク構 後の通常アドレス に従って するか、 または、 鎌己フラグ情報がオンであるネットワーク構 «更前のアド レスに従って することを特徴とする請求項 1 3又は請求項 1 4に記載のノード。
1 6. 嫌己テ一ブル 理部は、 ネットワーク構成 時に、 f 記フォヮ一ディングテ 一力レにおいて出力先力鞭となるァドレスに対し、 嫌 3ァドレスの^ ¾ビットをネットヮ ーク構 « ^前と ¾M後を区別するビットとして、 ネットワーク構) 時にアドレス変換 を行い、
ネットワーク構 i¾M後の経路確認を行う際には通常ァドレスをターゲットァドレスとし てフレーム^ S路確認、要求とし、 ネットワーク構成変更前の経路確認を行う際には前記変 換後アドレスをターゲットアドレスとしてフレーム転 確認要求として、 MM用保守 制御部に対して発行する設定制御部を備え、
tiiraffl保守制御部は、 MI3ターゲットノードに対して ΙϋΙ3ホップ数を した lifts要求 メッセ—ジを^！する際に、 鎌 3要求メッセージに格納されるネットワーク構成颜後の通 常アドレスに従って するか、 または、 鎌 3要求メッセージに格納されるネットワーク構 前の変換後アドレスに従って ¾Mすることを纖とする請求項 1 3又は請求項 1 4に 記載のノード。
1 7. 觸己テ一ブル » ^理部は、 ネットワーク構) 時に、 編己フォヮ—ディングテ —カレにおいて出力先が ¾Mとなるァドレスに対し、 鎌己ァドレスの H'ットをネットヮ —ク構 前と ¾ 後を区別するビットとして、 ネットワーク構 時にアドレス変換 を行い、
ネットワーク構 前と 後を示す前記フラグ情報を含むフレーム 確認要求 を嫌 3®用保守制御部に対して発行する設定制御部を備え、
嫌 31用保守制御部は、 嫌己夕一ゲットノードに対して嫌3ホップ数を した嫌己要求 メッセ一ジを する際に、 嫌 3要求メッセージに格納される嫌 3フラグ情報がオフの齢 はネットワーク構 « ^後の通常アドレスに従って^!し、 編 3要求メッセージに格納され る嫌己フラグ情報がオンの は觸 3ァドレス変換を行い、 変換後ァドレスに従って す ることを特 ί敦とする請求項 1 3又は請求項 1 4に記載のノード。
1 8. 嫌 3テーブル^^理部が、 嫌己フォヮーディングテーブルにおいて、 アドレスの 15ビットをネットワーク構) 前と^後を区別するビットとして、 ネットワークネ冓成 ¾Μ時にァドレス変換する際に、
前記アドレスの^ ^ピッ卜が嫌3ターゲッ卜ノードの MACアドレスの任意のビットである ことを特徴とする請求項 1 6又は請求項 1 7に記載のノード。
1 9. 前記テーブル ¾ ^理部が、 前記フォヮーディングテーフ 1 /において、 アドレスの
15ビットをネットワーク構 前と^後を区別するビットとして、 ネットワーク冓成 ¾g時にァドレス変換する際に、
前記ァドレスのー咅ビッ卜が前記夕一ゲッ卜ノ一ドの MACアドレスの上位 8ビット目のマ ルチキャストビットであることを とする請求項 1 8に記載のノード。
2 0. 嫌 3テーブル 理部が、 觀フォヮ一ディングテーブルにおいて、 アドレスの 一部ビットをネットワーク構 前と^後を区別するビットとして、 ネットワーク冓成 時にァドレス変換する際に、
編己アドレスの ビッ卜が盲 !3ターゲッ卜ノードの VLA タグの任意のビッ卜であるこ とを舰とする請求項 1 6又は請求項 1 7に記載のノード。
2 1. ΙϋΕテーブル 理部が、 嫌 3フォヮ一ディングテ一ブルにおいて、 ァドレスの ビットをネッ卜ワーク構 j«g前と^後を区別するビットとして、 ネットワーク構成 ¾M時にァドレス変換する際に、
lift己ァドレスの一 |5ビットが前記夕一ゲットノードの VLA タグの P r i o r i t yビッ トであることを ¾とする請求項 2 0に記載のノード。 2 2 . 嫌己テーブル #M理部が、 編己フォワーディングテーカレにおいて、 アドレスの ^^ピットをネットワーク構 前と ¾ 後を区別するビットとして、 ネットワークネ冓成 変更時にァドレス変換する際に、 前記アドレスの一部ビットを前記夕一ゲットノードの VLA タグの P r i 0 r i t yビッ トとして、 アドレス変換時に割り当てられていた P r i o r i t y値を 「0 1 0」 に変換す ることを特徴とする請求項 2 1に記載のノード。 2 3 . 前記フレームがィーサネットフレームであり、 M記ァドレスが MACァドレスまたは VLANタグであることを特徴とする請求項 1 3から請求項 2 2のいずれか 1項に記載のノー ド。
2 4. 送信元端末から送信されるデータフレームを宛先端末に するネットワーク上の ノードで実行させるフレーム転送経路確認プログラムであつて、
ネットワーク構成変更時に、 編 3データフレームの嫌 3アドレスに対する出力ポートを保 持するフォヮ一ディングテ一ブルにおいて出力先力鞭となるァドレスに対し識リ情報を付 与して lift己ァドレスを残すテーブル書議能と、
夕一ゲットノードに対してホップ数を した嫌腰求メッセージを する際に、 嫌 3 要求メッセージを通常アドレスに基づいて するか、 または、 謙己 iisu情報を付与して残 したァドレスに基づいて する運用保守制御機能とを ΙΐίΙ3ノードに持たせることを體と するフレーム転 経路確認プログラム。
2 5. 嫌 3テーブル書讓理機能は、
ネットワーク構 «更時に、 嫌己フォヮ一ディングテ一ブルにおいて出力先が 更となる ァドレスに対し、 前記ァドレスのー |5ビットをネットヮ一ク構] «更前と ¾H後を区別する ビットとして、 ネットワーク構成変更時にアドレス変換を行い、
ネットワーク構 ¾ 後の経路確 を行う際には通常ァドレスをターゲットアドレスとし てフレーム 確認要求とし、 ネットヮ一ク構 前の «確認を行う際には嫌 3変 換後ァドレスをターゲットアドレスとしてフレーム^^路確認要求として、 前言 31用保守 制御部に対して発行する設定制御機能を ftff己ノードに持たせ、
嫌 31用保守制御機能は、
編 3夕一ゲットノードに対して ホップ数を した嫌3要求メッセージを ¾ する際 に、 觸 3要求メッセージに格納されるネットワーク構戯更後の通常アドレスに従って するか、 または、 漏己要求メッセージに格納されるネットワーク構 j« ^前の変換後ァドレ スに従って^ 31することを糊敷とする請求項 2 4に記載のフレーム ^確認プログラム。
2 6. 鎌 3テーブル書讓理機能は、
ネットワーク構厳更時に、 廳3フォヮ一ディングテ一ブルにおいて出力先力鞭となる ァドレスに対し、 Mf己ァドレスのー |5ビットをネットヮ一ク構 前と^後を区別する ビッ卜として、 ネットワーク構] «更時にァドレス変換を行い、
ネットワーク構 前と^後を示す fir ^フラグ情報を含むフレーム 経路確認要求 を fifths用保守制御部に対して発行する設定制御機能を tot己ノードに持たせ、
編 用保守制御機能は、
191己夕ーゲットノ一ドに対して前記ホップ数を した前記要求メッセージを する際 に、 嫌 3要求メッセージに格納される鎌 3フラグ情報がオフの はネットワーク構«¾ 後の通常アドレスに従って し、 鎌 3要求メッセージに格納される編己フラグ情報がオン の：^は鎌己ァドレス変換を行い、 変換後ァドレスに従って することを赚とする請求 項 2 4に記載のフレーム転逸経路確認プログラム。
2 7. 嫌 3テ—カレ書讓理機能は、
嫌己フォヮ一ディングテーブルにおいて、 編己ターゲットノードの MACァドレスの任意の ビットをネットワーク構 «S前と麵後を区別するビットとして、 ネットワーク構 時にァドレス変換することを とする請求項 2 5または請求項 2 6に記載のフレーム^ ¾ 経路確認プログラム。
2 8. 嫌 3テーブル «®理機能は、
嫌 3フォヮ一ディングテーブルにおいて、 嫌 3夕ーゲットノードの MACァドレスの上位 8 ビット目のマルチキャストビットをネットワーク構^ H前と 後を区別するビットとし て、 ネットワーク構] 時にァドレス変換することを纖とする請求項 2 7に記載のフレ ーム転送経路確認プログラム。
2 9. 編 3テーブル書纏理機能は、 鎌3フォヮ一ディングテーブルにおいて、 嫌己夕一ゲットノードの VLANタグの任意のビ ットをネットワーク構 前と変更後を区別するビットとして、 ネットワーク構 時 にアドレス変換することを樹敷とする請求項 2 5又は請求項 2 6に記載のフレーム ¾¾路 確認プログラム。
3 0. 編 3テーブル書観理機能は、
鎌己フォワーディングテーブルにおいて、 嫌己ターゲットノードの VLANタグの P r i o r i t yビットをネットワーク構^^前と変更後を区別するビットとして、 ネットワーク 構 時にアドレス変換することを體とする請求項 2 9に記載のフレーム 認 プログラム。
3 1. 嫌己テーブル書讓理機能は、
鎌己フォワーディングテ一ブルにおいて、 鎌己ターゲットノードの VLA タグの P r i o r i t yビットをネットワーク構)«¾前と麵後を区別するビットとして、 ネットワーク 構成^時のアドレス変換時に割り当てられていた P r i o r i t y値を 「0 1 0」 に変換 することを特徴とする請求項 3 0.に記載のフレーム転送経路確認プログラム。
3 2. 送信元端末から送信されるデータフレームを宛先端末に するネットワーク上の ノ一ドで実行させるフレーム転 怪路確認プログラムであって、
ネットワーク構) 時に、 觸 3デ一夕フレームの編 3アドレスに対する出力ポートおよ びネットワーク構 前と颜後を示すフラグ情報を搬するフォヮ一ディングテ一ブル において出力先が となるァドレスに対し、 鎌己フラグ情報を颜して嫌 3ァドレスを残 すテーフレ書讓理機能と、
嫌己フラグ情報を含むフレーム転逸怪路確認要求を発行する設定制御機能と、 婦己フレーム 確認要求を受け取り、 ターゲットノードに対して嫌 3ホップ数を減 算した嫌己要求メッセージを する際に、 嫌己要求メッセージをネットワーク構] 後 の通常アドレスに従って するか、 または、 嫌 3フラグ情報がオンであるネットワーク構 成颜前のァドレスに従って する運用保守制御機能とを鎌 3ノ一ドに持たせることを特 徴とするフレーム^怪路確認プログラム。
3 3. 運用保守制御機能は、
ターゲットノードに対してホップ数を格納した要求メッセージを生成、 送信し、 嫌 3夕一 ゲットノ一ドに対して鎌己ホップ数を した編 3要求メッセ一ジを錢し、 嫌 3ホップ数 を «した応答メッセージを要求メッセージ送信元ノードに返信し、 嫌 3応答メッセージを 受信すると前記ホップ数に従って降順または昇順に前記応答メッセージの並べ替えを行い、 嫌 3応答メッセージの送信元アドレスによって、 嫌 3送信元ノードから嫌己夕一ゲットノ一 ドまでの経由ノ一ド' I青幸 gを耳又 ί辱することを,とする請求項 2 4から請求項 3 3のいずれか 1項に記載のフレーム転逸経路確認プログラム。
3 4. 送信元端末から送信されるデータフレームを宛先端末に するネットワークのフ レーム 路確認システムにおレ ^て、
ネットワーク構 時に、 フォヮ一ディングテ一カレにおいて出力先力鞭となるァド レスに対し識 ij情報を付与して嫌己ァドレスを残し、
觀要求メッセ一ジを賺己識1』情報を付与して残したァドレスに基づいて して繊確 認することを特徴とするフレーム 怪路確認システム。
3 5. 送信元端末から送信されるデータフレームを宛先端末に ¾tするネットヮ一クにの フレーム転逸経路確認システムおいて、
ネットワーク構 «^時に、 フォワーディングテーブルにおいて出力先が ¾Μとなるアド レスに対し識 U情報を付与して嫌己ァドレスを残し、
編 3要求メッセ一ジを通常アドレスに基づいて して露確認するか、 または、 嫌 3識 別情報を付与して残したァドレスに基づレて して «確認することを體とするフレー ム転 経路確認システム。
3 6. 嫌己ネットワークが、 ノードが夕一ゲットノードに対してホップ数を格納した要求 メッセージを送信し、 中継ノードおよび嫌 3ターゲットノードは嫌己ホップ数を »した応 答メッセージを要求メッセージ送信元ノードに返信し、 編 3 ^言元ノードが嫌 3ホップ数に 従って嫌 3応答メッセージの並べ替えを行うことにより、 Ml己送信元ノ一ドから嫌 3タ一ゲ ットノードまでの経由ノ一ド情報を取得するネットヮ一クであることを糊敷とする請求項 3 4又は請求項 3 5に記載のフレーム 経路確認システム。
3 7. Ιίί ネットワークは、 ノードがターゲットノードに対してホップ数を格納した要求 メッセージを送信し、 中継ノードは嫌 3ターゲットノードに対して編己ホップ数を禱した 前記要求メッセージを ¾ すると共に前記ホップ数を減算した応答メッセージを要求メッセ ージ送信元ノードに返信し、 嫌 3ターゲットノードは嫌 Sホップ数を購した応答メッセ一 ジを要求メッセージ送信元ノードに返信し、 嫌 3送信元ノードは嫌 3応答メッセージの漏 3 ホップ数に従って降順または昇順に編己応答メッセージの並べ替えを行い、 嫌 3応答メッセ —ジの送信元アドレスによって、 嫌 3送信元ノードから編 3ターゲットノードまでの経由ノ 一ド情報を取得するネットワークであることを とする請求項 3 4又は請求項 3 5に記載 のフレーム転送経路確認、システム。
3 8. 嫌 3フォヮ一ディングテ一ブルにおいて出力先力鞭となるアドレスに対し iigij情 報を付与して編己ァドレスを残す際に、
廳3フォワーディングテーブルにおいて、 ネットワーク構 ¾ ^前と変更後を示すフラグ フィールドを設け、 ネットワーク構成変更時にフラグの値をオンに し、
鎌己要求メッセージに鎌己フラグ情報を格納して、 通常アドレスに従って するか、 ま たは、 鎌己識 U情報を付与して残したァドレスにしたがって して纖確認するかを指定 して、 経路確認することを赚とする請求項 3 5から請求項 3 7のいずれか 1項に記載のフ レーム 怪路確認システム。
3 9. 編己フォヮ一ディングテーブルにおいて出力先力鞭となるァドレスに対し識情 報を付与して前記ァドレスを残す際に、
鎌己フォヮ一ディングテ一ブルにおいて、 ァドレスの ットをネットワーク構 前と変更後を区別するビットとして、 ネットヮ一ク構成変更時にァドレス変換し、
嫌己要求メッセージに通常ァドレスまたは変換後ァドレスを格納して、 通常ァドレスに従 つて するか、 または、 変換後アドレスにしたがって転送して «確認するかを指定 して、 経路確認することを糊敷とする請求項 3 5力、ら請求項 3 7のいずれか 1項に記載のフ レーム 怪路確認システム。
4 0. 嫌己フォワーディングテーカレにおいて出力先力鞭となるアドレスに対し讕 IJ情 報を付与して嫌 3ァドレスを残す際に、
鎌 3フォヮーディングテ一ブルにおいて、 ァドレスの^ ¾ビットをネットワーク構 «更 前と颜後を区別するビットとして、 ネットワーク構成麵時にァドレス変換し、
嫌 3要求メッセージに編己フラグ情報を格納して、 通常アドレスに従って するか、 ま たは、 嫌己 ϋ ^情報を付与して残したァドレスにしたがって ¾iして «確認するかを指定 して、 嫌己 ^情報を付与して残したァドレスに従う：！^には鎌己各中継ノードにおいてァ ドレス変換したァドレスにしたがって I3要求メッセージを して∞確認、することを特 徴とする請求項 3 5から請求項 3 7のいずれか 1項に記載のフレーム 確認システム。
4 1. 編 3フォヮ一ディングテーブルにおいて、 ァドレスの^ ¾ビットをネットヮ一ク構 成 ^前と^後を区別するビットとして、 ネットワーク構成変更時にアドレス変換する際 に、
1513ァドレスの^ ¾ビットが嫌 3夕一ゲットノードの MACァドレスの任意のビットである ことを特徴とする請求項 3 9又は請求項 4 0に記載のフレーム転 経路確認システム。 4 2. 黼3フォワーディングテーブルにおいて、 アドレスの ビットをネットワーク構 成^前と変更後を区別するビットとして、 ネットワーク構成変更時にアドレス変換する際 に、
ΙϋΙ3ァドレスの一部ビッ卜が嫌己夕ーゲットノードの ACァドレスの上位 8ビット目のマ ルチキャストビットであることを樹敦とする請求項 4 1に記載のフレーム 路廳忍シス テム。
4 3. 前記フォワーディングテ一フレにおいて、 アドレスの一部ビットをネットワーク構 ^^前と麵後を区別するビットとして、 ネットワーク構 時にァドレス変換する際 に、 ffftSァドレスの一部ビットが前記ターゲットノードの VLA タグの任意のビットで とを特敷とする請求項 3 9又は請求項 4 0に記載のフレーム転送経路確認システム。
4 4. 前記フォヮ一ディングテ一ブルにおいて、 ァドレスの一部ビットをネットワーク構 成 前と ^後を区別するビットとして、 ネットワーク構 ¾ 時にァドレス変換する際 に、
嫌 3アドレスの^^ビットが嫌己ターゲットノードの VLANタグの P r i o r i t yビッ トであることを特徴とする請求項 4 3に記載のフレーム^ ¾経路確認システム。
4 5 . 鎌 3フォヮ一ディングテーブルにおいて、 ァドレスの ピットをネットワーク構 成 前と^後を区別するビットとして、 ネットワーク構] 時にァドレス変換する際 嫌己アドレスの ビットを嫌 3夕一ゲットノードの VLA タグの P r i o r i t yビッ トとして、 アドレス変換時に割り当てられていた P r i o r i t y値を 「0 1 0」 に変換す ることを特徴とする請求項 4 4に記載のフレーム転送経路確認システム。
4 6 . 前記フレームがィーサネットフレームであり、 前記ァドレスが MACァドレスまたは VLA タグであることを とする請求項 3 4から請求項 4 5のいずれか 1項に記載のフレ —ム^!;経路確認、システム。
PCT/JP2007/057357 2006-03-27 2007-03-27 フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム WO2007119635A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008510908A JPWO2007119635A1 (ja) 2006-03-27 2007-03-27 フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム
CN200780011237.8A CN101411138B (zh) 2006-03-27 2007-03-27 帧传送路由确认方法、节点、帧传送路由确认程序以及帧传送路由确认系统
US12/293,855 US8218446B2 (en) 2006-03-27 2007-03-27 Frame transfer route confirmation method, node, frame transfer route confirmation program and frame transfer route confirmation system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006084761 2006-03-27
JP2006-084761 2006-03-27

Publications (1)

Publication Number Publication Date
WO2007119635A1 true WO2007119635A1 (ja) 2007-10-25

Family

ID=38609399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/057357 WO2007119635A1 (ja) 2006-03-27 2007-03-27 フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム

Country Status (4)

Country Link
US (1) US8218446B2 (ja)
JP (1) JPWO2007119635A1 (ja)
CN (1) CN101411138B (ja)
WO (1) WO2007119635A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009246610A (ja) * 2008-03-31 2009-10-22 Kddi Corp 運用保守管理用のトレース要求を中継する方法、管理中継点装置及びプログラム
JP2010147732A (ja) * 2008-12-18 2010-07-01 Hitachi Ltd インターネット回線冗長化構成におけるマルチホーミング自動切換方式
JP2012156597A (ja) * 2011-01-21 2012-08-16 Ntt Communications Kk 情報処理装置、ネットワーク試験方法、及びプログラム
JP2013502774A (ja) * 2009-08-20 2013-01-24 中興通訊股▲ふん▼有限公司 光アクセスノードの管理方法及び光アクセスノード

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011055837A1 (ja) * 2009-11-05 2011-05-12 日本電気株式会社 ノード及びそれに用いる監視管理方法並びにそれを用いる転送システム、入力回路、出力回路
US8953621B2 (en) 2010-09-10 2015-02-10 Futurewei Technologies, Inc. Specifying priority on a virtual station interface discovery and configuration protocol response
IL209250A0 (en) * 2010-11-11 2011-01-31 Eci Telecom Ltd Technology for managing traffic via dual homed connections in communication networks
US9112794B2 (en) * 2013-11-05 2015-08-18 International Business Machines Corporation Dynamic multipath forwarding in software defined data center networks
US9647925B2 (en) 2014-11-05 2017-05-09 Huawei Technologies Co., Ltd. System and method for data path validation and verification

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10303913A (ja) * 1997-04-25 1998-11-13 Hitachi Ltd Ａｔｍネットワークにおける経路切り替え方式
JP2002111665A (ja) * 2000-09-27 2002-04-12 Fujitsu Denso Ltd ローカルエリアネットワーク監視装置
JP2005026902A (ja) * 2003-06-30 2005-01-27 Nec Engineering Ltd ネットワーク中継装置におけるネットワーク障害監視方法及びこれを適用した中継装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6580721B1 (en) * 1998-08-11 2003-06-17 Nortel Networks Limited Routing and rate control in a universal transfer mode network
US7143187B1 (en) * 2000-03-08 2006-11-28 Hitachi, Ltd. Packet communication control device and packet communication control method
US20020150099A1 (en) * 2001-04-13 2002-10-17 Pung Hung Keng Multicast routing method satisfying quality of service constraints, software and devices
JP4340400B2 (ja) * 2001-04-27 2009-10-07 富士通株式会社 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法
JP2003249949A (ja) 2002-02-22 2003-09-05 Nippon Telegr & Teleph Corp <Ntt> ネットワーク経路選択方法、ルータ及びそのプログラム並びに情報記録媒体
JP3934030B2 (ja) 2002-08-30 2007-06-20 株式会社エヌ・ティ・ティ・データ パケット通過ルート探索方法およびその方法をコンピュータに実行させるプログラム
US7924725B2 (en) * 2003-11-10 2011-04-12 Nortel Networks Limited Ethernet OAM performance management
US7483383B2 (en) * 2004-10-28 2009-01-27 Alcatel Lucent Stack manager protocol with automatic set up mechanism
JP4546351B2 (ja) 2005-07-29 2010-09-15 富士通株式会社 Ｉｐマルチキャストネットワークにおけるマルチキャストトレースルートシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10303913A (ja) * 1997-04-25 1998-11-13 Hitachi Ltd Ａｔｍネットワークにおける経路切り替え方式
JP2002111665A (ja) * 2000-09-27 2002-04-12 Fujitsu Denso Ltd ローカルエリアネットワーク監視装置
JP2005026902A (ja) * 2003-06-30 2005-01-27 Nec Engineering Ltd ネットワーク中継装置におけるネットワーク障害監視方法及びこれを適用した中継装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IWAMURA A. ET AL.: "Ethernet OAM (Y. 17ethoam) no Shosai Mechanism no Shokai", TECHNICAL REPORT OF IEICE CS2004-85, 21 October 2004 (2004-10-21), pages 35 - 40, XP003015099 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009246610A (ja) * 2008-03-31 2009-10-22 Kddi Corp 運用保守管理用のトレース要求を中継する方法、管理中継点装置及びプログラム
JP2010147732A (ja) * 2008-12-18 2010-07-01 Hitachi Ltd インターネット回線冗長化構成におけるマルチホーミング自動切換方式
JP2013502774A (ja) * 2009-08-20 2013-01-24 中興通訊股▲ふん▼有限公司 光アクセスノードの管理方法及び光アクセスノード
US8737234B2 (en) 2009-08-20 2014-05-27 Zte Corporation Method for administrating optical access nodes and optical access node thereof
JP2012156597A (ja) * 2011-01-21 2012-08-16 Ntt Communications Kk 情報処理装置、ネットワーク試験方法、及びプログラム

Also Published As

Publication number Publication date
US8218446B2 (en) 2012-07-10
US20090122800A1 (en) 2009-05-14
CN101411138A (zh) 2009-04-15
CN101411138B (zh) 2012-12-26
JPWO2007119635A1 (ja) 2009-08-27

Similar Documents

Publication Publication Date Title
WO2007119635A1 (ja) フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム
US8565124B2 (en) Node, network, correspondence relationship generation method and frame transfer program
US7672314B2 (en) Scaling VLANs in a data network
US7855955B2 (en) Method for managing frames in a global-area communications network, corresponding computer-readable storage medium and tunnel endpoint
US8705526B1 (en) Extending VPLS support for CE lag multi-homing
US8009683B2 (en) IP network system
US20100284418A1 (en) Method and system for telecommunications including self-organizing scalable ethernet using is-is hierarchy
US7864666B2 (en) Communication control apparatus, method and program thereof
KR20090003225A (ko) Ｍａｃ 브리지를 이용하여 멀티홉 메시 네트워크를 연결하기 위한 컴퓨터 구현 방법, 컴퓨터 판독가능 매체, 및 메시 네트워크 연결 장치
CN102484604A (zh) 用于在网络区域之间路由数据的技术
WO2007094520A1 (ja) ノード、ネットワークシステム、フレーム転送方法及びフレーム転送プログラム
CN105917617B (zh) 针对校园网中的线路速率性能的单跳叠加架构
CN101442467A (zh) 在基于运营商骨干网传送的网络中提供多点到多点连接的方法
CN101517966A (zh) 用于检测混合交换网络中的传输泄漏的方法
JP2010524370A (ja) イーサネット・スパニング・ツリープロビジョン
CN104079466B (zh) 一种报文处理方法和设备
CN101171802B (zh) 网络节点，网络，产生在网络中传送信息的对应关系产生方法
US20120158992A1 (en) Group Member Detection Among Nodes of a Network
US20120163381A1 (en) Multiple Label Based Processing of Frames
CN101197760B (zh) 虚拟专网服务中用户分组互通/隔离装置
CN104885428B (zh) 基于ip地址的udp中继的方法、中继器和计算机可读介质
Malhotra IP routing
CN102333024A (zh) 虚拟专用局域网业务vpls的数据帧的转发方法、设备和系统
WO2004084506A1 (ja) ルータ，フレーム転送方法および下位レイヤフレーム仮想転送システム
CN115426296B (zh) 在evpn vpws双归属双活下的连通确认方法、装置、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07740793

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008510908

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 200780011237.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12293855

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 07740793

Country of ref document: EP

Kind code of ref document: A1