Method and Apparatus for Restoring Service Label Information

Abstract

Multiple service label types may be used in a given network element to optimize scalability of the data plane, minimize overhead associated with service label management, and allow new services to be offered. Service label management may be done in a dynamic manner so that service labels may be selected for routes in a dynamic fashion as the network changes. VPNs handled by the network element may have different types of service labels, and different routes within a particular VPN may be allocated different service label types. Service label requests may be stored on the data plane to allow a service label request database to be restored from the data plane upon a control plane failure, so that new service labels are not required to be allocated after a control plane failure.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS[0001]This application is a continuation of U.S. patent application Ser. No. 10 / 889,647, filed Jul. 12, 2004, the content of which is hereby incorporated herein by reference.BACKGROUND OF THE INVENTION[0002]1. Field of the Invention[0003]The present invention relates to communication networks and, more particularly, to a method and apparatus for restoring service label information.[0004]2. Description of the Related Art[0005]Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be hand...

AI Technical Summary

Benefits of technology

[0021]The present invention overcomes these and other drawbacks by providing a method and apparatus for restoring service label information upon a control plane failure. According to an embodiment of the invention, a service label type attribute is introduced to the service labels to enable the network element to treat packets associated with different service label types in different manners. This allows the service label management system to use more than one service label type to adapt the service label to the particular circumstances to optimize scalability of the data plane, minimize overhead associated with service label management, and provide particular services on the network element. The different service label types may be defined to enable additional information to be provided about an incoming packet associated with the service label or to enable the network element to take particular actions on packets associated with the particular service label types. This allows enhanced services to be provided while maintaining scalability in both the data and control plane.

[0023]According to another embodiment of the invention, the service label management may be done in a dynamic manner so that service labels may be selected for routes in a dynamic fashion as the network changes. For example, it may initially be advantageous to allocate service labels on a per-route basis for a particular VRF while the VPN associated with that VRF has few routes, and then switch to a per-VRF basis once the VPN has acquired a larger number of routes. By allowing the service label management system to select a particular service label management scheme in an adaptive manner based on the particular circumstances associated with the VPN, and to apply different service label management schemes to different VPNs, the network element can optimize service label management for the VPNs provisioned through the network element.

[0024]According to yet another embodiment of the invention, the service label management system may allocate service labels in a secure manner such that transferring from one service label management system to another does not cause traffic from one VPN to leak into another VPN space. Particularly, according to an embodiment of the invention, previously used service labels are maintained obsolete for a particular period of time (optionally related to the time-out periods for routes to decay on the network) before being reallocated to a new route or new VPN. This enables the service labels to be reused in a secure manner without jeopardizing the security of the VPN with which they were previously associated.

[0025]According to yet another embodiment of the invention, the service label management system enables recovery of service label information after a control plane failure, by causing the original request that resulted in allocation of the service label to be stored in the data plane along with the service label. By storing the request in the data plane along with the service label, the service label and original request information may be restored to the control plane from the data plane. Generation of new requests for service labels may thus be matched against previous requests so that the same service labels may continue to be used despite a control plane failure. This minimizes service label churn on the network by allowing service labels to continue to be used despite a loss of the control plane data.

Problems solved by technology

Since routes within the VRF may have non-unique IP addresses, it is not possible to designate routes globally using their IP address alone.

An error in service label management may result in routes from one VPN inadvertently being included in the wrong VRF, which compromises the security of the VPNs.

Since each service label may be associated with many routes, however, the data plane is required to do a full IP lookup for each packet received and, thus, this service label management system tends to be less scalable at the data plane.

Also, for particular VPN architectures, such as a strict hub and spoke topography, performing an IP lookup and taking action on an IP address basis may present security problem, as traffic may inadvertently be leaked between spokes instead of all passing through the hub.

Since there may be many routes, this method results in an inefficient control plane implementation.

Since the service label, as mentioned above, is a 20 bit number, this also limits the number of routes maintainable by the VRFs to around 1 million, which causes scalability problems in the dataplane as well.

Since each service label management scheme has its advantages and disadvantages, selecting a particular service label management scheme limits what you can do with the network element.

This causes service label churn which can disrupt traffic on the network.

Images