MPLS-TP transforms carrier networks for packet switching, but SDN could take it a step further. Combining the technologies, engineers could reduce complexity in the dynamic control plane and gain flexible service creation.
The MPLS Transport Profile (MPLS-TP) standard was developed to address a serious problem facing carriers -- traffic on their transport networks has shifted rapidly from circuit-switched TDM traffic to IP packet data. Now, they've got to support packet switching while continuing to carry legacy traffic with the high reliability of their current networks.
In large part, they've addressed the shift to packet networking with Multi-Protocol Label Switching (MPLS). But MPLS lacks some of the features transport network carriers require.
MPLS was developed to improve the efficiency of IP switched networks. It creates Label Switched Paths (LSPs) and replaces the IP lookup with a quick index of list of labels, replacing IPs' time-consuming, next hop lookup.
MPLS also supports applications such as interactive voice and video that require specified quality of service. Traffic engineered LSPs can be provisioned to create and maintain guaranteed throughput, delay and jitter levels.
But MPLS-TP brings added features -- including maintenance functions and the ability to carry any type of legacy data traffic -- operating over any physical layer technology, supporting both static and dynamic control planes. The MPLS-TP standardization effort was the joint work of the Internet Engineering Task Force ( IETF) and the ITU Telecommunication Standardization Sector (ITU-T), and based on requirements received from carriers.
MPLS-TP OAM functions
Existing transport networks have proven reliable due to the Operations, Administration and Maintenance (OAM) functions provided by current SONET/SDH and optical transport network (OTN) technologies. OAM packets are mixed in with customer data and flow along each data stream. Maintenance nodes along each network path constantly monitor OAM packet arrivals to measure throughput, packet loss rate, delay, jitter, and to detect breaks in network continuity.
When a problem is detected, network managers can then use other OAM functions to test the path. OAM commands can block the path to everything but OAM packets, allowing managers to test segments along the path and to detect the location, and cause of, the defect.
In an MPLS-TP environment, Pseudowire Emulation Edge-to-Edge (PWE3) standards under development by the IETF specify how to emulate a dedicated point-to-point or point-to-multipoint link. Client networks at each end of the pseudowire can continue to exchange legacy data, as they did before the change in transit network technology.
MPLS-TP also supports the GMPLS standards created by the IETF to extend label-switching concepts to a variety of physical layer technologies. By incorporating GMPLS, MPLS-TP meets carrier requirements to operate over technologies including SONET/SDH, OTN and Gigabit Ethernet.
MPLS-TP for both static and dynamic control planes
Carrier network transport paths have typically been set up statically by managers and modified only to support new requirements, such as when the physical network is updated or when there is an outage. Security requirements can also make it necessary for managers to set up a path along a specific geographical route.
MPLS-TP supports both static or dynamic path creation and management. It includes the dynamic control plane mechanisms in the MPLS protocol suite. A dynamic control plane offers advantages by creating and modifying paths without the need for manager intervention.
Benefits of MPLS-TP and SDN
Using SDN in an MPLS-TP environment can reduce complexity in the dynamic control plane and allow for flexible service creation.
In dynamic control plane operations, OSPF-TE, RSVP-TE, LDP, LMP, I-BGP and MP-BGP are required to find available paths, reserve bandwidth to create traffic-engineered LSPs, monitor paths in order to maintain guarantees, distribute labels to routers along a path, and establish routes between autonomous systems.
Each router in the network must have sufficient memory and CPU capacity to support all of these protocols. A software update must be scheduled every time a vendor fixes a defect in one of the protocol modules.
A switch to SDN would remove the need for router-resident protocol implementations. An OpenFlow controller, for example, would issue directives to set up network paths. Applications interfacing to the controller would implement the functions currently provided by the router resident protocol code. Routers would no longer require as much memory or compute capacity, reducing energy requirements and frequent updates.
SDN control would make it possible to create a service that requires capabilities not present in current protocol standards. Engineers could implement services by writing code for the application software interfaced to the OpenFlow controller. Without SDN, adding a feature to a standardized protocol would require a proposal to the IETF followed by a period of discussion and refinement before a new protocol version was issued; an extremely time-consuming effort.
With OpenFlow control, visibility engineers could also create a single optimized path across the boundaries of network segments. The current MPLS-TP control plane creates paths only within the boundaries of the MPLS-TP network itself. Creating an end-to-end service stretching between segments of a client network and connected by an MPLS-TP network requires setting up three individual paths, a path through each client network segment and another through the MPLS-TP link.
As SDN continues to display its benefits in the data center, proponents of extending the concept to transport networks will work with early adopters to test and refine their proposal. If SDN control proves successful, it will add flexibility and simplify transport networks operation.
No comments:
Post a Comment