Source: http://www.google.com/patents/US7336615?dq=patent:6144888
Timestamp: 2017-07-21 01:31:25
Document Index: 322496931

Matched Legal Cases: ['§ 119', '§ 112', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§4', '§ 4', '§ 4', '§ 4']

Patent US7336615 - Detecting data plane livelines in connections such as label-switched paths - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsTesting the liveliness of a data plane of a label switched path (LSP) using a two stage approach. The first stage may use a general echo request operation that may be implemented using hardware. Therefore, the first stage does not heavily burden the control plane of the LSR. If a suspect LSP passes the...http://www.google.com/patents/US7336615?utm_source=gb-gplus-sharePatent US7336615 - Detecting data plane livelines in connections such as label-switched pathsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS7336615 B1Publication typeGrantApplication numberUS 10/179,927Publication dateFeb 26, 2008Filing dateJun 25, 2002Priority dateJun 25, 2001Fee statusPaidPublication number10179927, 179927, US 7336615 B1, US 7336615B1, US-B1-7336615, US7336615 B1, US7336615B1InventorsPing Pan, Nischal ShethOriginal AssigneeJuniper Networks, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (5), Referenced by (44), Classifications (7), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetDetecting data plane livelines in connections such as label-switched paths
US 7336615 B1Abstract
Testing the liveliness of a data plane of a label switched path (LSP) using a two stage approach. The first stage may use a general echo request operation that may be implemented using hardware. Therefore, the first stage does not heavily burden the control plane of the LSR. If a suspect LSP passes the first stage of the diagnostic operation, nothing more needs to be done. If, however, the suspect LSP fails the first stage, the diagnostic operation proceeds to a second stage. The second stage of the diagnostic operation sends probing massages through the suspect LSP, but uses the control plane to deliver the acknowledging messages. If the suspect LSP fails the second stage of the diagnostic operation, the ingress LSR can infer that the LSP is down, and begin recovery actions. The probing messages may include padding so that MTU limits can be tested. In addition, the probing messages may be encapsulated in a protocol that allows flow control, thereby protecting an LSR that can receive such messages from DoS attacks.
Benefit is claimed, under 35 U.S.C. § 119(e)(1), to the filing date of provisional patent application Ser. No. 60/301,050, entitled “DETECTING DATA PLANE LIVELINESS IN RSVP-TE”, filed on Jun. 25, 2001 and listing Ping Pan and Nischal Sheth as the inventors, for any inventions disclosed in the manner provided by 35 U.S.C. § 112, ¶ 1. This provisional application is expressly incorporated herein by reference. However, the invention is not intended to be limited by any statements in that provisional application. Rather, that provisional application should be considered to describe exemplary embodiments of the invention.
The description of art in this section is not, and should not be interpreted to be, an admission that such art is prior art to the present invention. Although one skilled in the art will be familiar with networking, circuit switching, packet switching, label switched paths, and protocols such as RSVP and LDP, each is briefly introduced below for the convenience of the less skilled reader. More specifically, circuit switched and packet switched networks are introduced in § 1.2.1. The need for label switched paths, their operation, and their establishment are introduced in §§ 1.2.2-1.2.4 below. Finally, “failures” in a label switched path, as well as typical failure responses, are introduced in § 1.2.5 below.
§ 1.2.1 Circuit Switched Networks and Packet Switched Networks
Circuit switched networks establish a connection between hosts (parties to a communication) for the duration of their communication (“call”). The public switched telephone network (“PSTN”) is an example of a circuit switched network, where parties to a call are provided with a connection for the duration of the call. Unfortunately, many communications applications, circuit switched networks use network resources inefficiently. Consider for example, the communications of short, infrequent “bursts” of data between hosts. Providing a connection for the duration of a call between such hosts simply wastes communications resources when no data is being transferred. The desire to avoid such inefficiencies has lead to the development of packet switched networks.
Packet switched networks forward addressed data (referred to as “packets” in the specification below without loss of generality), typically on a best efforts basis, from a source to a destination. Many large packet switched networks are made up of interconnected nodes (referred to as “routers” in the specification below without loss of generality). The routers may be geographically distributed throughout a region and connected by links (e.g., optical fiber, copper cable, wireless transmission channels, etc.). In such a network, each router typically interfaces with (e.g., terminates) multiple links.
Packets traverse the network by being forwarded from router to router until they reach their destinations (as typically specified by so-called layer-3 addresses in the packet headers). Unlike switches, which establish a connection for the duration of a “call” or “session” to send data received on a given input port out on a given output port, routers determine the destination addresses of received packets and, based on these destination addresses, determine, in each case, the appropriate link on which to send them. Routers may use protocols to discover the topology of the network, and algorithms to determined the most efficient ways to forward packets towards a particular destination address(es). Since the network topology can change, packets destined for the same address may be routed differently. Such packets can even arrive out of sequence.
§ 1.2.2 The Need for Label Switched Paths
Traffic engineering permits network administrators to map traffic flows onto an existing physical topology. In this way, network administrators can move traffic flows away from congested shortest paths to a less congested path. Alternatively, paths can be determined autonomously, even on demand. Label-switching can be used to establish a fixed path from a head-end node (e.g., an ingress router) to a tail-end node (e.g., an egress router). The fixed path may be determined using known protocols such as RSVP or LDP. Once a path is determined, each router in the path may be configured (manually, or via some signaling mechanism) to forward packets to a peer (e.g., a “downstream” or “upstream” neighbor) router in the path. Routers in the path determine that a given set of packets (e.g., a flow) are to be sent over the fixed path (as opposed to being routed individually) based on unique labels added to the packets.
§ 1.2.3 Operations of Label Switched Paths
In one exemplary embodiment, the virtual link generated is a label-switched path (“LSP”). More specifically, recognizing that the operation of forwarding a packet, based on address information, to a next hop can be thought of as two steps-partitioning the entire set of possible packets into a set of forwarding equivalence classes (“FECs”), and mapping each FEC to a next hop. As far as the forwarding decision is concerned, different packets which get mapped to the same FEC are indistinguishable. In one technique concerning label switched paths, dubbed “multiprotocol label switching” (or “MPLS”), a particular packet is assigned to a particular FEC just once, as the packet enters the label-switched domain (part of the) network. The FEC to which the packet is assigned is encoded as a label, typically a short, fixed length value. Thus, at subsequent nodes, no further header analysis need be done—all subsequent forwarding over the label-switched domain is driven by the labels. Such FECs may be generalized such that particular ports, wavelengths, time slots, channels, etc. are used instead of labels.
FIG. 1 illustrates a label-switched path 110 across a network. Notice that label-switched paths 110 are simplex—traffic flows in one direction from a head-end label-switching router (or “LSR”) 120 at an ingress edge to a tail-end label-switching router 130 at an egress edge. Generally, duplex traffic requires two label-switched paths—one for each direction. However, some protocols support bi-directional label-switched paths. Notice that a label-switched path 110 is defined by the concatenation of one or more label-switched hops, allowing a packet to be forwarded from one label-switching router (LSR) to another across the MPLS domain 110.
Recall that a label may be a short, fixed-length value carried in the packet's header to identify a forwarding equivalence class (or “FEC”). Recall further that a FEC is a set of packets that are forwarded over the same path through a network, sometimes even if their ultimate destinations are different. At the ingress edge of the network, each packet is assigned an initial label (e.g., based on all or a part of its layer 3 destination address). More specifically, referring to the example illustrated in FIG. 2, an ingress label-switching router 210 interprets the destination address 220 of an unlabeled packet, performs a longest-match routing table lookup, maps the packet to an FEC, assigns a label 230 to the packet and forwards it to the next hop in the label-switched path.
In the MPLS domain, the label-switching routers (LSRs) 220 ignore the packet's network layer header and simply forward the packet using label-swapping. More specifically, when a labeled packet arrives at a label-switching router (LSR), the input port number and the label are used as lookup keys into an MPLS forwarding table. When a match is found, the forwarding component retrieves the associated outgoing label, the outgoing interface (or port), and the next hop address from the forwarding table. The incoming label is replaced with the outgoing label and the packet is directed to the outgoing interface for transmission to the next hop in the label-switched path. FIG. 2 illustrates such label-switching by label-switching routers (LSRs) 220 a and 220 b. When the labeled packet arrives at the egress label-switching router, if the next hop is not a label-switching router, the egress label-switching router discards (“pops”) the label and forwards the packet using conventional (e.g., longest-match IP) forwarding. FIG. 2 illustrates such label popping and IP forwarding by egress label-switching router 240.
§ 1.2.4 Establishing Label Switched Paths
There are two basic types of LSPs—static LSPs and protocol (e.g., LDP, RSVP, BGP) signaled LSPs. Although each type of LSP is known to those skilled in the art, each is introduced below for the reader's convenience.
With LDP signaled LSPs, routers establish label-switched paths (LSPs) through a network by mapping network-layer routing information directly to data link layer switched paths. LDP operates in a hop-by-hop fashion as opposed to RSVP's end-to-end fashion. More specifically, LDP associates a set of destinations (route prefixes and router addresses) with each data link LSP. This set of destinations is called the Forwarding Equivalence Class (“FEC”). These destinations all share a common data link layer-switched path egress and a common unicast routing path. Each router chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other routers. This forms a tree of LSPs that converge on the egress router.
With RSVP signaled LSPs, an ingress (i.e., head-end) router is configured. The head-end router uses (e.g., explicit path and/or path constraint) configuration information to determine the path. The egress (i.e., tail-end) and intermediate routers accept signaling information from the ingress (i.e., head-end) router. RSVP signaled LSPs maintain “soft-state” connections; meaning an RSVP signaled LSP is refreshed periodically or it is torn down. Therefore, the routers of the LSP set up and maintain the LSP cooperatively through the use of path signaling messages such as PATH messages and RESV messages.
PATH messages are sent from the ingress router to the egress router and follow the path of the LSP. RESV messages originate from the egress router, and is delivered hop-by-hop back towards the ingress router. As a PATH message travels the path of an LSP, it takes the IP address of the router it was transmitted from and stores it in the router to which it is sent. This “IP trail” left by the PATH message is used by RESV messages to return back through the LSP path. Any errors encountered when establishing and maintaining an LSP are reported back to the ingress (i.e., head-end) router.
§ 1.2.5 “Failures” in a Label Switched Path
In various situations the forwarding information 220 of the forwarding component 210 of intermediate label-switching routers (LSRs) may become corrupted, e.g., OUT label 230 is stored as “3” instead of “5”. In this situation, data leaving LSR 210 will be “black-holed”. That is, when LSR 220 a receives the packet with an IN label of “3” it will either discard it or transmit the packet along an LSP other than the desired LSP.
The present invention discloses apparatus, data structures and methods for testing the liveliness of a data plane of a label switched path (LSP). A two stage approach is used to minimize the processing overhead imposed on an LSR control plane. The first stage uses a general echo request operation that may be implemented using hardware. Therefore, the first stage does not heavily burden the control plane of the LSR. If a suspect LSP passes the first stage of the diagnostic operation, nothing more need be done. If, however, the suspect LSP fails the first stage, the diagnostic operation proceeds to a second stage.
FIG. 1 illustrates an LSP including a head-end (or ingress) LSR, an intermediate LSR, and a tail-end (or egress) LSR.
The present invention involves methods, apparatus and data structures for testing the liveliness of label switched paths. The following description is presented to enable one skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles set forth below may be applied to other embodiments and applications. Thus, the present invention is not intended to be limited to the embodiments shown and the inventors regard their invention as the following disclosed methods, apparatus and data structures and any other patentable subject matter.
In the following, exemplary environments in which the present invention may operate are described in § 4.1. Then high-level functions that may be performed by the present invention are introduced in § 4.2. In § 4.3, exemplary operations that may be used to effect those high-level functions are described. Thereafter, exemplary apparatus, methods and data structures that may be used are described in § 4.4. Examples illustrating operations preformed by exemplary embodiments of the invention are then provided in § 4.5. Finally, some conclusions regarding the present invention are set forth in § 4.6.
The present invention may be used in communication systems including nodes for forwarding addressed data, such as packets, and having a control component and a forwarding component. The present invention may be initiated by the control component of the ingress node of a label switched path. The node may be a router that supports label-switched paths.
FIG. 4 is a bubble-chart of an exemplary router 400 in which the present invention may be used. The router 400 may include a packet forwarding operation 410 (part of a “data plane”) and a control (e.g., routing) operation 420 (part of a “control plane”). The packet forwarding operation 410 may forward received packets based on route-based forwarding information 450 and/or based on label-based forwarding information 490, such as label-switched path information.
§ 4.2 HIGH-LEVEL FUNCTIONS THAT MAY BE PERFORMED BY THE PRESENT INVENTION
One high-level function of the present invention may be to test the liveliness of the data plane of an LSP in a reasonable amount of time, while minimizing processing burdens to the control plane of the LSP. This LSP test may be used when the failure of an LSP to deliver user traffic is not detected by the control plane. For instance when the forwarding labels in the data plane of an LSR become corrupted.
FIG. 5A is a messaging diagram illustrating the first stage in an exemplary implementation of the diagnostic operation of the present invention. FIG. 5B is a messaging diagram illustrating the second stage in an exemplary implementation of the diagnostic operation of the present invention. The discussion of the diagnostic operation will begin with a description of communication system 500 and the steps of the first stage in § 4.3.1. Then the steps of the second stage are discussed in § 4.3.2. In § 4.3.3 using flow control to protect against DoS attacks is discussed.
§ 4.3.1 Communications System Description and Stage One Operations
In communications system 500, an LSP 501 is defined to pass through an ingress LSR 510, one (or more) intermediate LSR 530, and an egress LSR 550. The communications system 500 may include other network components, represented as a cloud 540, that may or may not be part of the LSP 501.
The first stage of diagnosis operation 470 begins at ingress LSR 510. The ingress LSR LSP_ping operations 518 initiates the general echo_request operation 522. Dashed arrow 570 represents a first communication (“1”) transmitted by the general echo_request operation 522. A general echo request message, which includes a test message and an identifier, is generated and passed to the forwarding operation 526 for transmission through LSP 501. The identifier is used by the ingress LSR to distinguish between multiple LSPs, and may be used as the test message.
Next, dashed arrow 572 (“2”) represents the general echo request message being transmitted to the intermediate LSR 530. The forwarding operation(s) 538 of the intermediate LSR 530 may then forward the general echo request message along LSP 501 in a conventional manner.
Dashed arrow 574 (“3”) represents the general echo request message arriving at egress LSR 550. Dashed arrow 576 (“4”) represents the forwarding operation 566 sending the general echo request message to the general echo_reply operation 562.
Solid arrow 578 (“5”) represents the generated general echo reply message being sent to the forwarding operation 566 for transmission back to the node that sourced the echo request message. Solid arrow 580 (“6”) represents the forwarding operation 566 transmitting the general echo reply message through another LSP, or via a routed path through network nodes/components 540. Solid arrow 582 (“7”) represents the general echo reply message arriving at the ingress LSR 510. Solid arrow 584 (“8”) represents the forwarding operation 526 passing the general echo reply message to the general echo_request operation 522.
§ 4.3.2 Stage Two Operations
Now the second stage of an exemplary diagnosis operation 470 will be discussed, with reference to FIG. 5B. Dashed arrows represent information traveling downstream towards the egress LSR 550, and solid arrows represent information traveling upstream towards the ingress LSR 510. At this point of the diagnostic operation, the first stage of the diagnostic operation has indicated a failure, but it is not known with certainty whether the failure is due to a failure of the LSP 501.
FIG. 5B is a messaging diagram that illustrates exemplary second stage operations. Dashed arrow 571 (“1”) represents the LSP echo_request operation 520 sending a generated LSP_ping message to forwarding operation 526 for transmission. An LSP_ping message basically includes an LSP identifier, an ingress LSR (or source) identifier, and an LSP probe process identifier (which may be included in an LSP_echo object). A message sequence number may also be provided. The fields of an exemplary, more complex, LSP_ping message 600 will be discussed later. The LSP identifier and the ingress LSR identifier are used by an egress LSR to locate the LSP in its label-based forwarding information so that the egress LSR can use its control component to send a reply back to the ingress LSR that sourced the LSR_ping message. The LSP probe process identifier (e.g., LSP_echo object) carried within the LSP_ping message is returned to the sourcing LSR by the egress LSR, and is used to verify that the LSP is alive. In addition, since it is possible for the ingress LSR to check multiple LSPs, each check possibly including multiple LSP_ping messages, the LSP probe process identifier (e.g., LSP_echo object) may also be used by the ingress LSR to distinguish between LSPs being checked, and LSP_ping messages
Dashed arrow 573 (“2”) represents the LSP_ping message sent by the forwarding operation(s) 526 through LSP 501 in a conventional manner. Dashed arrow 575 (“3”) represents the LSP_ping message sent by the forwarding operation 538 of intermediate LSR 530 to egress LSR 550 in a conventional manner. Dashed arrow 577 (“4”) represents the LSP_ping message being sent to the LSP echo_reply operation 560.
The LSP echo_reply operation 560 uses the LSP identifier and the ingress LSR identifier to locate LSP 501 in its label-based forwarding information 556. In one embodiment, the LSP echo_reply operation 560 then checks to see if the path signaling, e.g., RESV, refresh message for LSP 501 already includes an LSP probe process identifier (e.g., LSP_echo object). If not, echo_reply operation 560 adds or updates the LSP probe process identifier (e.g., LSP_echo object) into the path signaling, e.g., RESV, refresh message. This is represented by dashed arrow 579 (“5”).
In an embodiment of the present invention to be used with soft-state LSPs, when it is time to refresh LSP 501, solid arrow 581 (“6”) represents the path signaling operation(s) 554 accessing the label-based forwarding information 556 for the path signaling (e.g., RESV) refresh message for LSP 501. Solid arrow 585 (“7”) represents the path signaling operation 554 forwarding the path signaling (e.g., RESV) refresh message including the LSP probe process identifier (e.g., LSP_echo object) to the intermediate LSR 530.
Solid arrow 587 (“8”) represents the control operation(s) 534 of the intermediate LSR 530 forwarding the path signaling (e.g., RESV) refresh message to ingress LSR 510. (In FIG. 5B the reverse LSP path followed by the path signaling (e.g., RESV) refresh message is a high level depiction. Therefore, at each LSR, the control plane may send the path signaling (e.g., RESV) refresh message to its forwarding component to perform the physical action of the path signaling (e.g., RSEV) refresh message.)
Solid arrow 589 (“9”) represents the path signaling operation 516 sending the LSP probe process identifier (e.g., LSP_echo object) to the LSP echo request operation 520. The LSP echo_request operation 520 compares the LSP probe process identifier (LSP_echo object) it received to the LSP probe process identifier (LSP_echo object) it transmitted, and if they are the same, it may infer that LSP 501 is alive. Since LSR 510 may be the ingress LSR to a plurality of LSPs, and LSR 510 may be diagnosing more than one LSP, a unique LSP probe process identifier (e.g., LSP_echo object) may be assigned to each suspect LSP so that LSR 510 may distinguish them. Further, if a given LSP echo request process generates multiple probing packets, sequence numbers may be used to distinguish such probing packets.
§ 4.3.3 Flow Control Considerations
When the LSP_ping messages are transmitted by the LSP echo request operation 520, each message should be encapsulated in a protocol that allows for flow control, e.g., User Datagram Protocol (“UDP”). UDP and other similar protocols use unique port numbers so that a router receiving such a message can identify the type of message it is receiving. This unique port number can be used by a rate limiter to regulate the amount of LSP_ping messages being sent to the control components of an egress LSR, thereby protecting the LSR in the event of a DoS attack.
§ 4.4 METHODS, DATA STRUCTURES, AND APPARATUS
Exemplary methods and data structures for effecting the functions summarized in § 4.2 and the operations described in § 4.3, are described in this section. More specifically, § 4.4.1.1 describes an exemplary diagnostic method, § 4.4.1.2 describes an exemplary ingress LSR LSP_ping method, § 4.4.1.3 describes an exemplary egress LSR LSP_ping method, § 4.4.1.4 describes an exemplary intermediate LSR LSP_ping method and § 4.4.2 describes an exemplary LSP_ping message. Then, exemplary apparatus that may be used to effect the functions summarized in § 4.2 are described in § 4.4.3. Finally, an example of operations described in § 4.3 is provided in § 4.5.
Exemplary methods for effecting the functions summarized in § 4.2 and the operations described in § 4.3, are described below.
§ 4.4.1.1 Diagnostic Method
FIG. 7 is a high-level flow diagram of an exemplary method 470′ for effecting various diagnostic operations 470. At block 704, an ingress LSR starts stage 1 operations of the diagnostic operation 470. Recall that stage 1 operations were discussed in § 4.3.1. The method 470′ then proceeds to decision block, 706. If the suspect LSP passes stage 1 of the diagnostic operation, e.g., replies to ICMP echo requests are received from the egress router, the diagnostic method 470′ is left via RETURN node 714. In this case, the LSP is alive and functioning. Returning to decision block 706, if the LSP fails stage 1 operations, e.g., ICMP echo requests are not answered, then the diagnostic method 470′ proceeds to decision block 708.
As indicated by block 710, the ingress LSR starts stage 2 operations of the diagnostic operation 470. Recall that stage 2 operations were discussed in § 4.3.2.
The foregoing describes an exemplary diagnostic method 470′ as applied over an LSP. Exemplary methods that may be performed by ingress, egress and intermediate LSRs are now described in § 4.4.1.2 through § 4.4.1.4 below.
§ 4.4.1.2 Ingress LSR LSP_Ping Method
§ 4.4.1.3 Egress LSR LSP_Ping Method
§ 4.4.1.4 Intermediate LSR LSP_Ping Method
§4.4.1.5 Alternative LSP_Ping Method
As described above, the data plane may be used to carry an LSP echo_reply to the ingress LSR. For example, if the label distribution protocol (“LDP”) is used to generate and control the LSP being checked, the LSP echo_reply (or replies) may be sent back to the source (ingress) LSR via the data plane, rather than via the control plane. Such LSP echo_reply (replies) may be in the ICMP format.
§ 4.4.2 Exemplary LSP_Ping Message
FIG. 6 is an exemplary data structure 600 for effecting an LSP_ping message. The LSP_ping message may be encapsulated in a protocol that allows flow control (e.g., UDP) to protect against DoS attacks.
§ 4.4.3 Exemplary Apparatus
FIG. 3 is high-level block diagram of a machine 300 which may effect one or more of the operations discussed above. The machine 300 basically includes a processor(s) 310, an input/output interface unit(s) 330, a storage device(s) 320, and a system bus(es) and/or a network(s) 340 for facilitating the communication of information among the coupled elements. An input device(s) 332 and an output device(s) 334 may be coupled with the input/output interface(s) 330. Operations of the present invention may be effected by the processor(s) 310 executing instructions. The instructions may be stored in the storage device(s) 320 and/or received via the input/output interface(s) 330. The instructions may be functionally grouped into processing modules.
§ 4.5 AN EXAMPLE ILLUSTRATING OPERATIONS OF AN EXEMPLARY EMBODIMENT
The following is an example illustrating the diagnostic operation 470 in an exemplary embodiment of the present invention. FIG. 11 is a high-level diagram illustrating communications system 1100 in which diagnostic operation 470 may be performed. Communications system 1100 includes LSP 1101, ingress LSR 1102, intermediate LSR 1104, egress LSR 1106, and other network elements 1120 capable of forwarding data. Dashed arrows 1112, 1114 represent control plane communications pertaining to LSP 1101, and solid arrows 1108, 1110 represent data plane communications that can occur over LSP 1101. Solid arrows 1116, 1118 represent other network connections the LSRs 1102, 1104, 1106 may have.
As can be appreciated from the foregoing disclosure, the present invention discloses apparatus, data structures and methods for testing the liveliness of a data plane of a label switched path (LSP). A two stage approach is used to minimize the processing overhead imposed on an LSR control plane. The first stage uses a general echo request operation that may be implemented using hardware. Therefore, the first stage does not heavily burden the control plane of the LSR. If a suspect LSP passes the first stage of the diagnostic operation, nothing more is done, but if the suspect LSP fails the first stage, the diagnostic operation proceeds to a second stage.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6775239 *Jul 26, 2000Aug 10, 2004Fujitsu LimitedChecking communication-path data in MPLS communication schemeUS6895441 *Jul 30, 2001May 17, 2005Atrica Ireland Ltd.Path rerouting mechanism utilizing multiple link bandwidth allocationsUS20020054405 *Feb 9, 2001May 9, 2002Duanyang GuoExtensions to resource reservation protocol (RSVP) -traffic engineering (TE) for bi-directional optical path setupUS20050281192 *Jun 18, 2004Dec 22, 2005Cisco Technology, Inc.Consistency between MPLS forwarding and control planesUS20060013142 *Jul 15, 2004Jan 19, 2006Thippanna HongalObtaining path information related to a virtual private LAN services (VPLS) based network* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7471636 *Feb 23, 2005Dec 30, 2008Cisco Technology, Inc.Methods and apparatus based on message transmission timesUS7680923 *Dec 22, 2003Mar 16, 2010Nortel Networks LimitedConnectivity assessment for label distribution protocol (LDP) networksUS7746793 *Jun 18, 2004Jun 29, 2010Cisco Technology, Inc.Consistency between MPLS forwarding and control planesUS7894352Dec 8, 2008Feb 22, 2011Juniper Networks, Inc.Detecting data plane liveliness of a label-switched pathUS7898970 *Oct 15, 2008Mar 1, 2011Internap Network Services CorporationMethod for end to end route controlUS8000252 *Jul 7, 2008Aug 16, 2011Sprint Communications Company L.P.Multi-path network element monitoringUS8014300 *Apr 9, 2009Sep 6, 2011Huawei Technologies Co., Ltd.Resource state monitoring method, device and communication networkUS8200839 *Jul 12, 2004Jun 12, 2012Rockstar Bidco LpMethod and apparatus for restoring service label informationUS8233378 *May 15, 2008Jul 31, 2012Telefonaktiebolaget L M Ericsson (Publ)Method and apparatus for validating control and data plane associationUS8248917 *Mar 21, 2007Aug 21, 2012Huawei Technologies Co., Ltd.Method and system for implementing protection switching in multi-protocol label switching networkUS8339973Sep 7, 2010Dec 25, 2012Juniper Networks, Inc.Multicast traceroute over MPLS/BGP IP multicast VPNUS8451834 *Aug 6, 2008May 28, 2013International Business Machines CorporationDetermining availability of a destination for computer network communicationsUS8472346May 9, 2011Jun 25, 2013Juniper Networks, Inc.Failure detection for tunneled label-switched pathsUS8576847 *Aug 26, 2010Nov 5, 2013International Business Machines CorporationMechanisms for discovering path maximum transmission unitUS8699358 *Sep 2, 2011Apr 15, 2014Huawei Technologies Co., Ltd.Troubleshooting method and apparatusUS8705374 *Oct 31, 2006Apr 22, 2014At&T Intellectual Property Ii, L.P.Method and apparatus for isolating label-switched path impairmentsUS8761024Aug 5, 2011Jun 24, 2014Huawei Technologies Co., LtdResource state monitoring method, device and communication networkUS8848518 *May 6, 2010Sep 30, 2014Verizon Patent And Licensing Inc.System and method for providing notification of a change in path conditionUS8879564 *May 30, 2011Nov 4, 2014Samsung Electronics Co., Ltd.Method to accurately and securely determine propagation delay and distance between sending and receiving node in packet network using cut-through approach and packet network node for executing the methodUS8902762Mar 5, 2014Dec 2, 2014Huawei Technologies Co., Ltd.Troubleshooting method and apparatusUS8958311Mar 5, 2014Feb 17, 2015Huawei Technologies Co., Ltd.Troubleshooting method and apparatusUS8964570 *Jan 11, 2013Feb 24, 2015Cisco Technology, Inc.Detecting failures of backup label switched paths in a network environmentUS8971195 *Jan 6, 2011Mar 3, 2015Cisco Technology, Inc.Querying health of full-meshed forwarding planesUS9537712Jan 20, 2015Jan 3, 2017Cisco Technology, Inc.Detecting failures of backup label switched paths in a network environmentUS20040196843 *Feb 19, 2004Oct 7, 2004AlcatelProtection of network infrastructure and secure communication of control information theretoUS20050281192 *Jun 18, 2004Dec 22, 2005Cisco Technology, Inc.Consistency between MPLS forwarding and control planesUS20060002306 *Jun 30, 2005Jan 5, 2006Ronald BrownFailure detection of path information corresponding to a transmission pathUS20060187916 *Feb 23, 2005Aug 24, 2006Jean-Philippe VasseurMethods and apparatus based on message transmission timesUS20070242605 *Mar 21, 2007Oct 18, 2007Lei WenyangMethod and system for implementing protection switching in multi-protocol label switching networkUS20080294795 *Aug 6, 2008Nov 27, 2008International Business Machines CorporationDetermining Availability Of A Destination For Computer Network CommunicationsUS20090040938 *Oct 15, 2008Feb 12, 2009Internap Network Services CorporationSystem and method for end to end route controlUS20090086644 *Dec 8, 2008Apr 2, 2009Kireeti KompellaDetecting data plane liveliness of a label-switched pathUS20090168779 *Dec 31, 2007Jul 2, 2009Nguyen Loc QIntegration of multi-protocol label switching (MPLS)US20090196198 *Apr 9, 2009Aug 6, 2009Huawei Technologies Co., Ltd.Resource state monitoring method, device and communication networkUS20090285089 *May 15, 2008Nov 19, 2009Shriram SrinivasanMethod and Apparatus for Validating Control and Data Plane AssociationUS20100262607 *Apr 10, 2009Oct 14, 2010Sergei VassilvitskiiSystem and Method for Automatic Matching of Contracts to Impression Opportunities Using Complex Predicates and an Inverted IndexUS20110243145 *May 30, 2011Oct 6, 2011Samsung Electronics Co., LtdMethod to accurately and securely determine propagation delay and distance between sending and receiving node in packet network using cut-through approach and packet network node for executing the methodUS20110274113 *May 6, 2010Nov 10, 2011Verizon Patent And Licensing Inc.System and method for providing notification of a change in path conditionUS20110296016 *Aug 5, 2011Dec 1, 2011Huawei Technologies Co., Ltd.Resource state monitoring method, device and communication networkUS20110310727 *Sep 2, 2011Dec 22, 2011Huawei Technologies Co., Ltd.Troubleshooting method and apparatusUS20120051236 *Aug 26, 2010Mar 1, 2012International Business Machines CorporationMechanisms for Discovering Path Maximum Transmission UnitUS20120176914 *Jan 6, 2011Jul 12, 2012Cisco Technology, Inc.Querying health of full-meshed forwarding planesUS20140198634 *Jan 11, 2013Jul 17, 2014Cisco Technology, Inc.Detecting failures of backup label switched paths in a network environmentUS20140226969 *Apr 14, 2014Aug 14, 2014Rockstar Consortium Us LpMethod and apparatus for detecting a fault on an optical fiber* Cited by examinerClassifications U.S. Classification370/248, 370/225International ClassificationH04L12/26Cooperative ClassificationH04L43/50, H04L43/12European ClassificationH04L43/50, H04L12/26TLegal EventsDateCodeEventDescriptionDec 10, 2002ASAssignmentOwner name: JUNIPER NETWORKS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PAN, PING;SHETH, NISCHAL;REEL/FRAME:013566/0634;SIGNING DATES FROM 20021118 TO 20021125Aug 26, 2011FPAYFee paymentYear of fee payment: 4Aug 26, 2015FPAYFee paymentYear of fee payment: 8RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services