User Network Interface Technology in Intelligent Optical Networks for automatic switching

Intelligent Optical Networks are still quite common. So I have studied the network interface technology of users in the automatic switching Intelligent Optical Networks. I would like to share it with you here and hope it will be useful to you. To establish a dynamic connection between a client, such as an IP address, an ATM, or a SONET device, and an optical transmission network, you must develop a product that can interoperate with each other. To this end, IETF, International optical Internet forum (OIF), Optica1DomainServiceInterconnect, ODST), ITU ITU-T) and Internet Engineering Task Group (IETF) chinanager is committed to the standardization of UNI signaling interfaces in intelligent optical networks.

1. OIFUNI

UNI is the service control interface between the transmission network and the customer's devices. The transmission network uses UNI to establish and delete basic services according to user requirements. The main objective of OIF is to promote the interconnection of intelligent optical networks and to test and demonstrate the interconnectivity between ASONUNI and E-NNI. The main work of OIF in the intelligent optical network is to develop technical specifications for UNI and E-NNI interfaces, which has completed the UNI1.0R2 and E-NNI1.0 signaling part), UNI2.0 is in the testing process. OIFUNI1.0 defines a series of services, such as the signaling protocol used to request services, the transmission signaling information mechanism, and the automatic discovery process of auxiliary signaling. Currently, UNI1.0 is mainly used for SONET/SDH connection services. More UNI versions may be used in the future.

The network models advocated by international standards organizations such as OIF and ITU are overlapping models, as shown in 1. The IP service layer and optical layer are completely independent. The two layers have independent control planes, and they are interconnected through a public UNI protocol, edge customer-layer devices and core network-layer devices do not exchange internal network information, such as the smart optical network topology information. Independent routing is implemented. A typical feature of this model is that no topology or resource information is exchanged between the business layer and the transport layer. This structure makes the management cost of a layered physical network very high, and also reduces the bandwidth utilization.

Public network Ethernet services are growing steadily. To enable the development of the network to support current and future Ethernet services, at many layers, such as the transport layer, control layer, and management layer, interconnection is required. At the same time, the operator has a heterogeneous core optical transmission network, which brings great challenges to the interoperability of these network elements. OIF has been committed to extensive and diverse cooperation with carriers, equipment manufacturers, and end users of telecom services for a long time. Its long-term efforts have increased the number of implementation protocols and demonstrated a wider network environment. In SUPPERCOMM05, OIF uses the control plane technology that supports Ethernet services to demonstrate the dynamic establishment and deletion of Ethernet services through a global optical transmission network that is interconnected by multiple manufacturers. In addition to dynamic control over Ethernet private line services, SUPPERCOMM05 also includes transmitting Ethernet virtual services through optical transmission networks. The client network can use the UNI2.0 signaling interface to control a 1-bit Ethernet Access link to dynamically request connections from the carrier network.

2. IETFGMPLSUNI

Because a large number of SCNET/SDH-based network structures are installed, operators have to use extensive and specialized technologies to manage and develop TDM-based business models. Although the actual growth rate is hard to predict, we all agree that IP traffic will continue to grow in the present and future, and IP traffic will occupy most of the network traffic. However, a large number of legacy SONET/SDH devices need to be effectively interconnected between traditional, circuit-oriented networks and IP/MPLS networks.

The most promising technology is the ability to meet the urgent needs of IETF-defined universal multi-protocol tag exchange GMPLS protocol groups. GMPLS extends Label Switching in MPLS and is an extension of a series of protocols. In the end, it can control group switching, TDM, and wavelength switching in a unified manner. As a result of protocol expansion, the routing and signaling protocols involved in tag allocation, traffic control, protection, and recovery have changed. The GMPLS structure specifies all protocol capabilities based on signaling, routing, and link management.

The network structure initially proposed by IETF is a peer-to-peer model. In this model, the IP service layer and smart optical network layer are equivalent, that is, the same routing protocol is run on two layers and a unified and integrated control plane is used. To this end, the basic idea of the GMPLS Technology proposed by IETF is to slightly modify the routing and signaling rules used by the IP layer for MPLS channels and then directly apply them to the Connection Control of the optical transport layer. For example, in an IPoverWDM network, the IP layer and the optical layer are regarded as a network with unified management and traffic control. OXC and vro are regarded as peer-to-peer entities. Therefore, UNI is located between the vrouni and OXC) and the network-network interface NNI, and there is no difference between OXC. However, since most of the current networks are based on overlapping models, there is still a certain distance between the peer-to-peer model networks and commercial applications.

IETF recently completed a set of GMPLS protocols to meet an overlapping control plane connection model. The GMPLSUNI model focuses on UNI reference points and fully complies with all G) MPLS-related standards for GMPLSUNI performance requirements.

This network node is connected to the core network by the red line in the traffic engineering link. These nodes are called edge node EN ). Only these edge nodes can send the established link signaling to other edge nodes through the core network. The core network is a network provided by services, while the edge node is a user-end device. The interface between EN and CN is a UNI reference point. To support the ASON model, draft RFC4208 defines the signaling through UNI, this signaling is fully compatible with GMPLS signaling RFC3471 and RFC3473 ). This UNI signaling mechanism complies with the RSVP model, and the user's connection signaling is an end-to-end RSVP session. The RSVP session carries the user's end-to-end parameters.

3. UNI Performance Analysis and Comparison

The overlap model is designed as a commercial model that allows optical backbone operators to flexibly lease their networks to ISPs. Therefore, in this model, there will be a well-defined customer server relationship between entities. In the overlapping model, the Control Plane Separation of IP/MPLS and SONET/SDH networks is required. Only a limited number of constrained signaling messages can be exchanged. Therefore, IP/MPLS routing and signaling protocol instances are independent from those running on the transport network. Based on the C/S relationship defined in the IP/MPLS and SONET/SDH networks, the two independent control planes interact with each other through UNI.

A special UNI implementation based on overlapping models is based on the UNII1.0 protocol developed by OIF, it is proposed to address the explosive growth of IP data traffic faced by operators who have installed a large number of SONET/SDH devices. OIFUNI assumes that the protocols running on the in-band or out-of-band transmission network are strictly independent. Due to management and security, this protocol does not allow exchange of any topology information between the client and the server. Information exchange is limited to establishing or deleting connections between requests and responses. Other messages allowed are only status requests and status responses.