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.

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.

Abstract: There is provided a configuration management system for a network device, said network device including one or more sub-systems for implementing network services, said system comprising a configuration management interface in communication with an external configuration management agent; a sub-system interface in communication with said one or more sub-systems; a control entity for establishing configuration elements based on a previously stored template, said template including a set of defined values; and a subscription sub-system for sending a specification for implementing a service determined by each configuration element to said sub-system interface; wherein when one of said set of defined values is updated, said control entity updates all of said configuration elements based on said previously stored template.

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.

Abstract: A scheme for allowing logical routers to achieve data path efficiency and still maintain network visible virtual links is provided by allowing logical routers in the same physical router to share routing information using standard protocols in place of proprietary route leaking, and by analyzing received data packets to determine if they are tandem data packets or terminating data packets. Tandem data packets are routed directly to egress ports with a single pass through the switch fabric to achieve efficiency, while the TTL value of the packet is decremented twice to maintain the external appearance of the separation of the logical routers. Terminating data packets are routed to other logical routers over virtual links to allow network visibility of the inter-logical router links.

Abstract: Deployment of a hub-and-spoke (HaSP) topology virtual private network (VPN) may be facilitated by implementing a bi-directional VRF on a hub PE and using the hub PE as a hub-reflector. Route distinguishers and route targets may be used to differentiate traffic originating on the spokes from traffic originating on the hub. Using a bi-directional VRF allows a HaSP VPN to be created using a single link between the hub CE and hub PE. Allowing the hub CE to control spoke route distribution, and differentiating the direction of the flow by route target and route designator, enables the hub to control traffic between the spokes. Configuring the hub PE as a route reflector allows communication between the spokes to take place without having the CE hub inspect every piece of traffic. Optionally, other services may be provided by the hub PE as well, such as NAT, firewall, and AAA services.

Abstract: Deployment of a hub-and-spoke (HaSP) topology virtual private network (VPN) may be facilitated by implementing a bi-directional VRF on a hub PE and using the hub PE as a hub-reflector. Route distinguishers and route targets may be used to differentiate traffic originating on the spokes from traffic originating on the hub. Using a bi-directional VRF allows a HaSP VPN to be created using a single link between the hub CE and hub PE. Allowing the hub CE to control spoke route distribution, and differentiating the direction of the flow by route target and route designator, enables the hub to control traffic between the spokes. Configuring the hub PE as a route reflector allows communication between the spokes to take place without having the CE hub inspect every piece of traffic. Optionally, other services may be provided by the hub PE as well, such as NAT, firewall, and AAA services.