1. Field
Embodiments of the invention relate to the field of networks and more specifically, but not exclusively, to decentralizing network management system tasks.
2. Background Information
Network management in optical networks has traditionally been implemented as a centralized control, with the control systems and optical network devices performing management processing as little as possible. As complexity in optical devices and networks increases, and the number of managed devices grows, it becomes an increasingly difficult management problem to centralize all functions.
One of the scalability problems with a large optical network is the volume of statistics and events that must be analyzed and processed by a centralized management system, such as a Network Management System (NMS). A single hardware failure can escalate into a large number of alarms that need to be handled with great efficiency to isolate the failure and select a solution or workaround. A link failure can cause these alarm notifications to be generated from all affected network elements. As the size of the network grows and the number of optical devices increases, this can swamp a centralized management system.
Further, centralized management systems encounter a high amount of latency to accommodate changes to the network configuration. Protocols, such as the Link Capacity Adjustment Scheme (LCAS), can be used to signal changes, but usually such changes must be pre-approved by the NMS. Such a scheme does not provide a mechanism to make configuration changes based on current network traffic conditions.
Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that embodiments of the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring understanding of this description.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Referring to
Network 100 also includes a Network Management System (NMS) 110. NMS 110 provides management and controllability of the network elements 102-108. In one embodiment, NMS 110 is coupled to each NE 102-108 by an Ethernet connection and communications between NMS 110 and the network elements is in accordance with the Internet Protocol (IP). In another embodiment, management information may be imbedded in a SONET transmission between network elements and NMS 110.
In one embodiment, NMS and its connections to NE's 102-108 form a management network 118. In one embodiment, management network 118 includes a Data Communication Network (DCN). NMS 110 has a network wide view of optical network 116 and allows network managers to monitor and maintain optical network 116. In one embodiment, NMS 110 provides provisioning of network resources, receives alarm notification and correlation, and gathers statistics regarding network traffic and other data. In accordance with embodiments described herein, network elements 102-108 perform processing of various management tasks and report the results of such processing to NMS 110.
In general, provisioning involves allocating network resources to a particular user. For example, in
Alarm correlation involves pinpointing the event(s) that triggered one or more alarms in a network. In optical network 116, a single failure event may trigger multiple alarms at various places throughout the network. Multiple network elements may detect a failure and report the failure to NMS 110. For example, in
Turning to
Line card 152 is coupled to optical devices (OD's) 158 and 159, and line card 154 is coupled to optical device 160. Optical devices 158, 159 and 160 include optical framers, optical transponders, optical switches, optical routers, or the like. In one embodiment, optical devices include devices capable of processing SONET traffic.
In one embodiment, each line card 152 and 154 includes one or more Intel® IXP network processors. In another embodiment, control card 156 includes an Intel Architecture (IA) processor. An embodiment of a line card is discussed below in conjunction with
Referring to
Control plane 202 handles various tasks including routing protocols, providing management interfaces, such as Signaling Network Management Protocol (SNMP), and error handling and logging. Data plane 204 performs packet processing and classification. In one embodiment, Application Program Interfaces (API's) provide interfaces between control plane 202 and data plane 204. Some interfaces have been standardized by industry groups, such as the Network Processing Forum (NPF) (www.npforum.org) and the Internet Engineering Task Force (www.ieff.org). Some embodiments described herein may operate substantially in compliance with these interfaces.
Management plane 206 includes components that span data plane 204 and control plane 206 to provide network management functionality at the network element level. In one embodiment, these components take the form of API's operating in the control plane and the data plane (discussed further below).
Referring to
In one embodiment, instructions for the control plane and the data plane are loaded into memory devices of the control card and line card, respectively. In one embodiment, these instructions may be loaded using a Trivial File Transfer Protocol (TFTP) of a boot image over an Ethernet connection from a server. In another embodiment, the instructions may be transferred from NMS 110 over management network 118.
In one embodiment, network elements implement a fastpath-slowpath design. In this scheme, as packets enter a network element, various processes to handle the packets are divided between a fastpath or a slowpath through the network element. Fastpath processes include normal packet processing functions and usually occur in the data plane. Processes such as exceptions and cryptography are handled by the slowpath and usually occur in the control plane. In one embodiment, management processes as described herein are handled in the slowpath. Changes affected by ODC 200 may result in changes in fastpath processing of packets.
Turning to
ODC 300 components span the control plane and data plane to provide management functionality at the network element level. The functionality of these components provide a high level interface with fine grained control to configure and manage optical devices. ODC 300 also provides support for interaction with optical device drivers. Example functions provided by ODC 300 include alarm correlation, event logging, filtering and propagation, statistics and diagnostic information collection, provisioning information management, and policy administration.
In one embodiment, NMS 320 communicates with ODC 300 using the High Level Services API 306. HLAPI 306 may be used by NMS 320 to receive control information, alarm notification, and statistics from ODC 300. HLAPI 306 may be supported on the control plane of the network element or may be supported by a proxy to the network element.
In one embodiment, Provider Level API 308 may handle notifications coming from the data plane 304. This will include fault notifications, such as alarms and events, as well as provide a configuration interface for requesting statistics and configuring statistic granularity and other attributes. Statistics may be periodically propagated via reports or retrieved via requests.
In another embodiment, Provider Level API 308 may provide a control plane side interface for control of optical devices 316. In this particular embodiment, API 308 may also provide a control plane side interface for other components of data plane 304 for downloading information to the data plane hardware for processing on data plane 304.
Data plane 304 includes Data Plane API 310 and Device Plug-in API 312. Data Plane API 310 may provide management functionality on the data plane side of ODC 300. API 310 propagates information to the control plane 302 using interface 318. In one embodiment, Data Plane API 310 executes on a general purpose processor of a network processor and is not part of fastpath packet processing.
Device Plug-in API 312 may provide a common interface for most optical devices as well as support the specific functionality that may be featured by a particular type of optical device. API 312 may provide a single point of control for all optical devices attached to the network element.
Turning to
In one embodiment, this standard interface includes the Distributed Management Task Force (DMTF) Web Based Enterprise Management/Common Information Model (WBEM/CIM). DMTF is an industry organization concerning network environments (see www.dmff.org). WBEM/CIM supports adapters that may be used to integrate with other standards to maximize system flexibility; WBEM/CIM provides a common framework for management applications. WBEM provides a standardized, environmentally independent way to process management information across a variety of devices. CIM includes a set of modeled objects to define and describe numerous aspects of an enterprise environment from physical devices to network protocols. CIM also provides methods for extending the model to include additional devices and protocols. Some embodiments described herein may operate substantially in compliance with the WBEM/CIM.
In an embodiment of HLAPI 406 using WBEM/CIM, HLAPI 406 may include a CIM Object Manager (CIMOM) 420. CIMOM 420 receives data regarding optical devices and replies to requests for such data. CIMOM 420 may use a Repository 422 to maintain this data. Repository 422 stores configuration data and other information associated with optical devices communicatively coupled to the ODC. Such data includes statistical information, configuration information, and event/alarm notification mechanisms. In an embodiment, not using WBEM/CIM, Repository 422 may use a generic object base for maintaining data.
Similarly as discussed above in conjunction with
In one embodiment to support these management functions, API 408 may serve as a WBEM provider to CIMOM 420; API 408 provides data to CIMOM 420 that may be kept in Repository 422. API 408 may also be used to retrieve data from Repository 422 using CIMOM 420. In another embodiment, other entities in the control plane 402 may call the Provider Level API 408.
In another embodiment, API 408 may also support a direct functional API for in process calls, and a Remote Procedure Call (RPC) interface of API 408 for out of process calls. In this embodiment, API 408 provides an alternative to using HLAPI 406 that is text and HyperText Transfer Protocol (HTTP) based due to CIM/XML.
In one embodiment, Provider Level API 408 supports WBEM plus ODC extensions. ODC extensions include additions and/or modifications to the WBEM/CIM specifications to support ODC as described herein. In one embodiment, ODC extensions add to the standard interfaces defined by the NPF. In another embodiment, ODC extensions correspond to commands between ODC components of the control plane and ODC components of the data plane.
In one embodiment, interface 418 includes NPF Programmers Developer Kit (PDK) plus WBEM plus ODC extensions. ODC extensions allow for ODC management functionality as described herein to pass between the control plane and the data plane.
Other management interfaces, shown at 428, may also be constructed in translation layers above the control plane. In one embodiment, these other management interfaces utilize HLAPI 406. Such other management interfaces include CMIP, TL1, Corba, SNMP Management Information Base (MIB), and Common Open Policy Service (COPS) Platform Information Base.
In one embodiment, Operations, Administration, Maintenance, and Provisioning (OAM&P) Applications 414 may be communicatively coupled to the control plane 402. OAM&P Applications 414 may operate from systems communicatively coupled to control plane 402 and include data and management applications such as Automatic Protections Switching (APS). OAM&P Applications 414 may provide higher level processing of data than the ODC, such as further alarm correlation and provisioning. These applications may utilize data from the CIMOM 420 and may also utilize the RPC interface to access the Provider Level API 408 directly.
Turning to
Data Plane API 510 may provide a higher level of functionality than provided by a driver interface, such as an Intel® IXF API. In one embodiment, such higher level of functionality includes management services such as LCAS handling, alarm correlation, propagation of alarm/event notifications and statistics to registered clients on the control plane or data plane, and provisioning such as Automatic Protection Switching (APS) processing. In other embodiments, such high level functionality also includes resource management (such as bandwidth management), admission control to the network, and other policy-based management to the control plane or to other data plane components.
For example, in one embodiment, when the data plane 504 receives an LCAS request in the SONET stream, the data plane 504 may process the LCAS request instead of pushing the request to the NMS 320. In general, LCAS is a provisioning protocol that allows SONET users to request a change in their bandwidth use of an optical network. Thus, automatic provisioning may occur on data plane 504.
Plug-In API 512 provides a hierarchy of API's for optical devices 516a and 516b. Device Common Plug-In 514 includes a set of APIs for optical devices 516a and 516b. Device Common Plug-In 514 may include a common API that is supported by all devices, and a number of feature API's (such as a Packet Over SONET (POS) API), as well as API's that map to specific hardware. The Device Common Plug-In 514 may provide a common entry point for optical devices and may be used as the primary interface to the optical devices 516a and 516b. In one embodiment, Device Common Plug-In 514 includes an Intel® IXF API to support the Intel® IXF family of optical devices. Plug-In API 512 may also provide a plug-in abstraction architecture for ease in discovering newly installed optical devices.
Device Specific Plug-In's 515a and 515b are unique to each optical device 516a and 516b, accordingly. In one embodiment, Device Common Plug-In 514 is a thin API layer that redirects calls to the Device Specific Plug-In's 515a and 515b. If an optical device supports a feature that is not covered by a feature API of the Device Common Plug-In 514, then the appropriate Device Specific Plug-In may be called directly to access this feature.
Referring to
Referring to
Proceeding to a decision block 626, the logic determines if the provisioning request is within provisioning guidelines. In one embodiment, the NMS may download resource policies to the network element control plane, which in turn are downloaded to the data plane. In this embodiment, the data plane may check the reserved resources and policies and grant permission and reservations to data plane clients, or on behalf of protocols processed on the data plane, such as LCAS, traffic grooming, or the like.
If the answer to decision block 626 is no, then the provisioning request is denied, as shown in a block 627. If the answer is yes, then the network is modified based on the provisioning request, as shown in a block 628. Continuing to a block 630, the ODC notifies the NMS of the network changes.
Referring to
Continuing to a block 644, the ODC detects an occurrence that triggers the policy. An occurrence includes a fault, an event, or the like. Moving to a block 646, the ODC administers the policy from the network element level. In a block 648, the ODC notifies the NMS of the policy administration.
Referring to
Proceeding to a block 665, a report including the collected data is sent to the NMS. In one embodiment, the report is sent according to a pre-determined schedule, while in another embodiment, the report is sent when requested by the NMS or other requesters.
NPU 702 includes, but is not limited to, an Intel® IXP (Internet exchange Processor) family processor such as the IXP 4xx, IXP 12xx, IXP24xx, IXP28xx, or the like. NPU 702 includes a plurality of micro-engines (ME's) 704 operating in parallel, each micro-engine managing a plurality of threads for packet processing. NPU 702 also includes a General Purpose Processor (GPP) 705. In one embodiment, GPP 705 is based on the Intel XScale® technology. In another embodiment, instructions for data plane components executing on line card 700 are stored in memory 708 and execute primarily on GPP 705.
NVS 712 may have stored firmware and/or data. Non-volatile storage devices include, but are not limited to, Read-Only Memory (ROM), Flash memory, Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), Non-Volatile Random Access Memory (NVRAM), or the like. Memory 708 may include, but is not limited to, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Synchronized Dynamic Random Access Memory (SDRAM), Rambus Dynamic Random Access Memory (RDRAM), or the like.
In an alternative embodiment, Line Card 700 may also include a GPP 706 coupled to bus 710. In one embodiment, GPP 706 is based on the Intel XScale® technology.
A bus interface 714 may be coupled to bus 710. In one embodiment, bus interface 714 includes an Intel® IX bus interface. Optical devices 716 and 718 are coupled to line card 700 via bus interface 714. Line card 700 is also coupled to a fabric 720 via bus interface 714.
For the purposes of the specification, a machine-accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form readable or accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible medium includes, but is not limited to, recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, a flash memory device, etc.). In addition, a machine-accessible medium may include propagated signals such as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible, as those skilled in the relevant art will recognize. These modifications can be made to embodiments of the invention in light of the above detailed description.
The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the following claims are to be construed in accordance with established doctrines of claim interpretation.