JP2010520663A - Software control plane for switches and routers - Google Patents

Abstract

  The provider network controller (PNC) addresses the problems of building services through the next generation network (NGN) architecture, and is an abstraction layer as a bridge or glue between the network transport and the applications that run through it Create PNC is a service activation and layer 0-2 for multiple transport technologies including Carrier Ethernet, Provider Backbone Transport (PBT), Multiprotocol Label Switching (MPLS), Transport MPLS (T-MPLS), Optical and Integrated Networking Platform A multi-layer, multi-vendor dynamic control plane that executes management tools. Options for choosing best-in-class equipment that simplifies service creation by separating transport control and services from network equipment and enables operators to leverage PNC to quickly create and manage forwarding and services I will provide a. PNC provides a service-oriented architecture (SOA) interface to abstract transfer objects specifically designed to support both wholesale and retail services, including various bandwidth and quality of service (QoS) requirements Supports service proposals, thus realizing the enterprise Ethernet economy.

Description

<< Cross-reference with related applications >>
This application claims the benefit of US Provisional Patent Application No. 60 / 904,259, filed March 1, 2007, and US Provisional Patent Application No. 61 / 032,214, filed February 28, 2008. is there. The entire teachings of the above application are incorporated herein by reference.

  The rapid growth of the Internet over the past few years has placed a heavy burden on service provider networks. Not only has the number of users increased, but the connection speed, backbone traffic, and modern applications have also increased in a wide variety. Initially, normal data applications required best-effort capabilities, but modern applications such as virtual private network (VPN), voice, multimedia traffic, and real-time e-commerce applications have higher bandwidth and better Progressing towards service assurance. The main technologies currently used to provide such quality of service (QoS) include multi-protocol label switching (MPLS) and provider backbone transport (PBT).

  Network operators are experiencing rapid changes in service revenue and technology over the last 20 years. In the late 1980s, almost all service revenues consisted of wired voice and leased line services based on traditional time division multiplexing (TDM) and synchronous optical networking (SONET) / synchronous digital hierarchy (SDH) or "circuit switched" network infrastructure It was caused by. By the late 1990s, the growth of the Internet and the business transition to packet-based services including Frame Relay, Asynchronous Transfer Mode (ATM) and Internet Protocol (IP) services will create completely new revenue and service models It was clear that.

  Today, telecom operators are facing increased competition in “bit pipe” business, a business model based purely on connectivity as practical, which results in both low revenue and low margin. The bitpipe model does not focus on content and services, but is driven by excellence in operation. In order to maintain profits in the midst of declining profits, carriers adopting the bitpipe method are forced to reduce management costs promoted by IP technology, infrastructure development, process automation, business outsourcing and excessive competition. Yes. In addition, telecommunications carriers are developing a growing number of managed business services, connection-type services such as voice over IP (VoIP), IP TV (IPTV) and broadband Internet, and both outsourcing and outsourcing, including wholesale sales. They are looking to generate new top-level growth from value-added services, while at the same time looking at smaller corporate customers and gaining momentum in their future cash flow.

  When doing this, carriers will raise another dominant trend of customer demand for bandwidth that is orders of magnitude higher than what was consumed just a few years ago, and SME outsourcing information technology (IT) The need for an automated turnkey service for). As a result, operators can create a portfolio that includes multiple clearly differentiated services from the simplest bitpipe through advanced applications, while at the same time facilitating automation throughout the service lifecycle, There is a need to find a way to satisfy customer requirements for. However, these services overlap on separate physical infrastructures with different constraints. For example, in metro aggregation, cost management is very important as well as a stable supply of increased bandwidth. Service providers want to configure new services through component reuse instead of independent stove pipes, which require these applications to utilize a common physical infrastructure.

  As the demand for packet services has increased and exceeded the demand for voice and line services, conventional carriers have realized that they operate separate circuit-switched networks and packet-switched networks. In addition, carriers are forced to rethink traditional models for service delivery through their transport networks by transitioning from bitpipe to value-added service providers. Current models that tightly link services to the basic transport network do not provide the flexibility that carriers need for true service innovation. Carriers need a flexible framework that handles services and transfers separately. In addition, the economy is always the most important concern. Thus, service providers have recognized the need to direct the economy and flexibility of Ethernet companies to carriers' networks. Telecom operators want to create new revenue streams by creating new applications and adding new customers to existing services in both wholesale and retail markets. In addition, operators want to reduce costs by automating services and streamlining regulatory compliance.

  The main problems faced by carriers are that the network does not have one topology, but three topologies: a “logical topology” of services that allow endpoints to address each other, and traffic Has a “traffic topology” of the network that shows the actual path followed between these endpoints, and a “physical topology” of the network that is important for availability management and recovery from failures. is there. The inability to individually control the three network topologies is not an academic issue.

  A VPN is a private communication network that is often used within a company or by several companies or organizations, and communicates secretly through a public network. In addition to standard protocols, VPN traffic is carried over public network infrastructure (such as the Internet) or over the service provider's private network through a service quality assurance system (SLA) established between VPN customers and VPN service providers. can do.

  VPN can be a cost-effective and secure way for various businesses to allow user access to the corporate network and for remote networks to communicate with each other over the Internet. VPN connections are more cost-effective than leased lines, and VPNs are usually more secure than protected or “internal” networks that provide physical and administrative security to protect transmissions. Includes two parts: a low (usually via the Internet) “external” network or segment. In general, there is a firewall between the remote user's workstation or client and the host network or server. When the user's client establishes communication using the firewall, the client can pass authentication data to an authentication service within the boundary. Only when a known trusted person sometimes uses a trusted device, can this person be given appropriate security privileges to access resources not available to the general user.

  A properly designed VPN can provide significant benefits to an organization. Such VPNs expand geographic connectivity, improve security where data lines are not encrypted, reduce remote user transit times and transfer costs, and over traditional wide area networks (WANs) Reduce operational costs, simplify network topology in some scenarios, invest in more than global network opportunities, telecommuter support, broadband network compatibility, and traditional carrier leased / owned WAN lines Provides fast revenue, shows good scale benefits, and can be properly scaled when used with public key infrastructure.

  The VPN can use a tunnel to make the connection. Tunneling is the transmission of data through a public network in such a way that a routing node in the public network does not realize that the transmission is part of a private network. In general, tunneling is performed by encapsulating private network data and protocol information in public network protocol data so that nobody who examines a transmitted data frame can use the data to be tunneled. Tunneling can use a public network (such as the Internet) to carry data on behalf of the user as if the public network had access to a “private network” and thus a name. it can.

  Carriers use MPLS to direct the flow of traffic within their network. MPLS is suitable for use in VPN tunneling because it provides traffic separation and differentiation without substantial overhead. MPLS emulates some characteristics of a circuit-switched network over a packet-switched network by setting up a specific path for a sequence of packets identified by a label within an individual packet. It is a transmission mechanism. MPLS is protocol independent and can be used to carry many different types of traffic, including IP packets and native ATM, SONET, and Ethernet frames.

  MPLS works by adding an MPLS header containing one or more “labels” to the beginning of the packet. This is called a label stack. Received data packets are assigned a label by a label edge router (LER) and then forwarded along a label switch path (LSP).

  During this routing, the contents of packets below the MPLS label stack are not examined. In accordance with the LSP, individual label switch routers (LSRs) forward packets based solely on the indication of the top label in the stack. At each hop, the LSR strips off the existing label and adds a new label that tells the next hop how to forward the packet. LSPs are established at all hops according to the data path, thereby providing a secure path across the IP cloud. Specific IP tunnels can be created for individual customers throughout the MPLS network without the need for encryption or end-user applications. Eventually, the LER at the destination removes the label and delivers the packet to the destination address.

  At the exit LER, the last label is removed so that only the payload remains. This can be either an IP packet or a number of other types of payload packets. The egress router must therefore have routing information for the payload of the packet because it must forward the packet without the aid of a label lookup table.

  In addition to high-speed traffic forwarding, MPLS facilitates network management for QoS. An Internet service provider (ISP) can perform better management of different types of data streams based on priority and service plans. For example, customers who are subscribed to a premium service plan or who receive large amounts of streaming media or high bandwidth content may experience minimal latency and packet loss.

  However, the operation of MPLS is closely tied to IP, and as a result, can take over many of the adaptive operation problems, congestion and security issues associated with IP. Consumer traffic fluctuations can affect network load and performance for business services. Therefore, there is a constant risk of service failure that induces congestion with high network load and traffic concentration. This impaired critical planning in the quality of the customer's overall experience. Furthermore, while packet networks perform adaptive operations to increase resiliency, IP is poor in line predictability because the operator cannot easily determine the path taken by customer critical data.

  PBT is an extension set to Ethernet technology that allows the use of Ethernet as a carrier class transport network. Ethernet is a diverse family of frame-based computer networking technologies for local area networks (LANs), and network access at the media access control (MAC) layer defines a number of wiring and signaling standards for the physical layer. . The MAC layer provides a 48-bit addressing mechanism called the MAC address, which is a unique serial number assigned to each network adapter, allowing data packets to be delivered to destinations within the network.

  The main standard in the Ethernet architecture is the Provider Backbone Bridge (PBB) standardized as the Institute of Electrical and Electronics Engineers (IEEE) 802.1ah. This standard incorporates encapsulation based on MAC addresses, often referred to as “M-in-M” or “MAC-in-MAC” encapsulation. PBT can be supported on the network using virtual local area network (VLAN) tagging according to IEEE standard 802.1Q, Q-in-Q according to IEEE 802.1ad, and MAC-in-MAC according to IEEE 802.1ah Extends the number of “service VLANs” but invalidates the concept of flooding / broadcasting and spanning tree protocols. PBT uses Ethernet for connection-type purposes as well as current synchronous SDH and SONET transfers by removing the complexity associated with current Ethernet LANs. PBT simplifies operations, management, and maintenance (OA & M) by using additional extensions based on IEEE802.1ag, as seen in the SDH / SONET world, and unidirectional path switching in SDH / SONET networks An extension is made to provide a path protection level similar to ring (UPSR) protection.

  The packet is transferred based on the external VLAN identifier (VID) and the destination MAC address. Path protection is performed by using one operation and one protection VID. If a work path fails, the source node swapped the VID value and preset it within 50 milliseconds, as indicated by the loss of the 802.1ag continuity check (CC) message Redirect traffic to a protected path.

  At present, there is no means for constructing a tunnel through a mixed network that utilizes MPLS and PBT, as there is no technology that provides a contact point between MPLS and PBT networks.

  Provider network controllers (PNCs) address the problems of building services across today's evolving network infrastructure. PNC provides a comprehensive state-of-the-art multi-layer, multi-vendor dynamic control plane, carrier Ethernet, provider backbone forwarding (PBT), multi-protocol label switching (MPLS), forwarding MPLS (T-MPLS), optical and integration Implement service activation tools and layer 0-2 management tools for multiple transfer technologies including networking platforms. PNC is technology independent and is designed for networks that include single or multiple switch technologies. PNC provides a service-oriented architecture (SOA) interface to bridge the gap between next generation network (NGN) architecture physical network and software infrastructure to support both wholesale and retail services Cleanly abstract well-designed transfer objects.

  One of the important functions of PNC is route calculation and related network planning and optimization functions. In addition to simple best-effort shortest path routing, the PNC is responsible for various constraints and equipment (such as bandwidth, delay, jitter, latency, lawful interference, and other constraints dictated by network policy rules). Complex route calculations including restrictions can be performed. The constrained optimization problem requires knowledge of the state of the entire network and is therefore ideally suited for a separate dynamic control plane. PNC uses a combination of algorithmic, heuristic, and rule-based approaches to route individual flows according to network device service constraints and restrictions. PNC is designed to operate in a multi-layer, multi-service, multi-vendor, multi-carrier environment by nature.

  Route calculation in the PNC is performed by a route calculation module (PCM). PCM is a highly optimized multi-threaded module that can route 3000 flows per second, for example, in a network of 100 nodes in a basic configuration (single thread). The route calculation function is designed to streamline and automate network operations while providing the highest level of scalability and reliability and enabling the implementation of complex network policies. The main task of PCM is to apply traffic engineering rules and network policies to the network topology to optimally route individual services across the network. PCM keeps track of all flows routed in the network. The PCM also maintains a database that stores data regarding individual nodes and links of flows routed through this element, as well as the associated capacity, utilization, and performance metrics of this element.

  By utilizing a network controller, which is an adhesive between network transport and service layer, to support a range of service offerings with various bandwidths, support quality of service (QoS) requirements, and thus realize the enterprise Ethernet economy In addition, the flexibility and economy of Carrier Ethernet can be fully exploited. To simplify service creation by separating transfer control and services from network equipment, and to select the best-in-class equipment that enables rapid creation and management of transfers and services using a centralized control plane. Provide alternatives.

  An exemplary network controller and corresponding method that can be fully automated controls services in a communication network by means of a software control plane system. The communication network may be a multi-layer, multi-service, multi-vendor, or multi-carrier communication network. The controller stores information about hardware endpoints that may include switches and routers and communication connections in the communication network, as well as traffic engineering rules and network policies that manage the communication network. This information can include capacity, utilization, and performance indicators.

  An exemplary network controller's path calculation module calculates a communication path, which may include a tunnel based on the stored information to perform a prescribed service. The path calculation module further programs the hardware endpoint according to the calculated communication path to set the communication path in the communication network, and monitors the programmed hardware endpoint and communication connection. The path calculation module updates the stored information, recalculates the communication path, reprograms the hardware endpoint according to the recalculated communication path, and stores the stored information and services to ensure service execution. The communication path is adapted based on the change.

  In addition, the path computation module communicates based on attributes that may include service performance including frame latency stored in a database that defines frame latency, delay variation and loss rates, and services performed on the network. The route can be calculated. The path calculation module can override the normal operation of the hardware endpoint, program the hardware endpoint according to the calculated communication path, and also program the hardware endpoint and communication connection programmed according to the calculated communication path. Can be monitored for network failure, overload or route optimization.

  In addition, the route calculation module calculates the communication route and reprograms the hardware endpoint according to the recalculated communication route to communicate based on changes in the attributes of the specified service to ensure service implementation. The path can be adapted. The path calculation module can optimize hardware endpoints and communication connections in the communication network based on quality of service and bandwidth constraints per class.

  In addition, the path calculation module can recalculate the communication path based on the economic or social value associated with the communication path. The path calculation module recalculates the communication path and reprograms the hardware endpoint according to the recalculated communication path, and if at least one of the communication connections in the calculated communication path fails, the path calculation module The communication path can be repaired. A communication path calculated by using a communication connection in a communication network having a basic communication protocol different from the basic communication protocol of the communication path when the communication connection has a basic communication protocol. The basic communication protocol can be emulated. The route calculation module recalculates the communication route and reprograms the hardware endpoints according to the recalculated communication route to optimize the communication route for each service in the communication network based on the stored information. Can do.

  The path calculation module can dynamically adjust the repair time constant of the associated communication path based on the repair time constant of each of the communication connections of the recalculated communication path. The network controller can further move the service from the calculated path to the recalculated path to arbitrarily maintain hardware points and communication connections in the communication network without interrupting the service.

  As a further exemplary embodiment, there is a method of repairing a communication tunnel in a network, such as a first concept network. At present, there are other network optimization methods, but these cannot perform a quick repair of the service. MPLS does not optimize and does not note the reason for setting up a particular network (such as the lowest cost bandwidth available), but rather knows only the order of connections that have been set up. Furthermore, these methods for optimization do not know how the repair is done.

  Another exemplary embodiment is a method for emulating a communication tunnel in a network. According to this method, a communication tunnel having a first basic communication protocol and a plurality of hardware endpoints is assigned. The tunnel is then connected to another communication tunnel having a basic communication protocol different from the first protocol by directly programming the hardware endpoint of the communication tunnel.

  The foregoing will become apparent from the following more specific description, which illustrates exemplary embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters designate like parts throughout the different views. In showing embodiments of the present invention, the drawings are not necessarily drawn to scale, but rather emphasized.

1 is an abstract block diagram illustrating a conventional voice and data network architecture. FIG. 1 is an abstract block diagram illustrating the architecture of a next generation network (NGN). FIG. 1 is an abstract block diagram illustrating an NGN architecture. FIG. FIG. 2 is an abstract block diagram illustrating details of a conventional voice and data network architecture. It is an abstract block diagram showing details of the NGN architecture. FIG. 2 is an abstract block diagram illustrating the NGN architecture and the problems faced by carriers in its implementation. 1 is a network diagram illustrating an example Ethernet local area network (E-LAN) service deployment of the prior art in the form of an E-LAN instance and network topology. FIG. An abstract block diagram showing the network structure created under standards created by the Institute of Electrical and Electronics Engineers (IEEE), International Telecommunications Union (ITU), Internet Engineering Task Force (IETF) and Metro Ethernet Forum (MEF). is there. FIG. 2 is an abstract block diagram illustrating the NGN architecture of FIG. 1C including an exemplary embodiment provider network controller (PNC) according to the present invention. It is an abstract block diagram which shows the abstraction layer which PNC provides. FIG. 2 is a network diagram illustrating an exemplary E-LAN service deployment utilizing an exemplary embodiment PNC according to the present invention. FIG. 6 is a flow diagram illustrating path calculation by an exemplary path calculation module (PCM) in an exemplary embodiment PNC according to the present invention. FIG. 6 is a state diagram showing the state of a route layer when a flow is routed through a network to maintain consistency with a network policy. FIG. 5 is a flow diagram illustrating classes of network policies that occur with respect to network failure and recovery in an exemplary embodiment PNC according to the present invention. 1 is a network diagram illustrating a network including a PNC of an exemplary embodiment according to the present invention that supports network maintenance operations and events and associated network link status. FIG. 1 is a network diagram illustrating an example virtual private network (VPN). FIG. FIG. 2 is a network diagram showing a contact point between two Internet service providers (ISPs). FIG. 12 is a network diagram illustrating control of an exemplary embodiment software control plane via the ISP of FIG. 11 in accordance with the present invention. FIG. 2 is a network diagram illustrating a software control plane of an exemplary embodiment in a network according to the present invention. FIG. 3 is a network diagram illustrating an exemplary emulation of tunnel creation by an exemplary embodiment software control plane according to the present invention. FIG. 6 is a network diagram illustrating an exemplary emulation of the connection of tunnels of different topologies by an exemplary embodiment software control plane according to the present invention. FIG. 3 is a network diagram illustrating connection rerouting due to a failure in a first connection by an exemplary embodiment software control plane according to the present invention. FIG. 3 is a network diagram illustrating service migration by an example embodiment software control plane according to the present invention.

  Hereinafter, exemplary embodiments of the present invention will be described.

  FIG. 1A is an abstract block diagram illustrating a conventional voice 110 and data 120 network architecture 100a used by a carrier. Over time, the relative importance of different networks has changed. Thus, due to the large growth of data traffic through the data network 120, the uniform growth of voice traffic through the voice network 110, and the maturity of Internet Protocol (IP) technology, operators are evaluating their systems, We have anticipated the services that our networks will need to support and the types of competition these networks will face in the future. The relative conclusion is that the traditional network architecture 100a needs to change so that management can effectively respond to the market and compete in the new environment. For this reason, the International Telecommunication Union (ITU) has developed a Next Generation Network (NGN) architecture to enable delivery of a wide range of telecommunications services through a single packet-based infrastructure.

  FIG. 1B is an abstract block diagram illustrating the NGN architecture 100b. The NGN architecture 100b includes a “building block” layer, ie, a service / application layer 130 that defines most of the service, a control layer 140 that represents a software system such as an IP Multimedia Subsystem (IMS), and the role of physical transfer of data. It is built around the transfer layer 150 responsible for All three layers 130, 140, 150 use several common components 180, such as those represented by Operational Support System (OSS) / Business Support System (BSS). The NGN architecture 100b uses a plurality of broadband, quality of service (QoS) compatible transfer technologies and makes the service-related functions independent of the selection of the basic transfer technology.

  FIG. 1C is an abstract block diagram illustrating the NGN architecture. Layers 130, 140, 150, 160, 170 represent how the carrier thinks about its network architecture 100c. Transfer 150 is the overall physical infrastructure 155, while access 160 and subscriber premises equipment (CPE) 170 represent the deployment of physical networks 165, 175 to reach the customer. Above that is the control domain 140, where a system such as IMS 145 resides. Further above is the actual end application 130 such as a voice phone 132 and Internet access 134.

  FIG. 1D is an abstract block diagram detailing the architecture 100a of a conventional voice network 110 and data network 120. As shown in FIG. From the first circuit switched voice network 110 in the public switched telephone network (PSTN) architecture, the stove pipe architecture 100a expands as new services are developed, thereby enabling voice 110, digital subscriber line (DSL) 122, asynchronous Each service, such as Transfer Mode (ATM) 124 and Virtual Private Networking (VPN) 126, has come to have its own dedicated network or overlay network to carry the service. As a result, a number of services need to be distributed over an increasing range of access devices.

  FIG. 1E is an abstract block diagram illustrating the NGN architecture 100b. The NGN architecture 100b constructs a new service with the possibility of an individual service in each layer and a function to move to a new network architecture. Specifically, the NGN architecture 100b frees the telephone operator from the constraints and costs of the stove pipe architecture 100a of FIG. 1D. Service providers 137 (such as service / application domain 130) increase to increase revenue and pressure to support multiple access networks (such as access domain 160) and devices 167 (such as CPE domain 170). Depending on the needs, carriers are trying to aggregate the number of platforms in the “middle” of the network 157 (such as forwarding domain 150). Thus, the convergence from the top (ie, services provided) 137 and the bottom (ie, available access devices) 167 is effectively converged.

  FIG. 1F is an abstract block diagram illustrating the NGN architecture and the problems faced by carriers in its implementation. Today, forwarding domain 150 lacks a general service quality assurance system (SLA) -aware application programming interface (API) that allows service elements to specify attributes such as bandwidth, disaster recovery procedures, and delay characteristics. is doing. In order to be implemented correctly on the NGN, the service needs a clear API at the boundary of each layer that can instruct the transport layer 150 and control layer 140 of the network how to handle various types of traffic. This greatly improves the operator's ability to deliver at the time of rapid application (service) introduction and adapt to the changing nature of service demand and delivery issues. For example, in the case of an application such as a game, a function for determining characteristics such as jitter and packet loss is essential. New services require absolute parameters on a service-by-service basis rather than traditional generalized bronze, gold and platinum service levels. Due to the diversification of services, there must be a place on the network where services can be arbitrated. Absence of global resource arbitration leads to excessive network intervention. Furthermore, the absence of a resource arbitration policy creates a risk for high value services. Resource arbitration must be done centrally and brought into the distributed network.

  Furthermore, in order to protect physical assets from “value usage” by competitors 136 at the service layer 130, particularly in the forwarding layer 150 and the access layer 160, a standard API that can be executed is required.

  Telecom operators also want to increase revenue opportunities by taking advantage of the transport network 150 they have invested heavily. In order to realize this, the communication carrier wants to connect the transfer network 150 to the service 130 that performs distribution for making a hybrid service proposal distinct from the competitor 136. A further problem for carriers is that services 130 compete for each other in the transport layer 150 for resources because there is no centralized “service-centric” information in the IP-based transport layer 150. Accordingly, when different services 132, 134, 136 move through the transport network 150, service information is required to be able to effectively manage them.

  Furthermore, there is a problem in maintaining “touch” within the OSS 180 in the transition from legacy services to NGN framework services. For example, operators may operate frame relays and ATM networks that support high-end, “high touch” services that are highly appreciated by business customers. While carriers want to move from expensive frame relay and ATM networks to lower cost IP networks, they cannot afford to lose the ability to deliver legacy “high touch” offerings. Thus, service providers lose their “touch” with traffic and do not always know where a particular packet exists or how it actually works. For this reason, end customers are reluctant to move from legacy ATM to IP.

  High value services also require that service requirements for procedures such as disaster recovery can be communicated to the network so that the system can repair the most important services first. Ultimately, carriers want to link business needs with network operations. At the same time, however, the network continues to evolve from IP to IP over Multiprotocol Label Switching (MPLS) and further to lower cost technologies such as Provider Backbone Transfer (PBT) and Ethernet. A further complex factor is the number of devices from multiple vendors in the network or with different lifetimes and different functions. It is necessary to adjust the technology and functions that constitute the network so that the service can use the network optimally.

  This transition to packet services has presented managers and customers with special problems used in circuit-based operations. The circuit is “stateful” and is set up according to a specific route. Knowing these paths makes it easier for the carrier to defend against node and link failures and react and repair immediately. Since trunk bandwidth is allocated end to end, circuit switching manages congestion purely through admission control. However, packet services require more complex traffic and congestion management as the size of the network increases.

  Telecom operators seek services and applications that are not bound by technology. For example, a voice-over-IP (VoIP) carrier simply wants an IP call to be completed and does not care whether it is carried over an MPLS, Ethernet or native IP link. Carriers also want to be able to control multiple services, eg via IMS, and manage future services via the same architecture. Further, integration of transfer layers using technologies such as IP / MPLS, Ethernet PBT, and all optical networks is performed. At the other end of the frequency band, network access methods are diversified by technologies such as WiFi, radio access network (RAN), and CPE devices. Carriers are performing centralized provisioning processes such as authentication, authorization, and accounting (AAA), and SLA-based subscriber and policy management. These processes are based on building blocks that can be reused or reconfigured to meet changing needs.

  In addition, compliance with regulatory standards, such as legitimate access, is involved in telecom operators regarding monetizing service-oriented infrastructure. Security issues related to the separation of user data from competitors and the protection of network information also involve carriers.

  Carrier Ethernet offers operators the opportunity to position their services as their greatest strength. For retail customers, Ethernet is a convenient, easy-to-use and cost-effective packet transfer technology. For telecommunications carriers serving their customers, Carrier Ethernet provides an opportunity to provide a simple and useful foundation that can build a layer of value-added services ranging from IP services to VoIP. Since Carrier Ethernet is not tied to transport, operators have complete freedom to develop or add to their Layer 0/1 infrastructure in whatever way seems best. Carrier Ethernet has similar value in wholesale services. The service phase is likely to start with dark fiber, followed by lambda, followed by framed layer 1 services such as, for example, synchronous optical networking (SONET). These characteristics for accurate SLA and support for Carrier Ethernet are based on the fact that a single Ethernet virtual circuit can be used for a carrier's major cities and long-range infrastructure, regardless of which combination of Layer 0/1 technology can be used. It can be an excellent basis for wireless backhaul and similar applications.

  Although Ethernet interfaces have been used for routers and other packet devices for many years, there is a significant difference between the mission of point-to-point Ethernet and the mission of “traffic topology”. Ethernet was developed as a standard for local area networks (LANs) and has shown significant problems in terms of scalability and compatibility with regard to carrier operation. By limiting Ethernet based on the number of virtual LANs (VLANs) that can exist on a single network, carriers can support as many customers as they want without resorting to non-standard means It becomes difficult to do. Further, as a corporate technology, Ethernet does not include the operation, management, and maintenance (OA & M) functions found in carrier technologies such as SONET, and does not provide a quick failover function for SONET. Finally, while plug-and-play operations are often desirable for enterprise operations, plug-and-play operations are particularly important for operators, especially when they have an SLA to meet. It becomes traffic engineering.

  There are numerous standards groups that address the Carrier Ethernet problem, including the Institute of Electrical and Electronics Engineers (IEEE), ITU, Internet Engineering Task Force (IETF), and Metro Ethernet Forum (MEF). Its activities have expanded as service provider interest in Ethernet evolved from a simple service interface to an architecture for the Carrier Ethernet ecosystem. MEF has developed five critical attributes for the Carrier Ethernet architecture and has worked to develop a complete solution in each area. Its main requirements are (1) standardized services through the use of non-technical service behavior abstractions, and (2) cities to ensure that providers are not at risk of moving away from carrier Ethernet investments. Scalability to national and even global deployments, (3) reliability to ensure that the Ethernet layer contributes to greater network availability, (4) much managed QoS and stringent QoS to ensure that Carrier Ethernet can support all currently available service proposals for service quality assurance schemes, and (5) Service management to ensure that Carrier Ethernet can be linked to services and operational processes , Thus supporting effective and efficient operation, management and provision (OAM & P) It is to be.

  Carrier Ethernet still needs to make one of its promises real, relief from spanning tree and traffic engineering issues. Ethernet Basic Spanning Tree Protocol (STP) has already been enhanced to Rapid Spanning Tree Protocol (RSTP) and Multi Spanning Tree Protocol (MSTP), which still data on the size and complexity of Carrier Ethernet networks. It creates plane and control plane constraints. It is in this area that disputes arise between standards groups, providers, and equipment vendors. One side has promoted PBT as an extension of Carrier Ethernet, and the other has promoted a variant of MPLS called Transport MPLS (T-MPLS).

  PBT has evolved from other Carrier Ethernet technologies and is easily introduced into many Carrier Ethernet products. PBT is an “under IP” service framework that avoids adaptive and relatively unpredictable IP behavior, and can be used to deliver high value services at a lower cost compared to existing solutions. PBT is built on IEEE 802.1 and supports the use of point-to-point tunnels provided, Ethernet line (E-LINE), Ethernet LAN (E-LAN), or Ethernet tree (E-TREE) services Layer 2 VPN elements that link the fragments. In PBT, the occurrence of spanning tree update is suppressed. As a result, there is no control plane operation for building the bridging table. Instead, the bridging table is built using an external management system. Just as PBT is an extension to Ethernet technology, T-MPLS is an extension to router technology. However, routers are usually more expensive than Ethernet switches. Therefore, if the network does not yet support routing, the implementation cost of PBT is lower.

  In order for PBT to be the basis of a service element, it needs to be part of an open control plane. The carrier does not want a further control plane dedicated to PBT. Providers want an open control plane concept that is compatible with other network technologies such as IP. However, countering this transition is the desire of equipment vendors to keep the control plane in the equipment vendor's system a barrier to low cost competitors. PBT has emerged as a low-cost, high-touch alternative, but carriers have already adopted MPLS and are investing in equipment to support it.

  The PBT operates as a data plane without a policy. Therefore, network policies should be defined by the carrier's business policy (ie, the relationship between the provider and between the provider and its customers). Business policies should flow down the network. A natural order is to achieve a contract between business parties, each pushing their policies into the network. At present, there is no abstraction that implements this information flow. To make matters worse, today's protocols require the exchange of business policies at the network layer.

  PBT and T-MPLS have various approaches in common and their technical functions are substantially the same. Both proposed extensions to the Carrier Ethernet framework create an alternative to provider backbone bridging (PBB). Both have specific “edges” and form an intra-network network with special internal operations. Both also create a more manageable control plane architecture based on something other than normal topology update messages. Supporters of PBT and T-MPLS should also use a general purpose MPLS (GMPLS) control plane architecture, and most importantly, there must be a connection-oriented transport technology layer as layer 2 of the provider packet network Agree that there is.

  The role of GMPLS as the control plane for both architectures stems from its roots as the control plane for optical routing. Since optical devices do not exchange topology information, GMPLS assumes that this information can be gathered through separate control plane layers using standard discovery protocols to learn the topology. This result is then fed down towards the lower layers to manipulate the connect operation that allows significant control of the conditions that result in updating the topology. Topology awareness can also be obtained from higher layer control plane exchanges, such as those already used for IP / MPLS. An important requirement for GMPLS is the correlation between nodes and trunks in the control and data planes so that the underlying topology can be accurately represented. The PBT / T-MPLS controversy can be said that the problem of topology and configuration management with independent higher level control planes is generally important to managers.

  Carrier Ethernet is the ITU recommendation G.I. Inherits all Ethernet OAM & P extensions including IEEE 802.1ag OA & M connectivity fault management functions and Ethernet protection switching standardized in 8031 SG15. The former provides frame loss, delay and jitter information, as well as service availability and usage information. Unlike MPLS label switch path (LSP), which is difficult to track internally, the Carrier Ethernet path can be tracked for troubleshooting purposes, and this Carrier Ethernet path can be affected by adaptive routing changes. I do not receive it. For this reason, the failover route can be calculated in advance as necessary. Together with PBT, these functions can write strict SLA as well as for Carrier Ethernet services, which solves one of the major provider problems for enterprise services based on IP and MPLS. Similarly, the rapid automated failure detection of Carrier Ethernet will notify you as soon as a network problem occurs.

  PBT traffic engineering (PBB-TE) defined in IEEE 802.1Qay is a technology that supports advanced carrier Ethernet. PBB-TE enables the creation of connection-oriented Ethernet tunnels that allow service providers to provide services such as time division multiple access (TDM) circuits with deterministic performance characteristics. This PBB-TE is designed to satisfy or exceed the functions currently introduced by tunneling technology (such as MPLS), just in terms of Ethernet costs, and includes simplified control and management. PBB-TE effectively “disables” several Ethernet features such as broadcasting, media access control (MAC) address learning, and spanning tree functionality without introducing new complex / expensive network technologies. By doing so, the connection-oriented transfer mode is extracted from the existing switch. However, some obstacles need to be removed when (1) lack of control plane in PBB-TE equipment and (2) need to support all kinds of business services under PBB-TE. There is.

  FIG. 2 is a network diagram illustrating an exemplary prior art E-LAN service deployment in the form of an E-LAN instance 200a and a network topology 200b. The E-LAN service is a multipoint-to-multipoint service that connects the LANs 201 to 206 at different customer sites via a trunk line of a communication carrier that creates recognition as a single-bridge corporate LAN 210. For example, customer networks 201-206 are connected to provider edge (PE) switches PE1-PE3 of PBB network 210 by connection lines (AC) AC1-AC6 at customer edge (CE) switches CE1-CE6. To the individual customer networks 201-206, the provider network 210 appears to be a single LAN with CE devices attached.

  The group of customer networks 201-206 can belong to a separate respective E-LAN instance 230, 240 in the provider network 210. For example, customer networks 201, 202 and 205 belong to E-LAN instance 230, and customer networks 203, 204 and 206 belong to E-LAN instance 240. In order to maintain isolation across several E-LANs 230, 240, individual instances are associated with Ethernet virtual switch instances (EVSI) 235, 245. EVSI instance information is held and processed in the associated PE switch by the ingress PE responsible for forwarding frames based on the search for the destination MAC address.

  In order to achieve any-to-any connection to all remote sites, all EVSIs 235, 245 of ELAN instances 230, 240 are connected via a full mesh of PBB-TE trunks (PT) PT1-PT3. EVSI is similar to an Ethernet bridge that performs intelligent learning (such as PT1-PT3 and AC1-AC6) connected to virtual and physical ports. For example, EVSI 235 in PE1 is connected to CE1 via AC1, and to EVSI 235 in PE2 and PE3 via PT1 and PT2. EVSIs 235, 245 at individual PEs build and maintain a MAC address forwarding table that maps destination MAC addresses and associated ports or PTs. The learning process takes place by examining the source MAC address of the frame that arrives at the port or via the PT and by creating a corresponding entry in the forwarding table.

  The forwarding mechanism and frame processing in a given PE switch includes two scenarios: a frame received at a port (AC) and a frame received at a virtual circuit (PT). When one of the ACs at the ingress PE receives a service frame addressed to a remote site, it processes this to determine the output line of either a physical (AC) or virtual (PT) transfer line, and the remote site To reach. This is done by searching for the destination MAC address in the MAC forwarding table associated with the E-LAN service instance 230, 240 of the input port. If found, the frame is properly encapsulated and forwarded through the PBB network 210 to the remote PE or other AC. If there is no match, the frame is flooded to all physical (AC) and virtual (PT) connections. If the timer does not exist or the timer is updated to an existing table entry, the source MAC address and input line of the received frame are added.

  For example, when node A transmits traffic to node B, the frame reaches PE1 from CE1 via AC1. PE1 searches the MAC address table of E-LAN service instance 230 for the MAC address of Node B. If the Node B MAC address is not found, the frame is flooded from PE1 to PE2 via PT1 and from PE1 to PE3 via PT2. When a service frame addressed to a remote site is received at the PT, the frame processing is the same as that received at the physical port, but flooding is limited to the physical AC only. This limited flooding is to prevent a forwarding loop that occurs when flooding is performed on a virtual link (ie, split horizon).

  When a frame is received with the MAC address of node A in PT1 from PE2 to PE1, PE1 searches the MAC address table of E-LAN service instance 230 for the MAC of node A. If there is no match, the frame is flooded through all physical ports (AC) and no flooding is performed on any of the PTs. In this case, this frame is flooded to AC1 and AC4 connected to CE1. Broadcast traffic processing is the same as flooding in which a frame received from a connection line is transmitted on all connection lines and PTs. The remote PE further floods the received broadcast frame in all ACs associated with that E-LAN instance. Similar to unicast frame processing, frames received via PTs are not sent via other PTs (ie, split horizon) to avoid forwarding loops.

  FIG. 3 is an abstract block diagram illustrating a network structure created under standards created by IEEE, ITU, IETF, and MEF. A provider network (not shown) of optical and Ethernet devices creates a physical infrastructure in metro 310, wide area core 320 and backhaul 330. Through this, the transfer abstraction 340 hides the differences in basic technology and facilitates the construction of point-to-point, multipoint and one-to-many services. Some of these services are sold directly to end users (like the managed service 350), others are voice 362, streaming (like the 3rd Generation Partnership Project (3GPP), 4GPP, IMS 360, etc.) Some form the basis for a “service infrastructure” that supports other applications such as 364, IPTV (370), broadband Internet 380, and wholesale services 390.

  The basic task of the control plane is to execute the network policy associated with the service based on the current network state. In early IP networks, the control plane was integrated into the line card. A simple distributed control plane in an IP network has allowed rapid growth of the IP network. However, as the network traffic and size increased, in the first stage of separating the control plane from the forwarding plane, the control plane was moved to another processing card, but still integrated into the router.

  As the size of the network continues to grow, the complexity of the control plane has increased dramatically and the basic hypotheses underlying the distributed autonomous control plane can no longer be held. A control plane associated with the Internet Gateway Protocol (IGP) that divides the network into hierarchical domains to provide predictable services including guaranteed SLA across a wide range of traffic in a cost-effective manner Overcame processing limitations. In order to overcome the limitations of extensibility due to the external gateway protocol (EGP), a route reflector was introduced. Route reflectors were originally routers that did not have user ports, but these account for the second step in moving the control plane away from the routers and switches. However, a more comprehensive and holistic view of the entire network (or multiple networks) is needed because of multiple services that include multiple network policies.

  FIG. 4A is an abstract block diagram illustrating the NGN architecture 100c of FIG. 1C including an example embodiment provider network controller (PNC) 402 according to the present invention. PNC 402 addresses the challenges of building services across today's developing network infrastructure 100c, provides a comprehensive, state-of-the-art multi-layer, multi-vendor dynamic control plane, Carrier Ethernet, PBT, MPLS Perform service activities and layer 0-2 management tools for multiple transport technologies, including T-MPLS, optical and integrated networking platforms. PNC 402 is technology independent and includes single or multiple switch technologies to conceal the complexity of the transport domain technology and structure and to the resource side via abstractions such as TeleManagement Forum (TMF) and IP Sphere. Designed for networks that play a supporting role. The PNC 402 provides a common control framework for basic technologies including IP, Ethernet, and optical, and allows transitions between different network technologies. Like software-based systems, the control plane is fully automated.

  The PNC 402 provides a service-oriented architecture (SOA) interface to cleanly abstract forwarding objects that are specifically designed to support both wholesale and retail services, thereby enabling the physical nature of the forwarding domain 150 in the NGN architecture. Bridging the gap between the network and the software infrastructure of the control domain 140. By providing an abstraction layer that lies on both MPLS and PBT, services can be mapped to either MPLS or PBT as needed. Furthermore, PNC 402 allows for a seamless transition from MPLS to PBT without a flagday scenario (ie, a complete restart or conversion of software or data that is significantly larger in size). The PNC 402 is located as an API between the business layer 140 and the network layer 150, and translates the business policy into a network policy so that this information flows.

  IMS is an example of an upper layer application service that can be processed by the PNC 402. At the highest level, IMS simply establishes a point-to-point user session between two gateways through any available full mesh packet forwarding capable network technology (ie, IMS, such as MPLS, native IP and PBT). I don't care about basic transfer technology). The main element is SLA, so the application is resource oriented. The PNC 402 can provide APIs to IMS resource admission control function session-oriented elements, select the optimal forwarding elements, configure the network, and monitor actual features to comply with desired behavior.

  The route calculation in the PNC 402 is performed by a route calculation module (PCM) 405. The PCM 405 is a highly optimized multi-thread module 405 that can route 3000 flows per second, for example, in a 100 node network in the form of a basic configuration (single thread). The main task of PCM 405 is to apply traffic engineering rules and network policies to the network topology to optimally route individual services across the network. PCM 405 keeps track of all flows routed in the network. The PCM 405 also maintains a database 407 that stores data regarding individual nodes and links of flows routed through this element, as well as the associated capacity, utilization, and performance metrics of this element.

  FIG. 4B is an abstract block diagram showing an abstraction layer provided by the PNC 402. A service 430 is defined based on the network technology 440. PNC 402 then emulates legacy service definitions and defines new services unrelated to network technology 440 to facilitate integration of inter-provider services with service management and functional applications. The PNC 402 provides a service facing API 450 that is layered on top of the virtual resource abstraction 460. Resource abstraction 460 describes resource abstraction behavior in the network so that service requirements can be mapped to available resources. The behavior manager 470 maps virtual resources in a way that is optimal for network technology. For example, low resource aggregation applications may be carried over IP, and more demanding applications may use MPLS. Ethernet or PBT may be used in the access network, or for high bandwidth services, all optical links may be selected if available.

  Referring again to FIG. 4A, the PNC 402 overcomes the fundamental technical problems associated with current distributed control plane implementations. Unlike traditional static service delivery, the PNC 402 continually monitors SLA compliance and network failures, providing a higher level of network reliability and efficiency than previously possible with packet-based technology. Optimize network resource commitment to provide The PNC 402 arbitrates between multiple resource requests from the OSS service 430 / control layer via a standard SOA-based interface. The PNC 402 dynamically models the available and in-use capacity of the network and selects the most efficient path based on modeling of customer and carrier QoS and policy requirements. PNC offers a number of benefits, including (1) eliminating hardware limitations, (2) eliminating vendor limitations on innovation, (3) enhancing control plane robustness, and (4) end. Customer customization and programmability services are included.

  Advanced switching and routing products require customized hardware development to achieve the state of the art price / performance. This takes a long development cycle. The selection of the processing engine for the control plane for the product occurs early in the development cycle because it needs to be integrated into the platform hardware and software. As a result, when this product is introduced, the control plane processor is usually obsolete compared to a general purpose computer platform, which closely follows Moore's Law and continually improves the price / performance of general purpose computer platforms. . Simple tasks such as adding more memory to an integrated control plane processor often require hardware upgrades, and often require a complete major upgrade of the entire system. This has created a model in the industry where customers pay for new features by purchasing new hardware.

  The PNC 402 eliminates these limitations as a separate control plane based on software running on a general purpose computer platform. Control plane resources can be traced to Moore's Law in computer functions without being limited by hardware design points in the forwarding plane. Rather than updating the forwarding plane hardware, scaling is done by adding additional processing and memory resources. Functions are purchased as functions, not as new hardware. Also, fine-grained policy control can be performed without falling into the resource limits brought about by the integrated control plane processor.

  Industry innovation is constrained by the “lowest common denominator” effect that prevents all vendors in the network from introducing new features until they run an interoperable solution that typically requires hardware upgrades or replacements. It has been rare. The only alternative is that the customer is forced to purchase all equipment from a single vendor to obtain the desired functionality, while giving up other desired functionality that the vendor does not perform. Was the approach. A separate control plane in the PNC 402 allows many functions to be performed in the control plane software itself and can be serviced regardless of the forwarding plane hardware. In addition, the PNC 402 mediates differences in vendor-to-vendor implementations that enable seamless services that would otherwise be impossible. Because it is a software-based implementation, it is not related to the long-term forwarding plane hardware development cycle, thereby greatly increasing the speed of function and the ability to grow new revenue through new services and functions. To do.

  The PNC 402 protects the control plane from forwarding plane based anomalies and attacks. The PNC 402 provides the ability to easily hide the internal network infrastructure that is becoming increasingly important in inter-provider services. The PNC 402 also prevents forwarding plane congestion, which is a major cause of network failure, from affecting the operation of the control plane to solve the problem. Since the control plane redundancy / resiliency option can be configured separately from the forwarding plane configuration, the PNC 402 also allows the control plane to make more redundancy and resiliency choices, thereby substantially reducing A high level of availability is realized at low cost. For example, the control plane can be configured by 1: 1, 1: N, M: N, other combinations, etc. regardless of the configuration of the transfer plane.

  Apart from the general advantage of having separate control planes in the PNC 402, as with the PNC 402, there are (1) predictability, (2) fault handling, and (3) There are three important technical differences: optimality and constraints.

  First, in large networks with distributed algorithms, it is becoming increasingly difficult to accurately predict the path a flow takes through the network, especially during times of network stress (such as multiple functional failures). In the centralized route calculation environment, a restoration line is prepared in advance and can be simulated and modeled in advance. This has become particularly important for mission critical services including strict SLA. Centralized provisioning provides operators with two main benefits: (1) accurate knowledge of the path taken by individual customer traffic, and (2) accurate and efficient allocation of network resources. Based on this technology, carriers can (1) provide and deliver accurate SLA, (2) reduce operational costs while achieving higher availability, and (3) small businesses. Several important goals can be achieved, such as advantageously expanding their target market to include: These goals are achieved by two functions inherent to Carrier Ethernet in the packet switching world: (1) Carrier Class OAM & P (including 50 millisecond (ms) failover) and (2) External Control Plane Can be achieved by fine-tuned automated traffic engineering.

  In addition, in distributed algorithms such as Open Show Test Path First (OSPF), faults in the network are handled “locally” (ie, a node uses an existing path computation algorithm to route new paths around a particular fault. calculate). In a centralized implementation like the PNC 402, the control plane calculates a first path and a redundant backup path that will be used if any element in the first path fails. The backup path must be fully redundant because it is not possible to know in advance which element will fail. A sufficiently redundant path may not be the optimal path for any particular failure. At the same time, locally calculated and distributed failure paths may not be optimal for the network as a whole (such as when moving a large amount of traffic over an already congested link). Recovery in a centralized implementation is instantaneous, whereas in a distributed implementation, the recovery time varies with the convergence time and stability of various protocols.

  Distributed algorithms such as OSPF rely on the optimality properties used by dynamic programming algorithms for their efficiency and operation. Optimality characteristics arise from the ability to decompose the original problem into subordinate problems and the optimal solution to the subordinate problems leading to the optimal solution to the original problem. However, by adding constraints (bandwidth, delay, jitter, etc.) to the problem, the situation changes and the optimality principle leading to an effective distributed algorithm is no longer valid. In general, the constrained shortest path problem is a non-deterministic polynomial time (NP) complete problem, but in reality, it is possible to obtain a polynomial-like behavior from algorithms present in actual network applications. Thus, in the case of constrained route computations as expected in new applications, existing distributed algorithms will not work without the addition of considerable complexity and global network knowledge, resulting in more centralization. That approach is preferred.

  Optimizing the entire network (ie routing all flows in the network at the same time) is likely to be costly due to the complexity of constrained routing, and operators can choose to I don't want to make it unstable like this, so it's likely that it has little value. PCM 405 performs local optimization by periodically identifying “misrouted” flows. A misrouted flow is a flow that has a current path that differs significantly in terms of “cost” from the unconstrained minimum cost path. The PCM 405 attempts to find other flows in range that can be preempted (ie rerouted) with minimal incremental cost that would result in a misrouted path. A “misrouted” path function can also be used to determine which path should be moved to a new part of the device added to the network. By moving only “misrouted” routes, the amount of churn entering the network is minimized. Calculate the optimal path for all flows, identify flows that use the new device, reroute misrouted flows in the set, and use the new device. This is likely to free up capacity in other parts of the network and reroute other misrouted flows. The process continues in this way until no new misrouted flows are rerouted.

  A PNC database 407 showing the status of individual network elements, including associated utilization and performance statistics, allows the PNC 402 to proactively plan usage for network planning over time. The PNC 402 also knows which elements and routes are approaching constraints and are responsible for misrouted routes as an additional component of the network planning process. Also, tracking the percentage and number of “misrouted” paths over time provides additional insight into network planning issues. PNC 402 also supports a “what if” mode that allows network planners to see the effect of adding, changing, or subtracting network capacity. They can also model the effects of network failures as well as “pre-planned” maintenance events.

  The PNC 402 enables a carrier to use the new carrier Ethernet technology to support all of the carrier's business applications ranging from E-Line to E-LAN services, thereby creating a real-world carrier network. PBB-TE can be introduced. PBB-TE allows service providers to design their network traffic by assigning tunnel routes to individual service instances. In addition, PNC 402 uses PBB-TE to allow providers to add new carrier Ethernet devices to network 400 without the interoperability burdens that exist within integrated data / control plane solutions as in the prior art. Can be introduced. Carriers can make service-specific QoS and bandwidth reservations to ensure SLA compliance for the transport network. The use of Ethernet technology allows the construction of backup protection tunnels and leverages the Carrier Ethernet QA & M standard to provide <50 ms failover time consistent with benchmarks set by existing SONET / SDH networks .

  The PBB-TE E-LAN service offers several advantages. First, a traffic handoff exists at Layer 2 with traffic ingress and egress from both the access domain and the provider domain via the Ethernet switch. Thus, existing Ethernet deployments show a severe service SLA without rebuilding the network. Next, the PBB-TE E-LAN service provides a connection-oriented circuit plan via a shared infrastructure at a significantly lower cost than conventional routers used for VPN service configuration. Further, the PNC 402 eliminates the need for additional protocol complexity and user configuration errors. Further, the absence of discovery and signaling protocols eliminates scaling limits that may have been enforced by protocol control. Finally, a centralized scheme allows for more robust security that can be applied to a single configuration point. The PNC 402 is flexible enough to be integrated with any external server to retrieve E-LAN membership information.

  The real value lies in having an independent level 2 infrastructure that can create “routes” associated with the main traffic patterns and that can manage how the physical infrastructure is used. By separating the control plane from the data plane, service provision is decoupled from the basic network technology, allowing operators to develop heterogeneous networks and develop their networks and service proposals separately. Will be able to. However, simply calculating the path is not sufficient. Effective and efficient provisioning of services and resources is required.

  The purpose of the service management framework is to build a link between service experiences provided by service providers and the resources that support those experiences. In the early days of data networking (data services were sold to businesses for tens of thousands of dollars per month), service-resource links were created through manual provisioning. The main cause of service outages in today's networks is management mistakes. Carriers may still have to rely on manual provisioning, but as a general practice, even with the complexity of today's routing and switching elements, broadband and data service subscribers Manual processing is less favored due to a decline in average per capita sales (ARPU).

  Instead, management uses the form of process automation to create and maintain service-network links. To make this efficient, service connectivity and performance goals must be automatically changed to resource commitment. This means that an abstract form of service as a series of operations is transformed into a provisioned series of resource commitments. Element / device management systems, network management systems, and policy management systems are all useful for the provisioning part of this process, but less useful for the conversion from abstraction to provisioning. However, a separate control plane such as PNC allows such services to be performed safely and reliably without putting the network at risk. For operators, enabling customer programmability and customization provides new revenue streams and service differentiation while reducing these operating costs.

  Some of the building blocks used to configure the solution are similar to the virtual private LAN service (VPLS) currently installed in MPLS networks. The main differences are: (1) the use of PBB-TE trunks and service instances (I-SID) as an alternative to LSP tunnels and pseudowires, respectively (2) discovery and signaling mechanisms (border gateway protocol (BGP), label distribution) (3) the concept of EVSI in a PE switch as a substitute for a virtual switch instance residing in a PE router. Thus, the three building blocks for E-LAN services over PBB-TE are: (1) an external network controller in the PNC, (2) a full mesh PBB-TE trunk in the core, and (3) per E-LAN instance. EVSI.

  FIG. 5 is a network diagram illustrating an exemplary E-LAN service deployment 500 utilizing an exemplary embodiment PNC 502 according to the present invention. PNC 502 facilitates discovery and signaling along with QoS and policy-based path provisioning for PBB-TE trunks. Discovery relates to PEs that discover other PE members of a particular E-LAN instance 530, 540. The signaling aspect addresses provisioning full mesh PBB-TE trunks between PEs. By associating the connection line AC with a particular E-LAN instance 530, 540, membership to the particular E-LAN service instance 530, 540 is displayed at the PNC 502. The PNC 502 maintains a repository 550 of mappings of E-LAN instances 530, 540 to PE switches, along with the port (AC) associated with the highly utilized data store. PNC 502 also provides a mapping between E-LAN service instances 530, 540 and AC to all PE nodes in PBB network 510. Based on the represented mapping, PNC 502 calculates a path that satisfies the QoS and user policy constraints required for the service and provides a PBB-TE trunk between PEs.

  FIG. 6 is a flow diagram 600 illustrating path computation by an exemplary PCM in an exemplary embodiment PNC according to the present invention. PCM performs algorithm calculations using a modification of Dijkstra's shortest path algorithm. This calculation limits the node under consideration to the subset that moves most efficiently towards the destination, so that only in a practical and practical sense can only be extended by extending the best known path at once. It will be efficient. The route calculation begins by specifying a service instance (605) and specifying a source and destination location (610). For each type of service, the PCM determines the constraints and parameters required for the function and state of the individual parts of the devices in the network, as stored in the service and database 617 (615). The PCM then proceeds to find a “least cost” path in the network that satisfies the constraints associated with the service instance (620). Thereafter, the process ends (625).

  The cost function minimized by PCM may be a function of many variables that change from situation to situation. In a simple example, the cost function may simply be a hop count, or in a delay sensitive application, the cost function may be a link latency or physical length. In more complex examples, PCM can support various heuristics in its computation. For example, various functions for link utilization can serve as heuristics for performance metrics such as delay, jitter, packet loss, flow balance, etc., and these functions can be incorporated into cost or constraint functions . Heuristics can be applied to simulate some network behavior (eg, giving priority to fast links by using a low cost function as a function of link speed). Similarly, other network operations can be realized by using a cost function that is a weighted sum of various factors (latency, packet loss, hop count, jitter, flow balance, link utilization, etc.) .

  PCM also supports heuristics for tie-breaking schemes and for evaluating lower than the optimal alternative to the optimal path and for determining the choice of redundant paths. For example, PCM also calculates a sufficiently redundant path (ie, a path that does not have a node or link in common with the first path), except for certain endpoints that use the boundary algorithm. If there is not a sufficiently redundant path, the PCM proposes an alternative that emphasizes the common elements including the first path. PCM uses a tie-break rule to select a route when there are multiple routes with equal cost results. Tiebreak rules can be configured by the user. Because link utilization is a major determinant of delay, jitter, and load balance, the default tiebreak rule can minimize link utilization across the path. Optionally, the PCM can be configured to perform less than optimal paths that appear to have performed better in other metrics (such as flow balance).

  The user may also want to override the cost function for a link and insert a specific value to achieve a certain action. The user can specify the overbooking factor used for route calculation. The overbooking factor is the ratio of the amount of traffic routed through the network link to the nominal capacity of the link. For the “guaranteed bandwidth” calculation, the overbooking factor is 1.0. Using an overbooking factor greater than 1.0 (such as 2 or 3) will take into account the statistical and time-varying nature of the traffic flow, resulting in better overall network utilization. I will provide a. The overbooking factor may be the network scale specified for each link or for each type of link (such as core-to-access).

  NGN, in contrast to the older technology implementations of today's networks, requires a comprehensive effort to link the business systems that operate the services to the network elements that provide the services. PNC provides a clean abstraction of network elements to the NGN software framework across different technologies, different vendors and different networks. In general, flows are routed continuously in the network (ie, routed in the order in which the services are ordered). In an unconstrained network, individual flows can be used throughout the network, and this is also the optimal routing because each flow selects the optimal route. In a constrained routing network, the order in which flows are added can change significantly and is inferior to an optimal routing plan overall.

  One of the unique functions of PNC is the ability to apply complex network policies to the route calculation process. Various types of network policies are supported. Rules that define constraints on routed service instances can inform the PCM what types of network devices are allowed and / or required or even prohibited. An example is lawful intercept, in which case the route may need to cross a lawful intercept point somewhere in the network.

  Another example is politically sensitive traffic, in which case it is required not to traverse a certain terrain or some network device. This scenario is addressed by removing these nodes and links from the network topography and running a path computation algorithm. The network device database allows the PCM to adapt network elements taking these rules into account. The rules dynamically correspond to a suitable encapsulation method that follows the routing process, eg the route of the path. Rules can also be used to force undesired desired network behavior in many real networks (eg, from the access node to the core node towards another set of access nodes back to the core and there. To the desired destination access node).

  An example of lawful intercept is further detailed. The optimal algorithm is to calculate the shortest path from the source to all lawful intercept points in the network, to calculate the shortest path from each lawful intercept point to the destination, and the sum of the costs of the two sub-routes Select the path through the lowest lawful intercept point. Although optimal, this algorithm is not always efficient because it finds routes to all intercept points in the network, even though many of the routes are likely not involved in the solution. The ability to address requirements such as lawful intercept can be extended out of order to multiple types of such requirements using a more efficient approach, such as PCM's multi-layer route computation capability.

  FIG. 7 is a state diagram illustrating a path layer state 700 when a flow is routed through the network 710 to maintain consistency with a network policy. In multi-layer path computation, the network topology consists of several layers 720 (such as wavelength division multiplexing (WDM), optical transport network (OTN), SDH and Ethernet), and nodes (NE) and links 705 in the network 710. Can appear in several layers 720. When performing integrated layer 0-2 path computations, as well as dealing with constraints in the network such as different adaptation or multiplexing schemes in the physical layer, different encapsulations in the logical layer, and the physics of the basic forwarding function This situation occurs when enforcing network policy rules, such as those related to genetic diversity. Such restrictions may arise when a carrier purchases physical devices (such as network equipment (NE)) from different vendors (such as vendors A, B, and C). These vendors can supply a single piece of vendor-specific software to support network management. These subsystems need to be integrated into larger units to provide end-to-end services. Furthermore, as the path crosses individual layers, the PNC needs to properly adjust the failover time constant to take into account the repair protocol of the individual layers.

  In addition to basic path computation in a multilayer network, the PCM computes edge and node disjoint redundant paths in the multilayer network 710 using a dedicated algorithm. Multi-layer path computation also allows for a direct representation of shared function constraints in a basic transport network. This feature can be enabled for all or part of the network, and service providers provide this level of protection for the most important parts of the network without having to worry about all of the basic transport plans It can be so.

  An example of multiple constraints of this type may arise when tail circuits are routed. In many cases, the required path is not for a specific node, but rather a specific (such as a broadband remote access server (BRAS), a session border controller (SBC), a multi-service access node, a service provider interface point, etc.) For every node that has a function. In some cases, if the rest of the route from such a node has already been established, the route can end at that point. In tail circuit routing, the PCM determines a route using a multi-layer route calculation algorithm as described above. In more complex examples, there may be multiple types of nodes that must be traversed, requiring a more complex but similar multilayer routing approach. For tail line routing issues (such as routing to BRAS), the PCM can create a redundant path to the BRAS or another redundant path to the BRAS if the network policy mandates. In the former case, the PNC dynamic control plane detects a BRAS failure or a trunk behind the BRAS and reroutes all of the paths that terminate at that BRAS.

  FIG. 8 is a flow diagram 800 illustrating classes of network policies that occur for network failure and recovery in an exemplary embodiment PNC according to the present invention. When a failure is detected (801), the network device switches to a backup redundant path (805). The PNC typically waits 807 for some time before taking any action, because some basic transport networks automatically recover from some failures. Further actions depend on the network policy (810). After the end of the time, the PNC can leave the path as it is (815). Alternatively, the PNC can switch between the role of the first route and the role of the backup route (820). Alternatively, the PNC can calculate a new backup path based on the new network topology reflecting the failure (825), or calculate a new first path and backup path (830). Next, the PNC determines whether the fault has been repaired (835). If not repaired, the PNC continues to monitor the network (837). When the fault is repaired (838), the set of options 840 leaves the path as it is (845), switches the role of the path (850), calculates a new backup path (855), or creates a new first path and Similar to the above options, such as calculating the backup path (860). When processing a constrained route calculation, a new service routed between the failure time and the repair time may consume resources used by the original route set, so the policy choice here is Especially important. Thereafter, the process ends (865).

  FIG. 9 is a network diagram illustrating a network 900 including an exemplary embodiment PNC 902 according to the present invention that supports network maintenance operations and events, and associated network link conditions. “Bridge and Roll” is a good example of an operation that the PNC 902 can easily perform, which allows customers to seamlessly introduce new hardware or services into an existing network or to perform routine maintenance automatically. Like that. In this example network policy, the PNC 902, which maintains the mapping between services, forwarding (trunks, LSPs), nodes and links, moves all traffic safely from a particular piece of network equipment during a maintenance event. , Allowing customers to request removal of a node from an active service without interrupting service.

  In network 900, a bi-directional first trunk 930 via node 1, node 2 and node 3 carries data between source 910 and destination 920. There is also a backup trunk 940 between the source 910 and the destination 920 via node 1, node 4 and node 3. Keepalive messages are sent on both the first trunk and the backup trunk (eg, at a rate of 10 ms). If source 910 fails to receive a response from a node (such as node 2) within a particular failover window (such as 30 milliseconds), source 910 fails over to backup trunk 940. The node (such as node 2) is then removed from service by the PNC 902, after which the PNC 902 notifies all affected services. For each affected service, PNC 902 recalculates a new trunk and maps the service over the available network. For example, the source must then create a new backup, the third trunk 950. In this case, the third trunk 950 goes through node 1, node 5 and node 3. If the customer is ready to make a declaration to activate the switch again, the node can be disabled. The PNC 902 detects a new switch in the network and recalculates all existing tunnels. Similar to the description above, the network policy then determines how to process the flow when a portion of the network device returns to service.

  By emulating a communication tunnel in the network, the PNC 902 can be used for service migration. In practice, the third trunk 950 can be configured with a network link other than layer 2 with the PNC 902 emulating connectivity using different technologies. For example, the third trunk 950 can be configured via the layer 0/1 ring network 960. However, when configuring the third trunk 950, the PNC 902 makes this layer change seamless to the service so that it appears as a layer 2 link. In addition, the third trunk 950 has a repair time that is longer than the repair time of the basic network it uses to avoid collision of protection mechanisms.

  The PNC 902 also needs to resolve multi-layer latency constraints. For example, when changing channels in an IPTV service, a short waiting time is required so that there is only a short time between the remote command and the channel being changed. In this example, source 910 and destination 920 are confident that the layer 2 Ethernet service connects source 910 and destination 920. However, in reality, an optical ring network is used for the third trunk 950. Therefore, by providing a service (layer 0/1) that is superior to the expected (layer 2), service restrictions are eliminated by using the multi-network layer.

  PNC 902 also allows for repair of connections in the event of a failure. An example embodiment PNC 902 according to the present invention detects a failure and allocates a new connection based on stored information about the connection that causes the failure. This information can relate to the importance associated with the service (such as economic or social importance). For example, an emergency service is represented by traffic like all other services, but is very important and is therefore assigned a repair emergency value when a service is requested. However, this type of data can carry important information such as emergency alert SMS messages, so repair emergency based only on speculative assumptions based on technology (ie voice, video, short message service (SMS)). A value cannot be assigned. There must be a context-based prioritization (eg, based on destination / source address, etc.). The software control plane then emulates the connection of the tunnel by directly configuring the network device at the newly formed tunnel contact.

  The network abstraction provided by PNC provides device and addressing virtualization that expands the range of potential and valuable new services in much the same way that network control points extend the range of services in voice telephone networks. enable. Network addresses no longer need to have any physical or geographical significance, and the mapping from virtual addresses to physical addresses may be a function of time, location, load, etc. From an operational point of view, this network abstraction allows complex device-specific procedures (such as “bridge and roll” operations) to be selected and the entire operation can be performed safely and predictably with a single command. To do.

  The PNC can configure forwarding with various protection options (link and node disjoint, shared risk link group (SRLG), etc.) to protect against major failure events. PNC monitoring enables intelligent failure reporting and recovery, in which case services on the network are dynamically moved. Furthermore, the PNC enables service “repair” in the case of correlated failures that affect both the first path and the backup path. This feature eliminates the need for operator intervention and reduces the mean repair time (MTTR) of the service. The normal first path and backup path recover when the fault is repaired. In addition, the transfer and service creation process is automated, which greatly simplifies the provisioning of new services and allows network devices to occupy on / off lines. This limits manual configuration and thus reduces configuration errors which are one of the main causes of service interruption.

  However, for business customers, E-LAN services need to provide more than just inter-site connectivity. QoS attributes such as service attributes defined for user traffic (frames, packets, etc.) form the basis of the SLA specification. Use service performance and bandwidth profiles (such as frame latency, delay variation (jitter) and loss rate) as in the MEF service framework described in Technical Specification MEF 10.1 Ethernet Service Attributes Phase 2. The purpose of the Ethernet service.

  Table 1a lists various factors that affect service performance. Frame latency (frame delay) means the time required for a service frame to pass across the network. This is measured from the arrival of the first bit at the ingress user network interface (UNI) to the output of the last bit at the egress UNI. Similarly, some SLA measures round trip delay. Frame delay variation (jitter) is the difference in time gap between two subsequent frames at the ingress UNI compared to the delay measured between arrivals of similar frames at the egress UNI. This delay is an important factor in the transmission of unbuffered video, and variations occurring in the millisecond range can affect the quality of service. The frame loss rate is a measurement of the number of lost service frames inside the provider network. Frame loss is measured in the ratio of the number of lost frames measured at the transfer exit divided by the number of transmitted frames measured at the transfer entrance.

  Table 1b describes the building blocks for end-to-end QoS delivery. Ethernet-based forwarding aggregation services that were traditionally delivered using separate networks require consideration of the need for QoS for each service so that providers are not forced to build too many networks. . The main building blocks for this efficient end-to-end QoS guarantee are (1) connection-oriented forwarding, (2) route calculation based on constraints, (3) capacity planning with effective admission control, and (4) providers. This is traffic processing for each hop in the network.

  The connection-oriented transfer performed by the carrier Ethernet switch and the service aggregate edge device refers to a preset transfer through the provider network that enables the PBB-TE to transmit service traffic through the carrier network. means. Predictability also helps deliver at the optimal cost point of QoS guarantees that satisfy the service SLA. Route calculation based on constraints performed by PNC means a process that leads to an appropriate combination of network nodes and links, and this combination satisfies the bandwidth, quality and carrier policy constraints. Form a transfer together. The connection admission control performed by the PNC refers to the process of efficiently allocating available bandwidth resources across service traffic classified into classes in compliance with agreed service contracts. The hop-by-hop traffic processing performed by the carrier Ethernet switch and the service aggregate device means that the service traffic passing through the statistically multiplexed network is differentiated appropriately by the agreed service contract. Means that “conditioning” is required in various parts of

  Table 2 shows various bandwidth profiles (ie, the rate at which user traffic (frames, packets, etc.) can pass through the UNI (at the admission point)). Bandwidth profiles form the basis for service proposals and pricing. The bandwidth profile is expressed in terms of commit information rate (CIR) and excess information rate (EIR). CIR is the average rate at which a subscriber can transfer service frames. Such transfers are affected by the commit burst size (CBS), which is the maximum size that can transmit service frames and still be CIR conformant. The EIR is the maximum rate that is faster or the same average rate as the CIR and is allowed to allow service frames to enter the provider's network. Similarly, EIR is affected by excess burst rate (EBR), which is the maximum size configured as an EIR conformant.

  User traffic is classified and marked (colored) at the entrance to comply with CIR and EIR. Traffic that is a CIR conformant is colored green and allowed to enter. Traffic that is CIR non-conformant but EIR conformant is colored yellow and allowed to enter, but is marked for best effort delivery and may therefore fall off at congestion points in the network. Traffic that is neither CIR nor EIR conformant is colored red and drops off at the edge.

  Table 3a shows an exemplary SLA obtained from a major provider that enables customers to obtain Layer 2 point-to-multipoint Ethernet connections to six sites at a cost of $ 48,000 per month. . For each SLA, bandwidth from 1 Mbps to 8 Mbps can be purchased in increments of 1 Mbps, and bandwidth above 8 Mbps can be purchased in increments of 5 Mbps. This service also supports unicast, multicast and broadcast packets, which are only allowed up to 15% of the total bandwidth.

  The PNC breaks down the SLA into service and forwarding configurations as shown in Table 3b. The service configuration recognizes the type of service and triggers the creation of a PBB-TE trunk to create a full mesh transfer through the PE switch. The PNC builds a PBB-TE trunk through a QoS constrained PE, such as frame delay = 100 ms, jitter = 5 ms, and frame loss is less than 0.05%. A network controller built on the Ethernet softswitch model uses the switch shaping and policing functions efficiently to “smooth” the traffic flow that affects the arrival distribution, thus reducing queuing contention and congestion in the network. Avoid hot spots.

  Tables 4a and 4b show two types of bandwidth constraint models that PNC supports to manage bandwidth contention across different classes of traffic according to the SLA of Table 3a: (1) Russian Doll (RDM) and its reservation Deformation and (2) Maximum Allocation Type (MAM). However, for a given domain, one bandwidth constraint model (ie RDM or MAM) is used for connection admission control.

  Table 4a shows exemplary traffic classes and bandwidth targets allocated to individual classes. There are four class types: (1) real time (RT), (2) priority data (PD), business data (BD), and (4) basic data (BSD). RT has a class bandwidth target of less than or equal to 300 megabytes per second (Mbps). The PD has a class bandwidth target that is less than or equal to 200 Mbps. The BD has a class bandwidth target that is less than or equal to 300 Mbps. BSD has a class bandwidth target that is less than or equal to 200 Mbps.

  Table 4b shows an exemplary RDM and MAM assignment for an exemplary SLA. The aggregated reservable bandwidth on the link is “sliced” into a number of bandwidth constraints (BC), and the individual classes are “allocated” bandwidth based on the following mechanism: In MAM, individual class types are associated with maximum bandwidth and are assigned to each class independently. Since the bandwidth “slice” is constant for each class type, unused bandwidth cannot be shared among class type traffic. Thus, in some deployment scenarios, the MAM model cannot achieve high link utilization. RDM assumes a hierarchy between classes, and constraints are applied in a nested manner. The best class type is assigned the maximum bandwidth. The next maximum bandwidth is defined for both the two highest class types, the next bandwidth is defined for the three highest class types, and so on. In general, this model results in very high link utilization and allows absolute priority with respect to the class type of traffic selected. This allows for better control to satisfy the SLA guarantee.

  The PNC calculates an optimized path based on a plurality of QoS and bandwidth constraints for each class. This is integrated with connection admission control schemes (ie RDM and MAM) to enable service differentiation and thus limit network usage on a class-by-class basis. The PNC pushes the NE specific configuration to the PE and performs traffic classification and conditioning (meters, shapes, drops, marks) at the edge. In addition, all NEs that follow the trunk path are set up to achieve hop-by-hop processing for domain-consistent and SLA-compliant service traffic.

  PNC maintains an abstract representation of the provider network in the form of a topology graph. PNC models nodes and links with an accurate representation of characteristics such as bandwidth, delay, and jitter overhead, which provide data points to the route computation engine and route based on the constraints needed between trunk endpoints. Is realized. In a simplified example, for a route that does not have an associated protection attribute, a topology subgraph is formed by removing nodes and links that do not satisfy the user-specified constraints, and a constrained shortest route calculation (CSPF) algorithm on this topology subgraph. To calculate the path between forwarding endpoints. When selecting multiple attractive routes, the weighted metric of the aggregated link acts as a tie breaker.

  Table 5 shows the PNC support protection and repair scheme. The protection attribute adds resiliency to the forward carrying service traffic, and the criticality of the service traffic activates the selected option. A standby (backup) is set up to protect traffic loss in the working (first) path due to network outages. To protect against “correlated” failures in the network, additional attributes such as links and node disjoints for working and standby paths can be required. The link disjoint property ensures that the first transfer is protected with a backup transfer that does not pass through any of the links used for the first transfer, and thus protects against link failure. The node disjoint property ensures that the first transfer is protected with a backup transfer that does not pass through any of the nodes on the first path, and thus protects against node and link failures.

  The first concept is a method of dynamically emulating a communication tunnel that can be configured in a network. According to this method, a plurality of communication tunnels are allocated. Each tunnel has multiple hardware endpoints and may be a different type of communication protocol (such as MPLS or PBT). The entire end-to-end tunnel is composed of a plurality of tunnels. Multiple tunnels are connected by directly programming the hardware endpoint of each individual tunnel to form an overall tunnel. Hardware endpoints can include switches and routers, and programming the endpoints can include disabling the normal routing behavior of the hardware endpoints. Also, hardware endpoints can be programmed with instructions from business plane modules residing on the network.

  An example of a VPN is shown in FIG. In this example, an enterprise needs to set up a VoIP connection between its headquarters in the United States (US) and a branch office in Fiji. In this scenario, it is assumed that the optimal (ie, cheapest) route between the US Internet Service Provider (ISP) and the Fiji ISP is through the MPLS network of the Russian ISP. However, US ISPs and Fiji ISPs use PBT networks.

  To establish a VoIP connection, the US ISP has three tunnels: a tunnel T1 from the US headquarters to the Russian ISP network, a tunnel T2 via the Russian ISP network, and a Russian ISP network to the Fiji branch office. It is necessary to obtain the tunnel T3. Next, the three tunnels need to be “glued” together to form a VPN for VoIP connection. However, since there is no interoperability between MPLS and PBT, these tunnels cannot be connected.

  This method allows the connection of these tunnels by directly programming the network devices present at the contacts between the individual tunnels. FIG. 11 shows the contacts between the US ISP and the Russian ISP. Each network includes a part of a network device such as a switch or a router. In order to emulate the connection of each tunnel of devices, it is necessary to program some of the individual devices to correctly handle packets traveling through the tunnel. In order to achieve this, it is necessary to disable the normal routing operation of the switch / router.

  FIG. 12 shows a high level overview of controlling the method via the ISP. This method directly programs network devices through a software control plane that resides in each of the ISP networks. The software control plane receives a request to connect the US headquarters to a Fiji branch office. The software control plane then examines the network in terms of the desired connection and determines which network device needs to be configured to make the connection. Based on this decision, the software control plane selects the network technology (such as MPLS or PBT) to use for the relevant part of the network, and if a compatible protocol is not available, the packet traveling through the tunnel Configure each relevant part of the network device directly to handle correctly.

  FIG. 13 is a more detailed view of the software control plane. ISPs can communicate policies with each other via the business plane, which controls the respective software control planes of the individual ISPs, and which network equipment is required by the software control plane according to these network policies. Configure directly.

  This method can be used to emulate a tunnel configuration within a single ISP as shown in FIG. In this situation, the software control plane can configure network devices that reside on a single ISP to connect tunnels that use different basic communication protocols.

  Furthermore, the software control plane can emulate the connection of tunnels with different topologies as shown in FIG. MPLS does not allow connection of tunnels with different topologies. For example, MPLS conventionally does not allow a point-to-point tunnel A → B to connect to a multicast tree B → C. However, in this method, it is possible to emulate such a tunnel connection by directly configuring the network device at the contacts of various tunnel topologies. Referring to FIG. 15, A → B is a point-to-point tunnel, and B → C is a multicast tree. An exemplary embodiment of this method is to directly configure a network device at B to process packets received from the A → B tunnel to be transmitted via the B → C multicast tree, thereby allowing A → Emulate the connection between B and B → C. The software control plane can also emulate other tunnel connections such as multipoint-to-point and multipoint-to-multipoint.

  The second concept is a method for repairing a communication tunnel in a network, such as the network of the first concept. At present, there are other network optimization methods, but these cannot perform a quick repair of the service. MPLS does not optimize and does not note the reason for setting up a particular network (such as the lowest cost bandwidth available), but rather knows only the order of connections that have been set up. Furthermore, these methods for optimization do not know how the repair is done.

  According to this method, information about a plurality of existing communication tunnels in the network is stored. If one of the existing tunnels fails, a new communication tunnel is assigned based on the information stored about the original tunnel. It then connects the new tunnel by directly programming the new tunnel's hardware endpoint to restore the functionality of the original tunnel configuration. Also, new tunnels can be connected so that bandwidth costs are optimized.

  FIG. 16 shows a communication network as in FIG. 10 but includes VoIP connections rerouted through a French ISP. In this scenario, the tunnel through the Russian ISP fails. In an exemplary embodiment of the method, upon detection of such a failure, the software control plane reroutes traffic through different ISP networks, regardless of the network communication protocol type, according to the protocol's traffic engineering rules. Can do.

  Referring to FIG. 16, the software control plane stores information about existing connections, such as VoIP connections between a company's US headquarters and its Fiji branch office. At some point, a Russian ISP that has failed the tunnel will fail. An exemplary embodiment of the method detects a failure through a French ISP and assigns a new tunnel based on stored information about the VoIP connection. The software control plane then emulates the tunnel connection by directly configuring the network device at the newly formed tunnel contacts.

  The third concept is a method for emulating a communication tunnel in a network. According to this method, a communication tunnel having a first basic communication protocol and a plurality of hardware endpoints is assigned. The tunnel is then connected to another communication tunnel having a basic communication protocol different from the first protocol by directly programming the hardware endpoint of the communication tunnel.

  According to the method of the third concept, the software control plane of the first concept can be used for service transition. Referring to FIG. 17, an existing MPLS connection can be easily and quickly converted to a PBT connection by directly programming network devices associated with different connections. The first concept of tunnel abstraction allows separation of the desired connection between the point ("what") and the network protocol to use ("how"), i.e. for connection to the software control plane The request is interested in which connections are desirable, and the software control plane is interested in how to configure the network devices available to make these connections.

  The fourth concept is a method for auditing network hardware resources in a network. According to this method, information related to the configuration of a plurality of communication tunnels is stored. For each communication tunnel, the associated resources used by the tunnel are identified. The method then retrieves information about the configuration state of the resource from the identified resource. The method then identifies any discrepancies between the stored information and the retrieved information. If a mismatch exists, the method then resolves the mismatch by allocating new resources or deallocating existing resources.

  At present, there is no central source responsible for resource allocation. Many individual system administrators manually add resources to the associated connection and manually remove resources from the associated connection, typically using only spreadsheets to keep track of resources. The first concept of tunnel abstraction allows accurate calculation of these resources.

  The fourth concept method provides a model of an assigned network device that is used in establishing an emulated tunnel connection. This method keeps track of who resources have been allocated and how these resources are being used. In the case of a network failure, the method can determine which network device should be assigned for communication and which network device is actually assigned.

  To determine which network device to assign, the software control plane stores a high level list of devices and how they are using it to make existing connections. To determine which network device is actually assigned, the software control plane polls the network device for whether the device thinks it should be assigned. The method then compares the stored list with information retrieved from the device and flags any inconsistencies. This discrepancy can include some of the network devices that are scheduled to be assigned but not assigned, or some of the devices that are assigned but no longer in use. If any mismatch exists, the software control plane can allocate additional resources when there are no resources, and can deallocate extra resources when no more resources are needed.

  Although the invention has been particularly shown and described with reference to exemplary embodiments thereof, those skilled in the art will recognize that the invention is in the form of a invention without departing from the scope of the invention as encompassed by the appended claims. It will be understood that various changes in detail can be made.

100c NGN architecture; 130 service / application domain;
140 control domain; 150 forwarding domain; 160 access domain;
170 CPE domain; 402 Provider Network Controller (PNC);
405 Route Calculation Module (PCM); 407 Database.

Claims (56)

A method for controlling a service in a communication network, the method comprising:
Storing information on hardware endpoints and communication connections in the communication network, traffic engineering rules and network policies controlling the communication network;
Defining a service to be performed on the communication network;
Calculating a communication path based on the stored information to implement the defined service;
Programming a hardware endpoint according to the calculated communication path to set a communication path in the communication network;
Monitoring programmed hardware endpoints and communication connections according to the calculated communication path and updating the stored information;
Recalculate the communication path, reprogram the hardware endpoints that follow the recalculated communication path, adapt the communication path based on the stored information and service changes, and ensure the implementation of the service Steps,
A method comprising the steps of: The communication network is a multi-layer, multi-service, multi-vendor, or multi-carrier communication network.
The method according to claim 1. The path includes a tunnel;
The method according to claim 1. The hardware endpoint includes a switch and a router,
The method according to claim 1. The information regarding hardware endpoints and communication connections in the communication network includes capacity, utilization rate and performance index,
The method according to claim 1. The service is defined by attributes, and the method includes:
Storing attributes defining the service implemented on the network;
Calculating a communication path based on the attribute to implement the defined service;
The method of claim 1 further comprising: The attributes defining the service include service performance including frame latency, delay variation and loss rate, and bandwidth profile.
The method according to claim 6. Recalculate the communication path and reprogram hardware endpoints that follow the recalculated communication path to adapt the communication path based on changes in the attributes of the defined service and ensure the implementation of the service Further comprising steps,
The method according to claim 6. Computing the communication path further comprises optimizing hardware points and communication connections in the communication network based on quality of service and bandwidth constraints per class;
The method according to claim 1. The step of calculating a communication path includes the step of calculating a sufficiently redundant backup communication path from the calculated communication path.
The method according to claim 1. Programming a hardware endpoint that follows the calculated communication path includes disabling normal operation of the hardware endpoint;
The method according to claim 1. Monitoring programmed hardware endpoints and communication connections according to the calculated communication path further comprises monitoring for network failure, overload or path optimization.
The method according to claim 1. Recalculating the communication path and reprogramming a hardware endpoint according to the recalculated communication path, if at least one of the communication connections in the calculated communication path fails, in the communication network Repair the communication path,
The method according to claim 1. The communication connection has a basic communication protocol, and the method uses a communication connection in the communication network having a basic communication protocol different from the basic communication protocol of the communication path; Further emulating the basic communication protocol of the calculated communication path;
The method according to claim 1. Recalculating the communication path and reprogramming hardware endpoints that follow the recalculated communication path optimize the communication path of individual services in the communication network based on the stored information;
The method according to claim 1. Recalculating the communication path includes dynamically adjusting an associated repair time constant of the communication path based on a respective repair time constant of a communication connection of the recalculated communication path;
The method according to claim 1. Recalculating the communication path includes recalculating based on an economic or social value associated with the communication path;
The method according to claim 1. Further comprising transferring service from the calculated route to the recalculated route;
The method according to claim 1. Transferring service from the calculated path to the recalculated path enables maintenance of hardware endpoints and communication connections in the communication network without interrupting the service;
The method according to claim 18, wherein: In a communication network, a software control plane network controller configured to control services defined to be implemented on the communication network,
A database configured to store information regarding hardware points and communication connections in the communication network, traffic engineering rules and network policies controlling the communication network;
In order to implement the defined service, calculate a communication path based on the stored information, program a hardware endpoint according to the calculated communication path, set a communication path in the communication network, and Monitor the programmed hardware endpoint and communication connection according to the calculated communication path and update the stored information, recalculate the communication path and reprogram the hardware endpoint according to the recalculated communication path; A path calculation module configured to adapt the communication path based on the stored information and service changes and to ensure the implementation of the service;
A software control plane network controller comprising: The communication network is a multi-layer, multi-service, multi-vendor, or multi-carrier communication network.
The network controller according to claim 20. The path includes a tunnel;
The network controller according to claim 20. The hardware endpoint includes a switch and a router,
The network controller according to claim 20. The information regarding hardware endpoints and communication connections in the communication network includes capacity, utilization rate and performance index,
The network controller according to claim 20. The path calculation module is further configured to calculate a communication path based on attributes stored in a database defining the service implemented on the network;
The network controller according to claim 20. The attributes that define the service include service performance including frame latency, delay variation and loss rate, and bandwidth profile.
26. The network controller according to claim 25. The path calculation module calculates a communication path and reprograms a hardware endpoint according to the recalculated communication path to adapt the communication path based on a change in the attribute of the defined service, Further configured to ensure the implementation of
26. The network controller according to claim 25. The path calculation module is further configured to optimize hardware endpoints and communication connections in the communication network based on quality of service and bandwidth constraints per class;
The network controller according to claim 20. The path calculation module is further configured to calculate a sufficiently redundant backup communication path from the calculated communication path;
The network controller according to claim 20. The path calculation module is further configured to program a hardware endpoint that follows the calculated communication path by disabling normal operation of the hardware endpoint;
The network controller according to claim 20. The path calculation module is further configured to monitor programmed hardware endpoints and communication connections that follow the calculated communication path for network failure, overload or path optimization.
The network controller according to claim 20. The path calculation module recalculates the communication path and reprograms a hardware endpoint according to the recalculated communication path when at least one of the communication connections in the calculated communication path fails. Further configured to repair a communication path in the communication network;
The network controller according to claim 20. The communication connection has a basic communication protocol, and the path calculation module uses a communication connection in the communication network having a basic communication protocol different from the basic communication protocol of the communication path. Further configured to emulate the basic communication protocol of the calculated communication path;
The network controller according to claim 32, wherein: The path calculation module recalculates the communication path and reprograms hardware endpoints according to the recalculated communication path to optimize communication paths of individual services in the communication network based on the stored information. Further configured to
The network controller according to claim 20. The path calculation module is further configured to dynamically adjust an associated repair time constant of the communication path based on a respective repair time constant of a communication connection of the recalculated communication path;
The network controller according to claim 20. The path calculation module is further configured to recalculate the communication path based on an economic or social value associated with the communication path;
The network controller according to claim 20. The network controller is further configured to transfer service from the calculated route to the recalculated route;
The network controller according to claim 20. The network controller is further configured to transition services to allow maintenance of hardware endpoints and communication connections in the communication network without interrupting the service;
38. The network controller according to claim 37. A method for repairing a communication tunnel in a communication network, the method comprising:
Storing information about hardware endpoints and communication connections in the communication network;
Calculating a communication tunnel based on the stored information;
Programming a hardware endpoint according to the calculated communication tunnel to set up the communication tunnel in the communication network;
Detecting a failure in a hardware endpoint and communication connection following the communication tunnel;
Reassigning a new communication tunnel and reprogramming hardware endpoints following the new communication tunnel to repair the communication tunnel;
A method comprising the steps of: The hardware endpoint includes a switch and a router,
40. The method of claim 39. Programming a hardware endpoint that follows the calculated communication tunnel includes disabling normal operation of the hardware endpoint;
40. The method of claim 39. The communication tunnel has a basic communication protocol, and the method uses a new communication tunnel in the communication network having a basic communication protocol different from the basic communication protocol of the communication tunnel; Further emulating the basic communication protocol of the calculated communication tunnel;
40. The method of claim 39. Allocating a new communication tunnel and reprogramming a hardware endpoint following the new communication tunnel optimizes the communication tunnel based on the stored information;
40. The method of claim 39. Further comprising transferring services from the calculated communication tunnel to the new communication tunnel;
40. The method of claim 39. A software control plane network controller configured to repair a communication tunnel in a communication network,
A database configured to store information regarding hardware endpoints and communication connections in the communication network;
Calculating a communication tunnel based on the stored information, programming a hardware endpoint according to the calculated communication tunnel, setting up the communication tunnel in the communication network, and a hardware endpoint and communication connection following the communication tunnel A route calculation module configured to detect a failure in the network, assign a new communication tunnel and reprogram a hardware endpoint following the new communication tunnel to repair the communication tunnel;
A software control plane network controller comprising: The hardware endpoint includes a switch and a router,
The network controller according to claim 45, wherein: The path calculation module is further configured to program a hardware endpoint that follows the calculated communication tunnel by disabling normal operation of the hardware endpoint.
The network controller according to claim 45, wherein: The communication tunnel has a basic communication protocol, and the path calculation module uses a communication tunnel in the communication network having a basic communication protocol different from the basic communication protocol of the communication tunnel. Further configured to emulate the basic communication protocol of the calculated communication tunnel,
The network controller according to claim 45, wherein: The path calculation module is further configured to allocate a new communication tunnel and reprogram a hardware endpoint following the new communication tunnel to optimize the communication tunnel based on the stored information;
The network controller according to claim 45, wherein: The network controller is further configured to transfer service from the calculated communication tunnel to the new communication tunnel;
The network controller according to claim 45, wherein: A method of repairing a communication tunnel in a network,
Storing information about a plurality of existing communication tunnels;
If at least one of the plurality of existing communication tunnels fails, assigning a plurality of new communication tunnels each having a plurality of hardware endpoints based on the stored information;
Connecting the plurality of new tunnels by directly programming the plurality of hardware endpoints;
A method comprising the steps of: The plurality of hardware endpoints include switches and routers,
52. The method of claim 51, wherein: Directly programming the plurality of hardware endpoints includes disabling normal routing operations;
52. The method of claim 51, wherein: A method of emulating a communication tunnel in a network,
Assigning a communication tunnel having a first basic communication protocol and a plurality of hardware endpoints;
Connecting the tunnel to another communication tunnel having a basic communication protocol different from the first protocol by directly programming the plurality of hardware endpoints;
A method comprising the steps of: The plurality of hardware endpoints include switches and routers,
55. The method of claim 54, wherein: Directly programming the plurality of hardware endpoints includes disabling normal routing operations;
55. The method of claim 54, wherein:

Images