HK1039990B - Providing desired service policies to subscribers accessing internet - Google Patents

Description

Providing desired service policies to users accessing the internet

The present invention relates generally to digital communication networks and, more particularly, to a system and method for providing a desired service policy to users accessing the internet.

Users often use local systems to access remote systems. In a typical scenario, a user would use a (nearby) computer system to access a remote system (typically located at a remote location). Access plays a fundamental role for some useful applications, such as Web browsing, email, and database access, which are well known in the relevant art.

Remote access devices often exist between a local system and a remote system. The remote access system generally functions as a multiplexer or aggregator (hub) originating from the user's physical connection (e.g., dial-up connection of a large community on a local loop and dedicated T1 line). The operation of a remote access device is generally to send digital data bits ("bit groups") to a destination user and to receive bit groups originating from the user. Remote access servers (supporting digital and/or digital modems) provided by internet service providers, Digital Subscriber Line Access Multiplexers (DSLAMs) provided by local exchange carriers (legacy and competitive Local Exchange Carriers (LECs)), and cable modems provided by cable television providers are examples of such remote access devices.

The remote access device is typically connected to a data switch that selectively forwards received groups of bits, typically based on address information encoded in the groups of bits, to a corresponding destination. In a common implementation, the data switch behaves as an Internet Protocol (IP) router that examines the destination address of an IP packet to determine the next point (typically another router or computer system) to which the IP packet is destined.

In conventional implementations, the combination of the router and the remote access device may not meet the user's specified requirements (or desired service policies). In this application, a group of users (including a single user) having a particular service policy requirement will be referred to as a subscriber. First, the subscriber's specification requirements are presented as an example. It is then shown that conventional routers and remote access devices do not adequately meet the user requirements.

The subscriber may have several reasons to have a specialized requirement. For example, a subscriber who contains a large community, such as a business enterprise, and the business enterprise may wish to limit the total bandwidth used by some or all of the users. Some other business enterprise may wish to have a Virtual Private Network (VPN) with possibly private secure links between locations at different distances to some, but not all, of the users. Other business enterprises may also wish to restrict access to certain types of applications (e.g., only Web access, not file transfer or telenet), or have different classes of services (cos) for different applications.

In addition to such requirements of large communities, individual users (subscribers) may also have different requirements. These individuals may be part of a large business enterprise or home users. The user may wish to be allocated only 56Kpbs during peak hours (e.g., business hours when the network is typically more congested) and higher bandwidth during other times. An ISP may wish to charge such a user a lower fee. In summary, it should be understood that a user or subscriber may have different and specialized service policy requirements.

There are several reasons why conventional combinations of data switches and remote access devices do not adequately satisfy such combinations of requirements. For example, a data switch may be implemented primarily as a fast packet forwarding device-despite limited prioritization and access control schemes. Asynchronous Transfer Mode (ATM) switches that prioritize traffic (traffic) based on quality of service (QoS) and traffic (traffic) parameters, and IP routers that filter data for only a few applications, are illustrative examples.

However, the architecture chosen for the legacy data switch and/or remote access device may not be conditioned to customize service policies for individual users/subscribers. An ATM switch that forwards cells (cells) may not be able to distinguish individual users by examining a single cell. Data switches (e.g., IP routers) operating at higher levels can be designed to handle packets according to a uniform standard-typically for increased speed, and therefore cannot be designed to provide customized service policies to individual subscribers.

As noted above, such customization may be desirable in some situations. What is needed, therefore, is a flexible architecture that can provide different customized service policies to different subscribers.

In addition to customization, the architecture is generally required to be suitable for serving a large number of subscribers. What is needed, therefore, is a flexible architecture that is better suited to serving a large number of subscribers.

The present invention relates to an Internet Service Node (ISN) that provides a desired set of service policies to each subscriber. ISN is particularly useful for remote access providers such as ISPs and LECs, which are both interdependent and competitive. An access provider may use the ISN as an edge device (edge device) of an access network (access network) to provide customized service policies to each subscriber.

An ISN according to the present invention may contain multiple processor groups, with each subscriber being assigned to one processor group. The processor group may be provided, for example, in the form of a packet service card (packet service card). The processor complex may be configured with processing rules for all designated subscribers so that the processor complex can provide customized service policies desired by any given subscriber.

One port (port) of the ISN may be designed to determine the particular set of processors to which received data is to be forwarded, depending on the particular subscriber to which the received data relates. The switch fabric may then forward the data to the determined processor group based on the determination of the port.

Since each processor group may need to be designed to serve only a subset of subscribers (served by the ISN), the present invention may be well suited to large and/or complex networking environments.

The present invention can be used at the edge of the access network (edge) to provide a customized service policy desired by each subscriber. In one embodiment, the desired service policy may be specified using a configuration manager. The configuration manager may be integrated with the ISN or may be a distinct unit.

The configuration manager may translate the service policy into a set of processing rules, each processing rule containing a classifier and an associated action. The classifier generally specifies the data stream and any conditions under which the operation can be applied to the set of data bits transmitted over the data stream. In an Internet Protocol (IP) environment, the source/destination IP address, source/destination port, and protocol type fields generally collectively define an IP data flow that supports a particular remote access application.

The condition may include a match of a particular variable defining the service policy. For example, a certain service policy might specify that data bits are to be processed in a particular way between 9 am and 5 pm, in which case TIME is a variable, provided that TIME is 9 am to 5 pm. As another example, if the total BANDWIDTH used by a subscriber is greater than T1, the data bits for that subscriber may be given a lower priority, in which case BANDWIDTH is a variable, provided that BANDWIDTH > T1.

In general, most processing rules can be established statically by a specified service policy. However, some processing rules may need to be instantiated dynamically when a particular event occurs. For example, the IP address of a subscriber that dials into and relies on the access network to assign an IP address may not be available in advance. Therefore, the ISN builds processing rules when a subscriber is assigned an IP address after successful pull-in.

The present invention therefore dynamically instantiates the functionality of the processing rules to enable the ISN to service subscribers who may asynchronously access an access network, providing the ISN with the ability to also provide customized service policies to such subscribers. In addition, for inactive (i.e., not logged in) subscribers, an ISN may be used to serve a large number of subscribers since it is not necessary to configure the ISN with processing rules.

Another example of dynamic instantiation of a processing rule is that in a RealAudio type application, a new TCP (or UDP) connection may be started in the middle of the application session (session), which may contain a port number that cannot be determined in advance. The port number is typically negotiated with the control flow (negotiated) -this is well known in the relevant art. The ISN may be designed to examine packets in the control flow and determine the required information, and once this information is available, to establish new processing rules.

One embodiment of the ISN includes a plurality of processor groups, each of which in turn contains a plurality of processors. All flows of a subscriber may be dedicated to initial processing by one of the processor groups. When ATM cells (cells) are used as groups of data streams, channel identifiers (channels) may be used for assignment to the respective groups of processors. To balance the load, the packets may be distributed to the various processors within the group in a weighted round robin fashion. Other resource allocation schemes or management policies may also be employed.

The processor that processes the packets (to provide the desired service) may be provided as a physical unit separate from the access and trunk ports. The physical separation enables the number of processors and ports to be changed (increased or decreased) independently of each other. The flexibility thus achieved makes the architecture according to the invention well suited to support a large number of subscribers.

As described above, data associated with each subscriber may be assigned to a processor group. One aspect of the present invention provides an efficient way to distribute such data to processor sets. This assignment is illustrated in connection with an IP packet received in the form of a series of ATM cells.

To determine the particular set of processors to which to forward an IP packet, it may be necessary to examine the header data of the IP packet. This is at least true when cell data destined for multiple subscribers is received over a shared ATM virtual connection, since all cells may contain the same VPI/VCI data. This is typically encountered when data destined for a subscriber is received on a trunk port. In this case, the processor group may be determined by examining an IP destination address located in an IP header.

However, in some situations, further inspection of the data within the IP packets may be required to determine the subscriber. For example, data related to the subscriber may be received on a particular call (call) tunneled at L2 TP. In this case, the received packet may need to be examined to determine the UDP protocol type, UDP port number specifying the L2TP protocol, tunnel ID, and subscriber-specific call ID (call ID).

The present invention enables this checking to be done efficiently by using a Content Addressable Memory (CAM) in which each CAM cell has a search field, a mask, and an output field. The search field of each storage element may be configured to store data identifying a subscriber, and the output field may be configured to store data identifying a processor or a group of processors that provide a desired service policy to the subscriber associated with the CAM entry.

Additionally, to check the bits identifying the subscriber, a mask may be established for each CAM memory location. As an example, a CAM storage unit may be designed to only check the destination IP address when data for multiple subscribers is received over a shared ATM connection. On the other hand, when data for a subscriber is received over the L2TP tunnel, the mask field of the corresponding CAM location may be established to check for multiple data bytes.

Thus, when the first ("header") cell of an IP packet is received, the header data is provided as input to the CAM and the output data identifies an appropriate processor. Since different CAM entries may have different masks, a CAM access can find a matching entry. The output of the match may either represent a processor (group) identifier or result in further access to determine the processor.

When the output data does not represent a processor identifier, in the embodiments described herein, the output data either contains an index (index) in the IP table or indicates that additional CAM retrieval is required to determine the processor (group) identifier. Indexing is useful to minimize the number of CAM entries. The index may be used to select an entry from a table stored in high speed memory (e.g., SRAM), and the retrieved value may represent a processor identifier or a processor group identifier. Illustratively, only the first three bytes of an IP address may be checked by selecting an appropriate mask CAM entry and thereby committing a match to 225 IP addresses. Other accesses to the high speed memory may provide a specific processor identifier.

When the CAM contains an insufficient number of bits in the search field to identify a subscriber, additional CAM retrieval is typically required. For example, when subscriber data is received with one L2TP tunnel, it may be required to check a greater number of bits than are available in the search field of a single CAM storage location. In this case, some bits may be checked in a first search and other bits in subsequent searches. A match is considered to have occurred only if one match is detected for all of the searches.

In one embodiment described in this application, only two searches may be required. However, embodiments requiring other methods should be considered within the spirit and scope of the present invention. Whether retrieval is required depends on the format of the protocol and the number of bits that need to be checked.

In one embodiment of the ISN, the above features can be implemented in either access ports (access ports) that receive cells from subscribers, or trunk ports (trunk ports) that receive cells destined for subscribers. The ISN includes multiple processor groups, a single group typically configured to process IP packets associated with a subscriber. Furthermore, a switch fabric may be designed to assign cells to one of the groups based on the headers of the received cells. In particular, the VPI/VCI field may uniquely identify the processor group that handles the cells received by the switch fabric.

Accordingly, an allocation logic of the present invention determines a processor group by using the CAM and replaces a portion of the cell header (e.g., VPI) of all cells of the IP packet with the processor group identifier. The switch fabric can then assign all cells associated with the IP packet to the processor group identified by the cell header (VCI/VPI).

Thus, the present invention enables a desired service policy to be implemented for individual subscribers by providing each subscriber with a separate processing rule and using the processing rule to process data bits received on different data streams from the subscriber.

An ISN according to the present invention may be well suited to serve a large number of subscribers, since each subscriber may be assigned to a group of processors that provide the desired service policy.

The present invention is particularly suited for remote access applications because an ISN can be provided as an edge device that can control all application data flows, providing a desired service policy for each subscriber using a single ISN.

The invention makes subscriber devices easier to manage and less expensive because the desired service policies (no intelligent devices needed at the subscriber) can be implemented by the remote access service provider.

The present invention enables multiple subscribers to share the same ISN because the service policy of one subscriber generally does not affect other subscribers.

The present invention is particularly useful for remote access providers that service subscribers who access a remote access network through dialing (or other asynchronous mechanism) because subscriber policies can be dynamically added to the subscriber's ISN.

The present invention enables a large number of subscribers to be serviced because the subscriber's processing rules can be instantiated dynamically and only the ISN needs to be configured with the processing rules of the active subscribers.

The present invention makes an ISN well suited to serve a large number of subscribers because the number of processors can be increased and the computational load of processing packets can be distributed among the processors.

The present invention provides a flexible architecture that serves a large number of subscribers because the processors are physically separated from the ports used to transmit and receive data, and the number of processors can be changed independently of the number of ports, and vice versa.

The present invention thus provides a fast and efficient method of distributing cells constituting an IP packet to a predefined processor or group of processors by using a CAM with masks for the respective memory locations.

The present invention enables one identifier to be determined in one CAM access because each storage location can be configured to correspond to a mask of bits (associated with that storage location) that need to be retrieved for the subscriber.

The present invention minimizes the number of CAM memory cells required by using a single CAM memory cell for a set of IP addresses and using the output of the CAM access as an index (index) to retrieve the processor or processor set identifier.

The present invention enables a switch fabric to quickly forward IP packets to a corresponding processor by replacing a VPI in a cell with a determined processor identifier and having the switch fabric assign the cell to the processor using the VPI.

Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which a component first appears is indicated by the leftmost digit(s) in the corresponding reference number.

The invention will be described in conjunction with the following figures:

FIG. 1 is a flow chart illustrating a method according to the present invention;

FIG. 2 is a block diagram of a telecommunications system that represents one example environment in which the present invention can be implemented;

FIG. 3 is a flow chart representing one method in accordance with the present invention by which a service provider can provide customized service policies desired by each subscriber;

FIG. 4 is a block diagram of an embodiment of an Internet Service Node (ISN) provided in accordance with the present invention;

FIG. 5 is a block diagram of an embodiment of a packet service card provided in an ISN in accordance with the present invention;

FIGS. 6A and 6B are tables representing examples of processing rules for providing a desired service policy for a subscriber;

FIG. 7A is a block diagram illustrating the operation of a CAM having all memory cells with only one mask in common;

FIG. 7B is a block diagram illustrating the operation of the CAM with one mask per memory cell;

FIG. 8 is a block diagram representing circuitry for determining a processor for processing IP packets in an embodiment of the present invention;

FIG. 9 is a flowchart showing steps performed in embodiments of the present invention to determine processor identifiers for different applications;

figure 10 is a block diagram illustrating details of an embodiment of allocation logic for modifying a cell header using the method of figure 9.

1. Summary and discussion of the invention

An Internet Service Node (ISN) provided in accordance with the present invention enables customized service policies to be provided to individual users or subscribers. The ISN may enable the network manager to specify a desired set of processing rules for each subscriber. When data is received, the ISN may first determine the particular subscriber to which the data relates and process the received data according to the processing rules corresponding to that subscriber.

Since the relevant subscriber of the received data is first determined and only the processing rules corresponding to that subscriber can be applied to the data, the data can be efficiently processed since the processing rules of other subscribers served by the ISN are not taken into account.

In accordance with another aspect of the invention, the processing rules for each subscriber may be assigned to a predefined processor or group of processors. The data associated with each subscriber may then be forwarded to the respective processor(s).

Because each subscriber may be assigned to a different processor group, the present invention may be well suited to service a large number of subscribers. In other words, the service provider can serve more subscribers by adding processors.

The invention is explained in more detail below with respect to several examples. It should be noted, however, that the present invention can be implemented in a number of other environments and that several variations are possible. The method according to the invention will now be described first.

2. Method of producing a composite material

Fig. 1 is a flow chart illustrating a method according to the present invention. In step 110, the processing rules required to provide the desired service policies for each subscriber may be determined. Processing rules generally specify the manner in which data is processed (e.g., dropped, forwarded, prioritized, encrypted, etc.). In the embodiments described below, a processing rule may contain a classifier and an associated operation. The classifier specifies the data bits (of the subscriber) to which the operation is to be applied.

In step 120, an internet service node may be configured with processing rules for several subscribers. The configuration mechanism is related to the specific implementation of the internet service node and several ways of implementing such a mechanism will be apparent to those skilled in the relevant art, at least from the disclosure provided herein.

In step 130, the internet service node may receive data in the form of bit groups. In step 140, the internet service node may determine the subscriber to which the received data relates by checking the set of bits. The determination of a particular subscriber is also related to the particular format used for the bit set. An example of an implementation is described in more detail below with reference to Asynchronous Transfer Mode (ATM). It should be noted, however, that the present invention may be implemented with other formats (e.g., frame relay, ethernet) as will be apparent to those skilled in the relevant arts in view of the disclosure provided herein.

In step 150, the internet service node may apply the processing rules corresponding to the subscriber determined in step 130. The data is forwarded (or discarded) according to the processing rules. Since the processing rules are designed to provide the service policies desired by the subscriber, the internet service node can provide the service policies according to the present invention. Furthermore, since the internet service node can be configured with processing rules specific to each subscriber, differentiated services can be provided for each subscriber.

The present invention will be described in more detail with reference to an exemplary environment. However, it is useful (particularly in the case of ATM) to know the format of the byte(s), which helps to determine the particular subscriber to which the received data relates.

3. Bit group

In general terms, a group of bits refers to a number of bits that can be identified by a group. Depending on the protocol supporting the different access methods, different bitset formats may be used. As is well known in the related art, a plurality of groups of bits may form another group of bits according to a predefined convention. For example, data in several ATM cells may constitute one IP packet.

For purposes of specific explanation, the description of the present invention is primarily in the context of Internet Protocol (IP) packets carried in ATM cells. It should be understood, however, that the present invention can be implemented with other protocols and transport mechanisms, as will be apparent to those skilled in the relevant art.

Each ATM cell contains 53 bytes of data, of which 5 bytes are used as a header and 48 bytes are used as a payload (using the actual application data of the ATM network). The header contains a Virtual Path Identifier (VPI) and a Virtual Channel Identifier (VCI) field that defines the channel. The next node in the connection path is typically defined when the channel is established by an appropriate signaling scheme (signaling scheme). For a detailed understanding of the ATM, the reader is referred to the title ATM: theory and application (ISBN: 0070603626, computer communication book published by McGraw-Hill, 9.1994, authors David E.McDysan and Darren L.Spohn), and is hereby incorporated by reference in its entirety.

Sometimes, the subscriber can be identified with an ATM cell-the method is to check the VPI/VCI field (and the port number at which the cell is received). Many times, however, each ATM cell does not contain the information necessary to accurately identify the relevant subscriber in order to provide the customized service policies. It will be appreciated that the ISN therefore needs to examine higher layer protocols to determine the subscriber service policy according to which cells may need to be processed.

Accordingly, the payloads of ATM cells can be assembled to form packets of a higher layer protocol (the example herein is the IP protocol). The assembled packet may then be examined to determine the subscriber to which the data relates and the subscriber-specific processing rules applied to the packet. The considerations in the examination of higher layer protocol packets are explained below in relation to the IP environment.

4. Identifying subscribers and related protocol (IP) packets

Any association of service policies with groups relating to individual users will be apparent by understanding the manner in which the groups are associated with remote access applications as described below.

Each common remote access application requires a connection containing data flows in at least two directions. A data flow generally refers to a series of IP packets from a source system to a destination system for supporting an application. In an IP environment, applications are typically identified by TCP or UDP ports. TCP and UDP ports are typically pre-specified or agreed upon to determine a relationship with an application. An IP flow is typically defined using source and destination port number protocol types (TCP, UDP or ICMP), port numbers along with source and destination IP addresses.

Some application-specific sessions employ more than two flows and possibly multiple connections. All streams associated with an application session define a dialog (conversation). In the IP environment, the session is generally implemented over TCP (transmission control protocol), UDP (user datagram protocol), and ICMP (internet control message protocol) — which are well known in the related art. Depending on the application, a dialog may contain multiple data streams. For example, applications such as File Transfer Protocol (FTP) and RealAudio employ multiple data streams, sometimes using a higher layer combination (e.g., TCP versus UDP in the IP field).

TCP is the most common advanced transport (transport) used by applications because TCP provides reliable data flow using potentially unreliable IP packet transport. A TCP connection typically contains two data streams with both port numbers and IP addresses reversed. For example, assuming that N1, N2, N3, and N4 refer to the source IP address, source port number, destination IP address, and destination port number, respectively, of a data flow in one direction, then a data flow in the other direction will have N2, N1, N4, and N3, respectively, to represent the same variable. An application may be implemented with multiple TCP connections.

In the case of UDP, the source port is generally unpredictable when checking between two end systems. In the case of ICMP, such ports are replaced by type and identification fields.

It should be appreciated from the foregoing that each flow can be uniquely identified by examining the contents of the IP packets. In addition, many types of applications use a pre-specified port number (e.g., SMTP mail-use port 25), which can be used to identify a particular user's application if the processing rules are specified per user application.

In some instances, the port number for a flow in a session may be determined based on negotiations conducted on a "control flow" that is typically set on a pre-designated known port. For example, in a multimedia (containing a combination of text, sound and video) application, multiple streams may be used to transmit the digital data associated with each multimedia component. A control connection is first initiated on a predefined port (e.g., port 200) and the ports of the remaining flows are then determined based on the packet flows on the control connection. The port numbers of these new streams are encoded according to a predetermined convention-as is well known in the relevant art.

An ISN may be implemented using at least the general format and protocols described above, as described in more detail below, to provide each subscriber with a desired service policy. For purposes of illustration, an example environment in which the invention can be implemented is first discussed. Then, the embodiments of the present invention are explained.

5. Example of the Environment

Fig. 2 is a schematic diagram of an example telecommunications system environment 200 in which the present invention can be implemented. This figure shows the manner in which the ISN250 can be used by a remote access service provider (e.g., an internet service provider) to provide differentiated services to subscribers. User (subscriber) locations (210, 230-a and 230-X) are connected with an Internet Service Node (ISN)250 using different access technologies. The ISN250 is provided in the access network 290. In accordance with the present invention, the ISN250 enables different service policies to be provided to different users as desired.

The customer network 210 may contain several systems connected to a router 220. The user network 210 may be considered to contain one subscriber or multiple subscribers. Router 220 may communicate data to ISN250 in the form of IP packets using a protocol such as Serial Line Interface Protocol (SLIP) or point-to-point protocol (PPP). Subscriber location 230-a and subscriber location 230-X are shown connected to a remote access device 240, which may correspond to a remote access server (supporting analog and/or digital modems) or DSLAM implemented in a known manner. Remote access device 240 may communicate data in the form of IP packets that are segmented into ATM cells. Each location 230 may contain a single or multiple subscribers-as described below.

It should be understood that the interfaces and subscriber locations of fig. 2 are examples only. It will be apparent to those skilled in the relevant art that the ISN250 may be connected to different subscriber locations using different media and techniques without departing from the spirit and scope of the present invention. Such other implementations are not to be regarded as a departure from the scope and spirit of the invention.

The ISN250 processes data received over the various interfaces in order to provide desired service policies to different subscribers in accordance with the present invention. Although not shown, remote access device 240 may also be considered part of access network 290. The ISN250 may also be directly connected to the internet without relying on the data switch 280. Generally, if the implementation of the ISN250 does not include routing functionality, a data switch 280 will be required.

The desired service policies are specified by or translated into processing rules that indicate the manner in which data corresponding to applications of different subscribers needs to be processed. In order to enable different groups of bits to be correlated with different applications, ISN250 may combine groups of bits into packets containing the necessary information. Processing rules are then applied to the packets to provide the desired service policies. Data switch 280 may receive the bit set from ISN250 and connect to other external systems in the internet. The data switch 280 may correspond to an IP router, ATM or frame relay switch, according to a predefined design.

As also shown in fig. 2, the ISN250 has particular application to remote access service providers such as ISPs and LECs (which are obligatory or competitive). The ISN250 of the present invention may be located at the edge of the remote access network 290 (i.e., in connection with subscriber devices) as it can provide the desired service policies to various subscribers. In this case, ISN250 may be referred to as an edge device, ingress/egress router, or gateway.

As will be apparent from the following description, the use of the ISN250 at the edge enables subscriber devices (e.g., router 220) to be implemented with a lower level of complexity and thus provides easier management and lower cost. This feature is particularly important for ISPs and LECs. Accordingly, fig. 3 illustrates the manner in which a desired service policy can be provided to each subscriber.

6. Providing differentiated services with edge devices

Fig. 3 is a flow chart illustrating the manner in which a service provider may provide differentiated services to subscribers in accordance with the present invention. In step 310, the ISN250 of the present invention is provided as an edge device in the access network shown in fig. 2. Since the IP protocol is widely used by various systems, the ISN250 may be implemented as one IP router.

In step 320, different service policies may be specified for each subscriber. Service policies may specify-for example-the total bandwidth that can be used by a certain subscriber or some system used by the subscriber, firewall parameters (which applications/IP addresses are allowed to go out/in), security for specified sessions (e.g., virtual private network with encryption and tunneling against spoofing), priority in the use of buffers and bandwidth (e.g., giving higher priority to interactive applications such as telnet), communication control (traffic), etc. An example of specifying a service policy is described in more detail below.

In step 325, processing rules corresponding to the service policies may be generated. Each processing rule contains a classifier and associated operations. The classifier specifies all data streams and any conditions under which the correlation operation needs to be applied to the data on that data stream. In an IP environment, each data stream, in turn, may be uniquely identified by a protocol type, source/destination IP address, and (TCP/UDP) source/destination port. The classifier may specify a plurality of data streams.

The condition may be specific to the type of service policy in effect. For example, a subscriber may be allowed higher bandwidth during non-business hours. Another subscriber may have data assigned a lower priority if the data is to definitely reach a particular subscriber during a specified time. These conditions will be illustrated in more detail below in conjunction with fig. 6B.

Many processing rules may be pre-generated when a service policy is specified. However, for some processing rules, the necessary information may not be available in advance. In this case, the rules are dynamically generated when the information is available. Some cases of dynamically generating processing rules are described below by way of example.

An example of a situation requiring dynamically generated rules is where a subscriber uses a dial-up connection with the access network 290 and relies on the access network 290 to assign an IP address. For example, with respect to FIG. 2, subscriber location 230-A may correspond to a computer using a modem. When the user establishes a dial-up connection, the IP address of the machine at user location 230-a may be assigned by an authentication-authorization-access (AAA) server-as is well known in the relevant art. Assuming that a processing rule requires an assigned IP address, the processing rule can only be generated after the assignment of the IP address.

Another example is that for some applications, a data stream may be started in the middle of an application session, and the port information is only available after the corresponding data stream is started. Port information is typically determined during a negotiation between two end systems. The port information is typically contained in packets that serve as the basis for negotiation.

Accordingly, the ISN250 may have to monitor packets on some flows to determine port numbers of other flows. The ISN250 may then use the determined information to generate processing rules with classifiers and associated operations.

In step 330, the processing rule is instantiated in the ISN 250. Instantiation generally refers to the activation of processing rules by appropriate configuration of the ISN 250. Once instantiated, the ISN250 applies processing rules to the respective subscribers, as explained in more detail below.

It may be noted that some of the processing rules may be pre-instantiated, for example, at startup of the ISN250 or upon specification of a desired service. Other processing rules may be instantiated as generated in step 325 as described above.

In step 340, the ISN250 may receive the bit group in accordance with the particular interface provided to the subscriber device. In step 360, the bit groups are converted into packets suitable for applying the processing rules. The bit group itself may be processed in packets without translation if the bit group contains enough data for applying the processing rules. For example, if the bit group corresponds to a complete IP packet without segmentation, assembly (assembling) may not be needed. If the bit group is an ATM cell, the payloads of the multiple cells can be combined (assembled) to form an IP packet.

In general, if an IP packet is fragmented, it may sometimes be desirable to further combine data in multiple IP packets into a single packet. For example, the fragmentation may be performed to make the length of each IP packet small enough to fit the maximum packet length allowed by an intermediate network in the connection path. The combined packet will also be referred to as a packet. In summary, multiple levels of assembly of bit groups can be performed to determine whether subscriber data (received in bit groups) matches a classifier.

In step 380, the packets are processed according to the processing rules provided for each user. That is, each packet is first associated with a subscriber and then the processing rules corresponding to that subscriber are applied. As is well known in the related art, one IP address may be shared by a plurality of machines during remote access. Accordingly, a virtual channel number (e.g., VCI/VPI combination in ATM, DLCI in frame relay) may first identify a subscriber and then may apply the subscriber-associated processing rules to packets received or transmitted on that channel.

In some cases, multiple subscribers may share a channel identifier. For example, when a subset of the network 210 is considered a subscriber, the subscribers of the network 210 may share a single channel. In this case, the IP addresses may be designed to be non-overlapping so that different flows are uniquely associated with different subscribers. Similarly, the ISN250 may receive packets destined for each subscriber on a channel. In this case, the ISN250 may need to check the IP address and other information to associate the packet with the subscriber.

To ensure a predictable and desired service policy, the processing rules may need to be applied in one of several possible orders. In summary, the process determines if/where/how to forward the packet and at what priority to forward the packet. To implement a processing rule, several "states" need to be saved in the ISN 250. For example, if a predetermined total bandwidth is to be allocated to multiple streams, it may be necessary to maintain the number of bits transmitted for the multiple streams to limit the total bandwidth. The data in the packet typically needs to be forwarded on the interface that houses the next system in the connection path.

Therefore, by applying the processing rules to the different packets, each subscriber can be provided with the desired service features. The method of fig. 3 may be implemented in several ISNs. Embodiments of the ISN250 are described more information below.

7. Internet service node

FIG. 4 is a block diagram showing details of ISN250 in one embodiment. ISN250 may include access ports (410-A and 410-B), trunk ports (420-A, 420-B, and 420-C), switch fabric 440, packet service cards 450-A and 450-B, routing/service management card (RMC)460, and configuration manager 470. Trunk ports 420-A, 420-B, and 420-C will be referred to collectively or individually by 420, where the context is clear. Similar conventions apply for other components described in this application.

It may be noted that packet service card 450 is physically separate from ports 410 and 420. This physical separation enables the number of packet service cards 450 to be changed independently of the number of ports 410 and 420, and vice versa. This flexibility makes ISN350 well suited to serve a large number of subscribers.

The access port 410 provides the necessary physical interface for receiving and transmitting cells in a predetermined format. Protocols such as Sonet may be used for the high speed interface. For purposes of this detailed description, it is assumed that the access port 410 will send and receive data in the form of ATM cells. Each access port 410 forwards ATM cells to the switch fabric 440.

Trunk port 420 provides a high speed access line for internet access to subscribers. Trunk port 420 receives ATM cells (or other groups of bits) from switch fabric 440 and forwards these cells on corresponding lines specified by channel identifiers (or other destination addresses). Similarly, trunk port 420 may receive groups of data bits in the form of ATM cells or IP packets from the internet and forward these groups of data bits to switch fabric 440. In such a reception scenario, higher layer protocol information (e.g., IP headers) may need to be examined to determine the particular processor group to which the data is to be forwarded. Once the data is received by the respective processor group, the data is examined to determine the particular subscriber to which the data relates, and the corresponding processing rules to be applied.

In one embodiment, multiple ports are provisioned on a line card, each of which can be configured as a trunk port or an access port. Line cards can support different access technologies such as frame relay, ATM, Sonet packets, fast ethernet, gigabit ethernet.

The configuration manager 470 provides a convenient user interface for implementing different service policies specified for different subscribers. The service policy determines the services offered to different subscribers. Configuration manager 470 may communicate various configuration parameters (as determined by the service policies) to RMC460, which RMC460 in turn configures the different components to provide the service policies. In one embodiment, the configuration manager 470 is implemented as a separate computer system that interacts with the ISN250 according to a predetermined protocol. In another embodiment, the configuration manager 470 may be integrated in the ISN 250.

The configuration manager 470 may translate the service policies into processing rules when information is available and provide the processing rules to the corresponding packet service cards 450. Packet service card 450 may instantiate these processing rules for the corresponding subscriber. For example, the configuration manager 470 may interact with an authentication-authorization-access (AAA) server to determine when to assign an IP address to a subscriber accessing the access network through a dial-up connection and provide processing rules corresponding to the subscriber to one of the packet service cards 450.

The routing/service management card (RMC)460 implements a routing protocol such as open shortest Path First (OSPF-openshort Path First), RIP, or BGP to determine the next hop (hop) (or forwarding information in general) for each IP packet. The routing protocol can be performed in a known manner. RMC460 may provide forwarding information in the form of VCI/VPI information for identifying the next hop for an IP packet.

In addition, RMC460 may also configure different components of ISN250 to implement different functions of the present invention. With respect to L2TP, RMC460 may be designed to handle requests to establish L2TP tunnels and intra-tunnel calls. RMC460 may provide the call ID, tunnel ID, and any other necessary information to the corresponding access/trunk port that receives the data associated with the tunnel. The access port can then use this information to assign IP packets received in the tunnel to a particular packet service card 450.

The switch fabric 440 receives the bit sets from the access ports 410 and forwards the received bit sets to the packet service card 450 after receiving the data for the entire packet. If the data bits are received as ATM cells, the last cell of a packet may be determined according to AAL5 protocols well known in the relevant art. Thus, once the data for a packet is available, all cells that make up a frame can be sent to the appropriate packet service card 450. Different service policy types may be implemented in different packet service cards 450. Accordingly, each subscriber (using the connection or subscriber identifier) may be assigned to a packet service card that provides the desired type of service policy.

To determine the appropriate packet service card, switch fabric 440 may maintain a channel identifier associated with each channel on which a bit group is received. In the case of ATM cells, the VCI/VPI information in the byte uniquely identifies such a channel. If the data is received directly from a subscriber and destined for the internet, the physical port number and channel identifier (where the data was received) can uniquely identify each subscriber (or a group of non-overlapping IP addresses). On the other hand, if the data is received from the internet, it is determined that the relevant subscriber checks the IP header. In summary, the switch fabric 440 may buffer each cell until the last cell of the packet is received, and then forward all cells of the packet to the packet service cards assigned to the respective subscribers.

Switch fabric 440 receives cells from access ports 410 and trunk ports 420 and forwards these cells to a packet service card 450. The switch fabric 440 may forward the received cells to the packet service card 450 when the data of the entire packet is received. Switch fabric 440 may use a high speed random access memory (not shown) to buffer each cell while waiting for the last cell to arrive. The last cell of a packet may be determined according to the AAL5 protocol, which is well known in the relevant art. Thus, once the data for a packet is available, all cells making up a frame can be sent to the appropriate packet service card 450.

Switch fabric 440 may receive packets from packet service cards 450 after processing according to service processing rules and transmit the received packets on one trunk port 420. The particular trunk port 420 may be determined by contacting the particular trunk port 420 for each channel, which may also be identified by a channel identifier provided by the packet service card 450. Switch fabric 440 may convert these packets into cells before transmission on trunk port 420.

The packet service card 450 may be configured with a number of processing rules per subscriber, where each processing rule contains a classifier and associated operations. The classifier generally specifies the data flow and any conditions to be followed to apply the operation to the set of data bits transmitted on the data flow in order to provide the desired service policy to each subscriber. In an Internet Protocol (IP) environment, source/destination IP addresses, source/destination ports, and protocol type fields together typically define an IP data flow that supports a particular remote access application.

Each packet service card 450 may be configured to correspond to a number of processing rules for a subscriber for several reasons. For example, by assigning each subscriber's data processing to a particular packet service card 450, each packet service card 450 may only need to be configured with the processing rules corresponding to the subscriber assigned to it.

Multiple packet service cards 450 may be employed to fit well into a complex large environment. In addition, some packet service cards 450 may have special functionality for handling some types of subscriber data.

The packet service card 450 may first assemble the cell data into packets that can be used for subscriber identification. Once determined, the subscriber can determine the flow to which the packet relates and then apply the corresponding processing rules. In this process, the packet service card 450 may determine whether to drop or forward the packet. The packet service card 450 may process the received cells according to the subscriber's processing rules to provide the desired service policy for each particular subscriber.

Packet service card 450 may determine the next hop for the packet based on routing information provided by route management card 460 or a cell header associated with the incoming cell. A new VCI/VPI number is generated for all cells to be generated from the processed packet according to the next hop. The packet service card 450 sends each cell with the new VCI/VPI number to the switch fabric 440 for forwarding on the appropriate trunk port 420.

Although each subscriber is said to be assigned to one packet service card 450, it should be understood that multiple packet service cards may handle data associated with a single subscriber. This is often the case when one of the packet service cards is designed to provide a particular special service that suits all/many subscribers, while the other packet service cards are designed to provide the remaining services desired by the subscribers. In this case, the switch fabric may be used to forward data processed by one of the service cards to another packet service card in a predetermined order. The processors in all such packet service cards may also be referred to as processor groups.

By applying processing rules to each packet, the packet service card 450 may enable the ISN250 to provide several features in accordance with the present invention. Several embodiments of the packet service card 450 may be implemented without departing from the scope and spirit of the present invention. An example implementation is described below.

8. Packet service card

Figure 5 is a block diagram illustrating details of one embodiment of a packet service card 450. Packet service card 450 may contain four processor groups (550-a to 550D), a Processor Interface (PIF)530, and control logic 520. The operation of each block is described in detail below.

Control logic 520 coordinates and controls the operation of the other components in packet service card 450. Control logic 520 may determine which of the processors in the processor set is capable of processing the packet. In one embodiment, the packets are distributed among the four processors in a round robin fashion. The control logic 520 is operable with the configuration manager 470 to instantiate (configure) the processor complex 550 with processing rules associated with the assigned subscriber.

When implementing a service policy requires dynamic instantiation of a processing rule based on examining data transmitted in a data flow, control logic 520 may examine the data flow and generate a new processing rule. By way of illustration, in h.323, voice-over-IP (voice-over-IP), or streaming applications (streaming applications), new connections, or data streams can be created dynamically based on negotiations implemented in the control stream. Control logic 250 may examine the control flow to determine any necessary information (e.g., port numbers) and create processing rules based on the examination. The control logic 250 may configure the processor complex 550 to ensure that the processor complex 550 performs the operations specified by the processing rules. The control logic 520 may in turn be controlled due to the service policies specified with the configuration manager 470.

PIF530 may receive cells from switch fabric 440 and forward the cells (which constitute an IP packet) to one of four processor groups 550. In one embodiment, PIF530 may have four inputs corresponding to four processor groups, and switch fabric 440 may send these cells on one of the four ports (and thus to a particular processor group) as determined by the VCI header information. That is, the VCI header can determine not only the packet service card, but also the particular set of processors that process the received cell.

Each processor group 550 may be uniquely assigned to several subscribers. RMC460 may generate the necessary commands to configure each processor complex 550 with the processing rules associated with the assigned subscriber. RMC460 may determine which particular processor group 550 is to process each subscriber-related data and configure the corresponding processor group with the processing rules associated with the assigned subscriber. The configuration command may be issued through the processor interface 530.

Each processor group 550 may contain several processors and an SRAM (not shown) for storing cells associated with a packet. The SRAM may be shared by all processors contained in the processor set 550. All of the processors in processor set 550 are capable of processing all of the data associated with the assigned subscriber. The particular processor that processes the packet while the group of processors is determined by the channel identifier associated with each cell may then be determined by control logic 520.

Since each subscriber can be assigned to a certain processor group 550, the service provider can service more subscribers by adding additional processor groups. Therefore, the solution provided by the invention is well suited for large networks. Furthermore, a certain processor group may be designed to serve the specific policy requirements of a certain subscriber. For example, only processor group 550-B may be designed to provide a Virtual Private Network (VPN), and all subscribers requiring a VPN may be assigned to processor group 550-B. Some service policies are illustrated in more detail below with reference to fig. 6A and 6B.

9. Examples of service policies

Fig. 6A and 6B collectively show an example of a subscriber policy for a subscriber. For purposes of this detailed description, each packet is said to be processed according to a first matching policy. However, it will be apparent to those skilled in the relevant art that other matching strategies, such as a "best match" strategy, may be used.

Fig. 6A shows how different policy rules can be specified for implementing security (security). It is first noted that the selection of the classifier of the security policy includes only the data needed to identify the flow (unconditional). A classifier specified by the service rule 610, IP address susa or office 1, destination IP address susa or office 1, service IMAP, and encrypt matching data using 3xDES encryption protocol. That is, the mail exchange between Subsa and office 1 is encrypted using the specified protocol.

To implement service rule 610, two processing rules may be generated, each having a classifier that specifies a flow. In general, each processing rule may be generated in the form of a five-tuple comprising a source IP address, a destination address, a protocol field (e.g., TCP or UDP), a source port number, and a destination port number.

At least some of the service rule parameters are available in advance and can therefore be statically translated into corresponding processing rule parameters. Therefore, assuming that the IP address susa and office of the service rule 610 are known in advance, two processing rules can be generated from the service rule because the TCP port number of IMAP is predefined.

However, if one of the IP addresses (e.g., Subsa) is to be dynamically generated, for example, because the user system needs to establish a dial-up connection, the user interface 470 may dynamically generate the processing rules after the user is assigned to the IP address. The processing rule may also be instantiated dynamically.

Service rules 620 attempt to accept and encrypt HTTP, SMTP and TELNET traffic (traffic) from or to susa. Processing rules may be generated for each of HTTP, SMTP, and TELNET. The protocol types and port numbers of these three applications are pre-specified, and the processing rules can be generated statically, assuming that the IP addresses (of the susa and other offices) are also known.

The service rules 630 accept all HTTP traffic destined for the susa-Web-Srvr. The service rules 640 accept all SMTP traffic related to Subsa-Web-Srvr. The service rules 650 accept all traffic from susa-Subsets. The service rules 660 discard all other data and record the discarded data for later accounting or analysis. It can be readily appreciated that the method of fig. 6A can be used to achieve subscriber-specific security requirements. Different subscribers may have different policy rules to suit their individual needs.

In the method of fig. 6A, each classifier generally includes information required to identify a stream. The classifier may include service policy specific conditions-as shown in fig. 6B, which represents service policy rules for policing (policing) in one embodiment. Policing generally refers to the prioritization and allocation of bandwidth to different connections that share available bandwidth.

The service rules 680 specify that if data is being received on SubsAlink-In with a total bandwidth of less than 1Mbps and a continuous bandwidth of less than 500Kbps, the data must be retransmitted with the type of service (TOS). The persistent bandwidth, and the total bandwidth, may be measured according to one of several known methods. The classifier specifies that the rule applies to all TOS at any time of day. TOS, time, location, and line condition (lineconnected) are all conditions for policing service policies.

If the line condition of the service rule 680 is violated, the service rule 680 lowers the priority of the data. Since the ISN250 of the above embodiment regenerates the data-bit groups before transmission on trunk port 430, the TOS value can be reduced in a known manner.

If at least the above embodiments are employed, each subscriber can be provided with a specific service policy by the ISP. As mentioned above, the present invention is particularly useful for remote access applications.

Furthermore, the implementation of the ISN250 as an edge router enables simple equipment to be deployed at the subscriber. Illustratively, without the present invention, a subscriber located in the network 210 of FIG. 2 may need to be equipped with a complex router 220 to provide different service policies. The overhead may be unacceptably high. In contrast, if the present invention is employed, the desired service policies can be provided by a central remote access provider using the appropriate configuration of the ISN250, thereby simplifying the configuration and management of equipment at the subscriber site.

However, one requirement associated with internet service nodes is that data associated with a subscriber is quickly and efficiently allocated to a particular processor for processing, so that the solution of the present invention can be used in an environment where there are a large number of subscribers. The following describes some of the problems associated with such an allocation and solution according to the invention.

10. Problems in assigning to processors

It can be noted from the above description that the switch fabric 440 may need to allocate cells of an IP packet to a particular processor group 450. Since the switch fabric 440 can receive cells on different access ports and trunk ports, the assignment to a particular processor group 450 may need to be made quickly (in a short time).

For expeditiousness, the assignment may be based on an examination of the cell header. In the following further description it will be assumed that the allocation is based only on VPI. However, other portions of the cell header may be used in the allocation of cells-without departing from the scope and spirit of the present invention. As cells are received on the access port 410, the VPI number of each connection on which the cell is received can be controlled to correspond to the identifier of that particular processor group 450-as will be apparent to those skilled in the relevant art.

However, when cells are received on trunk port 420, multiple subscribers typically share the same ATM virtual connection. Subscriber data for different subscribers received over the same ATM connection may need to be allocated to different processors. In this case, it may be necessary to examine the data in each ATM cell to determine the particular processor that processes each ATM cell.

In the case of an IP network, it may be necessary to examine the IP destination address contained in the payload of the first ATM cell of an IP packet to determine the (subscriber) processor to which the IP packet is to be assigned. As is well known in the relevant art, a series of cells represents an IP packet, the first cell typically containing an IP destination address. Therefore, when cell data is received from trunk port 420, it may be necessary to check at least the IP header information.

The need to check cell data is not limited to the case where cells are received on trunk port 420. When a cell is received on the access port 410, the cell data may also need to be examined. For example, when cells are involved in applications such as tunneling (e.g., L2TP and L2F) and IP security (typically containing data related to multiple subscribers on the same virtual circuit), further inspection of the header data of higher layers (e.g., UDP, TCP) may be required to determine the particular processor that processes each cell.

For simplicity, this requirement is explained with reference to L2 TP. It should be understood, however, that the present invention may be applied to other applications. The use of the present invention in the context of such applications is considered to be within the scope and spirit of the present invention.

In L2TP, all IP packets using one tunnel share the same IP destination address, i.e. one of the IP addresses assigned to ISN 250. However, L2TP is typically implemented on top of the UDP protocol type, the UDP port number identifying that the IP packet is associated with a certain L2TP tunnel. The tunnel ID and call ID fields in the UDP packet further identify the particular subscriber to which the IP packet relates. The processor for processing may be determined based on the identity of the subscriber. Therefore, further inspection of the header of the higher layer protocol (UDP) or other information in the packet may be required to determine the subscriber information.

To enable the switch fabric 440 to assign each cell to one of the packet service cards 450 based on an examination of the cell header, a different cell header (or other identification data) may be exchanged to enable the switch fabric 440 to assign each cell to the packet service card 450 identified by the cell header. Such a replacement may be required in both of the above examples. Such higher-level protocol checks and replacements may need to be done in real-time to avoid extensive caching.

The invention enables inspection of cell headers and replacement of individual memory cells with masked CAMs. The operation of the CAM with the mask of the individual memory cells is first described in summary. The invention is then illustrated.

11. CAM with masks for individual memory cells

To understand the efficiency achieved by a CAM with a mask of individual memory cells, the operation of a conventional CAM is first described with reference to fig. 7A. The CAM710 contained in FIG. 7A typically provides only one mask for access. In the illustrated CAM710, each CAM cell 720-A, 720-B, etc. has a search field 711 and an output data field 715.

In operation, an input value and mask are received on the value bus 701 and mask bus 702, respectively. Each input value and mask has a number of bits equal to the length of the search field (the number of bits of the search field 711). If the input value at the bit position specified by the mask bus 702 matches (i.e., is equal to) the corresponding bit in the search field 711, the data stored in the output field 715 is generated as output on the output bus 749. That is, only each of the bit positions specified by the mask 702 may be compared.

Therefore, if matching of different bit positions in different memory locations 720 of the CAM710 is required, a corresponding number of accesses (each with a different mask) may be required.

It will be appreciated that IP header (including UDP/TCP/ICMP information) data identifying each subscriber may be stored in each memory unit 720 and the IP header data in the first cell of a received IP packet may be provided as value 701. However, different mask values may need to be provided on mask bus 702 because the bit positions to be checked differ from case to case (e.g., the IP destination address needs to be checked when the difference is based solely on the IP destination address; for L2TP, the IP destination address, protocol type, UDP port number, tunnel ID, and peer ID may need to be checked).

That is, multiple CAM accesses may be required, each with a corresponding mask representing the bit positions checked for subscriber matches. Such multiple CAM accesses can take an unsatisfactorily long time and are therefore unsatisfactory.

Another embodiment may use multiple CAM710 cells, each CAM having a particular mask serving subscriber. However, multiple CAMs may also be unsatisfactory, at least from a cost perspective. As described below, the need for multiple accesses may be avoided with a single CAM having masks for the individual CAM locations.

FIG. 7B is a block diagram of CAM750 having multiple memory cells (770-A, 770-B, and 770C). The CAM may include an input bus 751, a search field 761, an output field 765, and an output bus 799, which are similar to input bus 701, search field 711, output field 715, and output bus 749, respectively, of fig. 7A. In addition, CAM750 also includes a mask field 764, which stores a mask associated with each storage unit 770. Thus, rather than all memory cells sharing a mask, each memory cell of CAM750 has an associated mask.

In operation, when an input value (input bit) is provided on input bus 751, only the bit position of each CAM memory cell specified by the corresponding mask is compared to the input bit, and the output value in the output field 765 of the matching memory cell is provided on output bus 799. The output value may (directly or indirectly) identify the processor to which the cell (or packet) is assigned for further processing.

Therefore, different masks can be used for different memory locations. Each mask specifies the bit positions to be compared. The bit position itself is determined by a particular field to be compared in the determination of the processor processing the cell-as exemplified below.

12. Reference to an instantiation of an IP environment

This section illustrates how a subscriber (and thus a processor for processing) is determined in two scenarios: (1) when the IP destination address uniquely identifies the subscriber; (2) for L2 TP. In the description in this section, it is first described how IP packets can be identified with the corresponding subscriber. It is then illustrated how this identification can be used for the allocation of cells in one embodiment.

In summary, it should be understood that the bit positions to be identified are related to the particular format used by the protocol. Details regarding IP and L2TP may be found in "query for Commerts RFC" 768, 791, and 1483, which are incorporated herein by reference in their entirety.

For case 1, to determine a matching destination IP address in version 4.0 of the internet protocol, the following bit positions (expressed in byte boundaries, where each byte contains 8 bits) may need to be examined to determine the following relationship:

byte 1: the IP version number is 4; the header length is 20 bytes;

bytes 17-20: the destination IP address of the received packet is the IP address assigned to the particular subscriber.

Similarly, when receiving subscriber data using L2TP, the following bit positions (i.e., unshielded in the mask) may need to be checked to identify the subscriber (to which the IP packet relates) and thus the processor:

byte 1: the application is as above

Byte 10: protocol type UDP

Bytes 17-20: destination IP address of received packet-IP address of one interface of ISN250

Assuming an IP header length of 20 bytes, the following bytes are checked:

bytes 23-24: destination UDP port number ═ port number of L2TP protocol

Bytes 29-30: l2TP version, length, and header information

Bytes 31-32: if the length does not exist, the tunnel ID assigned to the subscriber is the tunnel ID specified by the received IP packet

Bytes 33-34: if the length exists, the tunnel ID assigned to the subscriber is the tunnel ID specified by the received IP packet

Bytes 35-36: the call ID of the received packet is the call ID assigned to that particular subscriber.

So in summary, each search may require checking some bit positions identifying packet format, version number and application type (e.g., L2TP) and other subscriber-specific bit positions (e.g., call ID and/or tunnel ID for the L2TP case, the destination IP address in the first example above). When all bit positions match, the received IP packet can be mapped to the subscriber associated with the matched memory location.

With continued reference to FIG. 7B, one CAM memory cell may be allocated for each search. For example, CAM memory cell 770-A may be allocated for a search of the type described in example 1 above, and CAM memory cell 770-B may be allocated for a search of the type described in example 2 above. Mask field 764 of CAM storage unit 770-a may have the bit positions corresponding to bytes 1, 17, and 18 unmasked (set to 0) and the remaining bits may be masked (set to 1). The search field of CAM storage unit 770-a may contain data identifying the IP protocol version number, length, and IP address identifying a certain subscriber system in the corresponding bit position.

The contents of CAM storage unit 770-B may be similar. The bit positions of the bytes may be unmasked as described above. The search field 761 may be set with an appropriate value at a corresponding location, where the tunnel ID and/or call ID uniquely identify a certain subscriber.

If more than one protocol format needs to be supported, multiple entries may be required to determine the subscriber. For example, in the above example 2, if the length field does not exist, it may be necessary to provide an entry for checking the bytes 31 and 32; if a length field is present, another entry may need to be provided for checking bytes 33 and 34. Similarly, more entries may need to be provided if the subscriber is likely to use a different version of the IP protocol (e.g., IP version 6). In summary, the entries in CAM759 define a search tree, with each leaf identifying a subscriber. Multiple leaves may identify the same subscriber.

Once header data (for IP and higher protocol data) is provided as input on input bus 751, the data stored in output field 765 is provided as output on output bus 799. It will be appreciated that data identifying a plurality of subscribers may be stored in the storage unit 770, with a match being detected in one access.

However, the width of the search field (and thus the width of the mask and input) may require at least 40 bytes (320 bits) to thoroughly check the IP header and higher layer information. Commercial embodiments of masked CAMs, with individual memory cells, are often small in width. At least to address this width issue, the following optimization may be employed.

13. Optimisation

In one embodiment, assuming an IP header length of 20 bytes and employing IP version 4, only bytes 1, 7, 8, 10, 13-15, 17-20, 23, 24, and 27-36 of the IP packet are examined. However, it will be apparent to those skilled in the relevant arts that different bit positions may be searched for depending on the particular application in light of the description provided herein. Such a search is also considered to be within the scope and spirit of the present invention.

The above bytes contain information of applications such as L2TP, L2F, IPSEC, etc., which are well known in the related art. By bypassing other bytes during the search, the required CAM width is minimized to 24 bytes (192 bits). However, it is possible to operate with CAMs of smaller width. In the embodiment described below, a CAM having only 112 bits (14 bytes) in the search field 761 may be provided.

In this case, a search may be split into a series of searches, with subsequent searches being made only if previous searches in the series match. When all searches in the series match, indicating that the received IP packet is relevant to the subscriber involved in the series search, the IP packet is processed by the processor specified by the output of the CAM.

The operation of an insufficient-width CAM is described below in conjunction with L2 TP. These CAMs can be implemented in access port 410 and trunk port 420. By way of illustration, an implementation in trunk port 420 is described below.

14. Trunk line port

Fig. 8 is a block diagram showing the implementation and operation of a circuit according to the present invention. Framer (framer)810 may provide an electrical interface when receiving subscriber data. Framer 810 may assemble bytes from the received bits and then provide the assembled bytes to allocation logic 850. These bytes constitute cell data. A switch interface (switch interface)880 receives cell data from the distribution logic 850 and forwards the received data to the packet service card 450. Framer 810 and switch interface 880 may be implemented in a known manner.

IP table 860 causes IP packets to be assigned to processors based on source or destination IP addresses. In particular, by using the IP table 860, the present invention may minimize the number of CAM storage units needed to support multiple subscribers. A CAM lookup may be used to first generate an index and then the data in table 860 may be used to further determine the particular processor group to which the IP packet is to be assigned.

Processor interface 830 may be coupled to RMC460 and configure CAM820 to enable data associated with each subscriber to be assigned to a particular processor group in accordance with the present invention. Processor interface may further configure IP table 860 and VC table 870 under the control of RMC 460. As related to L2TP type protocols, processor interface 30 may receive tunnel-related data (e.g., call ID, tunnel ID, and corresponding processor information) from RMC460 and configure CAM820 to assign IP packets associated with a subscriber to a particular processor group. CAM820, VC table 870, and IP table 860 may be shared by all access and trunk ports in ISN 250.

VC table 870 may store data representing a mapping (mapping) of VPI/VCI header information in ATM cells to unique connection identifiers. Therefore, VC table 810 returns a connection identifier in response to receiving VPI/VCI header data. IP table 860 and VC table 870 may be implemented with a high speed memory such as SRAM.

The CAM820 may be similar to CAM750 of FIG. 7B and contains a mask for each CAM memory cell. The mask and search fields are configured to enable a quick determination of matches. How the CAM820 needs to be configured will become apparent from the following description.

The output of the CAM820 may represent an identifier. The identifier either directly represents a processor or group of processors or may serve as an index (index) for further searching. In the embodiments described herein, the identifier represents a group of processors or an index to IP table 860. The output of the CAM820 may also specify whether the output should be interpreted as an index or an index for further searching.

The allocation logic 850 receives each IP packet in the form of a series of cells and determines the set of processors on which to process the IP packet. To make this determination, allocation logic 850 typically selects the relevant header bytes (IP header and necessary upper layer headers) from the first of a series of cells that make up the IP packet. The selected byte is used as an input to the CAM 820. The output of the CAM820 represents the identifier described above.

In one embodiment, the cell header is modified for the entire sequence of cells that make up an IP packet, the modified header identifying the processor(s) on which the IP packet is processed. An embodiment of a packet service card 450 that uses a modified cell header to assign to an identified processor(s) is described in more detail below in conjunction with fig. 9 and 10. These two figures further illustrate the multiple CAM searches that are employed when the search field of the CAM is not of sufficient length.

15. Method of producing a composite material

Fig. 9 is a flow chart showing how the present invention can allocate IP packets relating to a certain subscriber to processor(s). In step 910, a mask specifying the bit positions to be checked and a search field specifying a specific value (from the packet header) identifying the subscriber are configured in each CAM storage unit. As described above, in one embodiment, RMC460 and processor interface 830 may be configured in this manner. The following is a description of considerations that are typically taken into account in some scenario cases.

Some entries of the CAM820 may be dynamically configured as the ISN250 runs and processes subscriber data. For example, when a subscriber establishes a dial-up connection over a telephone line and is assigned a new IP address, an entry may be established based on the IP destination address.

Some other entries of the CAM820 may be statically configured. For example, when multiple subscribers share the same ATM virtual connection and are connected to the same access port, and if the IP address used by each subscriber is known, a CAM entry may be configured for checking the source IP address.

In one embodiment, each subscriber may be assigned a single entry and can be uniquely identified by a single (source or destination) IP address. One problem with using one item per subscriber is that the number of storage units required in the CAM820 can be unreasonably large. A large amount of storage is required, which is a problem at least in IP environments where each subscriber is assigned a unique address when dialling into an ISP network. As described in detail below, the present invention can be used to minimize the number of memory cells required in the CAM 820.

Instead of assigning a storage location to each IP address, a storage location may be assigned to a group of IP addresses. The processor that processes the IP packet may be determined in conjunction with entries stored in IP table 860. For example, the first three bytes of the IP address may identify the group, and the output of the CAM820 may serve as an index to the base address of the IP table 860. The last byte of the IP address may be used as an offset address from the base address, and the location in IP table 860 at the offset address may contain the processor number.

When a single CAM location contains an index to a set of IP addresses, the mask for that CAM location may be selected to reflect such grouping. For example, the first three bytes of an IP address may represent a group and a mask of 00.00.00.ff. may be selected. Thus, the CAM search provides an index to the first of 256 (or 254-taking into account subnet broadcast) addresses. IP table 860 may be accessed to determine the processor that processes the received IP packet. How to retrieve the processor identifier from the IP table 860 is described in more detail below (with reference to steps 960 and 961).

In the case of a tunnel, as described above, to determine the processor to process an IP packet, an IP version number, a header length, an IP protocol type (i.e., for UDP), an IP destination address, a UDP destination port number, an L2TP version number, a tunnel ID, and a call ID may be checked. As described above, the necessary information generated during tunneling and call setup (callset-up) may be provided by RMC460, and CAM820 may be configured with appropriate masks and search fields.

In some cases, multiple subscribers may share the same tunnel. In this case, each subscriber may be uniquely identified by an IP address. To minimize the number of CAM lookups, all packets for a tunnel may be assigned to a single packet service card 450, and the processor in the assigned packet service card 450 may distinguish between different subscribers by examining the IP address encoded within the tunnel data.

In step 920, the first element of a series of cells that make up an IP packet ("header cell") may be received. The last cell of an IP packet may be determined according to the AAL5ATM standard, which is well known in the relevant art, and a subsequent cell may be considered as the first cell of the IP packet.

In step 930, allocation logic 850 may send the port number of the received cell, the VPI and VCI of the received cell to VC table 870, and receive a connection identifier and data indicating whether further searching is required. Further searching is typically required if the assignment of the processor(s) requires further examination of the IP packets made up of the cells.

In general, one data bit retrieved from VC table 870 indicates whether further searching is required. The header of each cell of the IP packet may be unchanged and passed to switch interface 880 if searching is not required. Then, if no further searching is required, control may be transferred to step 920; if further searching is required, control may be transferred to step 950.

In step 950, the assignment logic 850 may construct the first input value of the CAM820 by selecting some of the bytes in each cell that make up the IP packet. The bytes need to be selected according to the search field and mask used in the storage in step 910. The first cell typically contains all the data needed to construct the input value.

In one embodiment, ISN250 may support both LLC/SNAP and VCMux. VCMux can be generally established for a protocol (IP version 4 in this example), and LLC/SNAP contains a byte specifying an Ethertype field. The Ethertype field may specify IP version 4 or 6, or other protocols common in the context of this ethernet type. Only the details of LLC/SNAP and VCMux applicable to the present invention are provided herein. The reader is referred to RFC1483 for further explanation of these two protocols and is hereby incorporated by reference in its entirety.

To accommodate both LLC/SNAP and VC Mux protocols, one embodiment of allocation logic 850 may include the following bytes in the first input value:

bytes 1 and 2 (of the first input value): ethertype field of LLC/SNAP, for VC Mux, does not care (don't care).

Byte 3: byte 1 of the IP header

Bytes 4-5: bytes 7 and 8 of the IP header

Byte 6: byte 10 of the IP header

Bytes 7-9: bytes 13-15 of the IP header

Bytes 10-13: bytes 17-20 of the IP header

Byte 14: the following search type field

The search type field may indicate the different types of searches performed on the CAM 820. For example, this field may indicate whether this is the first search (i.e., step 950) or the second search (i.e., step 970 described below). This field may further indicate whether the incoming IP packet is received over a virtual connection of the LLC/SNAP type or a virtual connection of the VC Mux type. It is again noted that the search field in each CAM cell needs to be stored in the format of the input value. In general, the output from a previous search may constitute the type field for a second search.

The data in the search field 761 again needs to be stored in the format of the input value (i.e., the selected bytes and the order in which they were submitted to the CAM). The format of the input field in one example is described above

The output of the CAM820 may be checked in step 955 to determine if there is a match. If no match is detected, control transfers to step 955 where a default processor set may be selected to process the IP packet. If there is a match, control transfers to one of steps 960, 961, 970, and 980, depending on the output of CAM820, described below.

The output data of the CAM820 identifies the processor(s), either directly or indirectly. If direct identification, the data itself may contain a processor identifier. In the case of indirect identification, additional searches are typically required. To indicate whether the processor identifier is included in the CAM output, a flag may be added to the output. The flag identifies how the processor can be further determined.

If the flag has a first value (e.g., 1), the search for a matching entry is equivalent to a group of subscribers identified by the destination IP address. Then, in step 960, an entry may be retrieved in the IP table 860 having an address [ the predetermined base address identified by the retrieved index + the last byte of the IP destination address in the received IP packet ]. The retrieved item may contain a processor (group) identifier.

If the flag has a second value, the search for a matching entry is equivalent to a group of subscribers identified by the source IP address. Control then transfers to step 961. Step 961 performs similarly to step 960, except that the last byte of the source IP address (i.e., bits 120: 127) is used as the offset address from the base address identified by the retrieved index. Control transfers from steps 960 and 961 to step 980 where a processor identifier is selected from the results of the access to the IP table 860.

If the flag has a third value, the search results of the CAM search of step 950 contain a processor identifier. This may be the case, for example, when IP packets requiring a particular special service need to be allocated to a particular processor. Another example is when the received IP packet relates to a routing protocol such as OSPF. It may be desirable to configure the CAM entries according to the matching requirements as in step 910.

If the flag has a fourth value, control transfers to step 975, in which case further searching of the CAM820 may be required to determine the processor (group) identifier. These further searches may be required in the case of, for example, L2TP, L2F, IPSec, as will be apparent to those skilled in the relevant art. As described above, since the number of bits available in the search field of a masked CAM is limited (e.g., 112), a second level of search may be required. If the CAM contains a sufficient number of bits in the search field, multiple levels (searches) can be avoided and higher throughput rates can be achieved.

In one embodiment, the second input value to the CAM820 may have the following format (assuming an IP header of 20 bytes):

bytes 1-2 (of the second input value): bytes 23 and 24 representing the UDP destination port number

Bytes 3-13: bytes 27-37 of a received cell

Byte 14: type of search

The search type may indicate that the current search represents a second search, which may avoid any accidental matches. In one embodiment, the search type of the second search may be composed of bits of the output of the first search. It will be apparent to those skilled in the relevant arts that this format and the above-selected bytes are sufficient to search for IP Sec, L2TP, L2F, and many other protocols in light of the description provided herein.

If there is a match, the CAM output may contain a processor group identifier, and control transfers to step 980. In step 980, the appropriate bits in the output may be selected to represent the processor group identifier. If there is no match, control transfers to step 995 where a default processor identifier is selected. All IP packets that do not match may be sent to the default processor.

A processor group identifier is determined at the end of steps 980 and 995 and control then transfers to step 990 which illustrates an example method of ensuring that the identified processor group executes IP packets received in the form of a plurality of ATM cells.

In step 990, the VCI and VPI fields of all ATM cells constituting the IP packet are replaced with a connection identifier and a processor identifier, respectively. The last cell of the IP packet can be determined according to AAL5 of the ATM standard well known in the related art. Once the last cell is processed in step 990, control transfers to step 920 where the first cell of a subsequent IP packet is examined.

The method of fig. 9 therefore specifically illustrates an example of a method for efficiently assigning IP packets to predetermined groups of processors. The processor complex may be identified by the VPI field indicated above in step 990. As described above, the switch fabric 440 may forward each cell to the processor group identified by the VPI field. Since the processor group contains the processing rules of the subscribers to which the cells relate, the corresponding processing rules can be applied when processing the cells (or the IP packets formed from the cells).

Therefore, by replacing the VPI/VCI field of the ATM header, allocation logic 850 ensures that packets received in the form of ATM cells can be sent to the appropriate processor group. One embodiment of allocation logic 850 is described in more detail below.

16. Allocation logic

FIG. 10 is a block diagram that illustrates details of allocation logic 850 in one embodiment. Framer interface 1010 receives bytes from framer 810 and stores the received bytes in a cell memory 1020. Connection identification block 1030 receives the header bytes and sends the VPI/VCI data and port number to VC-table 870. Connection identification block 1030 receives a connection identifier from VC-table 870 if VC table 870 is preconfigured with data for the connection. If the connection data is not predefined, the cells can be sent to a pre-specified special processor group. The connection identification block 1030 may connect with the VC-table 870 using the SRAM interface 1040.

The Parser (Parser)1060 may perform all the steps of fig. 9 except for step 910 through connection with other components. The analyzer 1060 receives the connection identifier from the connection identification block 1030, the header data in the IP packet from the cell memory 1020, and then determines the processor group identifier. The analyzer 1060 may be coupled to the CAM820 via a CAM interface 1080 and to the IP table 860 via an SRAM interface 1040.

The analyzer 1060 can use the retrieved data to determine the VPI/VCI of each cell when replacement is needed. The analyzer 1060 may store a new value in the cell memory 1020 in place of the new VPI/VCI value. The cell memory 1020 may have enough memory to buffer each cell for a sufficient time when the analyzer determines new VPI/VCI data. The data in cell memory 1020 is sent to switch interface 880.

Thus, by replacing the VCI field of each cell with a processor identifier, analyzer 1060 can enable switch fabric 440 to quickly forward each cell to the appropriate processor group that processes the IP packet. In other words, the switch fabric 440 may only need to examine the cell header (a small number of bits) to assign subscriber data to a particular processor (group). The processor complex itself may be configured to provide service policies specific to the respective subscriber.

While the present invention has been described as distributing data to different processor complexes in order to provide different service policies, it will be apparent to those skilled in the relevant art from the description provided herein that the present invention may be practiced in other embodiments, and such other embodiments are considered to be within the scope and spirit of the present invention.

It should be noted that the embodiments of fig. 8-10 described above are merely examples of methods for implementing steps 140 and 150 of fig. 1. It will be apparent to those skilled in the relevant art from the description provided herein that other embodiments can be practiced without departing from the scope and spirit of the invention. Such other embodiments are considered to be within the scope and spirit of the present invention.

17. Final phrase

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the scope of the present invention should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (55)

1. A method of providing a desired set of service policies to each of a plurality of subscribers, the method comprising:

(a) identifying a plurality of processing rules that provide a set of service policies desired by each subscriber;

(b) configuring an Internet service node with the processing rules corresponding to each of the subscribers;

(c) receiving data in the internet service node;

(d) determining in the internet service node a particular subscriber to which the received data relates;

(e) the plurality of processing rules in the internet service node relating to the determined specific subscriber application, wherein the application is made after the determination.

2. The method of claim 1, wherein said internet service node is provided as an edge device of an access network, enabling control of service policies from the edge of said access network.

3. The method of claim 2 wherein said internet service node comprises an edge router.

4. The method of claim 1 wherein said internet service node comprises a plurality of processors, said steps (d) and (e) collectively comprising:

assigning each of the subscribers to a processor group, wherein each processor group is configured to correspond to the processing rules of the assigned subscriber;

after said determining of the specific subscriber, forwarding data associated with each subscriber to a corresponding set of processors.

5. The method of claim 4, wherein each processor group comprises a plurality of processors.

6. The method of claim 4, wherein data related to subscribers assigned to the set of processors is distributed among the plurality of processors in a round-robin fashion.

7. The method of claim 4, wherein end systems of the plurality of subscribers generate data using Internet Protocol (IP).

8. The method of claim 7, wherein said data comprises ATM cells.

9. The method of claim 8, wherein the determining comprises examining data contained in said ATM cell, said determining for a particular subscriber being based on the result of the examination and a port on which said ATM cell was received, wherein the port is included in said internet service node.

10. The method of claim 9, wherein the applying comprises:

determining in the port a particular processor group to which the data is to be forwarded, wherein the particular processor group is determined according to the particular subscriber to which the received data relates;

modifying the header of the cell to indicate the determined processor group such that the cell can be forwarded to the appropriate processor group based on examining the cell header, wherein the appropriate processor group is configured with processing rules associated with the particular subscriber.

11. The method of claim 10, wherein said determining is performed using a Content Addressable Memory (CAM) having a plurality of memory cells, each of said plurality of memory cells having a mask, a search field, and an output field, the CAM being configured to receive an input value and to compare the input value to data at bit positions in said search field of each of said plurality of memory cells specified by said mask, the CAM being configured to generate as output the data stored in said output field when there is a match with the corresponding memory cell.

12. The method of claim 11, wherein the data stored in the output field of the CAM either directly or indirectly identifies an identifier of a processor group, wherein each of the masking and searching fields is performed to store data identifying a subscriber such that the identifier can be determined using said data stored in said output field.

13. The method of claim 12, wherein a portion of a header of said ATM cell is replaced with said identifier such that said ATM cell can be assigned to a group of processors designed to process data associated with the subscriber by examining said header.

14. The method of claim 13, wherein the identifier is stored in a Virtual Path Identifier (VPI) or Virtual Channel Identifier (VCI) field of the header.

15. The method of claim 12, wherein bytes 1, 7, 8, 10, and 13-20 of an IP header are provided as inputs to the CAM.

16. The method of claim 13, wherein the switch fabric forwards the data to the set of processors based on examining headers of the ATM cells.

17. The method of claim 13, further comprising:

storing a mapping of virtual path identifiers/virtual channel identifiers (VPI/VCI) and port numbers to a nexus identifier in a Virtual Channel (VC) table, wherein each entry of the VC table further indicates whether a VPI/VCI of a received cell needs to be replaced;

accessing an entry in the VC table corresponding to a received cell contained in the received data, wherein a header of the received cell is modified only if data in the entry indicates that a VPI/VCI field is to be replaced.

18. The method of claim 17, further comprising:

setting a VCI of a cell constituting the received data to the connection identifier;

generating a processor identifier or a processor group identifier using the output of the CAM;

setting the VPI of the series of cells to the processor identifier or the processor group identifier, wherein the switch fabric forwards the series of cells to one of the processors using the VPI.

19. The method of claim 12, further comprising setting said mask of a memory location for checking at least some bit positions corresponding to an IP address, said search field of said memory location being set in conjunction with said mask to a plurality of IP addresses, wherein at least some of said IP addresses are associated with said subscriber.

20. The method of claim 19, each of said IP addresses comprising an IP source address.

21. The method of claim 19, each of said IP addresses comprising an IP destination address.

22. The method of claim 19, further comprising:

maintaining an IP table mapping each of said plurality of IP addresses to a processor identifier or processor group identifier; and

the processor identifier or the processor group identifier is retrieved using bits in the masked locations of the IP address of the IP packet and the output of the CAM, wherein the series of cells is assigned to the processor identified by the processor identifier or the processor group identified by the processor group identifier.

23. The method of claim 12, wherein said search field contains insufficient bits to store data identifying said subscriber, said method further comprising:

data identifying the subscriber is stored in a plurality of entries of the CAM whose outputs are to be checked in determining the processor identifier or processor group identifier.

24. The method of claim 23, wherein an output of one of the plurality of entries is used as an input to another one of the plurality of entries of the CAM, wherein the output of the another one of the plurality of entries identifies the processor identifier or processor group identifier.

25. The method of claim 23, wherein the received data related to the subscriber is tunneled using L2 TP.

26. The method of claim 25, further comprising:

providing as a first input bytes 1, 7, 8, 10, 13-15 and 17-20 of an IP packet contained in a first cell of received data;

bytes 23, 24 and 27-37 of the IP packet contained in the first cell are provided as a second input.

27. The method of claim 4, further comprising:

(f) storing a mapping of virtual path identifiers/virtual channel identifiers (VPI/VCIs) and port numbers to connection identifiers in a Virtual Channel (VC) table, wherein each entry of the VC table further indicates whether a VPI/VCI of a received cell needs to be replaced;

(g) accessing an entry in the VC table corresponding to a first cell;

(h) (ii) performing (c) - (e) only if the retrieved entry indicates that the VPI/VCI of the first cell needs to be replaced.

28. The method of claim 5, wherein (e) comprises:

(i) setting a Virtual Channel Identifier (VCI) of a series of cells to the connection identifier;

(j) generating a processor identifier or a processor group identifier with the output of (d);

(k) setting a Virtual Path Identifier (VPI) of a series of the cells to the processor identifier or the processor group identifier;

wherein the VPI is used by the switch fabric to forward the series of cells to one of the plurality of processors.

29. A method of providing a desired set of service policies to each of a plurality of subscribers, the method comprising:

(a) providing an Internet Service Node (ISN) as an edge router;

(b) defining a set of desired service policies for each of the plurality of subscribers;

(c) translating each of said desired service policies into processing rules, wherein each processing rule contains a classifier and an associated operation, wherein the classifier identifies a data stream to which said associated operation is to be applied;

(d) configuring the ISN with the processing rules;

(e) receiving a plurality of bit groups from a subscriber included in the plurality of subscribers;

(f) generating a plurality of packets from data contained in said plurality of groups of bits, wherein each packet of said plurality of packets may be associated with a data stream generated by an application of said subscriber;

(g) determining a data flow associated with each of the plurality of packets;

(h) applying the operation associated with the classifier that matches each of the data streams determined in (g);

thereby providing each subscriber of the plurality of subscribers with the respective set of desired service policies.

30. The method of claim 29, wherein end systems of the plurality of subscribers generate data using Internet Protocol (IP) and (f) comprises generating a plurality of IP packets.

31. The method of claim 30, wherein said set of bits comprises an ATM cell, wherein said plurality of packets are generated from said ATM cell.

32. The method of claim 30, further comprising maintaining a state of one of the plurality of service policies, wherein the state enables a plurality of data flows to be processed to satisfy the service.

33. The method of claim 30, further comprising maintaining a state for each of the data flows, wherein the processing rules to be applied to packets of each flow are stored in the state.

34. The method of claim 30, further comprising:

(i) monitoring a control data flow of an application to determine a port number of a new data flow initiated by an application;

(j) a new processing rule is generated using the determined port number.

35. The method of claim 29, further comprising:

(k) providing a plurality of processor sets, wherein each processor set contains a plurality of processors;

(l) Assigning each of the packets to one of the plurality of processor groups, wherein one of the plurality of processors in the assigned group processes the assigned packet.

36. The method of claim 35, wherein packets associated with one subscriber are all assigned to a single processor group.

37. The method of claim 36, further comprising assigning the packets to the respective processors in a round-robin fashion.

38. An Internet Service Node (ISN) for providing a set of service policies desired by each of a plurality of subscribers, the ISN comprising:

an access port for receiving a plurality of groups of bits associated with a subscriber included in said plurality of subscribers;

a switch fabric coupled to said access port, said switch fabric receiving said plurality of bit groups and generating a plurality of packets, wherein said plurality of packets contain data generated from an application associated with said subscriber, wherein each of said plurality of packets contains sufficient data to be identified by a data stream generated by said application associated with said subscriber;

a packet service card for receiving the plurality of packets, the packet service card processing each of the packets in accordance with a plurality of processing rules associated with the subscriber, wherein each of the plurality of processing rules contains a classifier and an associated operation, the identifier identifying at least one data flow to which the associated operation is to be applied;

a trunk port coupled to said switch fabric, said trunk port carrying any of said plurality of packets for which transmission is desired, wherein each of said plurality of subscribers is provided with a corresponding plurality of processing rules, enabling said ISN to provide a desired set of service policies for each of said plurality of subscribers.

39. The ISN of claim 38, wherein the plurality of packets comprise Internet Protocol (IP) packets.

40. The ISN of claim 39, wherein each of the data flows is identified by a source IP address, a destination IP address, a protocol type, a source port number, and a destination port number.

41. The ISN of claim 40, further comprising an interface for enabling the manager to provide the desired set of service policies, wherein the ISN is designed to generate at least some of said processing rules based on the desired set of service policies provided by the manager.

42. The ISN of claim 41, wherein said packet service card is arranged to monitor a control data flow for an application in order to determine a parameter value for said data flow identifying the application, if the parameter value is not available in advance.

43. The ISN of claim 38, wherein said packet service card comprises a plurality of processors, said plurality of processors enabling said ISN to process the plurality of packets promptly.

44. The ISN of claim 43, wherein the plurality of processors are provided in a physical unit separate from said access ports and said trunk ports, the separation enabling the number of processors to be changed independent of the number of access ports and trunk ports.

45. The ISN of claim 43, wherein a state of each of said processing flows is maintained, the state indicating a processing rule to be applied to each of the plurality of packets associated with the respective flow.

46. The ISN of claim 38, wherein said set of bits comprises ATM cells, such that said switch fabric is designed to generate each of said packets from payload transitions of a plurality of ATM cells.

47. The ISN of claim 38, wherein said groups of bits contain sufficient data to be identified by a data stream generated by said application associated with the subscriber such that each of said packets is generated by one of said groups of bits.

48. The ISN of claim 38, further comprising a Random Access Memory (RAM), wherein said processor interface stores said plurality of bit groups in said RAM.

49. An Internet Service Node (ISN) for providing a desired set of service policies to each of a plurality of subscribers, the ISN comprising:

identifying means for identifying a plurality of processing rules that provide a set of service policies desired by each subscriber;

configuring means for configuring an internet service node to correspond to the processing rules of each of the subscribers;

receiving means for receiving data in said internet service node;

determining means for determining in the internet service node a particular subscriber to which the received data relates; and

applying means for applying the plurality of processing rules related to the determined specific subscriber in the internet service node, wherein the applying is performed after the determining.

50. The ISN of claim 49, wherein the internet service node is provided as an edge device of an access network, such that service policies can be controlled from the edge of the access network.

51. The ISN of claim 49, wherein said ISN has a plurality of processors, said determining means and said applying means collectively comprising:

assigning means for assigning each of the subscribers to a processor group, wherein each processor group is configured to correspond to a processing rule of the assigned subscriber;

forwarding means for forwarding data associated with each subscriber to the corresponding group of processors after said determining of the particular subscriber.

52. The ISN of claim 51, wherein end systems of the plurality of subscribers generate data using Internet Protocol (IP).

53. The ISN of claim 52, wherein said data comprises ATM cells.

54. The ISN of claim 53, wherein said distributing means comprises examining means for examining data contained in said ATM cells, said determination of a particular subscriber being based on the result of the examination and on a port on which said ATM cell was received, wherein the port is comprised in said internet service node.

55. The ISN of claim 54, wherein said allocating means further comprises modifying means for modifying a header of said cell for indicating the determined processor group, such that said cell can be forwarded to an appropriate processor group on the basis of checking a cell header, wherein the appropriate processor group is configured with processing rules associated with the particular subscriber.