US20020075873A1 - Method of protecting traffic in a mesh network - Google Patents
Method of protecting traffic in a mesh network Download PDFInfo
- Publication number
- US20020075873A1 US20020075873A1 US09/739,711 US73971100A US2002075873A1 US 20020075873 A1 US20020075873 A1 US 20020075873A1 US 73971100 A US73971100 A US 73971100A US 2002075873 A1 US2002075873 A1 US 2002075873A1
- Authority
- US
- United States
- Prior art keywords
- sequence number
- data packet
- traffic
- queue
- paths
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000012546 transfer Methods 0.000 abstract description 2
- 230000005540 biological transmission Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- RGNPBRKPHBKNKX-UHFFFAOYSA-N hexaflumuron Chemical compound C1=C(Cl)C(OC(F)(F)C(F)F)=C(Cl)C=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F RGNPBRKPHBKNKX-UHFFFAOYSA-N 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- 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
-
- 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/24—Multipath
-
- 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
Definitions
- This invention relates to the protection of traffic in a mesh network, and more particularly to the protection of traffic in a mesh network by using physically diverse transmission paths.
- a very small portion of the traffic requires highly reliable service, such as voice and video traffic.
- the traffic is fault intolerant in that it cannot afford to have call set up failure or to be dropped, and hence requires hitless switching.
- extremely fast restoration would be required to prevent such calls from being dropped in the case of a fault.
- a customer may be willing to pay for a higher degree of reliability (e.g. for mission critical applications) and in these cases it may also be desirable to provide hitless protection switching.
- the method is based on multiple physically diverse paths, each of the paths carrying data packets that have been duplicated in each of the other paths. That is, to achieve protection in the packet layer, a source node transmits the same data onto at least two physically diverse paths. A destination node receives the data packets and discards duplicate packets.
- the number of paths may be increased to achieve more reliability, but the paths must be physically diverse, as previously defined. Hence, the additional bandwidth required for providing protection for the traffic is dependent on the reliability desired and on the amount of protected traffic.
- embodiments of the invention use only packet selection and packet sequencing functions, and do not require the synchronization function of the prior art.
- the selection function is based on the expected sequence number of the next packet. This tends to favour packets from the leading path, but will select packets from any one of the other paths in the case of a fault, or a delay, on the leading path.
- packets are received from the paths, the next packet in the sequence is selected and transferred to the receiving queue of the destination node, while duplicate packets are discarded and future packets in the sequence are held in a holding queue for later selection.
- a method of protecting traffic in a mesh network comprising the steps of establishing at least two physically diverse paths from a source node to a destination node for transmitting data packets of the traffic; tagging, at the source node, each of said data packets with a sequence number; transmitting, by the source node, the tagged data packets onto the paths; receiving, at the destination node, the data packets transmitted over the paths; and reconstructing, at the destination node, the traffic from the received data packets.
- a method of receiving traffic in a mesh network comprising the steps of establishing at least two physically diverse paths from a source node to a destination node for carrying data packets of the traffic; receiving, at the destination node, the data packets transmitted over the paths; and reconstructing, at the destination node, the traffic from the received data packets.
- a network node for receiving protected traffic carried over physically diverse paths in a mesh network, the node comprising a plurality of receivers, each one of said receivers for connecting to one of the paths and being operable to receive data packets of the traffic, each of said data packets having a sequence number corresponding to its position in the traffic; a controller being operable to maintain an expected sequence number, the expected sequence number corresponding to the position in the traffic of a next data packet to be received; and a receiving queue for receiving the data packets.
- the controller is operable to cause a particular data packet to be delivered from any one of the receivers to the receiving queue responsive to the particular data packet having a sequence number equal to the expected sequence number.
- Advantages of embodiments of the invention are that they are scalable to provide multiple protection paths, and therefore greater protection, and are simple to implement since synchronization of data streams at the destination node is not required.
- FIG. 1 is a diagram of a mesh network
- FIG. 2 is a diagram representing the queues at the destination node according to a first embodiment of the invention
- FIG. 3 is a diagram of a mesh network in another configuration
- FIG. 4 is a flowchart of the method of protecting traffic according to a second embodiment of the invention.
- FIG. 5 is a flowchart detailing the step of setting up paths shown in FIG. 4;
- FIG. 6 is a flowchart detailing the step of tagging packets shown in FIG. 4;
- FIG. 7 is a flowchart detailing the step of reconstructing the traffic shown in FIG. 4.
- FIG. 8 is a block diagram of a portion of the source and destination nodes of FIG. 1, according to the first embodiment of the invention.
- a mesh network 10 for carrying data traffic includes a source node 12 and destination node 14 , which could be MPLS enabled IP routers for example.
- Three physically diverse paths P 1 , P 2 , and P 3 are available to carry traffic between the source node 12 and the destination node 14 .
- the first path P 1 carries traffic through intermediate nodes A and B over links 15 , 16 , and 17 , which interconnect the intermediate nodes A and B to the source and destination nodes 12 , 14 . These links could be SONET links for example.
- the second path P 2 carries traffic through an intermediate node C over the links 18 and 19 , which interconnect the intermediate node C to the source and destination nodes 12 , 14 .
- the third path P 3 carries traffic through three intermediate nodes D, E, and F over the links 20 , 21 , 22 , and 23 , which interconnect the intermediate nodes (D, E, and F) to the source and destination nodes 12 , 14 .
- the source, destination, and intermediate nodes are interconnected via the transmission links ( 15 to 23 ) to form a mesh communication network 10 , such that the three physically diverse paths (P 1 , P 2 , and P 3 ) can be established, thereby allowing the flow of traffic in the form of data packets from the source node 12 to the destination node 14 and vice versa.
- Protection of the traffic is based on multiple paths carrying duplicate data, for example paths P 1 , P 2 , and P 3 .
- Achieving 1+1 protection in the packet layer requires multicasting from the source node 12 onto at least two physically diverse paths.
- the destination node 14 is responsible for discarding duplicate packets.
- the number of physically diverse paths can be increased to achieve more reliability. This can be done on an “as needed” basis for a given user, or a period of time, or even for a portion of a path between the destination and source nodes.
- the bandwidth required for the protected traffic is dependent on the reliability desired, which affects the number of paths carrying duplicated data, and hence the overall bandwidth consumed by the protection scheme.
- services requiring high reliability typically constitute a very small portion of the network data traffic.
- Additional high-priority services may also include other types of voice and video traffic.
- Other mesh protection schemes could also be used in the network.
- the present method of protection uses physically diverse paths it does not rely on mesh restoration.
- the method requires that the source node 12 and destination node 14 be able to perform multicast, sequencing, packet selection, and discard functions, as will be described later.
- the multicast function is understood to mean that data packets sent over physically diverse paths will have the same data payload, and the same sequence number, but will have a different label identifier (e.g. a different label shim in the case of multi-protocol label switching (MPLS) protocol).
- MPLS multi-protocol label switching
- the rest of the network nodes i.e. apart from the source and destination nodes
- the method of protection does not require fault notification, hence inter-working between open system interconnection (OSI) layer 0 and layer 3 is not required.
- OSI open system interconnection
- the routers would eventually determine the failure, or fault notification could be obtained from the lower layers.
- the fault notification does not need to be fast since the present method of protection is not dependent on the fault notification.
- N There may be N different routes between a given source node 12 and destination node 14 . If there is a requirement for very high reliability (e.g. 911 services) and the ability to handle multiple simultaneous faults, then N will be a large number. For less critical data, or for data that does not require protection, N equals one. Data packets of the traffic requiring protection are multicast onto each of the N routes. If N equals 2 , this would be equivalent to 1+1 protection at layer 1 . However, this would only protect against one path experiencing a fault. In order to cover multiple fault scenarios, N needs to be increased.
- very high reliability e.g. 911 services
- An advantage of the present method of protection is that it is a path protection scheme, rather than a link protection scheme. Hence, the method uses less bandwidth than the corresponding 1+1 layer 1 SONET rings. Furthermore, if only a portion of the data packets being transmitted over a link are protected, then the method requires less protection bandwidth than link protection schemes. Therefore, the cost of protection is directly proportional to the desired quality of service of the traffic being carried and not to the bit rate of the links. Consequently, the cost, in terms of bandwidth, of protecting the protected traffic remains the same when the links are upgraded (e.g. OC 48 to OC 192 ). In the case of protection against multiple faults, since more paths are required, the bandwidth requirements for the protected traffic increases as the number of paths are increased.
- the proportion of protected traffic relative to unprotected traffic on the link would be relatively small.
- the savings in bandwidth could provide higher reliability of traffic selected for protection at the same cost as link protection schemes, albeit only for the selected traffic. For example, if the protected traffic represents only 10 percent of the link bandwidth, then there can be 10 protection paths before the same bandwidth as a link protection scheme is used.
- a further advantage of the present method of protection is that it is resilient to intermittent failures and “brownout” failures, as well as hard failures (e.g. fiber cuts), and transient failures, which cause link switchovers. As such, hold-off requirements to ensure the existence of a failure before a switchover is implemented are not required.
- the present method of protection provides a means of surviving multiple simultaneous failures and allowing for high priority traffic to continue as the network degrades gracefully with an increased number of simultaneous failures. Since the present method of protection allows for different levels of reliability by providing different numbers of paths, lower priority traffic will be affected first before higher priority traffic is affected, as the network degrades under multiple simultaneous failures. Still further, the present method provides the capability of adding more paths for high priority traffic, thereby enhancing the capability of the network to provide protection to high priority traffic.
- FIG. 2 which represents queues at the destination node according to a first embodiment of the invention
- Data packets are received from the source node 12 and stored in queues 30 at the destination node 14 .
- Path queues 32 , 34 , and 36 represent the queues corresponding to the first path P 1 , second path P 2 , and third path P 3 , respectively.
- Packets are stored in the path queues according to the order in which they are received, with the earliest packets received at time t- 7 and the most recent packets received at time t.
- the destination node 14 receives the data packets from each of the incoming paths (P 1 , P 2 , and P 3 ), but only accepts a packet onto a holding queue 38 if it has not yet received a packet with the same sequence identifier (ID) and label switched path (LSP) ID. The destination node 14 discards duplicate packets. Comparison of the data packets is based on the LSP ID and a sequence number assigned to each packet. The destination node 14 does any necessary reordering of packets when placing them into a receiving queue 40 .
- the path queue 34 for the second path P 2 receives packets 1 through 6 starting at time t- 7 .
- the first and second packets of this path queue 34 are immediately copied to the holding queue 38 .
- the path queue 32 for the first path P 1 receives packets 1 through 4 starting at time t- 5 and the path queue 36 for the third path P 3 receives the packets 1 and 2 starting at time t- 3 .
- none of the packets of the first path P 1 or the third path P 3 are copied to the holding queue 38 .
- the holding queue 38 has packets 3 and 4 interchanged in order, since they were received in this order, and the destination node 14 re-orders these packets when copying them to the receiving queue 40 .
- the other paths that do not have a fault will continue to carry packets. For example, if a fault occurred on the second path P 2 , then packets from the first path P 1 and the third path P 3 would be received in the path queues ( 32 and 36 ) and copied to the holding queue 38 or receiving queue 40 , accordingly. In this way, the destination node 14 will continue its acceptance of new packets, and discarding of duplicate packets, as before, with no interruption to the transfer of the protected traffic.
- the packets arriving at the destination node 14 from that path may be out of order. However, the other unaffected paths will continue to transmit, so this ‘fault’ in the network will be transparent to the receiving queue 40 of the destination node 14 .
- the present method does not address the potential need to ‘remove’ the failed path and allow the corresponding resources to be used for other new paths. In this case, it would be desirable to send fault notification to the source node 12 .
- An advantage of the present method of protection is that it effectively provides an immediate switch over from a failed path. Furthermore, the present method overcomes packet re-ordering problems, which may occur during rerouting, optimization, or de-fragmentation. Still further, the method is transparent to intermediate nodes (A-F), which means that no requirement additional to their normal functionality is required of these nodes. Only the source node 12 and destination node 14 need to be capable of performing the present method of protection. As long as MPLS paths are supported on the intermediate network nodes (A-F), these nodes need not be aware that there are multiple paths existing for this method of protection.
- FIG. 3 is a diagram of the mesh network in another configuration.
- An additional intermediate node G is shown connected between the intermediate nodes A and B, via another pair of links 24 , 25 represented by dotted lines.
- intermediate nodes A and B must be capable of performing the method of protection.
- the link 16 interconnecting of the nodes A and B is to be shut down, for example, for maintenance purposes. Traffic on the first path P 1 is to be routed over the intermediate node G before the link 16 is shut down. In this way, the degree of protection is maintained since, even though the link 16 is shut down, there are still three physically diverse paths for the protected traffic between the source and destination nodes 12 , 14 to be transmitted over.
- FIG. 4 shows the general steps of the method of protecting traffic according to the second embodiment of the present invention.
- the method starts by establishing at least two physically diverse paths, in step 100 , from the source node 12 to the destination node 14 for transmitting data packets of the traffic.
- step 110 each of the data packets for transmission is tagged with a sequence number by the source node 12 .
- the source node 12 transmits the tagged data packets onto the paths in step 110 .
- the destination node 14 receives the data packets transmitted over the paths, and reconstructs the traffic from the received data packets in step 140 .
- the paths are removed in step 180 .
- FIG. 4 depicts a serially executed procedure for the purpose of simplifying its explanation.
- tagging and transmitting packets (in step 110 ) at the source node 12 would be executed in parallel with receiving and reconstructing traffic (in steps 130 and 140 ) at the destination node 14 .
- a set of physically diverse paths is established from the source node 12 to the destination node 14 .
- the source and destination nodes 12 , 14 could be MPLS routers for example.
- the set of paths is identified in the nodes 12 , 14 as a protected set.
- Each path of the set is set up using a standard version of constrained route label distribution protocol (CR-LDP), or any other suitable protocol for setting up paths through the network.
- the paths are set up separately, with the first path P 1 being set up as a normal path in step 101 .
- the second path P 2 is set up in step 102 , a reference is made to the first path P 1 .
- step 103 the destination node 14 can associate the first path P 1 with the second path P 2 , thereby allowing the destination node 14 to perform further steps of the method of protection to the packets received from the two paths Pi, P 2 .
- Other paths as required by step 103 for example the third path P 3 , are set up in a similar manner by step 102 with reference made to the first path P 1 during set-up.
- step 110 data packets for the protected traffic are tagged with sequence numbers for reconstruction.
- a 32-bit sequence number updated in step 111 , is inserted, in step 112 , into the data packets before transmission.
- a larger sequence number could be used to accommodate higher bit rate links, for example 40 gigabit per second (Gbps) links. Updating the sequence number means incrementing the sequence number by one, but in the case of the first packet of a data stream transmission, there is no need to increment the sequence number.
- a 32-bit sequence number is one that is long enough not to wraparound. It is used to accommodate a time difference of 100 milliseconds, which represents worst-case scenario in delay variance. For a 10 Gbps link and packet size of 64 bytes, there will be about 2 ⁇ 10**6 packets. A 32-bit sequence number will accommodate roughly 4 ⁇ 10**9 packets and therefore with the 100 millisecond delay variance, wrapping around of the sequence number, which causes resequencing failure, should not occur. To be compatible with the existing MPLS protocol, a sequence number, in a label shim, will be pushed onto the label stack space along with other labels on the stack.
- the destination node 14 will be operable to pop the label stack twice, the second pop being required to retrieve the sequence number of the data packet from the stack.
- step 110 the source node 12 enqueues a copy of tagged packets onto each path in step 113 and transmits these packets. That is, the data packets are simultaneously transmitted onto the physically diverse paths P 1 -P 3 by the source node 12 . The data packets are transmitted on the paths P 1 -P 3 and enter the transmission stream like any other labelled packets. Responsive to more packets to be sent in step 114 , execution of the method returns to updating the sequence number (step 111 ) if more packets are to be sent, otherwise, execution of the method proceeds to step 130 of receiving tagged packets at the destination node.
- step 130 the tagged data packets are received from the paths P 1 -P 3 .
- the destination node 14 copies the received data packets into the respective path queues 32 , 34 , and 36 , or buffers as the case may be.
- the destination node 14 reconstructs the protected traffic from the data packets received in the step 130 .
- the current packet is set to a received data packet. Initially, the current packet set by the step 142 would be the first received data packet and on subsequent executions of the step 142 it would be set to the next data packet, from any of the paths.
- the destination node 14 retrieves the packet sequence number (PSN) from the received packet (the current packet).
- PSN packet sequence number
- step 146 if the packet sequence number of this packet equals the expected sequence number (ESN), which initially would equal the packet sequence number of the first received packet, then execution of the method proceeds to step 148 in which the current packet is delivered to the receiving queue 40 .
- step 152 Responsive to any packets being in the holding queue 38 , in step 152 , a determination whether or not the expected sequence number is in the holding queue 38 is made, in step 158 . This is done by comparing the sequence number of each data packet in the holding queue 38 against the expected sequence number. If a data packet having a sequence number equal to the expected sequence number is in the holding queue 38 , then execution of the method proceeds to step 160 of setting the current packet to the packet in the holding queue with the expected sequence number. Then in step 162 , the packet sequence number is set to the sequence number from the current packet, and execution of the method proceeds to the step 148 of delivering the current packet to the receiving queue 40 . However, if the expected sequence number is not in the holding queue 38 , execution of the method proceeds to step 154 , in which a determination of whether or not there are anymore received packets is made.
- step 142 of setting the current packet to the next received packet.
- step 156 a determination of whether or not a timer has expired is made.
- step 174 execution of the method proceeds to step 174 in which the current packet is set to the packet associated with the expired timer. Execution of the method then proceeds to the step 162 of setting the packet sequence number to the sequence number of the current packet.
- step 180 a determination of whether or not the paths should be taken down is made. This would typically be done by the source node 12 in the case of unidirectional transmission, and by either node in the case of bi-directional transmission. If the paths are to be taken down, the paths are removed and this is the end of the method. Otherwise, execution of the method at the destination node 14 continues from step 130 of receiving tagged packets.
- step 152 if there are no packets in the holding queue, then execution of the method continues from step 154 .
- step 146 if the packet sequence number does not equal the expected sequence number, then execution of the method continues to step 164 , and responsive to the packet sequence number being less than the expected sequence number, the current packet is discarded in step 168 . Execution of the method then continues from step 154 .
- step 166 Responsive to the packet sequence number not being less than expected sequence number in step 164 , a determination is made, in step 166 , whether or not the packet sequence number is in the holding queue 38 . This is done by comparing the sequence number of each data packet in the holding queue 38 against the packet sequence number. If a data packet having a sequence number equal to the packet sequence number is in the holding queue 38 , then the current packet is discarded in step 168 . However, if the packet sequence number is not in the holding queue 38 , execution of the method proceeds to step 170 , where the current packet is stored in the holding queue 38 , and then a timer for the current packet is started in step 172 .
- the value of the timer is chosen based on the performance of the network, which affects the delay variance between the paths P 1 -P 3 . For example, the value of the timer could be set to twice this delay variance. Execution of the method then continues to step 154 .
- FIG. 8 is a block diagram of portions of the source and destination nodes according to the first embodiment of the invention.
- the features shown in the source and destination nodes 12 , 14 are for a unidirectional traffic flow across the physically diverse paths P 1 -P 3 .
- the source node 12 would include all the features of the destination node 14 , and vice versa.
- the source node 12 includes a controller 200 communicatively coupled via a connection 201 to its other source processes 202 (e.g. the other protocol layers which receive data from users or other network nodes).
- Control messages flow over the connection 201 as well as data packets of the protected traffic.
- the controller 200 is bi-directionally connected via a system bus 203 to a memory 204 .
- the system bus is operable to provide connections 205 to transmit queues 206 a - 206 n , which are part of the memory 204 .
- the system bus 203 is also operable to provide a connection 207 to a location in the memory 204 , which holds a sequence number 208 .
- a transmission bus 209 connects the transmission queues 206 a - 206 n to respective transmitters 210 a - 210 n , which transmit data packets from the queues 206 a - 206 n onto the physically diverse paths P 1 , P 2 , P 3 , in response to a control signal provided via a connection 211 to the controller 200 .
- the destination node 14 includes a controller 300 communicatively coupled via a connection 301 to destination processes 302 (e.g. other protocol layers which send/receive data to/from users or other network nodes).
- a system bus 303 bi-directionally connects the controller 300 to a memory 304 .
- the bus 303 is operable to provide a connection 305 to memory storage locations 306 a - 306 n , which provide storage for the path queues 32 , 34 , 36 , previously mentioned.
- the bus 303 is also operable to provide a connection 307 to a location 308 in the memory 304 that holds the expected sequence number; another location 309 in the memory 304 for storing the current packet or an indication thereof such as a memory pointer; and two locations 310 , 312 in the memory 304 for the receiving queue 40 and for the holding queue 38 , respectively.
- a receive bus 313 connects a plurality of receivers 314 a - 314 n to the memory locations 306 a - 306 n , for transferring data packets received from the respective physically diverse paths P 1 , P 2 , P 3 to their respective path queues 32 , 34 , 36 .
- a connection 315 from the plurality of receivers 314 a - 314 n to the controller 300 provides the controller with an indication as packets are received.
- the controller 300 further includes timers 316 each of which is for timing a maximum duration that a packet is to remain in the holding queue 38 .
- the controller 200 executes a method which provides coordination for performing the steps of setting up the paths (step 100 ), tagging packet sequence numbers (step 110 ), and transmitting the tagged packets (step 120 ), as described earlier.
- the steps are performed by the controller 200 along with the other elements of the source node 12 described above. Therefore, the source node 12 has the means for setting up physically diverse paths, tagging packets with sequence numbers, updating the sequence number and inserting it into packets, enqueuing copies of tagged packets onto each path, and transmitting the tagged packets onto the paths, as described earlier with respect to the present method of protection.
- the controller 300 executes a method, which provides coordination for performing the steps of setting up the paths (step 100 ), receiving tagged packets (step 130 ), and reconstructing traffic (step 140 ), as described earlier. The steps are performed by the controller 300 along with the other elements of the destination node 14 described above.
- the destination node 14 has the means for setting up physically diverse paths, retrieving packet sequence numbers from received packets, updating the expected sequence number, comparing packet sequence numbers with the expected sequence number, delivering packets from the path queues to the holding queue or receiving queue, delivering packets from the holding queue to the receiving queue, discarding packets, and keeping a timer for a packet in the holding queue 38 , as described earlier with respect to the present method of protection.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- This invention relates to the protection of traffic in a mesh network, and more particularly to the protection of traffic in a mesh network by using physically diverse transmission paths.
- Communications networks can suffer from failures or service degradation, both of which often cause tangible losses to users as well as the network providers. Redundant transmission on physically diverse paths is a common precaution against the effects of failures in communication networks. Hereinafter, physically diverse is defined as meaning that a single failure will affect only one given path. In optical fiber networks the restoration time must be as short as possible since line bit rates are very high. Furthermore, some services require a high degree of reliability because they may be adversely affected by any amount of bit loss. For these types of services, protection switching without bit loss (hitless protection switching, hereafter) is desired.
- Typically, in a communication network a very small portion of the traffic requires highly reliable service, such as voice and video traffic. In some cases, for example with911 services, the traffic is fault intolerant in that it cannot afford to have call set up failure or to be dropped, and hence requires hitless switching. In a mesh network, extremely fast restoration would be required to prevent such calls from being dropped in the case of a fault. In other cases, a customer may be willing to pay for a higher degree of reliability (e.g. for mission critical applications) and in these cases it may also be desirable to provide hitless protection switching.
- Known approaches that provide hitless switching usually involve error detection, synchronization, and selection algorithms. For example, in a paper entitled “A New Synchronization Algorithm for Hitless Protection Switching in ATM Networks” in IEEE paper 0-7803-5258 -0/99 by Andreas Iselt, a method of hitless protection switching is described. Synchronization of the two data streams is an important aspect of the method and involves three phases: a hunt phase, a validation phase and a monitoring phase. While the method described by Iselt provides adequate synchronization for hitless switching, it may be quite complex to implement. Furthermore, it is not easily adapted to provide greater protection, for example using more than two paths, which could be useful for 911 services for example, to protect against multiple faults in the network.
- Therefore, a method of protecting traffic that is simple to implement and is scalable for selectable degrees of reliability against network faults is desired.
- It is an object of the present invention to provide an improved method of protecting traffic in a mesh network.
- The method is based on multiple physically diverse paths, each of the paths carrying data packets that have been duplicated in each of the other paths. That is, to achieve protection in the packet layer, a source node transmits the same data onto at least two physically diverse paths. A destination node receives the data packets and discards duplicate packets. The number of paths may be increased to achieve more reliability, but the paths must be physically diverse, as previously defined. Hence, the additional bandwidth required for providing protection for the traffic is dependent on the reliability desired and on the amount of protected traffic.
- At the destination node, embodiments of the invention use only packet selection and packet sequencing functions, and do not require the synchronization function of the prior art. The selection function is based on the expected sequence number of the next packet. This tends to favour packets from the leading path, but will select packets from any one of the other paths in the case of a fault, or a delay, on the leading path. In effect, packets are received from the paths, the next packet in the sequence is selected and transferred to the receiving queue of the destination node, while duplicate packets are discarded and future packets in the sequence are held in a holding queue for later selection.
- According to an aspect of the present invention there is provided a method of protecting traffic in a mesh network, the method comprising the steps of establishing at least two physically diverse paths from a source node to a destination node for transmitting data packets of the traffic; tagging, at the source node, each of said data packets with a sequence number; transmitting, by the source node, the tagged data packets onto the paths; receiving, at the destination node, the data packets transmitted over the paths; and reconstructing, at the destination node, the traffic from the received data packets.
- According to another aspect of the present invention there is provided a method of receiving traffic in a mesh network, the method comprising the steps of establishing at least two physically diverse paths from a source node to a destination node for carrying data packets of the traffic; receiving, at the destination node, the data packets transmitted over the paths; and reconstructing, at the destination node, the traffic from the received data packets.
- According to still another aspect of the present invention there is provided a network node for receiving protected traffic carried over physically diverse paths in a mesh network, the node comprising a plurality of receivers, each one of said receivers for connecting to one of the paths and being operable to receive data packets of the traffic, each of said data packets having a sequence number corresponding to its position in the traffic; a controller being operable to maintain an expected sequence number, the expected sequence number corresponding to the position in the traffic of a next data packet to be received; and a receiving queue for receiving the data packets. The controller is operable to cause a particular data packet to be delivered from any one of the receivers to the receiving queue responsive to the particular data packet having a sequence number equal to the expected sequence number.
- Advantages of embodiments of the invention are that they are scalable to provide multiple protection paths, and therefore greater protection, and are simple to implement since synchronization of data streams at the destination node is not required.
- The invention will be further understood from the following detailed description of embodiments of the invention with reference to the accompanying drawings, in which:
- FIG. 1 is a diagram of a mesh network;
- FIG. 2 is a diagram representing the queues at the destination node according to a first embodiment of the invention;
- FIG. 3 is a diagram of a mesh network in another configuration;
- FIG. 4 is a flowchart of the method of protecting traffic according to a second embodiment of the invention;
- FIG. 5 is a flowchart detailing the step of setting up paths shown in FIG. 4;
- FIG. 6 is a flowchart detailing the step of tagging packets shown in FIG. 4;
- FIG. 7 is a flowchart detailing the step of reconstructing the traffic shown in FIG. 4; and
- FIG. 8 is a block diagram of a portion of the source and destination nodes of FIG. 1, according to the first embodiment of the invention.
- Referring to FIG. 1, a
mesh network 10 for carrying data traffic, for example IP traffic, includes asource node 12 anddestination node 14, which could be MPLS enabled IP routers for example. Three physically diverse paths P1, P2, and P3 are available to carry traffic between thesource node 12 and thedestination node 14. The first path P1 carries traffic through intermediate nodes A and B overlinks destination nodes links destination nodes links destination nodes mesh communication network 10, such that the three physically diverse paths (P1, P2, and P3) can be established, thereby allowing the flow of traffic in the form of data packets from thesource node 12 to thedestination node 14 and vice versa. - Protection of the traffic is based on multiple paths carrying duplicate data, for example paths P1, P2, and P3. Achieving 1+1 protection in the packet layer requires multicasting from the
source node 12 onto at least two physically diverse paths. Thedestination node 14 is responsible for discarding duplicate packets. The number of physically diverse paths can be increased to achieve more reliability. This can be done on an “as needed” basis for a given user, or a period of time, or even for a portion of a path between the destination and source nodes. The bandwidth required for the protected traffic is dependent on the reliability desired, which affects the number of paths carrying duplicated data, and hence the overall bandwidth consumed by the protection scheme. However, services requiring high reliability (e.g. 911 services) typically constitute a very small portion of the network data traffic. Additional high-priority services may also include other types of voice and video traffic. Other mesh protection schemes could also be used in the network. - Since the present method of protection uses physically diverse paths it does not rely on mesh restoration. The method requires that the
source node 12 anddestination node 14 be able to perform multicast, sequencing, packet selection, and discard functions, as will be described later. The multicast function is understood to mean that data packets sent over physically diverse paths will have the same data payload, and the same sequence number, but will have a different label identifier (e.g. a different label shim in the case of multi-protocol label switching (MPLS) protocol). The rest of the network nodes (i.e. apart from the source and destination nodes) could be generic routers, for example, ones with MPLS capability. The method of protection does not require fault notification, hence inter-working between open system interconnection (OSI) layer 0 andlayer 3 is not required. When a path does fail, the routers would eventually determine the failure, or fault notification could be obtained from the lower layers. However, the fault notification does not need to be fast since the present method of protection is not dependent on the fault notification. - There may be N different routes between a given
source node 12 anddestination node 14. If there is a requirement for very high reliability (e.g. 911 services) and the ability to handle multiple simultaneous faults, then N will be a large number. For less critical data, or for data that does not require protection, N equals one. Data packets of the traffic requiring protection are multicast onto each of the N routes. If N equals 2, this would be equivalent to 1+1 protection atlayer 1. However, this would only protect against one path experiencing a fault. In order to cover multiple fault scenarios, N needs to be increased. - An advantage of the present method of protection is that it is a path protection scheme, rather than a link protection scheme. Hence, the method uses less bandwidth than the corresponding 1+1
layer 1 SONET rings. Furthermore, if only a portion of the data packets being transmitted over a link are protected, then the method requires less protection bandwidth than link protection schemes. Therefore, the cost of protection is directly proportional to the desired quality of service of the traffic being carried and not to the bit rate of the links. Consequently, the cost, in terms of bandwidth, of protecting the protected traffic remains the same when the links are upgraded (e.g. OC48 to OC192). In the case of protection against multiple faults, since more paths are required, the bandwidth requirements for the protected traffic increases as the number of paths are increased. However, typically the proportion of protected traffic relative to unprotected traffic on the link would be relatively small. By protecting only a portion of the link traffic the savings in bandwidth could provide higher reliability of traffic selected for protection at the same cost as link protection schemes, albeit only for the selected traffic. For example, if the protected traffic represents only 10 percent of the link bandwidth, then there can be 10 protection paths before the same bandwidth as a link protection scheme is used. - A further advantage of the present method of protection is that it is resilient to intermittent failures and “brownout” failures, as well as hard failures (e.g. fiber cuts), and transient failures, which cause link switchovers. As such, hold-off requirements to ensure the existence of a failure before a switchover is implemented are not required. Furthermore, the present method of protection provides a means of surviving multiple simultaneous failures and allowing for high priority traffic to continue as the network degrades gracefully with an increased number of simultaneous failures. Since the present method of protection allows for different levels of reliability by providing different numbers of paths, lower priority traffic will be affected first before higher priority traffic is affected, as the network degrades under multiple simultaneous failures. Still further, the present method provides the capability of adding more paths for high priority traffic, thereby enhancing the capability of the network to provide protection to high priority traffic.
- Referring to FIG. 2, which represents queues at the destination node according to a first embodiment of the invention, an overview of receiving data packets and reconstructing traffic at the destination node will be given. Data packets are received from the
source node 12 and stored inqueues 30 at thedestination node 14.Path queues destination node 14 receives the data packets from each of the incoming paths (P1, P2, and P3), but only accepts a packet onto a holdingqueue 38 if it has not yet received a packet with the same sequence identifier (ID) and label switched path (LSP) ID. Thedestination node 14 discards duplicate packets. Comparison of the data packets is based on the LSP ID and a sequence number assigned to each packet. Thedestination node 14 does any necessary reordering of packets when placing them into a receivingqueue 40. - Referring to FIG. 2, the
path queue 34 for the second path P2 receivespackets 1 through 6 starting at time t-7. The first and second packets of thispath queue 34 are immediately copied to the holdingqueue 38. Thepath queue 32 for the first path P1 receivespackets 1 through 4 starting at time t-5 and thepath queue 36 for the third path P3 receives thepackets queue 38. The holdingqueue 38 haspackets destination node 14 re-orders these packets when copying them to the receivingqueue 40. - If a fault occurs on one of the paths, the other paths that do not have a fault will continue to carry packets. For example, if a fault occurred on the second path P2, then packets from the first path P1 and the third path P3 would be received in the path queues (32 and 36) and copied to the holding
queue 38 or receivingqueue 40, accordingly. In this way, thedestination node 14 will continue its acceptance of new packets, and discarding of duplicate packets, as before, with no interruption to the transfer of the protected traffic. - If one of the paths is rearranged, for example via rerouting as required for network optimization or defragmentation, the packets arriving at the
destination node 14 from that path may be out of order. However, the other unaffected paths will continue to transmit, so this ‘fault’ in the network will be transparent to the receivingqueue 40 of thedestination node 14. - The present method does not address the potential need to ‘remove’ the failed path and allow the corresponding resources to be used for other new paths. In this case, it would be desirable to send fault notification to the
source node 12. - An advantage of the present method of protection is that it effectively provides an immediate switch over from a failed path. Furthermore, the present method overcomes packet re-ordering problems, which may occur during rerouting, optimization, or de-fragmentation. Still further, the method is transparent to intermediate nodes (A-F), which means that no requirement additional to their normal functionality is required of these nodes. Only the
source node 12 anddestination node 14 need to be capable of performing the present method of protection. As long as MPLS paths are supported on the intermediate network nodes (A-F), these nodes need not be aware that there are multiple paths existing for this method of protection. - FIG. 3 is a diagram of the mesh network in another configuration. An additional intermediate node G is shown connected between the intermediate nodes A and B, via another pair of
links link 16 interconnecting of the nodes A and B is to be shut down, for example, for maintenance purposes. Traffic on the first path P1 is to be routed over the intermediate node G before thelink 16 is shut down. In this way, the degree of protection is maintained since, even though thelink 16 is shut down, there are still three physically diverse paths for the protected traffic between the source anddestination nodes - FIG. 4 shows the general steps of the method of protecting traffic according to the second embodiment of the present invention. The method starts by establishing at least two physically diverse paths, in
step 100, from thesource node 12 to thedestination node 14 for transmitting data packets of the traffic. Next, instep 110, each of the data packets for transmission is tagged with a sequence number by thesource node 12. Thesource node 12 transmits the tagged data packets onto the paths instep 110. Next, instep 130, thedestination node 14 receives the data packets transmitted over the paths, and reconstructs the traffic from the received data packets instep 140. When traffic flow between thesource node 12 anddestination node 14 has ceased, the paths are removed instep 180. - It should be noted that FIG. 4 depicts a serially executed procedure for the purpose of simplifying its explanation. Of course, tagging and transmitting packets (in step110) at the
source node 12 would be executed in parallel with receiving and reconstructing traffic (insteps 130 and 140) at thedestination node 14. - Referring to FIG. 5, which shows the
step 100 in greater detail, a set of physically diverse paths is established from thesource node 12 to thedestination node 14. The source anddestination nodes nodes step 101. When the second path P2 is set up instep 102, a reference is made to the first path P1. This is done so that thedestination node 14 can associate the first path P1 with the second path P2, thereby allowing thedestination node 14 to perform further steps of the method of protection to the packets received from the two paths Pi, P2. Other paths as required bystep 103, for example the third path P3, are set up in a similar manner bystep 102 with reference made to the first path P1 during set-up. - Referring to FIG. 6, which shows the
step 110 in greater detail, data packets for the protected traffic are tagged with sequence numbers for reconstruction. For reconstructing out of sequence packets, a 32-bit sequence number, updated instep 111, is inserted, instep 112, into the data packets before transmission. A larger sequence number could be used to accommodate higher bit rate links, for example 40 gigabit per second (Gbps) links. Updating the sequence number means incrementing the sequence number by one, but in the case of the first packet of a data stream transmission, there is no need to increment the sequence number. - A 32-bit sequence number is one that is long enough not to wraparound. It is used to accommodate a time difference of 100 milliseconds, which represents worst-case scenario in delay variance. For a 10 Gbps link and packet size of 64 bytes, there will be about 2×10**6 packets. A 32-bit sequence number will accommodate roughly 4×10**9 packets and therefore with the 100 millisecond delay variance, wrapping around of the sequence number, which causes resequencing failure, should not occur. To be compatible with the existing MPLS protocol, a sequence number, in a label shim, will be pushed onto the label stack space along with other labels on the stack. Since the set of paths P1-P3 is known to the two
nodes destination node 14 will be operable to pop the label stack twice, the second pop being required to retrieve the sequence number of the data packet from the stack. - Continuing in step110 (FIG. 6), the
source node 12 enqueues a copy of tagged packets onto each path instep 113 and transmits these packets. That is, the data packets are simultaneously transmitted onto the physically diverse paths P1-P3 by thesource node 12. The data packets are transmitted on the paths P1-P3 and enter the transmission stream like any other labelled packets. Responsive to more packets to be sent instep 114, execution of the method returns to updating the sequence number (step 111) if more packets are to be sent, otherwise, execution of the method proceeds to step 130 of receiving tagged packets at the destination node. - In
step 130 the tagged data packets are received from the paths P1-P3. When the data packets exit from the paths P1-P3, thedestination node 14 copies the received data packets into therespective path queues - Referring to FIG. 7, which shows the
step 140 of reconstructing traffic in greater detail, thedestination node 14 reconstructs the protected traffic from the data packets received in thestep 130. Instep 142 the current packet is set to a received data packet. Initially, the current packet set by thestep 142 would be the first received data packet and on subsequent executions of thestep 142 it would be set to the next data packet, from any of the paths. Next, instep 144, thedestination node 14 retrieves the packet sequence number (PSN) from the received packet (the current packet). Instep 146, if the packet sequence number of this packet equals the expected sequence number (ESN), which initially would equal the packet sequence number of the first received packet, then execution of the method proceeds to step 148 in which the current packet is delivered to the receivingqueue 40. The expected sequence number is then updated (ESN=PSN+1) instep 150, by incrementing the packet sequence number by one. - Responsive to any packets being in the holding
queue 38, instep 152, a determination whether or not the expected sequence number is in the holdingqueue 38 is made, instep 158. This is done by comparing the sequence number of each data packet in the holdingqueue 38 against the expected sequence number. If a data packet having a sequence number equal to the expected sequence number is in the holdingqueue 38, then execution of the method proceeds to step 160 of setting the current packet to the packet in the holding queue with the expected sequence number. Then instep 162, the packet sequence number is set to the sequence number from the current packet, and execution of the method proceeds to thestep 148 of delivering the current packet to the receivingqueue 40. However, if the expected sequence number is not in the holdingqueue 38, execution of the method proceeds to step 154, in which a determination of whether or not there are anymore received packets is made. - Responsive to there being received packets, execution of the method proceeds back to the
step 142 of setting the current packet to the next received packet. However, if there are no more received packets, execution of the method proceeds to step 156 in which a determination of whether or not a timer has expired is made. - If a timer has expired, execution of the method proceeds to step174 in which the current packet is set to the packet associated with the expired timer. Execution of the method then proceeds to the
step 162 of setting the packet sequence number to the sequence number of the current packet. - If a timer has not expired, execution of the method proceeds to step180, shown in FIG. 4, where a determination of whether or not the paths should be taken down is made. This would typically be done by the
source node 12 in the case of unidirectional transmission, and by either node in the case of bi-directional transmission. If the paths are to be taken down, the paths are removed and this is the end of the method. Otherwise, execution of the method at thedestination node 14 continues fromstep 130 of receiving tagged packets. - Returning to step152, if there are no packets in the holding queue, then execution of the method continues from
step 154. - Returning to step146, if the packet sequence number does not equal the expected sequence number, then execution of the method continues to step 164, and responsive to the packet sequence number being less than the expected sequence number, the current packet is discarded in
step 168. Execution of the method then continues fromstep 154. - Responsive to the packet sequence number not being less than expected sequence number in
step 164, a determination is made, instep 166, whether or not the packet sequence number is in the holdingqueue 38. This is done by comparing the sequence number of each data packet in the holdingqueue 38 against the packet sequence number. If a data packet having a sequence number equal to the packet sequence number is in the holdingqueue 38, then the current packet is discarded instep 168. However, if the packet sequence number is not in the holdingqueue 38, execution of the method proceeds to step 170, where the current packet is stored in the holdingqueue 38, and then a timer for the current packet is started instep 172. The value of the timer is chosen based on the performance of the network, which affects the delay variance between the paths P1-P3. For example, the value of the timer could be set to twice this delay variance. Execution of the method then continues to step 154. - Referring to FIG. 8, which is a block diagram of portions of the source and destination nodes according to the first embodiment of the invention, more details of the structure of these nodes will now be given. The features shown in the source and
destination nodes source node 12 would include all the features of thedestination node 14, and vice versa. Thesource node 12 includes acontroller 200 communicatively coupled via aconnection 201 to its other source processes 202 (e.g. the other protocol layers which receive data from users or other network nodes). Control messages, such as connection and flow control messages, flow over theconnection 201 as well as data packets of the protected traffic. Thecontroller 200 is bi-directionally connected via asystem bus 203 to amemory 204. The system bus is operable to provideconnections 205 to transmit queues 206 a-206 n, which are part of thememory 204. Thesystem bus 203 is also operable to provide aconnection 207 to a location in thememory 204, which holds asequence number 208. Atransmission bus 209 connects the transmission queues 206 a-206 n to respective transmitters 210 a-210 n, which transmit data packets from the queues 206 a-206 n onto the physically diverse paths P1, P2, P3, in response to a control signal provided via aconnection 211 to thecontroller 200. - The
destination node 14 includes acontroller 300 communicatively coupled via aconnection 301 to destination processes 302 (e.g. other protocol layers which send/receive data to/from users or other network nodes). Asystem bus 303 bi-directionally connects thecontroller 300 to amemory 304. Thebus 303 is operable to provide aconnection 305 to memory storage locations 306 a-306 n, which provide storage for thepath queues bus 303 is also operable to provide aconnection 307 to alocation 308 in thememory 304 that holds the expected sequence number; anotherlocation 309 in thememory 304 for storing the current packet or an indication thereof such as a memory pointer; and twolocations memory 304 for the receivingqueue 40 and for the holdingqueue 38, respectively. A receivebus 313 connects a plurality of receivers 314 a-314 n to the memory locations 306 a-306 n, for transferring data packets received from the respective physically diverse paths P1, P2, P3 to theirrespective path queues connection 315 from the plurality of receivers 314 a-314 n to thecontroller 300 provides the controller with an indication as packets are received. Thecontroller 300 further includestimers 316 each of which is for timing a maximum duration that a packet is to remain in the holdingqueue 38. - Referring again to the
source node 12, thecontroller 200 executes a method which provides coordination for performing the steps of setting up the paths (step 100), tagging packet sequence numbers (step 110), and transmitting the tagged packets (step 120), as described earlier. The steps are performed by thecontroller 200 along with the other elements of thesource node 12 described above. Therefore, thesource node 12 has the means for setting up physically diverse paths, tagging packets with sequence numbers, updating the sequence number and inserting it into packets, enqueuing copies of tagged packets onto each path, and transmitting the tagged packets onto the paths, as described earlier with respect to the present method of protection. - Referring again to the
destination node 14, thecontroller 300 executes a method, which provides coordination for performing the steps of setting up the paths (step 100), receiving tagged packets (step 130), and reconstructing traffic (step 140), as described earlier. The steps are performed by thecontroller 300 along with the other elements of thedestination node 14 described above. Therefore, thedestination node 14 has the means for setting up physically diverse paths, retrieving packet sequence numbers from received packets, updating the expected sequence number, comparing packet sequence numbers with the expected sequence number, delivering packets from the path queues to the holding queue or receiving queue, delivering packets from the holding queue to the receiving queue, discarding packets, and keeping a timer for a packet in the holdingqueue 38, as described earlier with respect to the present method of protection. - Numerous alterations, variations and adaptations to the embodiments of the invention described above are possible within the scope of the invention, which is defined by the claims.
Claims (14)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/739,711 US6853641B2 (en) | 2000-12-20 | 2000-12-20 | Method of protecting traffic in a mesh network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/739,711 US6853641B2 (en) | 2000-12-20 | 2000-12-20 | Method of protecting traffic in a mesh network |
Publications (2)
Publication Number | Publication Date |
---|---|
US20020075873A1 true US20020075873A1 (en) | 2002-06-20 |
US6853641B2 US6853641B2 (en) | 2005-02-08 |
Family
ID=24973461
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/739,711 Expired - Lifetime US6853641B2 (en) | 2000-12-20 | 2000-12-20 | Method of protecting traffic in a mesh network |
Country Status (1)
Country | Link |
---|---|
US (1) | US6853641B2 (en) |
Cited By (59)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020089712A1 (en) * | 2001-01-10 | 2002-07-11 | Kang Min Ho | Routing table configuration for MPlambdaS (multi-protocol lambda switching) protection and restoration in optical mesh networks |
US20030023915A1 (en) * | 2001-07-30 | 2003-01-30 | Koninklijke Philips Electronics N.V. | Forward error correction system and method for packet based communication systems |
US20030043742A1 (en) * | 2001-08-31 | 2003-03-06 | Marcelo De Maria | Congestion management for packet routers |
US20030161315A1 (en) * | 2002-02-27 | 2003-08-28 | International Business Machines Corporation | Memory system with apparatus and method to enable balanced bandwidth utilization |
US20030236869A1 (en) * | 2002-06-04 | 2003-12-25 | Emmot Darel N. | Data management system and method |
US20040042418A1 (en) * | 2002-09-03 | 2004-03-04 | Fujitsu Limited | Fault tolerant network routing |
WO2004019558A1 (en) * | 2002-08-23 | 2004-03-04 | Koninklijke Philips Electronics N.V. | Method and apparatus for assuring quality of service in wireless local area networks |
US20040100899A1 (en) * | 2002-11-22 | 2004-05-27 | Nokia Inc. | System and method for implementing redundancy for multilink point to point protocol |
WO2004059921A1 (en) * | 2002-12-31 | 2004-07-15 | Nokia Corporation | Method and system for detecting duplicated frames in a mirrored network |
US20040143680A1 (en) * | 2003-01-22 | 2004-07-22 | Mikael Latvala | Method, system and mirror driver for LAN mirroring |
WO2004077758A1 (en) * | 2003-02-27 | 2004-09-10 | Siemens Aktiengesellschaft | Method and network nodes for determining multi-path transmission paths in a packet-switching communication network |
US20040179477A1 (en) * | 2003-03-13 | 2004-09-16 | Lincoln Patrick Denis | Method and apparatus for processing network packets |
US20050068975A1 (en) * | 2003-09-30 | 2005-03-31 | Pierre Colin | Computer data transport system and method |
US20050117509A1 (en) * | 2003-12-01 | 2005-06-02 | Alcatel | System for redundantly exchanging information parts |
WO2005055530A1 (en) * | 2003-12-02 | 2005-06-16 | International Business Machines Corporation | Packet processing system and method for a data transfer node with time-limited packet buffering in a central queue |
US20050153696A1 (en) * | 2001-09-17 | 2005-07-14 | Interdigital Technology Corporation | Radio resource control-service data unit reception |
US20050281204A1 (en) * | 2004-06-18 | 2005-12-22 | Karol Mark J | Rapid fault detection and recovery for internet protocol telephony |
WO2006006632A1 (en) | 2004-07-14 | 2006-01-19 | Nippon Telegraph And Telephone Corporation | Packet transmission method and packet transmission device |
US20060087963A1 (en) * | 2004-10-25 | 2006-04-27 | Cisco Technology, Inc. | Graceful port shutdown protocol for fibre channel interfaces |
US20060092932A1 (en) * | 2004-11-01 | 2006-05-04 | Cisco Technology, Inc. | Trunking for fabric ports in fibre channel switches and attached devices |
EP1675346A1 (en) * | 2004-12-22 | 2006-06-28 | Fujitsu Limited | Communication system |
US20060153186A1 (en) * | 2004-12-29 | 2006-07-13 | Cisco Technology, Inc. | In-order fibre channel packet delivery |
GB2426165A (en) * | 2005-05-13 | 2006-11-15 | Itt Mfg Enterprises Inc | Duplicating packets and transmitting them over separate non-overlapping network paths to improve reliability and reduce latency |
US20060256722A1 (en) * | 2005-05-13 | 2006-11-16 | Samer Taha | Ordered and duplicate-free delivery of wireless data frames |
US20070002737A1 (en) * | 2005-06-29 | 2007-01-04 | Manoj Paul | Access control dissemination |
US20070153679A1 (en) * | 2005-12-29 | 2007-07-05 | Jost Arthur P | Method and apparatus for glitchless failover to redundant stream |
US20070153816A1 (en) * | 2002-06-12 | 2007-07-05 | Cisco Technology, Inc. | Methods and apparatus for characterizing a route in a fibre channel fabric |
US20080002669A1 (en) * | 2001-09-14 | 2008-01-03 | O'brien Ray | Packet voice gateway |
US20080205406A1 (en) * | 2007-02-27 | 2008-08-28 | Fujitsu Limited | Recording medium having reception program recorded therein, recording medium having transmission program recorded therein, transmission/reception system and transmission/reception method |
US20080240283A1 (en) * | 2007-03-26 | 2008-10-02 | Sony Corporation | Extended serial communication protocols |
US20080316920A1 (en) * | 2005-12-09 | 2008-12-25 | Electronic & Telecommunications Research Institute | Apparatus and Method for Multi-Protocol Label Switching Label-Switched Path Protection Switching |
US20080316942A1 (en) * | 2002-11-27 | 2008-12-25 | Cisco Technology, Inc. | Methods and devices for exchanging peer parameters between network devices |
US20090006602A1 (en) * | 2007-06-27 | 2009-01-01 | Shinya Takeuchi | Multi-host management server in storage system, program for the same and path information management method |
EP2073461A1 (en) * | 2007-12-18 | 2009-06-24 | Alcatel Lucent | Process for delivering at least one data stream from a data source system to a data receiver system through a network |
US7586917B1 (en) * | 2003-09-30 | 2009-09-08 | Juniper Networks, Inc. | Systems and methods for re-ordering data in distributed data forwarding |
US20090228602A1 (en) * | 2008-03-04 | 2009-09-10 | Timothy James Speight | Method and apparatus for managing transmission of tcp data segments |
US7616637B1 (en) | 2002-04-01 | 2009-11-10 | Cisco Technology, Inc. | Label switching in fibre channel networks |
EP2148473A1 (en) * | 2008-07-22 | 2010-01-27 | ABB Research Ltd | Switching nodes for high availability networks |
US20100027476A1 (en) * | 2002-05-06 | 2010-02-04 | QUALCOMM Inorporated | Methods and apparatus for downlink macro-diversity in cellular networks |
US20100325310A1 (en) * | 2007-05-11 | 2010-12-23 | Gallegos Joseph A | Redundant routing of data in a network |
US7876711B2 (en) | 2003-06-26 | 2011-01-25 | Cisco Technology, Inc. | Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs |
US20110182294A1 (en) * | 2010-01-28 | 2011-07-28 | Brocade Communications Systems, Inc. | In-order traffic aggregation with reduced buffer usage |
US20110196999A1 (en) * | 2002-02-06 | 2011-08-11 | Juniper Networks, Inc. | Systems and methods for order preserving data |
US20110228690A1 (en) * | 2002-05-06 | 2011-09-22 | Qualcomm Incorporated | Methods and Apparatus For Uplink Macro-Diversity in Packet-Switched Cellular Networks |
US8117333B1 (en) | 2002-05-22 | 2012-02-14 | Juniper Networks, Inc. | Systems and methods for distributed data forwarding |
US8125997B1 (en) | 2003-03-12 | 2012-02-28 | Juniper Networks, Inc. | Systems and methods for processing any-to-any transmissions |
US20120057600A1 (en) * | 2010-03-08 | 2012-03-08 | Telcordia Poland Sp. Z.o.o Applied Research Center | Cooperative rerouting |
US8144711B1 (en) * | 2002-07-15 | 2012-03-27 | Rockstar Bidco, LP | Hitless switchover and bandwidth sharing in a communication network |
EP2595326A1 (en) * | 2003-01-21 | 2013-05-22 | Qualcomm Incorporated | Packet duplication |
US8554947B1 (en) * | 2003-09-15 | 2013-10-08 | Verizon Laboratories Inc. | Network data transmission systems and methods |
US20130329546A1 (en) * | 2012-06-08 | 2013-12-12 | Ijsbrand Wijnands | Mldp failover using fast notification packets |
US20140003344A1 (en) * | 2012-06-27 | 2014-01-02 | Electronics And Telecommunications Research Institute | Apparatus and method for multi-hop routing decision and looping prevention |
US20150326427A1 (en) * | 2014-05-06 | 2015-11-12 | Cisco Technology, Inc. | Fast Protection Switchover in a Transport Network |
WO2015191467A1 (en) * | 2014-06-13 | 2015-12-17 | Cisco Technology, Inc. | Active/static path redundancy |
US9509520B2 (en) | 2013-06-07 | 2016-11-29 | Cisco Technology, Inc. | Detection of repair nodes in networks |
GB2554370A (en) * | 2016-09-22 | 2018-04-04 | Canon Kk | Method for operating a reception device in a system using multi-copy transmission |
CN109714272A (en) * | 2018-12-29 | 2019-05-03 | 苏州睿安芯微电子有限公司 | A method of enhancing network stabilization and real-time |
CN112822048A (en) * | 2021-01-04 | 2021-05-18 | 烽火通信科技股份有限公司 | Method and system for realizing nondestructive protection switching |
US11777846B2 (en) * | 2020-05-06 | 2023-10-03 | Nokia Solutions And Networks Oy | Ultra reliable segment routing |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7099327B1 (en) * | 2000-10-12 | 2006-08-29 | Lucent Technologies Inc. | Data communications networks with high performance and reliability |
US7289428B2 (en) * | 2001-08-13 | 2007-10-30 | Tellabs Operations, Inc. | Inter-working mesh telecommunications networks |
US7245616B1 (en) | 2002-03-20 | 2007-07-17 | Applied Micro Circuits Corporation | Dynamic allocation of packets to tasks |
US7072342B1 (en) * | 2002-03-20 | 2006-07-04 | Applied Micro Circuits Corporation | Reordering of out-of-order packets |
US7941149B2 (en) * | 2002-05-13 | 2011-05-10 | Misonimo Chi Acquistion L.L.C. | Multi-hop ultra wide band wireless network communication |
US8780770B2 (en) * | 2002-05-13 | 2014-07-15 | Misonimo Chi Acquisition L.L.C. | Systems and methods for voice and video communication over a wireless network |
US7957356B2 (en) * | 2002-05-13 | 2011-06-07 | Misomino Chi Acquisitions L.L.C. | Scalable media access control for multi-hop high bandwidth communications |
US7835372B2 (en) * | 2002-05-13 | 2010-11-16 | Weilin Wang | System and method for transparent wireless bridging of communication channel segments |
US7069483B2 (en) * | 2002-05-13 | 2006-06-27 | Kiyon, Inc. | System and method for identifying nodes in a wireless mesh network |
US20050201346A1 (en) * | 2003-05-13 | 2005-09-15 | Weilin Wang | Systems and methods for broadband data communication in a wireless mesh network |
US7852796B2 (en) * | 2002-05-13 | 2010-12-14 | Xudong Wang | Distributed multichannel wireless communication |
US7406082B2 (en) * | 2002-09-30 | 2008-07-29 | Lucent Technologies Inc. | Sequence number schemes for acceptance/rejection of duplicated packets in a packet-based data network |
US7475142B2 (en) * | 2002-12-06 | 2009-01-06 | Cisco Technology, Inc. | CIFS for scalable NAS architecture |
US7443845B2 (en) * | 2002-12-06 | 2008-10-28 | Cisco Technology, Inc. | Apparatus and method for a lightweight, reliable, packet-based transport protocol |
US7271736B2 (en) * | 2003-01-06 | 2007-09-18 | Michael Aaron Siegel | Emergency vehicle alert system |
US7756008B2 (en) * | 2003-12-19 | 2010-07-13 | At&T Intellectual Property Ii, L.P. | Routing protocols with predicted outrage notification |
KR100624641B1 (en) * | 2004-10-07 | 2006-09-15 | 삼성전자주식회사 | On-chip bus architecture with multiple mapping of functional block cores and switch points, and semiconductor device using the same |
US7586888B2 (en) * | 2005-02-17 | 2009-09-08 | Mobitrum Corporation | Method and system for mesh network embedded devices |
US7630736B2 (en) * | 2005-10-11 | 2009-12-08 | Mobitrum Corporation | Method and system for spatial data input, manipulation and distribution via an adaptive wireless transceiver |
US7619993B2 (en) * | 2005-11-01 | 2009-11-17 | International Business Machines Corporation | Efficient probabilistic duplicate packet detector in computer networks |
US7773630B2 (en) * | 2005-11-12 | 2010-08-10 | Liquid Computing Corportation | High performance memory based communications interface |
WO2007149744A2 (en) * | 2006-06-19 | 2007-12-27 | Liquid Computing Corporation | Secure handle for intra-and inter-processor communications |
US8005972B2 (en) * | 2006-06-26 | 2011-08-23 | International Business Machines Corporation | Detection of inconsistent data in communications networks |
JP4748316B2 (en) * | 2006-07-13 | 2011-08-17 | 日本電気株式会社 | Packet transmission method and packet transmission system |
US7801058B2 (en) * | 2006-07-27 | 2010-09-21 | Mobitrum Corporation | Method and system for dynamic information exchange on mesh network devices |
USRE47894E1 (en) | 2006-07-27 | 2020-03-03 | Iii Holdings 2, Llc | Method and system for dynamic information exchange on location aware mesh network devices |
US8411590B2 (en) | 2006-07-27 | 2013-04-02 | Mobitrum Corporation | Mesh network remote control device |
US8305936B2 (en) | 2006-07-27 | 2012-11-06 | Mobitrum Corporation | Method and system for dynamic information exchange on a mesh network in a vehicle |
US8427979B1 (en) | 2006-07-27 | 2013-04-23 | Mobitrum Corporation | Method and system for dynamic information exchange on location aware mesh network devices |
US8305935B2 (en) * | 2006-07-27 | 2012-11-06 | Mobitrum Corporation | Method and system for dynamic information exchange on location aware mesh network devices |
US8175613B2 (en) * | 2006-08-04 | 2012-05-08 | Misonimo Chi Acquisitions L.L.C. | Systems and methods for determining location of devices within a wireless network |
US20080049720A1 (en) * | 2006-08-25 | 2008-02-28 | Sbc Knowledge Ventures, Lp | System and method of delivering data via a network |
JP5233102B2 (en) * | 2006-09-14 | 2013-07-10 | 富士通株式会社 | Mobile communication system and communication method thereof |
JP4861484B2 (en) * | 2006-12-07 | 2012-01-25 | ミソニモ チ アクイジションズ エル.エル.シー. | System and method for assigning time slots and channels |
US20090189739A1 (en) * | 2008-01-25 | 2009-07-30 | Mobitrum Corporation | Passive voice enabled rfid devices |
US20090190467A1 (en) * | 2008-01-25 | 2009-07-30 | At&T Labs, Inc. | System and method for managing fault in a multi protocol label switching system |
JP5176623B2 (en) * | 2008-03-18 | 2013-04-03 | 日本電気株式会社 | Ethernet transmission method, transmission apparatus and system |
US7929423B2 (en) * | 2008-12-31 | 2011-04-19 | Alcatel Lucent | MLPPP sequence number synchronization between the active and standby transmitters |
US8451717B2 (en) * | 2010-07-30 | 2013-05-28 | Alcatel Lucent | Method and apparatus for rapid switchover from primary to standby multicast trees |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5337313A (en) * | 1992-11-12 | 1994-08-09 | Motorola, Inc. | Method and apparatus for preserving packet squencing in a packet transmission system |
US5561661A (en) * | 1994-05-11 | 1996-10-01 | Siemens Aktiengesellschaft | Method for synchronizing redundantly transmitted message cell streams |
US5848228A (en) * | 1995-12-28 | 1998-12-08 | Cegelec | Method of ordering a plurality of messages from a plurality of sources and system for implementing the method |
US5883891A (en) * | 1996-04-30 | 1999-03-16 | Williams; Wyatt | Method and apparatus for increased quality of voice transmission over the internet |
US6091725A (en) * | 1995-12-29 | 2000-07-18 | Cisco Systems, Inc. | Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network |
US6246681B1 (en) * | 1997-12-19 | 2001-06-12 | Alcatel Usa Sourcing, L.P. | System and method for plane selection |
US6373821B2 (en) * | 1998-02-20 | 2002-04-16 | Apple Computer, Inc. | Method for setting time stamp in SYT field of packet headers for IEEE-1394 devices |
US6466576B2 (en) * | 1997-10-20 | 2002-10-15 | Fujitsu Limited | ATM switching unit |
US6466574B1 (en) * | 1998-06-05 | 2002-10-15 | International Business Machines Corporation | Quality of service improvement of internet real-time media transmission by transmitting redundant voice/media frames |
US6678267B1 (en) * | 1999-08-10 | 2004-01-13 | Texas Instruments Incorporated | Wireless telephone with excitation reconstruction of lost packet |
-
2000
- 2000-12-20 US US09/739,711 patent/US6853641B2/en not_active Expired - Lifetime
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5337313A (en) * | 1992-11-12 | 1994-08-09 | Motorola, Inc. | Method and apparatus for preserving packet squencing in a packet transmission system |
US5561661A (en) * | 1994-05-11 | 1996-10-01 | Siemens Aktiengesellschaft | Method for synchronizing redundantly transmitted message cell streams |
US5848228A (en) * | 1995-12-28 | 1998-12-08 | Cegelec | Method of ordering a plurality of messages from a plurality of sources and system for implementing the method |
US6091725A (en) * | 1995-12-29 | 2000-07-18 | Cisco Systems, Inc. | Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network |
US5883891A (en) * | 1996-04-30 | 1999-03-16 | Williams; Wyatt | Method and apparatus for increased quality of voice transmission over the internet |
US6466576B2 (en) * | 1997-10-20 | 2002-10-15 | Fujitsu Limited | ATM switching unit |
US6246681B1 (en) * | 1997-12-19 | 2001-06-12 | Alcatel Usa Sourcing, L.P. | System and method for plane selection |
US6373821B2 (en) * | 1998-02-20 | 2002-04-16 | Apple Computer, Inc. | Method for setting time stamp in SYT field of packet headers for IEEE-1394 devices |
US6466574B1 (en) * | 1998-06-05 | 2002-10-15 | International Business Machines Corporation | Quality of service improvement of internet real-time media transmission by transmitting redundant voice/media frames |
US6678267B1 (en) * | 1999-08-10 | 2004-01-13 | Texas Instruments Incorporated | Wireless telephone with excitation reconstruction of lost packet |
Cited By (131)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020089712A1 (en) * | 2001-01-10 | 2002-07-11 | Kang Min Ho | Routing table configuration for MPlambdaS (multi-protocol lambda switching) protection and restoration in optical mesh networks |
US20030023915A1 (en) * | 2001-07-30 | 2003-01-30 | Koninklijke Philips Electronics N.V. | Forward error correction system and method for packet based communication systems |
US20030043742A1 (en) * | 2001-08-31 | 2003-03-06 | Marcelo De Maria | Congestion management for packet routers |
US7215639B2 (en) * | 2001-08-31 | 2007-05-08 | 4198638 Canada Inc. | Congestion management for packet routers |
US20080002669A1 (en) * | 2001-09-14 | 2008-01-03 | O'brien Ray | Packet voice gateway |
US20050153696A1 (en) * | 2001-09-17 | 2005-07-14 | Interdigital Technology Corporation | Radio resource control-service data unit reception |
US20090083603A1 (en) * | 2001-09-17 | 2009-03-26 | Interdigital Technology Corporation | Radio Resource Control-Service Data Unit Reception |
US7581147B2 (en) * | 2001-09-17 | 2009-08-25 | Interdigital Technology Corporation | Radio resource control-service data unit reception |
US20110196999A1 (en) * | 2002-02-06 | 2011-08-11 | Juniper Networks, Inc. | Systems and methods for order preserving data |
US8189595B2 (en) | 2002-02-06 | 2012-05-29 | Juniper Networks, Inc. | Systems and methods for order preserving data |
US7286543B2 (en) * | 2002-02-27 | 2007-10-23 | International Business Machines Corporation | Memory system with apparatus and method to enable balanced bandwidth utilization |
US20030161315A1 (en) * | 2002-02-27 | 2003-08-28 | International Business Machines Corporation | Memory system with apparatus and method to enable balanced bandwidth utilization |
US7616637B1 (en) | 2002-04-01 | 2009-11-10 | Cisco Technology, Inc. | Label switching in fibre channel networks |
US9350653B2 (en) | 2002-04-01 | 2016-05-24 | Cisco Technology, Inc. | Label switching in fibre channel networks |
US20100008375A1 (en) * | 2002-04-01 | 2010-01-14 | Cisco Technology, Inc. | Label switching in fibre channel networks |
US8462790B2 (en) | 2002-04-01 | 2013-06-11 | Cisco Technology, Inc. | Label switching in fibre channel networks |
US20100027476A1 (en) * | 2002-05-06 | 2010-02-04 | QUALCOMM Inorporated | Methods and apparatus for downlink macro-diversity in cellular networks |
US20110228690A1 (en) * | 2002-05-06 | 2011-09-22 | Qualcomm Incorporated | Methods and Apparatus For Uplink Macro-Diversity in Packet-Switched Cellular Networks |
US9491677B2 (en) | 2002-05-06 | 2016-11-08 | Qualcomm Incorporated | Methods and apparatus for downlink macro-diversity in cellular networks |
US8670341B2 (en) | 2002-05-06 | 2014-03-11 | Qualcomm Incorporated | Methods and apparatus for uplink macro-diversity in packet-switched cellular networks |
US8665734B2 (en) | 2002-05-06 | 2014-03-04 | Qualcomm Incorporated | Methods and apparatus for uplink macro-diversity in packet-switched cellular networks |
US8117333B1 (en) | 2002-05-22 | 2012-02-14 | Juniper Networks, Inc. | Systems and methods for distributed data forwarding |
US20030236869A1 (en) * | 2002-06-04 | 2003-12-25 | Emmot Darel N. | Data management system and method |
US7830809B2 (en) | 2002-06-12 | 2010-11-09 | Cisco Technology, Inc. | Methods and apparatus for characterizing a route in a fibre channel fabric |
US20070153816A1 (en) * | 2002-06-12 | 2007-07-05 | Cisco Technology, Inc. | Methods and apparatus for characterizing a route in a fibre channel fabric |
US20120201123A1 (en) * | 2002-07-15 | 2012-08-09 | Rockstar Bidco, LP | Hitless switchover and bandwidth sharing in a communication network |
US8144711B1 (en) * | 2002-07-15 | 2012-03-27 | Rockstar Bidco, LP | Hitless switchover and bandwidth sharing in a communication network |
US8483224B2 (en) * | 2002-07-15 | 2013-07-09 | Rockstar Consortium Us Lp | Hitless switchover and bandwidth sharing in a communication network |
WO2004019558A1 (en) * | 2002-08-23 | 2004-03-04 | Koninklijke Philips Electronics N.V. | Method and apparatus for assuring quality of service in wireless local area networks |
US7796503B2 (en) * | 2002-09-03 | 2010-09-14 | Fujitsu Limited | Fault tolerant network routing |
US20040042418A1 (en) * | 2002-09-03 | 2004-03-04 | Fujitsu Limited | Fault tolerant network routing |
US20040100899A1 (en) * | 2002-11-22 | 2004-05-27 | Nokia Inc. | System and method for implementing redundancy for multilink point to point protocol |
US6912197B2 (en) * | 2002-11-22 | 2005-06-28 | Nokia Inc. | System and method for implementing redundancy for multilink point to point protocol |
US8605624B2 (en) | 2002-11-27 | 2013-12-10 | Cisco Technology, Inc. | Methods and devices for exchanging peer parameters between network devices |
US20080316942A1 (en) * | 2002-11-27 | 2008-12-25 | Cisco Technology, Inc. | Methods and devices for exchanging peer parameters between network devices |
US20040139123A1 (en) * | 2002-12-31 | 2004-07-15 | Lauri Glad | Method, system and mirror driver for LAN mirroring |
US7352753B2 (en) | 2002-12-31 | 2008-04-01 | Nokia Corporation | Method, system and mirror driver for LAN mirroring |
WO2004059921A1 (en) * | 2002-12-31 | 2004-07-15 | Nokia Corporation | Method and system for detecting duplicated frames in a mirrored network |
EP2595326A1 (en) * | 2003-01-21 | 2013-05-22 | Qualcomm Incorporated | Packet duplication |
US7389353B2 (en) * | 2003-01-22 | 2008-06-17 | Nokia Corporation | Method, system and mirror driver for LAN mirroring |
US20040143680A1 (en) * | 2003-01-22 | 2004-07-22 | Mikael Latvala | Method, system and mirror driver for LAN mirroring |
WO2004077758A1 (en) * | 2003-02-27 | 2004-09-10 | Siemens Aktiengesellschaft | Method and network nodes for determining multi-path transmission paths in a packet-switching communication network |
US8125997B1 (en) | 2003-03-12 | 2012-02-28 | Juniper Networks, Inc. | Systems and methods for processing any-to-any transmissions |
US20040179477A1 (en) * | 2003-03-13 | 2004-09-16 | Lincoln Patrick Denis | Method and apparatus for processing network packets |
US7706378B2 (en) * | 2003-03-13 | 2010-04-27 | Sri International | Method and apparatus for processing network packets |
US7876711B2 (en) | 2003-06-26 | 2011-01-25 | Cisco Technology, Inc. | Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs |
US20110090816A1 (en) * | 2003-06-26 | 2011-04-21 | Cisco Technology, Inc. | FIBRE CHANNEL SWITCH THAT ENABLES END DEVICES IN DIFFERENT FABRICS TO COMMUNICATE WITH ONE ANOTHER WHILE RETAINING THEIR UNIQUE FIBRE CHANNEL DOMAIN_IDs |
US8625460B2 (en) | 2003-06-26 | 2014-01-07 | Cisco Technology, Inc. | Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs |
US8554947B1 (en) * | 2003-09-15 | 2013-10-08 | Verizon Laboratories Inc. | Network data transmission systems and methods |
US8170028B1 (en) * | 2003-09-30 | 2012-05-01 | Juniper Networks, Inc. | Systems and methods for re-ordering data in distributed data forwarding |
US7586917B1 (en) * | 2003-09-30 | 2009-09-08 | Juniper Networks, Inc. | Systems and methods for re-ordering data in distributed data forwarding |
US20050068975A1 (en) * | 2003-09-30 | 2005-03-31 | Pierre Colin | Computer data transport system and method |
US20050117509A1 (en) * | 2003-12-01 | 2005-06-02 | Alcatel | System for redundantly exchanging information parts |
EP1538812A1 (en) * | 2003-12-01 | 2005-06-08 | Alcatel | System for redundantly exchanging information parts |
WO2005055530A1 (en) * | 2003-12-02 | 2005-06-16 | International Business Machines Corporation | Packet processing system and method for a data transfer node with time-limited packet buffering in a central queue |
US7181637B2 (en) | 2003-12-02 | 2007-02-20 | International Business Machines Corporation | Packet processing system and method for a data transfer node with time-limited packet buffering in a central queue |
US20050281204A1 (en) * | 2004-06-18 | 2005-12-22 | Karol Mark J | Rapid fault detection and recovery for internet protocol telephony |
EP1610496A1 (en) * | 2004-06-18 | 2005-12-28 | Avaya Technology Corp. | Rapid fault detection and recovery for internet protocol telephony |
US7782787B2 (en) | 2004-06-18 | 2010-08-24 | Avaya Inc. | Rapid fault detection and recovery for internet protocol telephony |
EP1768328A1 (en) * | 2004-07-14 | 2007-03-28 | Nippon Telegraph and Telephone Corporation | Packet transmission method and packet transmission device |
EP2424179A1 (en) * | 2004-07-14 | 2012-02-29 | Nippon Telegraph And Telephone Corporation | Packet transmission method and packet transmission device |
EP2424180A1 (en) * | 2004-07-14 | 2012-02-29 | Nippon Telegraph And Telephone Corporation | Packet transmission method and packet transmission device |
US8625588B2 (en) | 2004-07-14 | 2014-01-07 | Nippon Telegraph And Telephone Corporation | Packet transmission method and packet transmission device |
EP1768328A4 (en) * | 2004-07-14 | 2011-06-01 | Nippon Telegraph & Telephone | Packet transmission method and packet transmission device |
WO2006006632A1 (en) | 2004-07-14 | 2006-01-19 | Nippon Telegraph And Telephone Corporation | Packet transmission method and packet transmission device |
US20110038373A1 (en) * | 2004-07-14 | 2011-02-17 | Nippon Telegraph And Telephone Corp. | Packet transmission method and packet transmission device |
US20060087963A1 (en) * | 2004-10-25 | 2006-04-27 | Cisco Technology, Inc. | Graceful port shutdown protocol for fibre channel interfaces |
US7593324B2 (en) * | 2004-10-25 | 2009-09-22 | Cisco Technology, Inc. | Graceful port shutdown protocol for fibre channel interfaces |
US20060092932A1 (en) * | 2004-11-01 | 2006-05-04 | Cisco Technology, Inc. | Trunking for fabric ports in fibre channel switches and attached devices |
US20110141906A1 (en) * | 2004-11-01 | 2011-06-16 | Cisco Technology, Inc. | Trunking for fabric ports in fibre channel switches and attached devices |
US8750094B2 (en) | 2004-11-01 | 2014-06-10 | Cisco Technology, Inc. | Trunking for fabric ports in Fibre channel switches and attached devices |
US7916628B2 (en) | 2004-11-01 | 2011-03-29 | Cisco Technology, Inc. | Trunking for fabric ports in fibre channel switches and attached devices |
EP1675346A1 (en) * | 2004-12-22 | 2006-06-28 | Fujitsu Limited | Communication system |
US8335843B2 (en) * | 2004-12-22 | 2012-12-18 | Fujitsu Limited | Communication system having multiple communication lines between a transmitter and a receiver |
US20060195594A1 (en) * | 2004-12-22 | 2006-08-31 | Fujitsu Limited | Communication system |
KR100769094B1 (en) * | 2004-12-22 | 2007-10-23 | 후지쯔 가부시끼가이샤 | Communication system |
US7649844B2 (en) | 2004-12-29 | 2010-01-19 | Cisco Technology, Inc. | In-order fibre channel packet delivery |
US20060153186A1 (en) * | 2004-12-29 | 2006-07-13 | Cisco Technology, Inc. | In-order fibre channel packet delivery |
US8638797B2 (en) | 2005-05-13 | 2014-01-28 | Intel Corporation | Ordered and duplicate-free delivery of wireless data frames |
US7746866B2 (en) * | 2005-05-13 | 2010-06-29 | Intel Corporation | Ordered and duplicate-free delivery of wireless data frames |
US20060256768A1 (en) * | 2005-05-13 | 2006-11-16 | Chan Chi C | Method and system for transferring data in a communications network using redundant communication paths |
US7590756B2 (en) | 2005-05-13 | 2009-09-15 | Itt Manufacturing Enterprises, Inc. | Method and system for transferring data in a communications network using redundant communication paths |
GB2426165B (en) * | 2005-05-13 | 2009-10-07 | Itt Mfg Enterprises Inc | Method and system for transferring data in a communications network using redundant communication paths |
US20060256722A1 (en) * | 2005-05-13 | 2006-11-16 | Samer Taha | Ordered and duplicate-free delivery of wireless data frames |
US20100220658A1 (en) * | 2005-05-13 | 2010-09-02 | Samer Taha | Ordered and duplicate-free delivery of wireless data frames |
GB2426165A (en) * | 2005-05-13 | 2006-11-15 | Itt Mfg Enterprises Inc | Duplicating packets and transmitting them over separate non-overlapping network paths to improve reliability and reduce latency |
WO2006124260A1 (en) * | 2005-05-13 | 2006-11-23 | Intel Corporation | Ordered and duplicate-free delivery of wireless data frames |
US20070002737A1 (en) * | 2005-06-29 | 2007-01-04 | Manoj Paul | Access control dissemination |
US7872967B2 (en) * | 2005-12-09 | 2011-01-18 | Electronics And Telecommunications Research Institute | Apparatus and method for multi-protocol label switching label-switched path protection switching |
US20080316920A1 (en) * | 2005-12-09 | 2008-12-25 | Electronic & Telecommunications Research Institute | Apparatus and Method for Multi-Protocol Label Switching Label-Switched Path Protection Switching |
US8989006B2 (en) | 2005-12-29 | 2015-03-24 | General Instrument Corporation | Method and apparatus for glitchless failover to redundant stream |
EP1821543A1 (en) * | 2005-12-29 | 2007-08-22 | General Instrument Corporation | Method and apparatus for glitchless failover to redundant stream |
US20070153679A1 (en) * | 2005-12-29 | 2007-07-05 | Jost Arthur P | Method and apparatus for glitchless failover to redundant stream |
US20080205406A1 (en) * | 2007-02-27 | 2008-08-28 | Fujitsu Limited | Recording medium having reception program recorded therein, recording medium having transmission program recorded therein, transmission/reception system and transmission/reception method |
US20080240283A1 (en) * | 2007-03-26 | 2008-10-02 | Sony Corporation | Extended serial communication protocols |
US8027359B2 (en) * | 2007-03-26 | 2011-09-27 | Sony Corporation | Extended serial communication protocols |
US20100325310A1 (en) * | 2007-05-11 | 2010-12-23 | Gallegos Joseph A | Redundant routing of data in a network |
US8135012B2 (en) * | 2007-05-11 | 2012-03-13 | The Boeing Company | Redundant routing of data in a network |
US20090006602A1 (en) * | 2007-06-27 | 2009-01-01 | Shinya Takeuchi | Multi-host management server in storage system, program for the same and path information management method |
US8176202B2 (en) * | 2007-06-27 | 2012-05-08 | Hitachi, Ltd. | Multi-host management server in storage system, program for the same and path information management method |
US8423665B2 (en) | 2007-06-27 | 2013-04-16 | Hitachi, Ltd. | Multi-host management server in storage system, program for the same and path information management method |
EP2073461A1 (en) * | 2007-12-18 | 2009-06-24 | Alcatel Lucent | Process for delivering at least one data stream from a data source system to a data receiver system through a network |
US8015313B2 (en) * | 2008-03-04 | 2011-09-06 | Sony Corporation | Method and apparatus for managing transmission of TCP data segments |
US20120278502A1 (en) * | 2008-03-04 | 2012-11-01 | Sony Corporation | Method and apparatus for managing transmission of tcp data segments |
US8301685B2 (en) * | 2008-03-04 | 2012-10-30 | Sony Corporation | Method and apparatus for managing transmission of TCP data segments |
US8301799B2 (en) * | 2008-03-04 | 2012-10-30 | Sony Corporation | Method and apparatus for managing transmission of TCP data segments |
US8589586B2 (en) * | 2008-03-04 | 2013-11-19 | Sony Corporation | Method and apparatus for managing transmission of TCP data segments |
US20090228602A1 (en) * | 2008-03-04 | 2009-09-10 | Timothy James Speight | Method and apparatus for managing transmission of tcp data segments |
US20110122816A1 (en) * | 2008-03-04 | 2011-05-26 | Sony Corporation | Method and apparatus for managing transmission of tcp data segments |
US20110289234A1 (en) * | 2008-03-04 | 2011-11-24 | Sony Corporation | Method and apparatus for managing transmission of tcp data segments |
US8582424B2 (en) | 2008-07-22 | 2013-11-12 | Abb Research Ltd | Ring coupling nodes for high availability networks |
EP2148473A1 (en) * | 2008-07-22 | 2010-01-27 | ABB Research Ltd | Switching nodes for high availability networks |
US20110116508A1 (en) * | 2008-07-22 | 2011-05-19 | Abb Research Ltd | Ring coupling nodes for high availability networks |
US20110182294A1 (en) * | 2010-01-28 | 2011-07-28 | Brocade Communications Systems, Inc. | In-order traffic aggregation with reduced buffer usage |
US9137166B2 (en) * | 2010-01-28 | 2015-09-15 | Brocade Communications Systems, Inc. | In-order traffic aggregation with reduced buffer usage |
US20120057600A1 (en) * | 2010-03-08 | 2012-03-08 | Telcordia Poland Sp. Z.o.o Applied Research Center | Cooperative rerouting |
US20130329546A1 (en) * | 2012-06-08 | 2013-12-12 | Ijsbrand Wijnands | Mldp failover using fast notification packets |
US9491091B2 (en) * | 2012-06-08 | 2016-11-08 | Cisco Technology, Inc. | MLDP failover using fast notification packets |
US20140003344A1 (en) * | 2012-06-27 | 2014-01-02 | Electronics And Telecommunications Research Institute | Apparatus and method for multi-hop routing decision and looping prevention |
US9160676B2 (en) * | 2012-06-27 | 2015-10-13 | Electronics And Telecommunications Research Institute | Apparatus and method for multi-hop routing decision and looping prevention |
US9509520B2 (en) | 2013-06-07 | 2016-11-29 | Cisco Technology, Inc. | Detection of repair nodes in networks |
US9450774B2 (en) * | 2014-05-06 | 2016-09-20 | Cisco Technology, Inc. | Fast protection switchover in a transport network |
US20150326427A1 (en) * | 2014-05-06 | 2015-11-12 | Cisco Technology, Inc. | Fast Protection Switchover in a Transport Network |
WO2015191467A1 (en) * | 2014-06-13 | 2015-12-17 | Cisco Technology, Inc. | Active/static path redundancy |
US9503361B2 (en) | 2014-06-13 | 2016-11-22 | Cisco Technology, Inc. | Active/static path redundancy |
EP3373519A1 (en) * | 2014-06-13 | 2018-09-12 | Cisco Technology, Inc. | Active/static path redundancy |
GB2554370A (en) * | 2016-09-22 | 2018-04-04 | Canon Kk | Method for operating a reception device in a system using multi-copy transmission |
GB2554370B (en) * | 2016-09-22 | 2019-04-17 | Canon Kk | Method for operating a reception device in a system using multi-copy transmission |
CN109714272A (en) * | 2018-12-29 | 2019-05-03 | 苏州睿安芯微电子有限公司 | A method of enhancing network stabilization and real-time |
US11777846B2 (en) * | 2020-05-06 | 2023-10-03 | Nokia Solutions And Networks Oy | Ultra reliable segment routing |
CN112822048A (en) * | 2021-01-04 | 2021-05-18 | 烽火通信科技股份有限公司 | Method and system for realizing nondestructive protection switching |
Also Published As
Publication number | Publication date |
---|---|
US6853641B2 (en) | 2005-02-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6853641B2 (en) | Method of protecting traffic in a mesh network | |
US7639604B2 (en) | Packet routing apparatus and a method of communicating a packet | |
US6725401B1 (en) | Optimized fault notification in an overlay mesh network via network knowledge correlation | |
US7532570B2 (en) | Fault tolerant network traffic management | |
US6538987B1 (en) | Rapid ring protection switching system | |
US8483224B2 (en) | Hitless switchover and bandwidth sharing in a communication network | |
US7961602B2 (en) | Method and device using a backup communication path to transmit excess traffic | |
EP1348265B1 (en) | Maintaining quality of packet traffic in optical network when a failure of an optical link occurs | |
US20020133756A1 (en) | System and method for providing multiple levels of fault protection in a data communication network | |
US20030117950A1 (en) | Link redial for mesh protection | |
EP1608116A1 (en) | Method and apparatus for per-service fault protection and restoration in a packet network | |
EP2013996B1 (en) | System and method of multi-nodal aps control protocol signalling | |
JP3901977B2 (en) | The method used by the nodes in the packet network | |
US20030185201A1 (en) | System and method for 1 + 1 flow protected transmission of time-sensitive data in packet-based communication networks | |
US6452934B1 (en) | Packet forwarding apparatus | |
CA2294693A1 (en) | Method and system for protecting virtual traffic in a communications network | |
KR20090050933A (en) | Failure recovery method in non revertive mode of ethernet ring netwrok | |
US6426941B1 (en) | Hitless ATM cell transport for reliable multi-service provisioning | |
WO2011157130A2 (en) | Path establishment method and apparatus | |
US7046623B2 (en) | Fault recovery system and method for inverse multiplexed digital subscriber lines | |
CN115297051A (en) | Fast reroute using egress port loopback | |
JP3349988B2 (en) | Method and system for automatically switching back from detour route in ATM network | |
JPH04100343A (en) | Atm link system | |
CN115211088B (en) | Apparatus and method for recovering label switched paths in a network | |
US20030063561A1 (en) | Equivalent switching method for transmission devices in mpls networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NORTEL NETWORKS LIMITED, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LINDHORST-KO, GWENDA;LO, WAICHI;DALLAIRE, MICHEL;REEL/FRAME:011388/0387 Effective date: 20001215 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: CIENA LUXEMBOURG S.A.R.L.,LUXEMBOURG Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:024213/0653 Effective date: 20100319 Owner name: CIENA LUXEMBOURG S.A.R.L., LUXEMBOURG Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:024213/0653 Effective date: 20100319 |
|
AS | Assignment |
Owner name: CIENA CORPORATION,MARYLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CIENA LUXEMBOURG S.A.R.L.;REEL/FRAME:024252/0060 Effective date: 20100319 Owner name: CIENA CORPORATION, MARYLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CIENA LUXEMBOURG S.A.R.L.;REEL/FRAME:024252/0060 Effective date: 20100319 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:CIENA CORPORATION;REEL/FRAME:033329/0417 Effective date: 20140715 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NO Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:CIENA CORPORATION;REEL/FRAME:033347/0260 Effective date: 20140715 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: CIENA CORPORATION, MARYLAND Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:050938/0389 Effective date: 20191028 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, ILLINO Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:CIENA CORPORATION;REEL/FRAME:050969/0001 Effective date: 20191028 |
|
AS | Assignment |
Owner name: CIENA CORPORATION, MARYLAND Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:065630/0232 Effective date: 20231024 |