GMPS-UNI: Unleash the barriers of IP and Optical Network
Introduction
The rapidly increasing demand for more bandwidth, driven by the Internet, has led to a paradigm shift in the telecommunications industry to IP-centric networks. Optical networking using dense wavelength-division multiplexing (DWDM) in conjunction with optical cross-connects (OXCs) presents many new opportunities for supporting faster and more flexible provisions of IP services.
The signaling and operations and administration and maintenance requirements for integrating an IP network and an optical network in order to cope with the high bandwidth and poor resource granularity of the optical network, including the optical cross-connect system has been analyzed. On the basis of network architecture and a reference configuration model, the GMPLS-based control architecture and interconnection model has been proven as appropriate for controlling IP bandwidth and optical lambda resources.
The solution uses a label outside the normal spectrum to indicate a grey interface between a client and network equipment in an Internet Protocol (IP) over Dense Wavelength-Division Multiplexing (DWDM) network. A value for a wavelength label (outside the normal range) is used to signal the presence of a grey interface. The network node will recognize this value, understanding that it corresponds to a "grey" wavelength, and thus, will effectively behave as though the grey interface was a DWDM interface on the client.
Section 1: What is GMPLS?
GMPLS is developed from MPLS so that it inherits nearly all MPLS features and protocols. GMPLS also extends the definition of MPLS labels and it can be considered as an extension of MPLS in transmission networks. GMPLS provides a unified control plane for the IP layer and transport layer. In this manner, the network architecture is simplified, the network management cost is reduced, and the network performance is optimized.
The GMPLS User-Network Interface (UNI) is defined by IETF as a network connection interface. It is applicable to the overlay model in the GMPLS network structure and it meets the trend in network development.
Section 2:Evolution of GMPLS
GMPLS can be considered as extended version of MPLS in order to support other data transport technologies:
How MPLS works?
A number of signaling protocols such as LDP1, CR-LDP2 and RSVP-TE3 can be used to establish the label mapping and, consequently, the LSP. MPLS offers advantages and flexibility in the deployment of new applications, including traffic engineering (TE), support for differentiated quality of service, scalable Virtual Private Networks (VPN), and simplified integration of IP and other networking technologies (e.g. ATM). MPLS is currently being deployed by telecommunications carriers and Internet service providers.
The original MPLS framework consists of a data plane for packet forwarding and a control plane for LSP establishment. Generalized MPLS4, 5 extends the MPLS control plane to support other data transport technologies. In addition to Packet Switch Capable (PSC) interfaces, it defines three new interfaces, which correspond to three classes of transport technologies. These new interfaces are Time-Division Multiplex (TDM) Capable, Lambda (wavelength or waveband) Switch Capable (LSC), and Fiber-Switch Capable (FSC). GMPLS focuses mainly on the control plane for these new technologies. In particular, GMPLS reuses MPLS signaling and routing protocols with appropriate extensions and modifications based on generalized interface requirements. The suite of GMPLS protocols such as distributed signaling, routing, and link management is under standardization process in the Internet Engineering Task Force (IETF).
Note that unlike MPLS, GMPLS allows de-coupling the control channel and data channels. GMPLS requires control entities to be able to communicate for the purpose of routing, signaling, and neighbor discovery and link management. However the interface over which control messages are exchanged may not be the same as the interface over which data flows. This offers enhanced flexibility in the deployment of new network control capabilities and applications.
Section 3: Concepts and architectures of unified Control plane
Section 3.1:Concepts
Traditional transport networks can be modeled as the interaction of two operating planes: a transport plane and a management plane. In this model, the transport plane carries the user data and comprises network equipment, such as line interface cards, switch fabrics, backplanes and fiber plant. Network OAM&P is fully handled by the management plane, implemented by an EMS, NMS, and/or OSS.
Now, we are beginning to see the deployment of optical control planes that sit between the management and transport planes (Figure below). The control plane moves some of the network intelligence down to the NEs. As a result, the NEs have access to complete network topology and resource information, and can use this to plan, establish and maintain user services.
In the optical transport field, the control plane has been called different things by different standards bodies. In the IETF, the optical control plane is referred to as Generalized Multi-Protocol Label Switching, or GMPLS [1]. Within the ITU-T, the optical control plane initiative is referred to as Automatic Switched Optical Network (ASON) [2]. In general, the ITU-T has defined the architecture and requirements for an optical control plane, whereas the IETF has mostly focused on developing the control plane protocols. A third standards body, the OIF, has been working on applying the IETF GMPLS protocols to the ITU-T ASON architecture, in order to promote multivendor interoperability [8, 13, 14, 15, 16, 17, 18]. The standards bodies applicable to the optical control plane are shown in Figure below.
The control plane offers a number of benefits to carriers. A control plane-enabled network can support new, dynamic services. These services include bandwidth-on-demand applications, customer-initiated service requests via a UNI, and scheduled or time-of-day based services. The control plane also integrates well with mesh networks. Coupled with dynamic service restoration, the control plane can improve network efficiency and resilience. Finally, the control plane can help reduce operating expenses by decreasing operator workload, reducing service turn-up fallout, and supporting multivendor and multicarrier interoperability.
Section 3.2: Control Plane architecture
ITU-T defines three reference points within the network: the User-Network Interface (UNI), the Internal Network-Network Interface (I-NNI), and the External Network-Network Interface (E-NNI). These reference points are shown in Figure below.
The UNI reference point defines the boundary between a client and the network. The client requests network services over the UNI interface, and the network responds by establishing calls and connections to meet the request.
The NNI defines the interface between devices within the network. The NNI can be further divided into either an internal or external interface. The internal NNI, or I-NNI, is typically a single-vendor interface contained within a single-carrier network. Since it is single-vendor, this interface may contain proprietary elements specific to that vendor. It also assumes a full trust model and so maximizes the information exchange between devices.
The external NNI, or E-NNI, is an external interface between devices within the network that crosses domain boundaries. Domain boundaries are defined by the carriers and can include administrative boundaries within a carrier’s network, boundaries between different vendors within a carrier’s network, or boundaries between carriers. The information exchanged across the E-NNI is usually more restricted than that exchanged across the I-NNI. For example, topology information may be abstracted for scalability or to hide the internal details of a carrier’s network. Whereas the I-NNI may have the proprietary elements, the E-NNI is standardized to allow for multivendor interoperability.
Section 4: Control Plane Applications and Protocols
The control plane can be seen as a set of applications that support the ability to establish a service through the network. This is in contrast to the traditional method, where a management system establishes the service by provisioning cross-connects on each individual network element.
The control plane applications are:
4.1: Discovery Application
The discovery application is responsible for the discovery of neighbors and the links between neighbors. Neighbor discovery is automated when there is an in-fiber IP communication channel (i.e., DCC, GCC, OSC, etc.) to that neighbor. The local node sends a discovery message over the in-fiber channels. Neighbors receiving this message respond to the originating node, completing the neighbor discovery process. Node level information is exchanged during this process to allow for the discovery of the neighbor’s Node IP address and node identifier.
The discovery protocol also supports the discovery of link connectivity between neighbors. This is accomplished through the link verification process. Link verification works by sending a unique test message over the link being discovered. The local node sends a discovery request to its neighbors to search for that discovery message. The neighbor node that sees this message on an incoming link responds to the originating node. In this manner the local and remote link identifiers are discovered. The local node repeats this process for each of its links.
4.2: Routing Application
The routing application is responsible for propagating the link connectivity information to all nodes within the network. This results in the formation of the TE database. The TE database contains the information necessary to determine the network topology, as well as resource information to support traffic engineering (e.g., link bandwidth availability).
As the number of nodes increases, scalability of the routing protocol eventually becomes an issue. Hierarchical routing addresses this issue. A single-level hierarchical routing model is defined in OIF E-NNI routing 1.0, as shown in Figure 7. In this model, a separate and independent instance of a routing protocol is run within each I-NNI domain (considered Level 0). These I-NNI domains may run different routing protocols, perhaps even vendor proprietary implementations. For instance, in Figure 7, Domain 1 and Domain 3 run OSPF-TE, while Domain 2 runs ISIS-TE.
领英推荐
Routing information (i.e., topology, resource, and reachability information) is exported from the Level 0 I-NNI domains into the E-NNI routing area (considered Level 1). At the Level 1 E-NNI domain, all routing controllers must run the same routing protocol for interoperability. OIF E-NNI Routing 1.0 mandates that the Level 1 E-NNI routing protocol be OSPF-TE.
The routing hierarchy architecture allows for additional levels of hierarchy (Level 2 and above). Although the current OIF routing standard only defines a single hierarchical level (Level 1), it is expected that future standards development will extend the routing protocol to support additional hierarchical levels.
During the export of routing information from the Level 0 I-NNI domain into the Level 1 E-NNI domain, topology information can be abstracted, and reachability information can be summarized. This abstraction/ summarization can drastically reduce the amount of routing information carried within the E-NNI routing domain, thus improving network scalability.
4.3:Path Computation Application
The path computation application performs the planning function for the control plane. Path computation may be requested to determine one or more routes through the network in response to a service request. Path computation provides the necessary service information, such as the source ingress location, destination egress location and service constraints. The TE database is used to compute routes during path computation.
Each link in the TE database has a cost attribute. The cost of a route is the sum of the cost of each link that makes up the route. A CSPF algorithm is used to find the lowest cost route from source to destination that meets the service constraints. Examples of service constraints that can be considered by path computation are bandwidth requirements, lambda continuity for WDM circuits, maximum allowable end-to-end latency, and include/exclude links or nodes.
The path computation function can also calculate diverse routes for dedicated protected services. Path computation supports link, node, and SRLG diversity.
4.4: Signaling Application
The signaling application is responsible for setting up, modifying, and tearing down end-to-end services. When the ingress node receives a service request, the signaling controller requests an optimal path from the path computation application that meets the service constraints. The signaling controller then proceeds to establish the service using the signaling protocol.
The signaling protocol supports alarm-free connection setup by using a multi pass setup process, as shown in Figure below. The call ingress node starts by sending a connection setup request to the egress node. This request is used by intermediate nodes to verify admission criteria, check bandwidth availability, and reserve resources. The egress node, upon accepting the connection request, sends a connection request indication back to the ingress node. This indication triggers nodes to establish the cross-connects in their switch matrix, but in an alarm-suppressed state. Finally, the ingress node finalizes the setup by sending a confirmation message that transitions the connection to the alarm-enabled state.
Connection teardown is also alarm-free. A two-pass connection teardown is used as shown in Figure 10. To initiate the teardown, the call ingress node sends a connection release request. This message triggers nodes to suppress alarms for the connections. The egress node responds by sending a connection release indication. Upon receiving the release indication, nodes release the cross-connects associated with the connection.
Section 5: Application Scenario
A Scenario Using OXCs Controlled by an IP Router:
Figure below shows an optical network with reconfigurable OXCs controlled by an IP router. Each node consists of an IP router and a dynamically-reconfigurable OXC. In this model, IP routers play the role of UNI-C, and the UNI-N function is located in the OXC; this is a direct invocation model, and the control plane architecture is a domain service model.
In this model, the IP router is responsible for the management of optical resources, configuration and capacity management, addressing, routing, traffic engineering, topology discovery, exception handling, and restoration. In general, the IP router may be traffic bearing. However, it may function purely as a controller for the optical network and carry no user traffic from clients. The IP router implements the necessary signaling protocols to establish light paths.
Within the network, the routed lightpath can provide router to router connectivity. All traffic using this lightpath is forwarded by the IP router. All control messages are sent via the control channel.
In the Fig. , the Generic Switch Management Protocol (GSMP) master of the IP router communicates with the GSMP slave located in the OXC system. The interface defines a set of basic primitives to configure the OXC and to enable the OXC to convey information to the router. The GSMP translates the logical primitives to and from the system controls of the OXC.
To illustrate the provisioning of an end-to-end route at the optical layer in Fig., the ingress router receives a lightpath request from a source. The ingress router creates a lightpath request message and sends it towards the destination of the lightpath where it is received by the egress router. The lightpath is created when the ingress router receives the lightpath allocation message. If all routers are MPLS–capable, the appropriate constraint-based label distribution protocol (CR-LDP) or RSVP-TE messages can be used. If no channel is available on any link, the setup fails, and a message is returned to the ingress router informing it that the lightpath cannot be established. When the setup fails, the ingress router issues a release message to release resources allocated for the partially constructed lightpath; it may attempt to establish the lightpath over an alternate route before giving up on satisfying the original user request. After processing the setup, the egress router returns an acknowledgement to the source.
How GMPS-UNI works in integrated (IP+DWDM) platform-A brief illustration
Section 6: Vendor Innovation
6.1: Path Diversity Analysis for IP/Optical Networks by NOKIA:
6.2: Optical Layer Restoration for mission critical services by NOKIA:
Conclusion
GMPLS is intended to provide a scalable, interoperable and distributed network control plane for multiple types of network equipment. The prototype has demonstrated the feasibility, main features and benefits of GMPLS as a common control plane to support distributed topology dissemination, dynamic path computation and provisioning, protection and restoration in the optical core network. Various requirements (traffic engineering, desired protection and bandwidth requirements) are taken into consideration during the LSP establishment to optimize the network utilization. Actual adoption and deployment of GMPLS as a common control plane for intelligent transport networks will depend on the successful completion of relevant standardization activities, extensive interoperability testing as well as the strengthening of appropriate business drivers.
Thank you!!
Monowar Hossain
Microwave Unit Head (Planning and Operation)
VEON, Bangladesh
Email: [email protected]
Mob: +8801962424691