|Publication number||USRE40826 E1|
|Application number||US 11/640,430|
|Publication date||Jul 7, 2009|
|Filing date||Dec 18, 2006|
|Priority date||Mar 29, 2001|
|Also published as||CN1531834A, CN100420252C, DE60202454D1, DE60202454T2, EP1374628A2, EP1374628B1, US7099334, US20020143849, US20060215661, WO2002080468A2, WO2002080468A3|
|Publication number||11640430, 640430, US RE40826 E1, US RE40826E1, US-E1-RE40826, USRE40826 E1, USRE40826E1|
|Inventors||Darren L. Newell, Sandra S. Ballarte, Kasper K. Reinink|
|Original Assignee||Nortel Networks Limited|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (13), Non-Patent Citations (7), Classifications (13), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application relates to U.S. Provisional Patent Application 60/279,901 filed Mar. 29, 2001.
The present invention relates to data network transmissions and, more particularly, to methods and apparatus for implementing ATM (asynchronous transfer mode) connections over domains implementing MPLS (multiprotocol label switching) standards.
The field of data networking is continuously evolving and part of this evolution is the emergence of new standards, protocols, and technologies. As an example, ATM technology, now widely used in many networks, was developed over the past decade to overcome specific drawbacks of the then existing networking technology. One consequence of this continuous development is the need to adapt existing technologies with the newly developed protocols and standards.
One of these newly developed technologies is the MPLS standard. In an MPLS network, incoming packets are assigned a label by a label edge router (LER). Packets are forwarded along a label switch path (LSP) where each label switch router (LSR) makes forwarding decisions based solely on the contents of a label. At each hop, the LSR strips off the existing label and applies a new label. This new label then informs the next hop how to forward the packet. This technology, among other benefits, allows routers to make forwarding decisions based on the contents of a simple label rather than by performing complex route lookup operations.
While the MPLS standard holds out much promise, ATM technology needs to be adapted to the MPLS standard so that the benefits of MPLS technology can be added to the benefits of ATM technology. ATM technology provides access to a network by multiplexing user information into fixed length units or cells. Using ATM technology, networks today can establish dedicated links between nodes. These links can be created as needed and can create high-throughput connections between nodes. Currently, there are no call control procedures for the establishment and clearing of ATM on-demand connections over MPLS.
As noted above, an MPLS network consists of MPLS switches serving as LERs and LSRS and provides connection services for the establishment of MPLS connections. To establish on-demand ATM connections, ATM connection information needs to be exchanged between its call control peers or between two communicating ATM nodes. In ATM networks, ATM signalling protocols are used to exchange ATM connection information between call control peers or nodes.
One major feature of MPLS is the unidirectional nature of its connections. Forwarding of a traffic flow is determined by the label attached to a data transfer unit. Since label assignment in one direction is not associated with the reverse direction, there is no indication as to the original source of the data transfer unit. A destination node therefore cannot be determined from where traffic flow originated. Also, since in a uni-directional system the routing is label based, a route used by one data transfer unit may be different from a route used by a second data transfer unit even if both data transfer units originated from the same source and are heading to the same destination. This feature of the MPLS standard renders it quite difficult to set up an ATM style connection between two nodes. Furthermore, this feature renders any “link” between nodes across an MPLS domain as a unidirectional link. Coordinating control signals between two nodes is, again, rendered difficult.
From the above, what is therefore required is a solution which will allow ATM connections to be established across domains implementing the MPLS standard.
It should be noted that the term data transmission unit (DTU) will be used in a generic sense throughout this document to mean units through which digital data is transmitted from one point in a network to another. Thus, such units may take the form of packets, cells, frames, or any other unit as long as digital data is encapsulated within the unit. Thus, the term DTU is applicable to any and all packets and frames that implement specific protocols, standards or transmission schemes. It should also be noted that the term digital data will be used throughout this document to encompass all manner of voice, multimedia content, video, binary data or any other form of data or information that has been digitized and that is transmitted from one point in a network to another as a payload of a data transmission unit.
The present invention meets the above need by providing methods and apparatus for establishing connections between network nodes across an MPLS domain. A data receive node transmits to a data transmit node the service label that the data receive node expects to receive embedded in data transfer units originating from the data transmit node. Any DTU that has this service label and is received by the data receive node will therefore be treated and considered by this data receive node as originating from the data transmit node.
In one aspect, the present invention provides a method of establishing a bi-directional data transfer connection between a first node and a second node across a domain which only allows unidirectional data flow, the method comprising:
a) sending a setup message from the first node to the second node, said setup message containing a first connection service label for a backward direction of data flow, said backward direction being from said second node to said first node;
b) receiving said setup message at said second node and reserving said first connection service label for digital data being sent from said second node to said first node;
c) sending a response message from the second node to the first node, said response message containing a second connection service label for a forward direction of data flow, said forward direction being from said first node to said second node; and
d) receiving said response message at said first node and reserving said second connection service label for data being sent from said first node to said second node,
for forward data transmission in said forward direction, data transfer unit for said forward data transmission will be labelled with said second connection service label and for a backward data transmission in said backward direction, data transfer units for said backward data transmission will be labelled with said first connection service label.
In a second aspect, the present invention provides a setup message sent from a first node to a second node for establishing a data transfer connection across a domain which only allows unidirectional data flow, said setup message containing a connection service label to be used by said second node when transmitting digital data to said first node on said data transfer connection.
In a third aspect, the present invention provides a response message sent in response to a setup message from a first node establishing a data transfer connection across a domain which only allows unidirectional data flow, said response message being sent from a second node to said first node and containing a connection service label to be used by said first node when transmitting data to said second node on said data transfer connection.
In a fourth aspect, the present invention provides a data transfer unit being sent from a transmitting node to a receiving node, said data transfer unit having a service label indicating a processing context that determines how said unit is to be processed by said receiving node, said unit being used in a unidirectional data transfer connection and said service label being determined by said receiving node.
In a fifth aspect, the present invention provides a first network switch for bridging between a first domain which only allows unidirectional flow and a second domain, the first switch including:
wherein the first network switch executes computer readable and computer executable instructions for implementing a method for establishing a data transfer connection between the first network switch and a second network switch across the first domain, the method including:
a) sending a setup message from the first network switch to the second network switch, said setup message containing a first connection service label for a backward direction of data flow, said backward direction being from said second network switch to said first network switch;
b) receiving a response message from the second network switch, the response message containing a second connection service label for a forward direction of data flow, the forward direction being from the second first switch to the first second switch and reserving said second connection service label for data being sent from said first switch to said second switch,
for forward data transmission in said forward direction, data packets for said forward data transmission will be labelled with said second connection service label and for a backward data transmission in said backward direction, data packets for said backward data transmission will be labelled with said first connection service label.
A better understanding of the invention may be obtained by reading the detailed description of the invention below, in conjunction with the following drawings, in which:
Any one of the MPLS nodes can receive a DTU and route that DTU based solely on a transport label within the DTU. As example, if MPLS node 30A receives a DTU with transport label A1, node 30A may route that DTU to MPLS node 30E based on the transport label A1. MPLS node 30A may also strip that transport label A1 off the DTU and replace it with a different transport label prior to transmitting the DTU to the next MPLS node. Because of the forward passing or hoping of DTUS based on transport labels that may be changed or deleted by the MPLS nodes, the origin of a DTU may be lost after a few hops.
Difficulties may occur if the first ATM node 40 wishes to establish a data link or a connection to the second ATM node 50. Part of the ATM standard is the ability to designate, when required, dedicated data channels between ATM nodes. Such dedicated data channels would therefore be reserved for digital data traffic between two specific nodes in a virtual channel connection or in a virtual path between the 2 nodes. These channels are not necessarily point-to-point physical links between the ATM nodes in question but may be “virtual” channels that only route data between the two ATM nodes in question. Thus, a virtual channel connection (VCC), a concatenation of virtual channel links that extends between two ATM nodes, can be created between the ATM nodes. Such a channel may be classified as a data tunnel, defined as a secure, virtual point-to-point link that connects two ATM nodes and transfers a payload between the two nodes with the payload, including service labels, not being modifiable by intervening nodes. The transmission of DTUS through these channels is assisted by virtual path identifiers (VPI) or by virtual channel identifiers (VCI).
To connect the ATM nodes 40 and 50 with a temporary channel, known as a switched virtual channel (SVC), or a permanent channel, known as a permanent virtual channel (PVC), the connection to which DTUS belong must be known at each out of a channel. This information must accompany each data transmission through the channel so that the digital data in the transmission be processed accordingly. The processing of DTUS at each end of a channel usually depends on the specific characteristics or configuration of the channel. As an example, DTUS for channel x between ATM nodes A and ATM node B may need to be processed in a specific certain manner that is different from the processing that DTUS for channel y between the same two nodes receive. Typically, however, the channel configuration involves the processing of the DTUS after they pass through the ATM channels. Thus, DTUS in channel x from node A to node B may need to be forwarded to node Q after they exit node B. Similarly, DTUS in channel y, as between the same two nodes A and B, may need to be forwarded to node R after exiting node B.
A solution to the above issue is that of using an immutable or unchangeable service label between the two ATM nodes for a specific connection or channel. This is done by having a receive ATM node (a node receiving data) define a service label that it will expect from a transmit ATM node (a node transmitting data) for that connection. This service label is then sent to the transmit ATM node. Once received, the transmit ATM node will reserve that service label for any DTUS that need to be transmitted to the receive ATM node on that connection. Thus, any DTUS heading for the receive ATM node on the specific connection will have that service label. At the other end of the virtual channel, any DTUS received by the ATM receive node which has that service label will be considered to be for that specific connection and will be processed accordingly. This scheme avoids the need to encode an origin address for a DTU as connection context is implicitly defined by the service label of a DTU.
One other advantage to the above scheme relates to the unchanging nature of service labels in MPLS technology. Since service labels are not within the purview of MPLS LSR (label switched routine) nodes in terms of routing, they remain the same no matter how many changes are made to a DTU transport label. Thus, using the nodes in
It should be clear that, given the unidirectional nature of MPLS routing, two service labels will need to be exchanged between any two ATM nodes wishing to establish a bidirectional data connection. One service label will therefore serve as the service label for data being transmitted from node A to node B. Another service label will serve as the service label for data going in the opposite direction or from node B to node A.
One possible issue regarding the above service label concept is that of routing a setup or initialize DTU between a receive ATM node and a transmit ATM node. The setup DTU would setup one unidirectional channel between the receive ATM node and the transmit ATM node. A response DTU, sent in response to the setup DTU, not only acknowledges the setup DTU but also sets up another unidirectional channel between the received ATM node and the transmit ATM node. Clearly, these two unidirectional channels between the two ATM nodes transmit data in opposite directions and effectively form a single bidirectional channel. The routing of both the setup and response DTUS is effected by using dedicated control channels between the two ATM nodes. These channels can be set up when the network is engineered or created. Specific service labels are set aside for each unidirectional control channel between ATM nodes.
Using ATM nodes 40 and 50 in
By the above method, a bidirectional control channel between ATM node 40 and ATM node 50 is created. Control DTUS from ATM node 40 going to ATM node 50 will have service label N while control DTUS from ATM node 50 to ATM node 40 will have service label M. Thus, to set up a connection between these two ATM nodes, one ATM node will initiate the process by sending a setup DTU containing a service label for use by the connection in the reverse direction (from node 50 to node 40) to the other ATM node using the control channel and the relevant service label N. This sets up one unidirectional connection channel. The other ATM node, in response to this setup DTU, will then send a response DTU containing a service label for use by the convection in the forward direction (from node 40 to node 50) to set up the other unidirectional connection channel using the control channel and relevant service label M.
With control channels and control service labels established between ATM nodes, control signals can be passed between ATM nodes and virtual channels, either SVCs or PVCs, can be set up between them. The process proceeds as such: ATM node 40 desires a channel for a specific connection with ATM node 50. ATM node 40 thus sends a setup PDU (protocol data unit), or a setup DTU, to ATM node 50 with a predetermined service label N reserved for control DTUS. It is assumed that service label N is preassigned to the control channel flowing from the ATM node 40 to the ATM node 50. Contained within the setup PDU as part of its payload is a service label Z that ATM node 40 wishes to use for the virtual connection where VPI.VCI=x.y between itself and ATM node 50. This service label Z is thus to be used for data flowing from ATM node 50 to ATM node 40 for virtual connection x.y.
Once the setup PDU is transmitted from ATM node 40, it then traverses the MPLS domain, during which the setup PDU may or may not undergo numerous changes in its transported label. Once the setup PDU arrives at ATM node 50, this node checks the service label associated with the setup PDU and determines that, since service label N is used, the setup PDU is a control DTU. After further processing, ATM node 50 determines that ATM node 40 wishes to establish a data transfer connection labelled x.y and that service label Z is to be used for this connection. ATM node 50 thus reserves this service label Z for any data or connection x.y flowing from itself to ATM node 40. Depending on the type of connection desired by ATM node 40 the setup packet will also have configuration data for the connection. Parameters and configuration information such as the processing that DTUS on this connection will receive and the end destination of such DTUS may be in the setup DTU. ATM node 50 will thus reserve resources for the expected data transfer connection based on configuration information contained in the control packet.
With resources allocated, ATM node 50 then creates a response PDU and associates with this response PDU the predetermined service label M. Again, it is assumed that service label M is preassigned to the control or channel flowing from ATM node 50 to ATM node 40. As part of the payload for this response PDU, a service label Y is designated by ATM node 50 as the service label to be used for the data transfer connection labelled x.y for data flow from ATM node 40 to ATM node 50 on this connection. This response PDU is then transmitted to the ATM node 40. It should be noted that the response PDU is also a control DTU but is created and sent in response to a setup PDU.
Once the ATM node 40 receives the response PDU from the ATM node 50, ATM node 40 then reserves the service label Y as the service label for data received from ATM node 50 for that particular connection x.y. Data can now be exchanged between ATM nodes 40 and 50 for connection x.y. For data flowing from ATM node 40 to ATM node 50, connection x.y DTUS will use service label Y while data flowing from ATM node 50 to ATM node 40, connection x.y DTUS will use service label Z.
While the above example uses a response PDU to transmit service label Y from ATM node 50 to ATM node 40, not all response PDUs need to carry such a service label. A response PDU may have a different function from that of merely delivering the service label. Although this function of delivering the relevant service label is a primary function of the response PDU, the response PDU can be used to, among other functions, alert the other ATM node that the setup PDU has been received or alert the other ATM node that the relevant service label is on its way, or that the setup PDU is being processed. As such, the response PDU may alert the other ATM node that the timer on the other ATM node should be extended to prevent a time-out condition. As long as the important function of delivering the service label is performed by a subsequent response PDU, the preceding response PDUs may perform other functions related to the setup PDU such as the alerting function explained above.
As the payload for either the setup PDU or the response PDU, a generic identifier transport information element (GIT IE) may be used to identify the service labels to be used. Such a GIT IE may have a format as illustrated in FIG. 2.
To signify that MPLS service label data is being transported by the GIT IE, the Identifier Type field in the format illustrated in
It should be noted that the scheme explained above can be used for ATM nodes that may be separated by multiple MPLS domains.
While the above explanation and example notes the replacement of interim transport labels at the bridge servers 120, 130 further interim transport labels may be added and deleted from the DTU when the DTU is traversing any of the domains. Interim transport label TLA-1 may thus be added to the transport label field of the DTU when the DTU is traversing MPLS domain 20A and without affecting either transport label TLA or the initial transport label TL1. This interim transport label TLA-1 may then be removed from the transport label field of the DTU when the interim transport label is no longer required. Other transport labels may thus be added or deleted without affecting the previous transport labels. In this reuse, transport labels are added and discarded in a manner similar to that of a last-in first-out (LIFO) stack—the most recently added transport labels are the first transport labels to be discarded.
The above scheme of a single transport label used for routing DTUS between peer or similar nodes, such as two ATM nodes, allows for simplicity and low overhead when transmitting digital data between peer nodes. The scheme may also be used to differentiate between traffic classes in traffic between two nodes. From the above example, whenever ATM node 40 needs to send digital dat data to ATM node 50, then the DTU need only have an initial transport label TL1 for the digital data to arrive a ATM node 50.
It should be noted that service labels used for connections between ATM nodes may be released when a connection is terminated. Once a connection is terminated, a release PDU, also a control DTU similar to the setup and response DTUS or other types of DTUS, is sent to each ATM node affected by the terminated connection. This release PDU is sent via the dedicated control channels to the ATM nodes. When received, the release PDU instructs the ATM node to release the service labels associated with a specific connection. In the example given above, if the connection x.y is terminated, then service labels Y and Z are released. These two service labels can then be used by other ATM nodes for their connections. A release PDU may be generated by events other than a connection termination. As an example, if a fault at either end of a connection occurs, this can trigger a release PDU for all ATM nodes affected. It should be noted that local faults generated at an ATM node may also trigger such a release of service labels.
After the receive data service label is incorporated into the setup PDU, the initiating ATM node transmits the setup PDU to the responding ATM node in step 160. This is done using predefined control channel service labels and transport labels. After transmitting the setup PDU to the responding ATM node, the initiating ATM node then waits for a response PDU from the responding ATM node. This response PDU serves as acknowledgement from the responding ATM node that the setup PDU has been received and its commands have been executed. The initiating ATM node then receives the response PDU from the responding ATM node in step 170. Again, this step is executed using predefined control channel service labels and transport labels. In step 180, the initiating ATM node then extracts a transmit data service label from the response PDU. This transmit data service label is to be used by the initiating ATM node when transmitting data to the responding ATM node for the particular connection being set up.
With the transmit data service label having been received by the initiating ATM node, the connection is finally established by allocating the resources and to establish the configuration connection based on information contained in the response PDU (step 190). This step may include such processes as allocating bandwidth for the particular connection and allocating the receive transmit data service label for any data to be sent to the responding ATM node. It should be clear that, prior to step 190, the forwarding and/or processing of other PDUs may be accomplished before the ATM call establishment is completed.
Once the channel has been set up, either step 200 or step 210 is executed. In step 210, the initiating ATM node transmits data to the responding ATM transmit node using the transmit data service label that was received through the response PDU. Alternatively, in step 210 the initiating ATM node receives data from the responding ATM node with the receive data service label attached to the data. It should be clear that either of these steps can be executed concurrently or simultaneously by the initiating ATM node given that step 200 is executed for the data channel for data travelling from the initiating ATM node to the responding ATM node, while step 210 is for the channel for data travelling from the responding ATM node to the initiating ATM node.
It should be noted that the steps in the flow chart in
Embodiments of the invention may be implemented in any conventional computer programming language. For example, preferred embodiments may be implemented in a procedural programming language (e.g. “C”) or an object oriented language (e.g. “C++”). Alternative embodiments of the invention may be implemented as pre-programmed hardware elements, other related components, or as a combination of hardware and software components.
Embodiments can be implemented as a computer program product for use with a computer system. Such implementation may include a series of computer instructions fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk) or transmittable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. The medium may be either a tangible medium (e.g., optical or electrical communications lines) or a medium implemented with wireless techniques (e.g., microwave, infrared or other transmission techniques). The series of computer instructions embodies all or part of the functionality previously described herein. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server over the network (e.g., the Internet or World Wide Web). Of course, some embodiment of the invention may be implemented as a combination of both software (e.g. a computer program product) and hardware. Still other embodiments of the invention may be implemented as entirely hardware, or entirely software (e.g. a computer program product).
Furthermore it should be clear that while the ATM nodes in the Figures are located at the edges of the MPLS domain, these nodes may, be placed within the MPLS domain in an implementation of the invention.
As can be seen in
A person understanding the above-described invention may now conceive of alternative designs, using the principles described herein. All such designs which fall within the scope of the claims appended hereto are considered to be part of the present invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6341127||Jul 13, 1998||Jan 22, 2002||Kabushiki Kaisha Toshiba||Node device and method for controlling label switching path set up in inter-connected networks|
|US6374303||Nov 12, 1998||Apr 16, 2002||Lucent Technologies, Inc.||Explicit route and multicast tree setup using label distribution|
|US6594260||Sep 3, 1999||Jul 15, 2003||Cisco Technology, Inc.||Content routing|
|US6680943 *||Oct 1, 1999||Jan 20, 2004||Nortel Networks Limited||Establishing bi-directional communication sessions across a communications network|
|US6879594||Jun 7, 2000||Apr 12, 2005||Nortel Networks Limited||System and method for loop avoidance in multi-protocol label switching|
|US7061921 *||Sep 28, 2001||Jun 13, 2006||Juniper Networks, Inc.||Methods and apparatus for implementing bi-directional signal interfaces using label switch paths|
|US7099334||Dec 28, 2001||Aug 29, 2006||Nortel Networks Limited||ATM over MPLS connection establishment mechanism|
|US20020136226||Jan 23, 2002||Sep 26, 2002||Bluesocket, Inc.||Methods and systems for enabling seamless roaming of mobile devices among wireless networks|
|US20030088699||Nov 4, 1999||May 8, 2003||James V. Luciani||System, device, and method for supporting virtual private networks in a label switched communication network|
|US20040215787 *||Apr 15, 2004||Oct 28, 2004||Gibson Mark Robert||Establishing connections across a communications network|
|WO2000036871A1||Dec 7, 1999||Jun 22, 2000||Telia Ab||Data transmission system adapted to provide interworking between rsvp and mpls|
|WO2000045560A2 *||Jan 21, 2000||Aug 3, 2000||Ericsson Telefon Ab L M||Public mobile data communications network|
|WO2001022658A2 *||Sep 15, 2000||Mar 29, 2001||Ironbridge Networks Inc||Apparatus and method for forwarding data on multiple label-switched data paths|
|1||*||Byeongsik et al. (Constraint-based LSP setup by message reversing of CR-LDP; Information Networking, 2001. Proceedings. 15th International Conference on Jan. 31-Feb. 2, 2001 pp. 875-880.|
|2||Cisco MPLS Controller Software Configuration Guide Release 9.3.0 Apr. 2000.|
|3||*||Generalized MPLS For Photonic Service Switching; Fiber Optics News Aug. 20, 2001 vol. 21 Issue: 32 Document Type: Newsletter Publisher: Phillips Business Information.|
|4||Holness et al., "Multiprotocol Label Switching Within The Core Network", 38th European Telecommunications Congress, Proceedings Networking the Future, Utrecht, NL, Aug. 24-28, 1999, pp. 97-100.|
|5||*||Okumus et al. (Inter-Domain LSP Setup Using Bandwidth Management Points), Proc. of Globecomm2001.|
|6||Um et al., "A Study on Interworking Scenarios Between ATM-Based MPLS Network and IPOA/Lane Network", Proceedings of the IEEE Conference 2000 on High Performance Switching and Routing, Heidelberg, Germany, Jun. 26-29, 2000, Proceedings of the IEEE Conference on High Performance Switching and Routing, New York, NY, US, Jun. 26, 2000, pp. 275-800.|
|7||United States Office Action from Appl. No. 11/423,002 dated Jun. 9, 2008.|
|U.S. Classification||370/395.3, 370/395.5|
|International Classification||H04L12/56, H04L29/08, H04L29/06|
|Cooperative Classification||H04L69/32, H04L69/08, H04L45/00, H04L29/06, H04L45/50|
|European Classification||H04L45/00, H04L45/50, H04L29/06|
|Jan 22, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Mar 18, 2011||AS||Assignment|
Owner name: ERICSSON AB, SWEDEN
Free format text: ASSIGNMENT OF PATENTS;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:025979/0870
Effective date: 20110311
|Feb 28, 2014||FPAY||Fee payment|
Year of fee payment: 8