VNAG Binding for Multi-Domain LSP Orchestration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-domain and multi-layer traffic engineering networks, establishing a relationship between virtual networks (VNs) and label switched paths (LSPs) is crucial for effective management and orchestration, but existing systems lack a mechanism to bind VNs to the network paths used to form end-to-end tunnels, leading to inefficient orchestration from both service and network perspectives.
Innovation Solution
The proposed solution extends the Path Computation Element Communication Protocol (PCEP) to establish a binding association between VNs and LSPs using a Virtual Network Association Group (VNAG) object, which includes a Type-Length-Value (TLV) field containing a virtual network identifier, allowing for the binding of network paths to VNs and facilitating efficient orchestration across multiple domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If existing systems are used without VN-LSP binding mechanism, then system simplicity is maintained, but orchestration efficiency deteriorates
Solution Approach 1:
The patent introduces an association object as an intermediary data structure that binds virtual network identifiers to label switched path identifiers. This association object acts as a mediator between the service layer (VN) and network layer (LSP), enabling efficient orchestration without direct complex interactions between layers. The association object includes fields for VN identifier, LSP identifier, and association type, creating a standardized binding mechanism.
Solution Approach 2:
The binding information is nested within the existing PCEP protocol framework. The association object is embedded as an optional parameter within PCInitiate, PCUpdate, and PCRpt messages, allowing the VN-LSP binding mechanism to be integrated into the existing path computation protocol without requiring a separate communication channel or protocol.
2Adaptability or versatility
If PCEP protocol is extended with association objects, then binding capability is improved, but protocol complexity worsens
Solution Approach 1:
The association object is designed with universal applicability across multiple PCEP message types. The same association object structure can be included in PCInitiate messages for initial binding, PCUpdate messages for dynamic updates, and PCRpt messages for reporting. This multi-functional design allows a single data structure to serve multiple orchestration scenarios without requiring separate binding mechanisms for each message type.
Solution Approach 2:
The association object is implemented as an optional parameter rather than a mandatory field in PCEP messages. This partial action approach allows systems to adopt the binding capability selectively - implementations can choose to include association objects when VN-LSP binding is required while maintaining compatibility with existing systems that do not require this functionality. The optional nature prevents forced complexity adoption.
Data Source
AI summary
A method for establishing end-to-end tunnels extending across multiple domains using a network element. The method includes receiving a request from a customer controller to implement a virtual network (VN) created by the customer controller, wherein the VN identifies the end-to-end tunnels extending across the multiple domains, mapping the VN to available resources based on network constraints in response to the request, and transmitting, after the VN has been mapped, a message to a network controller managing one of the domains that includes a network path used to form a portion of one of the end-to-end tunnels, wherein the message includes an association object having a Type-Length-Value (TLV) field containing a virtual network identifier binding the network path to the VN.