Multi-service architecture with any port any service (APAS) hardware platform

An apparatus for a multi-service network architecture for processing network traffic arriving on a network connection is disclosed. The multi-service network architecture has a plurality of network connection components residing on a single platform and a processor coupled to the network connection components. The processor is configured to execute a predetermined one of a plurality of software images corresponding to the type of network traffic arriving on the network connection and to selectively enable at least one of the network connection components according to the predetermined software image.

FIELD OF THE INVENTION

The present invention is related to the field of network architecture, more specifically, the method and apparatus of the present invention is a multi-service architecture with “Any Port Any Service” (APAS) hardware platform.

BACKGROUND

In general, a network switch provides a data path, or interface, between networks and is a device that allows a connection to be established as necessary and terminated when there is no longer a session to support. A typical network switch is part of a network equipment such as a modular multi-service access concentrator (MAC) implemented in a multi-slot box chassis with a number of hardware boards with digital signal processors (DSPs). Each hardware board may have a set of port connectors that is wired or connected to a Public Branch Exchange (PBX) or some network level application.

A given network may operate according to a particular networking standard protocol and a typical network switch is designed to support a network application of a single networking standard protocol. Examples of networking standard protocols that may be supported by different network switches include, but are not limited to, Frame Relay, voice, circuit emulation, T1 channelized, E1 channelized, and Asynchronous Transfer Mode (ATM).

For example, a hardware board supporting a ‘Voice’ application may have a network switch that is connected to T1/E1 Framers and Digital Signal Processor Modules (DSPMs) specifically to support ‘Voice’ applications. A hardware board supporting an ‘ATM’ application may have a network switch that connects T1/E1 Framers to Serial Communication Controllers (SCCs) on processors specifically to support an ‘ATM’ application. Thus a hardware board with a typical network switch only supports a specific pre-defined network application.

The disadvantages of the current technology are many. For example, because a hardware board with a network switch designed for a given network application is only capable of supporting that network application, different hardware boards are required to support different network applications (e.g. Voice, ATM, Frame Relay). This multiplies the efforts in development, testing, integration and support of a network product. Additionally, current technology leads to greater inventory for a service provider because a service provider must keep in stock a sufficient number of hardware boards of different support capabilities.

BRIEF SUMMARY OF THE INVENTION

An apparatus for a multi-service network architecture for processing network traffic arriving on a network connection is disclosed. The multi-service network architecture has a plurality of network connection components residing on a single platform and a processor coupled to the network connection components. The processor is configured to execute a predetermined one of a plurality of software images corresponding to the type of network traffic arriving on the network connection and to selectively enable at least one of the network connection components according to the predetermined software image.

Other features and advantages of the invention will be apparent from the detailed description and drawings provided herein.

DETAILED DESCRIPTION

A multi-service architecture that supports “Any Port Any Service” (APAS) for use in multi-slot, multi-service networking products is described. As will be described in more detail below, software can be invoked to support the desired service type (HDLC/FR/ATM, etc.) while using the common hardware. The software can configure any port for any of the desired service types. In this way, different service types can be supported simultaneously on different ports. Additionally, making use of the common hardware platform simplifies the configuration of the various network interface cards.

By downloading an appropriate software image, the common hardware can be configured to support various services including but not limited to T1/E1 voice application, channelized FR application, unchannelized FR application, T1/E1 ATM application, serial Asynchronous/Bisynchronous mode applications or any combination across the ports, depending on the application and the corresponding software images.

The intended advantages include helping to save in hardware development, testing and qualification time, and helping to reduce costs associated with the training of the “service provider” line of customers, field/support and sales personnel. Further intended advantages include helping to reduce the risks associated with different service/interface types, helping to reduce time-to-market due to savings in efforts at various stages of hardware development, and helping to save in the overall hardware cost due to higher volumes resulting from the use of common hardware across various applications. Additional intended advantages include the benefit to a service provider by requiring only one type of hardware for different network applications and thereby decreasing inventory. This is opposed to requiring multiple types of hardware for different applications. Further, a service provider may be provided with a decreased learning curve on hardware aspects of a platform/product by providing one hardware that can be used for different applications.

FIG. 1is a diagram of one embodiment of a network. The exemplary network connects a head office10with at least one remote office12through a network carrier14such as a wide area network (WAN). A network equipment16residing at the head office10has several card slots for several feature cards201. . .20N. Each feature card20has a set of port connectors that is wired or connected to a Public Branch Exchange (PBX) or some network level application. The network carrier14is supported by all feature cards201. . .20Nand supports transmission through several different services including but not limited to an Asynchronous Transfer Mode (ATM) transmission coming from an ATM service connection and a Frame Relay (FR) service connection.

The network equipment16may be implemented with the APAS multi-service architecture to configure any port on a feature card for any desired service type and to allow different service types to be supported simultaneously on different ports.

FIG. 2ais a block diagram of one embodiment of an APAS configuration. The embodiment is comprised of a feature card20of a network equipment16. The system is also comprised of various software images2001. . .200Ndependent on a set of network service applications2021. . .202N. For one embodiment, the applications2021. . .202Nmay be, but are not limited to, an FR application, an ATM application or a digital voice application.

The illustrated system may have one network or multiple networks, and the various components of the network or networks may be deploying an FR service, an ATM service, or a digital voice service. Within the service, there are different types of transmissions including channelized and unchannelized transmissions.

The network equipment16may be a modular multi-service access concentrator (MAC) implemented in a multi-slot box chassis with a number of digital signal processors (DSP) and a feature card20implemented with an APAS hardware platform architecture.

In order to support different applications2021. . .202Nsuch as digital voice, ATM, FR or serial applications, the same feature card20may be used or different feature cards201. . .20Nmay be plugged into different slots and a corresponding software image200may be downloaded onto the respective feature cards201. . .20Nfor a particular application202. For example, if a card in a slot three is designated to support ATM service, then the software image200for ATM service is downloaded onto card three. To process various different applications2021. . .202N, a corresponding software image200is downloaded.

Alternatively, two ports may support a different type of application202within the same feature card20. For this scenario, two different types of software images200, and2002may be run on a processor that supports two different applications2021and2022.

The software images2001. . .200Ntherefore program the control logic of a feature card20differently depending on the network service type to be supported.

FIG. 2bis a software block diagram of exemplary software components interfacing with an APAS hardware platform. Application layer software202such as Voice over Internet Protocol (IP) or Voice over Asynchronous Transfer Mode (ATM) application software is coupled to network management software220. The network management software220is coupled to various device drivers230. The device drivers230are in turn coupled to firmware240which is referred herein as software images2001. . .200N. The boot and startup software250perform initialization of the hardware260which is the network equipment16.

FIG. 3is a block diagram of one embodiment of an APAS hardware platform. One embodiment may be implemented with either a single board housing the processors, T1/E1 framers, TDM switch and all related logic and the proper number of DSPs. In the alternative, the proper number of DSPs may be mounted with the associated logic on pluggable modules, while the remaining logic is housed on the base-board.

For one embodiment, the feature card20is composed of a base-board301and Digital Signal Processor Modules (DSPMs)3021. . .302N. The base-board301houses a first processor316and a second processor324with their respective associated logic while each DSPM302houses a predetermined number (such as up to six) of DSPs with their associated logic. The base-board301may support up to four T1/E1 ports3001. . .3004for a total of 96/120 channels.

The base-board301is implemented with a dual processor such as the MPC860 from Motorola, Inc. of Schaumberg, Ill. It may be noted that the MPC860 is an example and other suitable devices may be used to implement the common hardware.

Additionally, the choice of processors, the number of physical ports, the number of DSPs, and other devices on the base-board301are dependent on the required or desired networking applications2021. . .202Nand performance of the platform. The illustrated exemplary embodiment is one such case supporting a “common hardware” for specific set of requirements.

The first processor316may be configured to run the system's boot code and other firmware/software including one or more software image200. At power-on or on hard reset, the first processor316downloads the boot code from boot flash memory328to a first local memory318such as an SDRAM and executes the boot code from the first local memory318. The first processor316then initializes various on-board resources, such as the T1/E1 port interface320, TDM switch322and other input/output (I/O) devices. Additionally, the first processor316maintains the base-board301under reset until its initialization of the various peripherals, including the T1/E1 port interface320and the TDM switch322, is complete. Once initialization is complete, the first processor316removes the second processor324out of reset and allows the second processor324to run.

The second processor324is responsible for the DSP interface. After being removed out of reset by the first processor316, the second processor324copies code from the first local memory318to its local memory326(a second local memory such as an SDRAM) and begins executing the code out of the second local memory326. Further, the second processor324initializes the DSP's on the DSP modules3021. . .302N. The second processor324handles the data transfer to/from the DSP's on the DSP modules3021. . .302Nfrom/to the second memory326and handles various data-centric tasks such as protocol-specific-packetization. For one embodiment, the two processors interact with each other via interrupt-based messaging and/or software mailboxes/semaphores. In an alternate embodiment, the two processors are replaced by a single processor.

The TDM switch322under software control (via software images2001. . .200N) routes the individual timeslots (DSOs) from any TDM port to any other TDM port. This allows routing of voice connections (DSOs) from any given port to any other port on board across the T1/E1 ports3001. . .3004in case of ‘Voice’ applications. For one embodiment, the TDM switch322provides sixteen TDM ports in each direction. The spare ports are wired to Serial Communication Controllers (SCCs)345(TDM ports 1 and 2) on both processors. The single platform hardware architecture with the TDM switch322allows the single platform for use for Voice/ATM/Frame-Relay and other applications with the corresponding software images2001. . .200N.

T1/E1 port interface320is comprised of T1/E1 framers and Line Interface Circuitry (LIUs) and can be integrated (i.e. T1/E1 each framer and LIU integrated as a single unit) or separate. In the ingress direction, the T1/E1 framers perform data and clock recovery, monitor the trunk for alarms, receive serial bit stream from the physical line, perform the framing and other functions and send out the PCM bit stream consisting of individual timeslots to the TDM switch322. The T1/E1 framers also extract the received clock from the received data. In the egress direction, the PCM bit stream from the TDM switch322is processed by the T1/E1 framer and sent out over the T1/E1 physical line.

The DSP modules3021. . .302Ncomprise DSPs with their respective memories and clocking logic. The DSPs run various software algorithms for the required functions, such as different compression-modes, DTMF Tone detection/generation, Fax tone detection and processing, etc. The DSPs receive the serial data from the TDM switch322. Each DSP processes the data for certain timeslots and interrupts the second processor324at the completion of processing. Upon receiving the interrupt, the second processor324copies the processed data from proper DSPs to local memory (318and326). In the egress direction, the second processor324moves the data from local memory (318and326) to the proper DSPs and the DSPs process the data to generate serial bit streams. The serial bit streams from the various DSPMs3021. . .302Ncome to the TDM switch322and the TDM switch322routes the proper timeslots to the proper T1/E1 framers under software control.

The local memory (318and326) stores code and data for the processors including software images2001. . .200N. More specifically, when a new network connection is being configured (such as a “Voice Call Set-Up” or “an ATM VC being set-up” or a “Frame Relay connection (DLCI) set-up”), a connection manager340identifies the “type of connection set-up” being requested. The connection manager340invokes the proper low-level software/firmware modules (software images2001. . .200N) which are then downloaded into the local memory (318and326). Either memory is accessible by both processors. The processors execute out of their own local memory.

The backplane logic block325interfaces the processors with the backplane bus327. In the ingress direction, the backplane logic block325receives data (packets/cells/frames depending on the application and protocols), and transmits them over the backplane to the proper destination. In the egress direction, the backplane logic block325receives the data from the backplane (packets/cells/frames) and transmits the data to the processors.

The DSPMs3021. . .302NDSPs interface to TDM streams on one interface and to the carrier host router on the other. In the ingress direction, the DSPs take PCM traffic and form Internet Protocol (IP) packets, which are then read by the first processor316over an HPI bus350in the first local memory318and processed further according to the configuration of the corresponding software image200. In the egress direction, the first processor316sends the IP packets to the DSPs on the DSPMs3021. . .3024over the HPI bus350. The DSPs then convert the data to PCM bit streams, which are then routed to the proper T1/E1 framers by the TDM switch322.

FIG. 4is an embodiment of the TDM highway. The APAS hardware platform is implemented with a TDM highway that is connected such that the same hardware can be re-used to support a variety of different network applications (e.g. ATM, FR, voice applications). More specifically, the TDM highway connects the T1/E1 Framers to the TDM for two way communication. Further, the ports on the TDM switch322are wired to the DSPMs3021. . .302Nand to the TDM ports on the SCCs345(SCC1, 2) on the processors.

When a new network connection is being configured, a connection manager340identifies the type of connection set-up being requested. The connection manager340invokes the proper low-level software/firmware modules (software images2001. . .200N) which are then downloaded into the local memory (318and326). The processors (316and324) execute the code associated with the software image200which in turn programs the TDM switch322to correctly manage the desired connectivity (i.e. TDM Switch to DSPMs in case of Voice applications, TDM Switch to SCCs ports in case of FR/ATM applications). The SCC345would be connected Non-Muxed Serial Interface (NMSI) ports or TDM ports depending on whether the application needs Unchannelized mode or Channelized mode support, etc.

For example, in the ingress direction, the PCM stream from the T1/E1 framers4001. . .400Ncomes to the TDM switch322and the individual timeslots (or “channels”) on the PCM streams are routed by the TDM switch322per the software image200in the programmed manner to appropriate DSPM's3021. . .302N.

In the egress direction, the serial bit streams from the various DSPM's3021. . .302Ncome to the TDM switch322and the TDM switch322routes the proper channels to the proper T1/E1 framers4001. . .4004as programmed.

In this way, the traffic always passes through the TDM switch322, and the TDM switch322routes the traffic to the appropriate on-board component as programmed by the software image200corresponding to the traffic type to be processed. Thus, depending on the application202, the TDM switch322can be properly programmed by a software image200to send the data streams for individual (or complete T1/E1 frame) to any port according to the software image200being executed (e.g. the ports for the DSPMs3021. . .302Nor the SCCs345).

With the above described hardware scheme, some timeslots in a single T1/E1 frame may carry ‘Voice’ while some others may carry ‘data’ and the timeslots are routed properly through the TDM switch322by programming the TDM switch322(e.g. voice-channels routed to the DSPM/s and data-channels to the SCCs) simultaneously, without the need for different types of hardware. Thus, the hardware muxing logic (via the control logic on-board and the TDM switch322) and the TDM highway's connectivity makes the hardware architecture reusable for a variety of applications, thereby providing significant advantages.

FIG. 5is a flow chart showing one embodiment of an APAS set up process. In step501, whenever a new connection is being set-up, a higher layer software module such as a connection manager340detects the type of connection set-up being requested. In step502, the higher layer software module then invokes the proper lower level software/firmware modules such as a software image200. For example, in order to support multiple types of applications, different software images2001. . .200Nare made available in the system such as in a common repository, boot flash memory, PCMCIA disk, or downloadable over the Internet.

In step503, the desired software image200is downloaded to the on-board local memory. In step504, the code associated with the software image200is then executed from the local memory and traffic is processed by the processors according to its corresponding software image200. For example, the TDM switch322routes traffic according traffic type as programmed by the corresponding software image200(e.g. TDM Switch to DSPMs in case of Voice applications, TDM Switch to SCCs ports in case of FR/ATM applications). Once a particular type of software image200is resident in the local memory (318and326), for subsequent connection-setup of similar type (Voice/ATM/FR, etc.) the code execution simply continues from the local memory (318and326) directly.

What has been described is a method and apparatus for a multi-service architecture with “Any Port Any Service” (APAS) hardware platform. A single piece of hardware is capable of supporting various different software or individual software images related to a particular application. The software image simply needs to be downloaded and is processed by the hardware common across various applications.