Multiplex communications – Fault recovery – Bypass an inoperative switch or inoperative element of a...
Reexamination Certificate
1999-05-18
2004-06-15
Ton, Dang (Department: 2666)
Multiplex communications
Fault recovery
Bypass an inoperative switch or inoperative element of a...
C370S242000
Reexamination Certificate
active
06751190
ABSTRACT:
BACKGROUND OF THE INVENTION
There is a growing need for realtime data transfer on the Internet to support realtime applications such as, teleconferencing and live video. However, the Internet is not designed for realtime data transfer. Data is transferred on the Internet using Transmission Control Protocol (“TCP”)/Internet Protocol (“IP”). TCP/IP includes four layers, the application layer, the transport layer, the network layer and the link layer.
Data originates in the application layer, for example, the application data may be frames of a live video to be transmitted from a source node to a destination node. The transport layer includes the TCP protocol. The TCP protocol in the source node processes the frames of the live video into TCP data packets and assigns a sequence number to each packet of data. The TCP protocol in the destination node reassembles the TCP data packets transmitted by the source node using the data packet's sequence numbers.
The network layer includes the IP protocol. The IP protocol adds an IP address for the destination node to each TCP data packet. The size of the IP address added is dependent on the version of the IP protocol used. Version 4 of the IP protocol (“IPv4”) adds a 32 bit IP address to each TCP data packet. Version 6 of the IP protocol (“IPv6”), adds a 128 bit IP address to each TCP data packet. The link layer in the source node sends the TCP data packets including IP addresses over the physical medium. The link layer in the destination node receives the TCP data packets sent by the source node over the physical medium.
By dividing the application data into TCP data packets and providing the IP address for the destination node on each TCP data packet, each TCP data packet may travel on a different path between the source node and the destination node. Due to congestion in nodes along paths from the source node to the destination node, TCP data packets sent on different paths may not arrive in order.
For real-time data, for example, a live video the application can not wait until all the data packets are reassembled because the data packets are used as soon as they arrive at the destination node. If a data packet does not arrive at the destination node in time this delayed packet may be noticeable, for example, a delay in a data packet for live video may result in a loss of one or more frames of the video.
Extensions to TCP/IP have been proposed by the Internet Engineering Task Force (“IETF”) to add support for realtime data transfer. One proposed extension to provide in-order delivery of data packets for realtime data transfer between a source node and a destination node is Multiprotocol Label Switching (MPLS) described in “A Framework for Multiprotocol Label Switching” by Callon et al. in a Network Working Group Internet Draft published at http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-02.txt on May 21, 1998 incorporated herein by reference. MPLS adds a label to a data packet to guide the data packets through nodes along a pre-defined path in a network. The pre-defined path is called a Label Switched Path (“LSP”)Tunnel. LSP tunnels may be established using the Resource ReSerVation Protocol (“RSVP”) described in “Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification” by Branden et al. RSVP, Network Work Group, Request for Comment, 2205 published at http://www.ietf.org/rfc/rfc2205.txt on September 1997 incorporated herein by reference.
A “tunnel” in general, therefore, as used herein refers to a pre-defined path through networks. The “tunnel” may be established by RSVP or any other protocol now or hereafter established to support real time data transfer.
A tunnel failure may occur, for example, due to a hardware failure in one or more nodes or a communication link between nodes, requiring a new tunnel to be established to restore data packet transfer to transfer data. Until the new tunnel is established, data packets for the realtime application such as, live video are not being transmitted to the destination node.
SUMMARY OF THE INVENTION
The present invention provides a mechanism for quickly repairing a failure in a communications link and has particular application to failed communications links in tunnels established for realtime data transfer. The tunnel is established by assigning a label to each communication link. A plurality of labels for each communication link is stored in a node prior to any communication failure. The node may determine the label assigned to a communication link from the stored labels. After the detection of link failure the tunnel is repaired by redirecting data transfer for the tunnel around the failed communication link. The data transfer is redirected on an established bypass tunnel.
The labels are stored in the node by forwarding a message with a label table to each node in the tunnel. The node adds its address and the label for its communication link for the tunnel to the label table and stores a copy of the label table.
The nodes through which data transfer for the tunnel is to be directed may be determined before the communications link failure is detected. The bypass tunnel for redirecting data transfer for the tunnel may be established before the communications link failure is detected.
REFERENCES:
patent: 5146452 (1992-09-01), Pekarske
patent: 5764624 (1998-06-01), Endo et al.
patent: 5768256 (1998-06-01), Allen et al.
patent: 5999286 (1999-12-01), Venkatesan
patent: 6092113 (2000-07-01), Maeshima et al.
patent: 6167025 (2000-12-01), Hsing et al.
patent: 6185210 (2001-02-01), Troxel
patent: 6324162 (2001-11-01), Chaudhuri
patent: 6442131 (2002-08-01), Kondo
patent: 6452915 (2002-09-01), Jorgensen
Callon, R. et al., “A Framework for Multiprotocol Label Switching,” Internet Draft published at WWW.ietf.org/internet-drafts/draft-ietf-mpls-framework-02.txt; May 1998.
Branden, R., et al., “Resource ReSerVation Protocol (RSVP)”, Internet Draft, published at WWW.ietf.org/rfc/rfc2205.txt; Sep. 1997.
Cisco Technology Inc.
Hamilton Brook Smith & Reynolds P.C.
Ton Dang
Tran Phuc
LandOfFree
Multihop nested tunnel restoration does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Multihop nested tunnel restoration, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Multihop nested tunnel restoration will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3347163