Title of Invention

METHOD FOR ESTABLISHING AN ASYMMETRIC BI-DIRECTIONAL LABEL SWITCHED PATH (LSP) IN AN MULTI PROTOCOL LABEL SWITCHING (MPLS) NETWORK

Abstract

This invention explains a method of establishing an asymmetric bi-directional LSP in a MPLS network having plurality of MPLS nodes, the said method comprising the steps of: a first node sending PATH message to a last node via the next node which is connected between the said first node and the said last node in the network, where the PATH message contains objects that describe the resource requirements and/or the constraints to be met for the data flow in both directions ; receiving a RESV message containing a label object for the said LSP from the said next node when the PATH message reaches the last node where RESV message contains session parameters, parameters specifying the resource requirements for the data flows in both forward and reverse directions ; allocating resources for the flows in both forward and reverse direction ; and creating an entry comprising of a first element and a second element in a data-structure. This invention also explains a method of sending data traffic over the asymmetric bi-directional LSP via a label switched path in reverse direction in an MPLS network wherein the said method comprising the steps of: Identifying at a first node a first label attached to the data packet, the first label defining a forward path for the data packet; Using the first label to identify a second label associated with the first label, the second label defining the reverse path for the data packet; replacing the first label with the second label; sending the data packet along with the second label to a next node of the label switched path; and Using a special label which is the Reverse-Lookup-Label that identifies that the data packet is sent in reverse direction.

Full Text

FIELD OF THE INVENTION The present invention relates to a method of establishing an asymmetric bi-directional LSP in a label switch telecommunications network, in particular an MPLS network that uses a label distribution protocol such as RSVP-TE or CR-LDP. Particularly the present invention relates to a method of sending the data packets over the established asymmetric bi-directional LSP in both directions (forward and reverse direction) using a single forwarding entry. DESCRIPTION OF THE RELATED ART Bi-directional LSP signaling: Consider the simple GMPLS topology as shown in Figure 1. LER PE1 is connected to Customer A and LER PE2 is connected to Customer B. Suppose that Customer A wants to send data to Customer B and at the same time Customer B also wants to send data to Customer A. So, it is desirable to have a bi-directional LSP between PE1 and PE2. As per [GMPLS RSVP-TE], PE1 initiates the bi-directional LSP setup request by sending PATH message to P1. The PATH message contains session related parameters, resource parameters etc. It also contains a label request object and a label object (L23). The Label, L23, contained in the PATH message will be used by P1 to forward the data in reverse direction (i.e. data from Customer B to Customer A). The processing of PATH message at P1 takes place as per the rules specified in [RSVP], [RSVP-TE] and [GMPLS RSVP-TE]. P1, before forwarding the PATH message to next downstream router P2, allocates label L22 on interface no. 2 and puts this label (L22) in the PATH message. When the PATH message reaches PE2, it responds by sending a RESV message to immediate upstream P2. The RESV message contains session related parameters, resource parameters etc. It also contains a label object (L13). The label L13 is allocated by PE2 on interface no. 1. PE2, before sending the RESV message, reserves resources and creates two entries in it's forwarding table (One entry will be used to route the traffic in forward direction and the other entry will be used to route the traffic in reverse direction). The Label, L13, contained in the RESV message will be used by P2 to route the data in forward direction (i.e. data from Customer A to Customer B). The processing of RESV message at P2 takes place as per the rules specified in [RSVP], [RSVP-TE] and [GMPLS RSVP-TE]. P2, before forwarding the RESV message to next upstream router P1, allocates label L12 on interface no. 1, reserves resources and creates two entries in its forwarding table. RESV message leaving the router P2 contains the label L12. Finally when PE1 receives the RESV message, it reserves resources and creates two entries in its forwarding table. Thus the bi-directional LSP is setup in GMPLS networks. Data packet forwarding over the established bi-directional LSP: Step by step procedure involved in the forwarding the data in forward direction is given below (Refer Figure 2): • When the LER PE1 receives, on interface 1, an unlabelled IP data packet from Customer A that is destined to Customer B it performs a lookup into its forwarding table to determine the outgoing label and the outgoing interface to forward the packet. From Figure 2 it can be seen that the lookup gives the label L11 as the outgoing label and the interface 4 as the outgoing interface. PE1, being the ingress router for the packet, pushes the label L11 onto the packet and sends it via the interface 4. • When P1 receives the labelled packet, on interface 1, it performs a lookup on the label L11 (the key used to perform a lookup should be combination of Incoming Interface and Incoming Label (i.e. search key = [1 + L11]) if the label space is not platform wide) in its forwarding table. Lookup on L11 gives the outgoing label as L12 and the outgoing interface as 2. The LSR P1 swaps the label L11 with L12 and sends the data packet to the LSR P2. • Step 2 is performed at transit LSR P2. The data packet leaving P2 will be attached with the label L13. • When the LER PE2 receives the labelled packet it performs a lookup on the label L13. Lookup on L13 gives no outgoing label but the output interface 3 on which the data packet has to be sent. No output label indicates that the packet is to leave the MPLS network. PE2, being the egress router for the packet, pops the label L13. And the unlabelled IP data packet is sent to Customer B on the interface 3. Data forwarding mechanism, via the bi-directional LSP in GMPLS, in reverse direction is very similar to that described for forward direction. Step by step procedure involved in the forwarding the data in forward direction is given below (Refer Figure 3): • When the LER PE2 receives, on interface 3, an unlabelled IP data packet from Customer B that is destined to Customer A it performs a lookup into its forwarding table to determine the outgoing label and the outgoing interface to forward the packet. From Figure 3 it can be seen that the lookup gives the label L21 as the outgoing label and the interface 1 as the outgoing interface. PE2, being the ingress router for the packet, pushes the label L21 onto the packet and sends it via the interface 1. • When P2 receives the labelled packet, on interface 2, it performs a lookup on the label L21 (the key used to perform a lookup should be combination of Incoming Interface and Incoming Label (i.e. search key = [2 + L21]) if the label space is not platform wide) in its forwarding table. Lookup on L21 gives the outgoing label as L22 and the outgoing interface as 1. The LSR P2 swaps the label L21 with L22 and sends the data packet to the LSR P1. • Step 2 is performed at transit LSR P1. The data packet leaving P1 will be attached with the label L23. • When the LER PE1 receives the labelled packet it performs a lookup on the label L23. Lookup on L23 gives no outgoing label but the output interface 1 on which the data packet has to be sent. No output label indicates that the packet is to leave the MPLS network. PE1, being the egress router for the packet, pops the label L23. And the unlabelled IP data packet is sent to Customer A on the interface 1. The GMPLS mechanism for setting up a bi-directional LSP if used in MPLS networks has some disadvantages: 1. Resource requirements for the flows in both directions (forward and reverse direction) must be same. In other words, the bi-directional LSP established in a GMPLS network is symmetric. In MPLS networks, however, the resource requirements for the end-customer applications communicating over a bi-directional LSP may not be same. 2. Label space usage is not efficient. Two labels are allocated at each transit LSR along the path of the bi-directional LSP 3. Two forwarding entries must be created in the MPLS Forwarding Information Base at each LSR along the bi-directional LSP SUMMARY OF THE INVENTION Currently in MPLS there is no support for asymmetric bi-directional LSP Setup. LSPs in a MPLS network are unidirectional. Two independent unidirectional LSPs need to be setup to have data flowing in both directions (forward and reverse). Since two independent LSPs need to be setup two entries will be created in the MPLS Forwarding Information Base (forwarding table). One aspect of the present invention provides a method of establishing an asymmetric bi-directional LSP in a MPLS network using a label distribution protocol such as RSVP-TE. Other signaling protocols such as CR-LDP can also be used. The method, however, necessitates minor extensions to the concerned signaling protocols such as RSVP-TE, CR-LDP. Another aspect of the present invention describes a method for sending the data packets, in the reverse direction, over the established asymmetric bi-directional LSP using the same entry that is used for sending the packets in forward direction. Advantages of the present invention: 1. Resource requirements for the flows in both directions (forward and reverse direction) can be different. 2. Label space is conserved. Only one label is allocated at each LSR along the path of the bi-directional LSP 3. Only one forwarding entry is created at each LSR along the bi-directional LSP and same entry is used to send the packets over the directional LSP in both directions. Creation of only one entry per bi-directional LSP reduces the size of the forwarding information base considerably. Accordingly this invention explains a method of establishing an asymmetric bi-directional LSP in a MPLS network having plurality of MPLS nodes, the said method comprising the steps of: a first node sending PATH message to a last node via the next node which is connected between the said first node and the said last node in the network, where the PATH message contains objects that describe the resource requirements and/or the constraints to be met for the data flow in both directions ; receiving a RESV message containing a label object for the said LSP from the said next node when the PATH message reaches the last node where RESV message contains session parameters, parameters specifying the resource requirements for the data flows in both forward and reverse directions ; allocating resources for the flows in both forward and reverse direction ; and creating an entry comprising of a first element and a second element in a data-structure. The said PATH message does not carry any label along with it and the parameters that describe the resource requirements for data flow in reverse direction are derived from the objects contained in the received PATH message. The first element in the said entry identifies the FEC for the data packet via the said LSP in forward direction. The second element in the said entry is the said label contained in the RESV message received from the said next node. The communication between plurality of MPLS nodes comprising the steps of: the said next node sending PATH message to the last node; receiving a RESV message containing a label object for the said LSP from the said last node; allocating resources for the flows in both forward and reverse directions; allocating one label for the said LSP and creating an entry comprising of the two elements in a data-structure; and sending the RESV message to the said first node along with the said allocated label. Here the first of two elements in the said entry is the label allocated at the said next node for the said LSP. The second element in the said entry is the said label contained in the RESV message received from the said last node. Here the said last node, allocates resources for the flows in both forward and reverse directions upon receiving the PATH message from the said next node and allocates one label for the said LSP, creating an entry comprising of the two elements in a data-structure and sending the RESV message to the said next node along with the said allocated label. The first of two elements in the said entry is the label allocated at the said last node for the said LSP and the second element in the said entry identifies the FEC for the data packet via the said LSP in reverse direction. The data-structure is a table that contains input identifiers and corresponding output identifiers where the output identifiers defining the forward path for the data packets attached with corresponding input identifiers and, input identifiers defining the reverse path for the data packets attached with corresponding output identifiers. The input identifier or the output identifier is a label or a FEC. Accordingly this invention also explains a method of sending data traffic over the asymmetric bi-directional LSP via a label switched path in reverse direction in an MPLS network wherein the said method comprising the steps of : Identifying at a first node a first label attached to the data packet, the first label defining a forward path for the data packet; Using the first label to identify a second label associated with the first label, the second label defining the reverse path for the data packet; replacing the first label with the second label; sending the data packet along with the second label to a next node of the label switched path; and Using a special label which is the Reverse-Lookup-Label that identifies that the data packet is sent in reverse direction. Here the Reverse-Lookup-Label is at the top of the label stack. The step of using the first label to identify a second label involves searching a data-structure in reverse order, thereby to identify the second label associated with the first label. The data-structure is a label table that contains input labels and corresponding output labels. The output labels defining the forward path for the data packets attached with corresponding input labels and, input labels defining the reverse path for the data packets attached with corresponding output labels. If the top label of the packet is the special label then the node interprets that the data packet is routed via a bi-directional LSP in the reverse direction. Detailed understandings of the nature and advantages of the inventions herein may be realized by reference to the remaining portions of the document and the attached drawings. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS Figure 1 depicts the signaling of a bi-directional LSP in a GMPLS network. Figure 2 depicts the data packet forwarding via the established bi-directional LSP, in forward direction in a GMPLS network Figure 3 depicts the data packet forwarding via the established bi-directional LSP, in reverse direction in a GMPLS network Figure 4 depicts the signaling of an asymmetric bi-directional LSP in a MPLS network. Figure 5 depicts the data packet forwarding via the established asymmetric bi-directional LSP, in forward direction. Figure 6 depicts the data packet forwarding via the established asymmetric bi-directional LSP, in reverse direction. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. The following description and drawings are illustrative of the invention and are not to be construed as limiting the innovation. Numerous specific details are described to provide a thorough understanding of the present invention. However in certain instances well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Operation of the present invention can be divided into two parts. First part describes the method of establishing an asymmetric bi-directional LSP in a MPLS network. And the second part describes the method of sending the data packets over the established bi-directional LSP in reverse direction. Asymmetric Bi-Directional LSP Signaling in MPLS Networks: Signaling method described here uses RSVP-TE as the label distribution protocol. Other label distribution protocols such as CR-LDP can also be used for signaling but with necessary minor extensions described in this section. Consider a simple MPLS topology as shown in Figure 4. LER PE1 is connected to Customer A and LER PE2 is connected to Customer B. Suppose that Customer A wants to send data to Customer B and at the same time Customer B also wants to send data to Customer A. Also suppose that both flows have different resource requirements. So, it is desirable to have an asymmetric bi-directional LSP between PE1 and PE2. The signaling mechanism for setting up an asymmetric bi-directional LSP is very much similar to the signaling of unidirectional LSPs given in [RSVP-TE]. This section talks about only the extensions to the RSVP-TE protocol and the additional processing that need to be done for signaling an asymmetric bi-directional LSP. Ingress LER, PE1, initiates bi-directional LSP setup by sending a PATH message to its immediate downstream router P1. The PATH message, however, carries some new objects in addition to those present in a conventional PATH message. New objects that are carried in the PATH message describe the resource requirements and/or the constraints to be met for the data flow in reverse direction (flow from Customer B to Customer A). Thus the PATH message contains objects that describe the resource requirements and/or the constraints to be met for the data flow in both directions. It is important to note that, unlike GMPLS mechanism the PATH message will not carry any label along with it. The processing of PATH message at P1 takes place as per the rules specified in [RSVP-TE]. After processing the PATH message successfully, P1 forwards the PATH message to next downstream router P2. When the PATH message reaches the egress LER, PE2, it responds by sending a RESV message to immediate upstream router P2. RESV message contains session parameters, parameters specifying the resource requirements for the data flows in both forward and reverse directions etc. Note that the parameters that describe the resource requirements for data flow in reverse direction have been derived from the new objects contained in the received PATH message. Also, the RESV message contains a label object (L13). The label L13 is allocated by PE2 on interface no. 1. PE2, before sending the RESV message, reserves resources and creates one entry in its forwarding table (this single entry will be used to send the data traffic over the established LSP in both forward and reverse directions). The processing of RESV message at P2 takes place as per the rules specified in [RSVP-TE]. P2, before forwarding the RESV message to next upstream router P1, allocates label L12 on interface no. 1, reserves resources (bandwidth) and creates one entry in its forwarding table. RESV message leaving the router P2 contains the label L12. Finally when PE1 receives the RESV message, it reserves resources and creates one entry in its forwarding table. This completes the bi-directional LSP is setup in MPLS networks. Thus the signaling mechanism explained here differs from the mechanism described in the prior art (GMPLS mechanism) with respect to the following, - PATH message carries new objects the resource requirements and/or the constraints to be met for the data flow in reverse direction - PATH message does not carry/contain any label object - Only one entry is created in the MPLS Forwarding Information Base at each LSR along the path of the bi-directional LSP Data packet forwarding over the established asymmetric bi-directional LSP in reverse direction: Data traffic forwarding mechanism in forward direction (data packets coming from Customer A that are destined to Customer B) over the established asymmetric bi-directional LSP is same as that described in GMPLS mechanism. In other words, data traffic in forward direction (Refer Figure 5) is sent over the established asymmetric bi-directional LSP using the conventional Ingress Push, Transit Swap and Egress Pop operations as specified in [MPLS] / [GMPLS]. The method used for sending the data packets in the reverse direction (i.e. data traffic from Customer B to Customer A) via the established asymmetric bi-directional LSP, however, is somewhat different. The method makes use of a special label called "Reverse-Lookup-Label". Step by step procedure involved in the method is given below (Refer Figure 6): • When the egress LER PE2 receives an unlabelled IP data packet from Customer B that is destined to Customer A, PE2 pushes the label L13 onto the packet. Then the special label "Reverse-Lookup-Label" is pushed on top of L13. Thus, the IP data packet leaving PE2 will have two labels on it. • When P2 receives the labelled packet it checks the top label. If the top label is Reverse-Lookup-Label P2 interprets that the data packet is being routed via a bi-directional LSP in the reverse direction. This makes P2 to do a reverse lookup. Hence P2 does a reverse lookup on the inner label (the label which immediately follows Reverse-Lookup-Label) L13. It is RECOMMENDED that P2 typically has to take into account the interface, on which the data packet is received, while doing the reverse lookup. Reverse lookup on L13 gives the label L12 and the interface on which the data packet has to be sent. The LSR P2 swaps the label L13 with L12 and sends the data packet to the LSR P1. It is important to note here that P2 does not pop the special label Reverse-Lookup-Label. In other words the IP data packet leaving P2 will have two labels on it namely L12 and Reverse-Lookup-Label. • Step 2 is performed at transit LSR P1 • When the ingress LER PE1 receives the labelled packet it checks the top label. If the top label is Reverse-Lookup-Label PE1 interprets that the data packet is being routed via a bi-directional LSP in the reverse direction. This makes PE1 to do a reverse lookup. Hence PE1 does a reverse lookup on the inner label (the label which immediately follows Reverse-Lookup-Label) L11. It is RECOMMENDED that PE1 typically has to take into account the interface, on which the data packet is received, while doing the reverse lookup. Reverse lookup on L11 gives no label but the interface on which the data packet has to be sent. Since no label is obtained from the reverse lookup PE1 assumes that it is the egress point for the data flowing via the bi-directional LSP in the reverse direction. So, PE1 pops both labels L11 and Reverse-Lookup-Label. And the unlabelled IP data packet is sent to Customer A on the interface obtained from the reverse lookup. The present invention, thus, enables sending of data traffic over the asymmetric bi-directional LSP in both directions using the same entry in the forwarding table. Generalized step by step procedure for sending the data traffic over the asymmetric bi-directional LSP in reverse direction is given below: • When the egress LER receives an unlabelled IP data packet that is to be sent via a bi-directional LSP in the reverse direction, the LER should push two labels. One label is the label associated the bi-directional LSP and the other label is Reverse-Lookup-Label. Reverse-Lookup-Label should be the top of the label stack. • When a transit LSR receives the labelled packet it checks the top label. If the top label is Reverse-Lookup-Label the LSR interprets that the data packet is being routed via a bi-directional LSP in the reverse direction. This makes the LSR to do a reverse lookup. Hence the LSR does a reverse lookup on the inner label (the label which immediately follows Reverse-Lookup-Label). It is RECOMMENDED that the LSR typically has to take into account the interface,-on which the data packet is received, while doing the reverse lookup. Reverse lookup on the inner label gives the label, say out-label, (i.e. label allocated by the LSR during signaling of the bi-directional LSP) and the interface, say out-intf, on which the data packet has to be sent. The LSR swaps the inner label with the label 'out-label' and sends the data packet on the interface 'out-intf. It is important to note here that the LSR does not pop the special label Reverse-Lookup-Label. In other words the IP data packet leaving a transit LSR will have two labels on it namely the label obtained from the reverse lookup and Reverse-Lookup-Label. This step is performed at every transit LSR along the path of the bi-directional LSP. • When the ingress LER receives the labelled packet it pops both the labels Reverse-Lookup-Label and the inner label (the label which immediately follows Reverse-Lookup-Label). And the unlabelled IP data packet is sent on the interface obtained from the reverse lookup. Note that the reverse lookup at the ingress LER gives no label but the interface on which the data packet has to be sent. Getting no label from the reverse lookup is an indication to the ingress LER that it is the egress point for the data flowing via the bi-directional LSP in the reverse direction. The foregoing description of illustrated embodiments of the present invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed herein. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the present invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the present invention in light of the foregoing description of illustrated embodiments of the present invention and are to be included within the spirit and scope of the present invention. Thus, while the present invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the present invention. It is intended that the invention not be limited to the particular terms used in following claims and/or to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include any and all embodiments and equivalents falling within the scope of the appended claims. GLOSSSARY OF TERMS AND THEIR DEFINITIONS CR-LDP Constraint-based Routing using LDP Egress LER An LER where the LSP setup request terminates FEC Forwarding Equivalence Class - A group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment) GMPLS Generalized MPLS - Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). Ingress LER An LER that initiates LSP setup request MPLS Multiprotocol Label Switching Label A short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance LDP Label Distribution Protocol LSP Label Switched Path - A path through one or more LSRs at one level of the hierarchy followed by packets in a particular FEC. LER Label Edge Router - An MPLS node that connects an MPLS domain with a node which is outside of the domain, either because it does not run MPLS, and/or because it is in a different domain. Note that if an LSR has a neighboring host which is not running MPLS, then that LSR is an MPLS edge node. LSR Label Switching Router - An MPLS node which is capable of forwarding native L3 packets RSVP Resource Reservation Protocol RSVP-TE RSVP with Traffic Engineering extensions REFERENCE A large number of documents including requests for comments and internet drafts related to MPLS/GMPLS technology have been proposed to the Internet Engineering Task Force (IETF). Certain standards have been defined and accepted by the telecommunications industry. Some of the documents which have been submitted to the IETF in areas related to MPLS/GMPLS are listed below, all of which are incorporated herein by reference. [RSVP] Braden, R., Ed., Zhang, L, Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997. [MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RSVP-TE] Awduche, D., Berger, L, Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [GMPLS] Berger, L, Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [GMPLS RSVP-TE] Berger, L, Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. WE CLAIM 1. A method of establishing an asymmetric bi-directional LSP in a MPLS network having plurality of MPLS nodes, the said method comprising the steps of: a first node sending PATH message to a last node via the next node which is connected between the said first node and the said last node in the network, where the PATH message contains objects that describe the resource requirements and/or the constraints to be met for the data flow in both directions ; receiving a RESV message containing a label object for the said LSP from the said next node when the PATH message reaches the last node where RESV message contains session parameters, parameters specifying the resource requirements for the data flows in both forward and reverse directions; allocating resources for the flows in both forward and reverse direction ; and creating an entry comprising of a first element and a second element in a data-structure. 2. A method as claimed in claim 1 wherein the PATH message does not carry any label along with it. 3. A method as claimed in claim 1 wherein the parameters that describe the resource requirements for data flow in reverse direction are derived from the objects contained in the received PATH message. 4. A method as claimed in claim 1 wherein the first element in the said entry identifies the FEC for the data packet via the said LSP in forward direction. 5. A method as claimed in claim 1 wherein the second element in the said entry is the said label contained in the RESV message received from the said next node. 6. A method as claimed in claim 1 wherein communication between plurality of MPLS nodes comprising the steps of: the said next node sending PATH message to the last node; receiving a RESV message containing a label object for the said LSP from the said last node; allocating resources for the flows in both forward and reverse directions; allocating one label for the said LSP and creating an entry comprising of the two elements in a data-structure; and sending the RESV message to the said first node along with the said allocated label. 7. A method as claimed in claim 6 wherein first of two elements in the said entry is the label allocated at the said next node for the said LSP. 8. A method as claimed in claim 6 wherein second element in the said entry is the said label contained in the RESV message received from the said last node. 9. A method as claimed in claim 1 wherein the said last node, allocates resources for the flows in both forward and reverse directions upon receiving the PATH message from the said next node and allocates one label for the said LSP, creating an entry comprising of the two elements in a data-structure and sending the RESV message to the said next node along with the said allocated label. 10. A method as claimed in claim 9 wherein first of two elements in the said entry is the label allocated at the said last node for the said LSP. 11. A method as claimed in claim 9 wherein second element in the said entry identifies the FEC for the data packet via the said LSP in reverse direction. 12. A method as claimed in claim 1 wherein the data-structure is a table that contains input identifiers and corresponding output identifiers where the output identifiers defining the forward path for the data packets attached with corresponding input identifiers and, input identifiers defining the reverse path for the data packets attached with corresponding output identifiers. 13. A method as claimed in claim 1 wherein the input identifier or the output identifier is a label or a FEC. 14. A method of sending data traffic over the asymmetric bi-directional LSP via a label switched path in reverse direction in an MPLS network wherein the said method comprising the steps of: Identifying at a first node a first label attached to the data packet, the first label defining a forward path for the data packet; Using the first label to identify a second label associated with the first label, the second label defining the reverse path for the data packet; replacing the first label with the second label; sending the data packet along with the second label to a next node of the label switched path; and Using a special label which is the Reverse-Lookup-Label that identifies that the data packet is sent in reverse direction. 15. A method as claimed in claim 14 wherein Reverse-Lookup-Label is at the top of the label stack. 16. A method as claimed in claim 14 wherein the step of using the first label to identify a second label involves searching a data-structure in reverse order, thereby to identify the second label associated with the first label. 17. A method as claimed in claim 16, wherein the data-structure is a label table that contains input labels and corresponding output labels. 18. A method as claimed in claim 17, wherein output labels defining the forward path for the data packets attached with corresponding input labels and, input labels defining the reverse path for the data packets attached with corresponding output labels. 19. A method as claimed in claim 14, wherein if the top label of the packet is the special label then the node interprets that the data packet is routed via a bi-directional LSP in the reverse direction. 20. A method of establishing an asymmetric bi-directional LSP in a MPLS network having plurality of MPLS nodes substantially as herein described particularly with reference to the drawings. 21. A method of sending data traffic over the asymmetric bi-directional LSP via a label switched path in reverse direction in an MPLS network substantially as herein described particularly with reference to the drawings. Dated this 20th day of May 2005 ,

Documents:

0618-che-2005-abstract.pdf

0618-che-2005-claims.pdf

0618-che-2005-correspondnece-others.pdf

0618-che-2005-description(complete).pdf

0618-che-2005-drawings.pdf

0618-che-2005-form 1.pdf

0618-che-2005-form 13.pdf

618-CHE-2005 AMENDED PAGES OF SPECIFICATION 26-07-2012.pdf

618-CHE-2005 AMENDED CLAIMS 26-07-2012.pdf

618-CHE-2005 FORM-1 26-07-2012.pdf

618-CHE-2005 FORM-13 26-07-2012.pdf

618-CHE-2005 FORM-5 26-07-2012.pdf

618-CHE-2005 CORRESPONDENCE OTHERS 01-02-2013.pdf

618-CHE-2005 POWER OF ATTORNEY 26-07-2012.pdf

618-CHE-2005 AMENDED CLAIMS 01-02-2013.pdf

618-CHE-2005 AMENDED PAGES OF SPECIFICATION 01-02-2013.pdf

618-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 26-07-2012.pdf

618-CHE-2005 FORM-13 19-06-2006.pdf

618-CHE-2005 FORM-13 26-07-2012.pdf

618-CHE-2005 POWER OF ATTORNEY 01-02-2013.pdf