The present invention generally relates to forwarding data. The invention relates more specifically to a method and apparatus for forwarding data in a data communications network.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In computer networks such as the Internet, packets of data are sent from a source to a destination via a network of elements including links (communication paths such as telephone or optical lines) and nodes (usually routers directing the packet along one or more of a plurality of links connected to it) according to one of various routing protocols.
One such protocol is MPLS (Multi Protocol Label Switching). MPLS is a protocol that is well known to the skilled reader and which is described in document “Multi Protocol Label Switching Architecture” which is available at the time of writing on the file “rfc3031.txt” in the directory “rfc” of the domain “ietf.org” on the World Wide Web. According to MPLS, a complete path for a source-destination pair is established, and values required for forwarding a packet between adjacent routers in the path together with headers or “labels” are pre-pended to the packet. The labels are used to direct the packet to the correct interface and next hop. The labels precede the IP or other header allowing smaller outer headers.
The path for the source-destination pair, termed a Label Switched Path (LSP) can be established according to various different approaches. One such approach is Label Distribution Protocol (LDP) in which each router in the path sends its label to the next hop router on the path as determined from its IP routing table. Alternatively Resource Reservation Protocol (RSVP) can be invoked in which case, for example, a network administrator can engineer a path, providing strict source routing.
For each LSP created, a forwarding equivalent class (FEC) is associated with the path specifying which packets are mapped to it.
A problem in data communication networks arises upon de-activation of a network component such as a link or a node either by component failure or by planned down time. In either case there is a period of disruption to the delivery of traffic and packets for destinations which were previously reached by traversing the deactivated component may be dropped. In many time-critical applications it is not sufficient for the routers to converge on the adjusted network in a normal way as this takes too much time. Accordingly one known solution in MPLS networks is to pre-compute and pre-signal a repair path using RSVP methods. Such an approach can, however, require network administrator configuration of the repair paths.
An alternative approach is described in “ip/ldp local protection” which is available at the time of writing on the file “draft-atlas-ip-local-protect-00.txt” in the directory “pub/id” of the domain “watersprings.org” on the World Wide Web. According to the approach described in this document, a computing node computes both a “primary next-hop” for packets for a destination together with an “alternate next-hop”. The alternate next hop is used in the case of failure of the primary next hop (failure either of the next-hop node or the link to the next hop-node). The alternate next-hop can be another neighbor node whose own shortest path to the destination does not include the computing node. In another case the alternate next-hop is a “U-turn alternate” comprising a neighbor whose primary next hop is the computing node. And which has as its alternate next-hop a node whose shortest path does not include the computing node. However this approach can only redirect a packet over a maximum of two hops.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
A method and apparatus for forwarding data in a data communications network is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments are described herein according to the following outline:
1.0 General Overview
The needs identified in the foregoing Background, and other needs and objects that will become apparent for the following description, are achieved in the present invention, which comprises, in one aspect, a method of forwarding data in a data communications network having a plurality of nodes. The method comprises the steps, performed at the repairing node of computing a repair path around a network component to a target node and forwarding data along the repair path. The computing step comprises the step of computing an intermediate node reachable by the repairing node and from which the target node can be reached. The forwarding step includes the step of constructing a Multi-Protocol Label Switching (MPLS) packet for forwarding to the intermediate node.
In other aspects, the invention encompasses a computer apparatus and a computer-readable medium configured to carry out the foregoing steps.
2.0 Structural and Functional Overview
In overview a method for forwarding data can be understood with reference to
In the case of normal routing node A will forward packets to node X via node B, node C and a path designated generally 58. However referring to
According to the method described herein the repair path is constructed according to the approach described in co-pending patent application Ser. No. 10/340,371, filed 9 Jan. 2003, entitled “Method and Apparatus for Constructing a Backup Route in a Data Communications Network” of Kevin Miles et al., (“Miles et al.”), the entire contents of which are incorporated by reference for all purposes as if fully set forth herein and discussed in more detail below. According to the solution put forward in Miles et al, a repairing node (node A) pre-computes a first set of nodes comprising the set of all nodes reachable according to its protocol other than nodes reachable by traversing an adjacent component. This is termed here node A's “P-space” Pa reference numeral 60 and the operation is carried out for each adjacent component. The repairing node also pre-computes a second set of nodes comprising the set of all nodes from which a target node (node C) is reachable without traversing the failed component. This is termed here node C's “Q-space”, QC, reference numeral 62. The method then determines whether any intermediate nodes exist in the intersection between the first and second sets of nodes Pa, QC or a one-hop extension thereof. When the repairing node detects failure of an adjacent component it tunnels packets for the target node C to a tunnel end point comprising a node in the intersection of the first and second sets of nodes calculated for that failed component.
In particular
As a result of this approach an optimized and rapidly implemented repair route technique can be introduced in an MPLS network. Furthermore, making use of MPLS forwarding allows enhanced tunneling capability and in particular the possibility of multiply nested tunnels. Furthermore because the MPLS encapsulations are significantly smaller than IP tunnel headers and do not require a check sum fix-up higher performance is available.
In the MPLS implementation, in the case where the intermediate node lies both in P-space and Q-space and directed forwarding is not required then node A simply computes the repair path to node P and constructs a label switched path to node P in a manner described in more detail below. Where, however, directed forwarding is required the packet from node A to node P must carry a directed forwarding instruction for node P and various manners in which this can be achieved is described in more detail below. In addition, node A also needs to discover the node in Q-space's label for forwarding the packet to the destination and once again various approaches to achieving this are discussed in more detail below.
The method described herein further extends to additional improvements to repair paths in particular implemented in MPLS networks.
3.0 Method of Forwarding Data in a Data Communications Network
Referring to
The manner in which a repairing node such as node A pre-computes its repair path is described in detail in Miles et al and is only summarized here for purposes of ease of reference. In order to compute its P-space node A computes a shortest path tree rooted at node A but excising nodes reachable via the failed network component, node B. Similarly to compute the Q-space of a target node comprising a neighbor of the failed component, node C, the reverse spanning tree diagram is computed for the target node again excising nodes reachable only via the failed component. If a common node is found in P-space this becomes the intermediate node to which repaired packets are tunneled from node A. Otherwise the tunneled packet to node P is then directly forwarded to a node in Q-space no more than one hop away. From node Q the packet will be forwarded normally to node X. In order to implement a fast re-route capability the repair paths are pre-computed at each participating node for each possible failure and each packet destination such that upon component failure the repair path can be implemented as soon as possible.
Because MPLS rather than conventional hop-by-hop IP forwarding is implemented to effectively tunnel the packets along the repair path, however, additional information is required at the repairing node in order to allow implementation of the repair path. As mentioned above, the first information required is the DF Vector such that node P will direct forward the packet to node Q as part of the repair strategy. Generally it is necessary to encode the DF operations within the framework of the MPLS network and establish how the DF Vectors or labels are distributed. In particular two ways of encoding a DF operation in an MPLS network are available, either in a form of a composite FEC or a label stack. In either case the label will then be assigned to repaired packets as appropriate but must first be available at the repairing node.
In the case of a composite FEC, a new composite FEC is created for packets to be repaired along the repair path with the semantics “forward to node P and then forward directly (i.e. direct forward) to node Q”. For example where the eventual destination of a packet in the FEC is node X then the encapsulation at node A is as shown in
In the alternative the label stack pushed on the packet by node A is as shown in
Whether the directed forwarding instruction is carried in a single composite label as shown in
In the first implementation the label of either type can be distributed by LDP in the conventional hop by hop methods. For example in the case of composite labels a router will generate its own composite label for each participating node in the network and provide this to each of its neighbors. Internally it maps each of these composite labels to a next hop and to the composite label to the destination node provided by the next hop in accordance with conventional LDP operation although of course with a more complex FEC. For example referring to the network shown schematically in
In the case of the two label stack the DF FEC (P→Q)P is propagated unchanged throughout the network via LDP. That is, the DF FEC (P→Q)P is distributed to the immediate neighbors of P by conventional LDP means. In contrast to conventional LDP, this same FEC is re-distributed to the neighbors of the neighbors of P without modification, and so on until it is distributed throughout the network and thus it is learned by node A.
In an alternative implementation each node can flood via a consistent protocol such as IGP (Interior Gateway Protocol) a DF vector for each of its neighbors across the network in the form of an MPLS label from the DF FEC. As a result all routers in the network will receive all the DF vectors as part of the flooding of the IP topology information rather than via LDP. In that case, node A having established that it wishes to tunnel to node P and then direct forward to node Q as part of its repair strategy can retrieve the DF vector (P→Q)P from its link-state database.
A further implementation is described with reference to
Yet a further implementation can be understood with reference to
Reverting to
Once again various implementations are possible. In the first implementation, if the packet is an IP packet then node A can simply omit the label. In that case once P has stripped off the respective labels all that remains will be the payload in the form of an IP packet which Q can forward using normal IP forwarding over MPLS. However this will not be appropriate in the case where there is also non-IP traffic.
In an alternative implementation, in an approach equivalent to that described with reference to
In addition to the various implementations described above for obtaining the labels (P→Q) and XQ, additional functionality can be added into the MPLS network to allow the relevant labels to be extracted. In a first implementation an additional label server L, reference numeral 70 is included in the network shown in
In order to obtain Q's label for X, XQ, in block 730 node A obtains Q's label database from the label server as well.
Each node can register or request a full database of labels or individual labels in order to minimize the size of the transaction required as a result of a topology change such that when a network update is flooded through IGP each node will know to query the label server for appropriate label data.
An additional or alternative functionality which can be incorporated into an MPLS network is the provision of “domain-wide labels”. Typically, MPLS labels have only local scope, with the meaning of a given label being defined by the node that advertised it. This allows a single label to be used to mean many different things in different places in the network, and thus reduces the total size of the required label space. Accordingly a router imposing the label has to perform an association with the router that is going to interpret the label in order to learn the appropriate label value. MPLS further requires that a protocol is needed in order to exchange the labels with the neighbor nodes.
According to the domain-wide label approach a label is assigned a common meaning throughout a routing domain such as an IGP domain and the labels are flooded throughout the IGP. As a result all routers know the identity of the destination of a packet carrying a domain-wide label. Accordingly there is no need for an exchange of label information between nodes A and P and A and Q. A domain-wide label can be assigned for, for example, a packet tunneled to node P or a packet to be direct forwarded for node Q. Node Q can then strip the outer domain-wide label and forward the packet to the domain-wide label for destination X. Domain-wide labels can be allocated in any appropriate manner such as manual allocation or as a function of the IP address of a destination and can be a single stack entry or a composite of multiple label stack entries. As an alternative to flooding the domain-wide labels can be maintained, and accessed from a label server in a manner analogous to that described with reference to
In this case the number of domain-wide labels is reduced by defining “normal” domain-wide addresses and “adjacency” domain-wide labels. A node receiving a domain-wide label will establish whether it is a normal forwarding domain-wide label or an adjacency domain-wide label. If it is an adjacency domain-wide label the receiving node will then establish whether it is for a neighbor node. In that case the receiving node forwards the packet to the neighbor node by directed forwarding. Otherwise the receiving node forwards the packet by normal forwarding towards the destination. As a result, for a network of N nodes only 2N domain-wide labels are required: a normal forwarding domain-wide label and an adjacency domain-wide label for each node.
According to an alternative additional functionality the labels can be flooded according to a flooded local label (FLL) protocol. In this case local labels i.e. labels with local context rather than domain-wide context are used as in conventional MPLS but are flooded to all the nodes throughout the network using, for example, a link-state IGP rather than via LDP or RSVP. The method according to this implementation can be better understood with reference to
It will further be appreciated that the MPLS techniques described above can be extended yet further in conjunction with the construction of backup routes of the type described in Miles et al to yet further enhance the scope and flexibility of backup routes. For example the capability for multiply nested tunnels with reduced overhead provided by MPLS provides significant benefits.
A first extension of backup routes will be described with reference to
A further extension is described with reference to
One manner of doing this is to use node E's “extended” P-space, that is to say the union of the P-spaces of each of E's neighbors. In the same manner A's P-space can in fact be A's extended P-space.
Accordingly the extended P-space 1114 of node E includes a node F 1116 one hop from node E via link 1118. Node F has a path 1120 to a node G 1122 on the edge of node E's extended P-space 1114. Node G is in turn one hop from a node H 1124 in node C's Q-space 1110 QC via link 1126. Accordingly a repair path is constructed via nodes N, E, F, G and H. Alternatively node A's and/or node E's non-extended P-space can be used.
A further development of repair path construction can be understood with reference to
Yet a further implementation comprises allowing extension of the number of hops between P and Q-space. Referring once again to
It will be recognized that any appropriate extensions or variations used in the construction of repair paths can be implemented on an MPLS network. As discussed above it is possible to extend P-space or Q-space to include the union of the P-spaces of the repairing node or the Q-spaces of the target node with respect to the failed component. In addition, as described in co-pending patent application Ser. No. 10/442,589, filed 20 May 2003, entitled “Method and Apparatus for Constructing a Transition Route in a Data Communications Network” of Stewart F. Bryant et al., (Bryant et al) the entire contents of which are incorporated by reference for all purposes as if fully set forth herein, the approach can be extended to cover repairs for non-adjacent nodes. Accordingly a node not adjacent to a failure can nonetheless calculate a repair path to a target using the approaches discussed above.
Yet further, as described in co-pending patent application Ser. No. 10/848,669, filed May 18, 2004, entitled “Method and Apparatus for Forwarding Data in a Data Communications Network” of Mike Shand et al (“Shand et al”), it is possible to construct a “secondary repair path”. In that case a primary repairing node which is unable to establish a repair path to a target instead establishes a repair path to a secondary repairing node which can instigate a repair path for the target, for example by computing the P and Q-space for the secondary repairing node. As also discussed in Shand et al repair path can also be computed in the case of “multi-homed prefixes” (MHP). In some instances, rather than a prefix or address belonging for example to different autonomous systems or mission critical services being attached to exactly one node in the network, in many cases the same prefix will be attached for two or more nodes which may not be adjacent. According to the solution put forward in Shand et al, traffic for an MHP is tunneled to a node to which the MHP is attached other than the failed component.
In the case of secondary repairs and MHPs, an additional layer of encapsulation is constructed at node A allowing tunneling to be required to the destination either in the form of a secondary repairing node or an MHP alternative attachment point. As discussed above, node A will need to obtain the tunnel end point's label for the destination. For example when node A is conducting a secondary repair to a neighbor of a failed node it will need to acquire the necessary labels from the neighbor as well as node Q and place them in the label stack. The labels can be acquired in any of the manners discussed above as appropriate.
In the case of an MHP repair which may or may not involve secondary repair, node A needs to acquire the alternate exits points labeled to the destination according to one of the approaches described above and provide an appropriate encapsulation in the label stack. Alternatively since MHP is an IP concept node A could determine the path to the alternate exit point and allow the alternate exit points to perform a simple IP lookup for the final destination and forward as normal.
Once again it will be seen that these approaches can be implemented in, and improved by the techniques adopted by an MPLS network.
In order to implement the repair path, upon detection of a failed component the repairing node, node A in
The mechanisms by which the method and optimizations discussed above are implemented will be well known to the skilled reader and do not require detailed discussion here. For example the manner in which the repair paths are computed, the MPLS labels pushed and exchanged and packets forwarded along the repair path can be implemented in any appropriate manner such as hardware or software and using for example micro-code.
4.0 Implementation Mechanisms—Hardware Overview
Computer system 140 includes a bus 142 or other communication mechanism for communicating information, and a processor 144 coupled with bus 142 for processing information. Computer system 140 also includes a main memory 146, such as a random access memory (RAM), flash memory, or other dynamic storage device, coupled to bus 142 for storing information and instructions to be executed by processor 144. Main memory 146 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 144. Computer system 140 further includes a read only memory (ROM) 148 or other static storage device coupled to bus 142 for storing static information and instructions for processor 144. A storage device 150, such as a magnetic disk, flash memory or optical disk, is provided and coupled to bus 142 for storing information and instructions.
A communication interface 158 may be coupled to bus 142 for communicating information and command selections to processor 144. Interface 158 is a conventional serial interface such as an RS-232 or RS-422 interface. An external terminal 152 or other computer system connects to the computer system 140 and provides commands to it using the interface 158. Firmware or software running in the computer system 140 provides a terminal interface or character-based command interface so that external commands can be given to the computer system.
A switching system 156 is coupled to bus 142 and has an input interface and a respective output interface (commonly designated 159) to external network elements. The external network elements may include a plurality of additional routers 160 or a local network coupled to one or more hosts or routers, or a global network such as the Internet having one or more servers. The switching system 156 switches information traffic arriving on the input interface to output interface 159 according to pre-determined protocols and conventions that are well known. For example, switching system 156, in cooperation with processor 144, can determine a destination of a packet of data arriving on the input interface and send it to the correct destination using the output interface. The destinations may include a host, server, other end stations, or other routing and switching devices in a local network or Internet.
The computer system 140 implements as a router acting as a repairing node or target node the above described method of forwarding data. The implementation is provided by computer system 140 in response to processor 144 executing one or more sequences of one or more instructions contained in main memory 146. Such instructions may be read into main memory 146 from another computer-readable medium, such as storage device 150. Execution of the sequences of instructions contained in main memory 146 causes processor 144 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 146. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the method. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 144 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 150. Volatile media includes dynamic memory, such as main memory 146. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 142. Transmission media can also take the form of wireless links such as acoustic or electromagnetic waves, such as those generated during radio wave and infrared data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 144 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 140 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 142 can receive the data carried in the infrared signal and place the data on bus 142. Bus 142 carries the data to main memory 146, from which processor 144 retrieves and executes the instructions. The instructions received by main memory 146 may optionally be stored on storage device 150 either before or after execution by processor 144.
Interface 159 also provides a two-way data communication coupling to a network link that is connected to a local network. For example, the interface 159 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the interface 159 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the interface 159 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
The network link typically provides data communication through one or more networks to other data devices. For example, the network link may provide a connection through a local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”. The local network and the Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link and through the interface 159, which carry the digital data to and from computer system 140, are exemplary forms of carrier waves transporting the information.
Computer system 140 can send messages and receive data, including program code, through the network(s), network link and interface 159. In the Internet example, a server might transmit a requested code for an application program through the Internet, ISP, local network and communication interface 158. One such downloaded application provides for the method as described herein.
The received code may be executed by processor 144 as it is received, and/or stored in storage device 150, or other non-volatile storage for later execution. In this manner, computer system 140 may obtain application code in the form of a carrier wave.
5.0 Extensions and Alternatives
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Any appropriate routing protocol and mechanism can be adopted to implement the invention. The method steps set out can be carried out in any appropriate order and aspects from the examples and embodiments described juxtaposed or interchanged as appropriate.
Any appropriate implementation of MPLS and any appropriate label distribution protocol can be adopted to implement the invention. Similarly, where required, any appropriate link state protocol such as intermediate system-intermediate system (IS-IS) or open shortest path first (OSPF) can be implemented. Link state protocols of this type are well understood by the skilled reader and well documented in pre-existing documentation, and therefore are not described in detail here. Similarly any appropriate network can provide the platform for implementation of the method.
Any appropriate repair path construction in which the repairing node identifies an appropriate intermediate node which it can reach and from which the target node is reachable can be introduced as well.
Although the discussion is principally directed to use of an IP based repair path construction strategy in an MPLS network it will be seen that use of the MPLS encapsulation and techniques described above in an IP network is also contemplated. One possible example is the case of directed forwarding where an MPLS label is used as the PQ vector for example.
Number | Name | Date | Kind |
---|---|---|---|
4956835 | Grover | Sep 1990 | A |
5243592 | Perlman et al. | Sep 1993 | A |
5253248 | Dravida et al. | Oct 1993 | A |
5825772 | Dobbins et al. | Oct 1998 | A |
5959968 | Chin et al. | Sep 1999 | A |
5999286 | Venkatesan | Dec 1999 | A |
6002674 | Takei et al. | Dec 1999 | A |
6032194 | Gai et al. | Feb 2000 | A |
6044075 | Le Boudec et al. | Mar 2000 | A |
6061650 | Malkin et al. | May 2000 | A |
6075631 | Bala et al. | Jun 2000 | A |
6098107 | Narvaez-Guarnieri et al. | Aug 2000 | A |
6111257 | Shand et al. | Aug 2000 | A |
6128750 | Espy et al. | Oct 2000 | A |
6148410 | Baskey et al. | Nov 2000 | A |
6185598 | Farber et al. | Feb 2001 | B1 |
6243754 | Guerin et al. | Jun 2001 | B1 |
6246669 | Chevalier et al. | Jun 2001 | B1 |
6256295 | Callon | Jul 2001 | B1 |
6295275 | Croslin | Sep 2001 | B1 |
6321271 | Kodialam et al. | Nov 2001 | B1 |
6343122 | Andersson | Jan 2002 | B1 |
6349091 | Li | Feb 2002 | B1 |
6356546 | Beshai | Mar 2002 | B1 |
6389764 | Stubler et al. | May 2002 | B1 |
6473421 | Tappan | Oct 2002 | B1 |
6507577 | Mauger et al. | Jan 2003 | B1 |
6535481 | Andersson et al. | Mar 2003 | B1 |
6578086 | Regan et al. | Jun 2003 | B1 |
6654361 | Dommety et al. | Nov 2003 | B1 |
6668282 | Booth et al. | Dec 2003 | B1 |
6690671 | Anbiah et al. | Feb 2004 | B1 |
6697325 | Cain | Feb 2004 | B1 |
6704320 | Narvaez et al. | Mar 2004 | B1 |
6711125 | Walrand et al. | Mar 2004 | B1 |
6714551 | Le-Ngoc | Mar 2004 | B1 |
6718382 | Li et al. | Apr 2004 | B1 |
6778531 | Kodialam et al. | Aug 2004 | B1 |
6829215 | Tornar | Dec 2004 | B2 |
6879594 | Lee et al. | Apr 2005 | B1 |
6895441 | Shabtay et al. | May 2005 | B1 |
6928484 | Huai et al. | Aug 2005 | B1 |
6944131 | Beshai et al. | Sep 2005 | B2 |
6950870 | Beaulieu | Sep 2005 | B2 |
6982951 | Doverspike et al. | Jan 2006 | B2 |
6996065 | Kodialam et al. | Feb 2006 | B2 |
7046680 | McDysan et al. | May 2006 | B1 |
7058016 | Harper | Jun 2006 | B1 |
7099286 | Swallow | Aug 2006 | B1 |
7113481 | Elie-Dit-Cosaque et al. | Sep 2006 | B2 |
7158486 | Rhodes | Jan 2007 | B2 |
7209434 | Kano et al. | Apr 2007 | B2 |
7242664 | Einstein et al. | Jul 2007 | B2 |
7260645 | Bays | Aug 2007 | B2 |
7274654 | Yang et al. | Sep 2007 | B2 |
7274658 | Bornstein et al. | Sep 2007 | B2 |
7280472 | Rigby et al. | Oct 2007 | B2 |
7292581 | Finn | Nov 2007 | B2 |
7330440 | Bryant et al. | Feb 2008 | B1 |
7349427 | Canning et al. | Mar 2008 | B1 |
7490165 | Katukam et al. | Feb 2009 | B1 |
20020004843 | Andersson et al. | Jan 2002 | A1 |
20020021671 | Quinlan | Feb 2002 | A1 |
20020037010 | Yamauchi | Mar 2002 | A1 |
20020069292 | Gaddis et al. | Jun 2002 | A1 |
20020093954 | Weil et al. | Jul 2002 | A1 |
20020112072 | Jain | Aug 2002 | A1 |
20020116669 | Jain | Aug 2002 | A1 |
20020131362 | Callon | Sep 2002 | A1 |
20020136223 | Ho | Sep 2002 | A1 |
20020171886 | Wu et al. | Nov 2002 | A1 |
20020172157 | Rhodes | Nov 2002 | A1 |
20030063613 | Carpini et al. | Apr 2003 | A1 |
20030079040 | Jain et al. | Apr 2003 | A1 |
20030103449 | Barsheshet et al. | Jun 2003 | A1 |
20030110287 | Mattson | Jun 2003 | A1 |
20030193959 | Lui et al. | Oct 2003 | A1 |
20030210705 | Seddigh et al. | Nov 2003 | A1 |
20030223361 | Hussain et al. | Dec 2003 | A1 |
20040001497 | Sharma | Jan 2004 | A1 |
20040001508 | Zheng et al. | Jan 2004 | A1 |
20040017796 | Lemieux et al. | Jan 2004 | A1 |
20040038671 | Trayford et al. | Feb 2004 | A1 |
20040071089 | Bauer et al. | Apr 2004 | A1 |
20040085894 | Wang et al. | May 2004 | A1 |
20040117251 | Shand | Jun 2004 | A1 |
20040151181 | Chu et al. | Aug 2004 | A1 |
20040185777 | Bryson | Sep 2004 | A1 |
20050007950 | Liu | Jan 2005 | A1 |
20050031339 | Qiao et al. | Feb 2005 | A1 |
20050038909 | Yoshiba et al. | Feb 2005 | A1 |
20050047353 | Hares | Mar 2005 | A1 |
20050088965 | Atlas et al. | Apr 2005 | A1 |
20050097219 | Goguen et al. | May 2005 | A1 |
20050111351 | Shen | May 2005 | A1 |
20050281271 | Beshai et al. | Dec 2005 | A1 |
20060007929 | Desai et al. | Jan 2006 | A1 |
20060013125 | Vasseur et al. | Jan 2006 | A1 |
20060018253 | Windisch et al. | Jan 2006 | A1 |
20060080421 | Hu | Apr 2006 | A1 |
20060182117 | Chen et al. | Aug 2006 | A1 |
20060221962 | Previdi et al. | Oct 2006 | A1 |
20060291391 | Vasseur et al. | Dec 2006 | A1 |
20070011284 | Le Roux et al. | Jan 2007 | A1 |
20070038767 | Miles et al. | Feb 2007 | A1 |
20070248016 | Ashwood Smith et al. | Oct 2007 | A1 |
20070291790 | Ue et al. | Dec 2007 | A1 |
Number | Date | Country |
---|---|---|
1440159 | Sep 2003 | CN |
WO 0206918 | Jan 2002 | WO |
0223832 | Mar 2002 | WO |
Number | Date | Country | |
---|---|---|---|
20060087965 A1 | Apr 2006 | US |