The invention relates to data communication networks and protocols, in particular it refers to control plane architectures and protocols for optical transport networks.
This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
IETF: Internet Engineering Task Force
The IETF (Internet Engineering Task Force) standard RFC 4872 defines the procedures and RSVP-TE (Resource Reservation Protocol—Traffic Engineering) signaling extensions for end-to-end LSP recovery which is described in RFC 4426
The GMPLS (Generalized Multi Protocol Label Switching) end-to-end LSP recovery procedures are also defined in RFC 4872.
The shared-mesh restoration scheme allows multiple backup LSPs (Label Switch Path) to share network resources when the working LSPs that they protect are physically disjoint. The working LSP resources are reserved and committed in the data plane, while the backup LSP resources are only reserved, but not committed to the data plane. The resources along the backup LSP are committed to the data plane only with further signalling, i.e. after the occurrence of a transport plane failure and restoration signalling triggered by the ingress node. When a backup LSP is activated (due to a transport plane failure on the working LSP), the network resources are activated and are no longer available for use by the other backup LSPs sharing the same resource.
In SDH TDM (Synchronous Digital Hierarchy—Time Division Multiplex) networks, it is usual that nodes can switch timeslots from ingress to egress ports without constraints. It is thus common that the timeslot on a link is locally assigned by the upstream node and can be different on each link. For shared-mesh restoration LSPs, the resource is allocated locally at every transit node and possibly shared with other backup LSPs. When a backup LSP is activated, the shared resource is no longer available for the backup LSPs using the shared resource. Furthermore, the resource on the affected link(s) is re-allocated and possibly re-shared with other backup LSPs. This is possible due to the flexibility of SDH TDM systems. In most cases, resource reallocation is done locally and does not require end-to-end signalling nor ingress intelligence, and all backup LSPs are available again.
In OTN (Optical Transport Network) WDM (Wavelength Division Multiplex) networks, a resource is a wavelength or lambda, and the system has usually more constraints. Most important, an OCh (Optical Channel) LSP (Label Switch Path) has the same wavelength end to end, for the whole LSP (i.e. the same lambda is switched at each node). The lambda is usually decided during the planning phase or by the ingress and is set for the complete path. It can however be different for the working and backup LSPs. The transit nodes do not have the possibility to change a lambda.
The disadvantages are the following:
The problem to be solved is to overcome the disadvantages stated above and in particular to provide method of optimization of lambda resource usage in OTN WDM networks in case a set of backup OCh LSPs are no longer available due to the activation of the shared lambda.
In order to overcome the above-described need in the art, the present invention discloses a method for data communication networks, the data communication network including a label switch path, the method comprising the steps of providing a list including a plurality of entries, wherein each entry includes a wavelength that can be used by the label switch path for recovery procedures.
In a next embodiment of the invention, each entry further includes a plurality of parameters including the weight of the wavelength or the sharing degree of the wavelength or the status of the wavelength.
It is also an embodiment that the list of entries is ordered in ascending order of preference.
In a further embodiment, the order of preference is generated by a planning tool or by a network operator.
In a next embodiment, the method further comprises the step of signaling each entry of the list in both upstream and downstream direction.
It is also an embodiment that each entry is signaled during a path setup.
In a next embodiment, each entry is signaled periodically by means of refresh messages.
It is also an embodiment that entry is signaled upon specific network events, preferably during network failures.
In a further embodiment, a network operator generates the list.
In a next embodiment, the method further comprises the step of updating the list.
In a further embodiment, the order of the plurality of entries is updated.
In a further embodiment, a parameter included in one entry of the plurality of entries is updated
The problem stated above is also solved by a system for data communication networks, comprising: a label switch path, means for generating a list including a plurality of entries, wherein each entry includes a wavelength that can be used by the label switch path for recovery procedures.
The method, and the system provided, in particular, bears the following advantages:
The invention is explained by way of example in more detail below with the aid of the attached drawings.
Illustrative embodiments will now be described with reference to the accompanying drawings to disclose the teachings of the present invention. While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those having ordinary skill in the art and access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the present invention would be of significant utility.
According to an embodiment of the invention, for each backup LSP to be provisioned, the network operator (possibly with the help of a planning tool) provides an explicit route (list of nodes/hops) and optionally a list of possible lambdas which are optically feasible. In WDM OTN networks, it is common that not all lambdas are optically feasible for a given route or path.
According to an alternative embodiment of the invention, the route and list of possible lambdas for the backup LSP may be calculated by the ingress node and not required from the operator.
According to an alternative embodiment of the invention, the list may specify the possible lambdas that can be used by this LSP if the current lambda is no longer available, i.e. in case another shared backup LSP has been activated.
It is also an embodiment that each entry in the lambda list may consist of a lambda and optionally a set of parameters including weights, utilization or sharing degree, lambda status, etc.
In a further embodiment, the list of lambdas may be ordered in ascending order of preference. The order can be generated by the planning tool, the operator or the ingress node.
In a next embodiment, the lambda list may be signaled for backup LSPs in both downstream and upstream directions during the path setup, on periodic refresh messages, upon specific network events (such as the establishment or tear-down of services, network failures, etc. . . . ) and upon request from any node along the LSP path.
In an alternative embodiment, the lambda list order and parameter set can be modified by any node along the LSP path depending on local policy and other criteria (such as the lambda sharing degree). The decision may involve information from other backup LSPs transiting the node. Moreover, the control plane can be actively involved in the sharing optimization decision.
In a next embodiment, the updated lambda list signaled upstream to the ingress node ma be ordered, and its parameters updated by downstream nodes to optimize the lambda sharing for the given LSP.
It is also an embodiment that the LSP ingress node keeps track of the lambda list and updates it according to the list signaled upstream.
In a next embodiment, only one lambda may be signaled and reserved during the LSP setup. This “initial” lambda could be provided as the first element in the lambda list, or as a separate lambda.
In a further embodiment, when a backup shared LSP is activated:
The invention may relate to the following phases of shared-mesh LSPs provisioning and restoration in GMPLS controlled optical networks:
The exemplary invention implementation is based on OCh LSP signaling and the RSVP signaling protocol but is not restricted to those.
Lambda List Format
A new signaling object is provided, the lambda list object, with the format shown in
The lambda list entry object can be also defined with the format shown in
Local Sharing Information
The local sharing information can be used by a node to modify the lambda list order and update the lambda list entries, especially the weight, sharing degree and status, in order to reflect a preference for one or more lambdas. The local sharing information gathering can be achieved to a certain extent by inspecting the lambda list objects carried in signaling, or more generally via distribution using a routing protocol for instance. The decision to prefer a lambda to another is usually policy based and can depend on many factors. In the following examples, it is assumed for simplicity that sharing shall be maximized (in terms of number of sharing LSPs) whenever possible.
Exemplary Implementation and Procedures
The exemplary implementation defines the following procedures according to an embodiment of the invention:
1. A transit node receiving a Path message for a backup LSP:
2. An egress node receiving a Path message for a backup LSP:
3. A transit node receiving a Resv message for a backup LSP:
4. An ingress node receiving a Resv message for a backup LSP:
5. Optionally, a node detecting a change in its local sharing information for a given lambda notifies the ingress nodes of all affected LSPs using an RSVP Notification with a new error code/value “local sharing information changed” (If the node is itself the ingress, the notification is local). The affected LSPs have each an entry in their lambda list for the lambda for which the local sharing information has changed. This may happen for example when a new backup LSP is signaled (or an existing one deleted) with one or more lambdas which are already signaled in the lambda list of other backup LSPs. This step is optional as the lambda list needs to be updated anyways before re-signaling an LSP with a new lambda (see points 6 and 7 below). However, this step can optimize the results in specific cases.
6. An ingress node receiving a Notification message with error code/value “local sharing information changed” for a backup LSP:
7. An ingress node receiving a Notification message with error code/value “backup LSP resource unavailable” for a backup LSP (this notification is sent according to RFC4872 when a backup LSP is no longer available because its shared resource has been activated by another backup LSP. A new error code/value “backup LSP resource unavailable” is provided instead of the generic error code/value “Notify Error/LSP Locally Failed”):
The notification in point 7 is sent to the ingress nodes of all affected LSPs after a backup LSP has been activated following a network failure for example (making the shared resource no longer available for the other backup LSPs). The backup LSP activation procedure is described in RFC4872.
The following OCh services are preplanned, using a planning tool for example:
The initial lambda for all 3 backup connections is the same (value x), and can thus be shared on common links as the respective working connections are disjoint. The pre-calculated lambda lists specify the possible lambdas that can be used by a backup path if needed (for example if the shared resource is no longer available).
For simplicity in this example only the “lambda” and “weight” fields of the defined lambda list entry will be considered. The weight field shall denote the sparing potential for the specific lambda, in terms of number of lambdas that can be saved on an outgoing link. Furthermore, only the weight can be used as a preference criteria (a higher weight means higher lambda preference) and the lambda list is not ordered in this example. In case of identical weights, the lower lambda is preferred.
In this example, the following scenario is considered:
1. Services creation
2. Activation of a backup connection after a network failure
3. Re-signaling of the affected LSP with new lambdas, according to the updated lambda list
Below the detailed description of the scenario steps is provided:
1. Service 1 is configured at node A and enabled:
b. The backup connection (P1) is signaled using RSVP. The lambda list is carried on Path messages and updated on Resv messages. The nodes along the backup path build and update their local sharing information (
2. Service 2 is configured at node C and enabled:
3. Service 3 is configured at node B and enabled:
5. The reception of the RSVP Notify with error code/value “backup LSP resource unavailable” by ingress nodes C and B is the trigger to re-assign the lambda for P2 and P3 respectively.
The present invention is not limited to the details of the above described principles. The scope of the invention is defined by the appended claims and all changes and modifications as fall within the equivalents of the scope of the claims are therefore to be embraced by the invention. Mathematical conversions or equivalent calculations of the signal values based on the inventive method or the use of analogue signals instead of digital values are also incorporated.
Number | Date | Country | Kind |
---|---|---|---|
10197342.8 | Dec 2010 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2011/072917 | 12/15/2011 | WO | 00 | 9/17/2013 |