Methods and systems for per-session traffic rate policing in a media gateway

[0001] This application claims the benefit of U.S. Provisional Application No. 60/616,651 entitled “Media Gateway Features”, filed Oct. 7, 2004, the disclosure of which is incorporated herein by reference in its entirety.

[0002] The subject matter described herein relates to communications and more particularly, to traffic rate policing in a media gateway.

[0003] In modern telephony networks, media switching and call control functionality are separated. Call control, which includes setting up and tearing down calls and maintaining call state machines, is performed by a network entity referred to as a media gateway controller (MGC). Media stream switching, which includes switching media packets between input and output ports and converting the media packets into the appropriate formats for the sending and receiving parties, is performed by a media gateway (MG). Media gateway controllers communicate call control information to media gateways via a media gateway control protocol. Typical media gateway control protocols, such as MGCP and MEGACO, include commands for communicating information about each endpoint of a session to the media gateway and instructing the media gateway as to how to process packets to be delivered to each endpoint.

[0004] FIG. 1 is a schematic diagram illustrating voice sessions between media gateways 100, 102, 104, and 106 interconnected through an IP network 108. Media gateways 100, 102, 104, and 106 may be connected through IP network 108 via multiple paths through a series of next-hop routers. Multiple bidirectional voice sessions may be set up between any two or more of media gateways 100, 102, 104, and 106. As voice packets are received at a media gateway (ingress packets) or exit the media gateway (egress packets), the particular session that a packet belongs to must be identified for proper delivery and/or processing of the packet. The process of assigning a packet to a particular session to which it belongs is commonly referred to as packet classification.

[0005] FIG. 2 is a schematic diagram illustrating an exemplary media gateway 200. Referring to FIG. 2, media gateway 200 includes a control module 202, a resource manager 204, a packet switch fabric 206, voice servers 208, and network interfaces 210. Each voice server 208 contains voice processing resources for processing voice-over-IP (VoIP) and time division multiplexed (TDM) voice streams. For example, each voice server 208 may include codecs, VoIP, asynchronous transfer mode (ATM), and TDM chips, and digital signal processing resources for processing VoIP streams. A detailed description of exemplary resources that may be found in voice server 208 can be found in commonly assigned, co-pending U.S. patent application Ser. No. 10/676,233, the disclosure of which is incorporated herein by reference in its entirety.

[0006] Control module 202 of media gateway 200 controls the overall operation of media gateway 200 and communicates with media gateway controller 212 to set up and tear down calls. Resource manager 204 of control module 202 allocates new voice sessions to incoming calls. For example, resource manager 204 may assign one of voice servers 208 to a session and store session information for the session in a session table 214 in a memory. Session table 214 is then regularly accessed to classify ingress and egress packets to the appropriate sessions. Although session table 214 is shown logically as a single entity, session tables 214 may actually be distributed among, and accessed by, network interfaces 210, as will be discussed further below.

[0007] Voice servers 208 are each assigned individual IP addresses and are each reachable through packet switch fabric 206 via any of network interfaces 210. Multiple sessions may be processed by the same voice server 208. Furthermore, multiple sessions may be established between a given network interface 210 and a given voice server 208 through the packet switch fabric 206. The traffic rate for a given voice server 208 should not be exceeded to avoid degrading the voice quality of calls, or worse, overloading the voice of server 208. For example, a malicious attack can be launched against a media gateway by flooding the media gateway with packets, thereby reducing the call handling capacity, or even overloading, one or more of voice servers 208. While firewall protection mechanisms provide some degree of protection against unauthorized users, voice servers 208 are still vulnerable to receiving excessive packets from authorized users, whether maliciously or unintentionally. For example, once a call is allowed into a media gateway, packets for the session pass through the firewall. If either the calling or the called party send an excessive amount of packets, conventional firewall protection mechanisms are ineffective for preventing these packets from overloading media gateway resources.

[0008] Accordingly, a need exists for traffic rate policing in a media gateway to limit a packet traffic rate available to authorized users.

[0009] In one aspect of the subject matter disclosed herein, a method is disclosed for per-session traffic rate policing in a media gateway. VoIP packets are received at a media gateway where it is determined whether each VoIP packet is associated with an existing VoIP session in the media gateway. A per-session traffic rate policing policy is applied to the packets associated with the existing sessions in the media gateway. In response to determining that a packet violates the per-session traffic rate policing policy, the packet is discarded.

[0010] In another aspect of the subject matter disclosed herein, a system is disclosed for per-session traffic rate policing in a media gateway. The system includes a plurality of network interfaces for receiving VoIP packets at a media gateway and determining whether each VoIP packet is associated with an existing VoIP session in the media gateway and a plurality of voice server modules for receiving VoIP packets associated with existing sessions in the media gateway and for performing voice processing functions for the packets. The system also includes a packet switch fabric for connecting the voice server modules to the network interfaces and a control module for establishing connections between the network interfaces and the voice server modules via the packet switch fabric. At least one of the packet switch fabric and the network interfaces applies a per-session traffic rate policing policy for preventing packets associated with an existing session in the media gateway from exceeding a predetermined rate.

[0011] In another aspect of the subject matter disclosed herein, a system is disclosed for per-session traffic rate policing in a media gateway. The system includes logic configured to receive VoIP packets at a media gateway, logic configured to determine whether each VoIP packet is associated with an existing VoIP session in the media gateway, logic configured to apply a per-session traffic rate policing policy to the packets associated with the existing sessions in the media gateway, and logic configured to, in response to determining that a packet violates the per-session traffic rate policing policy, discard the packet.

[0021] To facilitate an understanding of exemplary embodiments, many aspects are described in terms of sequences of actions that can be performed by elements of a computer system. For example, it will be recognized that in each of the embodiments, the various actions can be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both.

[0022] Moreover, the sequences of actions can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor containing system, or other system that can fetch the instructions from a computer-readable medium and execute the instructions.

[0023] As used herein, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non exhaustive list) of the computer-readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CDROM).

[0024] Thus, the invention can be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. Any such form of embodiment can be referred to herein as “logic configured to” perform a described action, or alternatively as “logic that” performs a described action.

[0025] FIG. 3 is a schematic diagram illustrating an exemplary internal architecture for media gateway 200 in more detail. In FIG. 3, media gateway 200 includes voice servers 208, which include various voice chips, including VoIP chips 302, voice-over-AAL1 chips 304, and voice-over-AAL2 chips 306. In addition, each voice server 208 includes some digital signal processors 308 (e.g. voice transcoders, echo cancellers, conference bridges, etc.), a time slot interconnection (TSI) 310, and a central processing unit (CPU) 312.

[0026] In the illustrated example, each voice chip 302 implements one or more VoIP protocols, such as Real time Transmission Protocol (RTP). Each voice chip 304 implements ATM Adaptation Layer 1 (AAL1) functions. Each voice chip 306 implements ATM Adaptation Layer 2 (AAL2) functions. DSP 308 provides transcoding, echo cancellation and other payload-transformation functions. TSI 310 makes on-demand connections between VoIP chip channels, TDM matrix channels, and DSPs. CPU 312 controls the overall operation of each voice server 208.

[0027] In addition to a plurality of voice servers 208, media gateway 200 includes a plurality of network interfaces 210. Each network interface 210 implements network layer functions and packet forwarding functions, such as IP forwarding functions. In the illustrated example, different network interfaces are provided to connect to external Ethernet, Packet-Over-SONET (POS), ATM, and MPLS networks.

[0028] In addition to packet-based network interfaces 210, media gateway 200 may also include TDM network interfaces 318. TDM network interfaces 318 send and receive voice frames from external TDM networks. TDM network interfaces 318 may implement any suitable physical layer protocols for sending and receiving voice frames over TDM links. For example, each TDM network interface 318 may terminate one or more TDM voice trunks.

[0029] In order to switch media packets between network interfaces 210 and voice servers 208, media gateway 200 includes a packet switch fabric 206. Packet switch fabric 206 routes packets between voice servers 208 and network interfaces 210 under the control of control module 202. As discussed above, packet switch fabric 206 may connect every network interface 210 to every voice server 208. In addition to packet switch fabric 206, gateway 200 may also include a TDM matrix module 322 for switching traffic that is carried in each TDM timeslot. TDM matrix module 322 is also controlled by control module 320. Control module 202 may communicate with media gateway controller 212 to dynamically allocate logical and physical resources for each session.

[0030] In operation, control module 202 receives a request for a new call/session. The request may be generated by media gateway controller 212 in response to a call setup message associated with a new call. The call setup message may be an ISUP IAM message, a PRI SETUP message, a SIP INVITE message, or any other suitable type of call setup message for initiating a call. Control module 202 assigns a voice server 208 and a voice chip to process the media stream for the session. Control module 202 also identifies the session with an entry in a session table 214. The session identifier includes a combination of IP addresses and UDP port numbers that is unique among current sessions, as will be described further below. The session identifier is preferably assigned to a voice chip for the duration of the session and is communicated to the remote end of a session by media gateway controller 212. The remote end of the session will then send subsequent media stream packets that are addressed according to the session identifier. Session tables 214 on each packet network interface 210 are updated under the control of control module 202 so that packets addressed according to the session identifier are forwarded to the appropriate voice chip.

[0031] Once resources, such as a voice chip, have been assigned to the session, media gateway 200 classifies packets having the same session identifier to the session. That is, packets are forwarded via the switch fabric 206 to and from the voice chip assigned to the session for voice processing. Exemplary operations that may be performed by the assigned voice chip may include segmentation and reassembly (SAR), echo cancellation, transcoding, DTMF detection, DTMF generation, announcement, conference bridging, Internet fax, and law enforcement. Once the voice packets associated with the session have been processed, the voice packets may be sent from the voice chip to one of network interface 210 or to a TDM network interface 318 for transmission to the remote end of a session. Once a session ends, the resources used may be assigned to a new session. An exemplary method for dynamically assigning resources to sessions suitable for use with the methods and systems described herein is described in commonly assigned, co-pending U.S. patent application Ser. No. 10/676,233, referenced above.

[0032] FIG. 4 is a schematic diagram illustrating traffic rate control according to an aspect of the subject matter described herein. In FIG. 4, incoming packets arrive at network interface 210. Network interface 210 classifies the packets to a session and forwards each packet through packet switch fabric 206 to one of voice servers 208 for processing. Multiple unidirectional paths or connections are established through packet switch fabric 206 between a given network interface 210 and voice server 208, where N is an integer that may be based on concurrent sessions that voice server 208 is expected to handle. For example, permanent virtual connections (PVC) based on asynchronous transfer mode (ATM) protocol may be established through packet switch fabric 206, as will be appreciated by one of ordinary skill in this art. In the example given by FIG. 4, N PVCs 400 are established between one network interface 210 and one voice server 208. It will be appreciated, however, that PVCs 400 may be established between multiple network interfaces 210 and the same voice server 208, and vice versa.

[0033] Each PVC 400 through packet switch fabric 206 may be set up in advance under the control of control module 202. The bandwidth allocated to a PVC 400 may be established to accommodate a single session. That is, enough bandwidth is allocated to support a maximum allowable traffic rate for a single session. For example, the bandwidth of each PVC 400 may be limited to allow a maximum traffic rate of 100 Kbps per session. Packets received in excess of the maximum traffic rate are discarded. Accordingly, if an excessive number of packets are received for a given session, then the additional packets are discarded before the respective voice server's 208 call handling capacity can be unnecessarily diminished, or overloaded, or the call quality is degraded in other sessions handled by voice server 208.

[0034] Alternatively, PVC 400 may be more tailored to the particular session for which it is established. For example, control module 202 may communicate with media gateway controller 212 during call setup to determine the attributes of a particular session, such as encoding and compression attributes. The traffic rate for the associated PVC 400 may be set according to the attributes of the session.

[0035] In either case, control module 202 may communicate with packet switch fabric 206 to set a per-session maximum traffic rate for a session by establishing a per-session bandwidth limited path, such as PVC 400, through switch fabric 206 to limit the maximum traffic rate for the respective session. If the traffic rate exceeds the value of the maximum traffic rate, then the excess packets are discarded. Since the traffic rate policing function is carried out predominantly by packet switch fabric 206 once established, processing overhead in control module 202 is minimized. It should be noted also that the traffic rate policing described above may be omitted for packets leaving media gateway 200 (egress packets), since egress traffic rates are set by each respective voice server 208.

[0036] FIG. 5 is a schematic diagram illustrating traffic rate control according to another aspect of the subject matter described herein. In FIG. 5, incoming packets 500 arrive at network interface 210. Network interface 210 classifies the packets to a session and forwards each packet through packet switch fabric 206 to a respective voice server 208 currently processing packets for the respective session. Here, network processor 316 of network interface 210 includes one or more traffic rate monitors 502. Each traffic rate monitor 502 is assigned to a respective session and monitors the traffic rate for that session. Network processor 316 monitors the traffic rate for each session via traffic rate monitors 502 and discards packets that exceed a traffic rate threshold. The traffic rate threshold for each session may be set using either of the methods described above for setting traffic rates in PVCs. Namely, the traffic rate threshold may be set to a maximum value allowable for each of multiple sessions or to a traffic rate set according to the attributes of each session individually as determined during call setup between control module 202 and media gateway controller 212. When the traffic rate threshold is exceeded in a traffic rate monitor 502, this is an indication that an excessive number of packets have been received for a given session and additional packets are dropped before a respective voice server's 208 call handling capacity can be unnecessarily diminished, or overloaded, or the call quality is degraded in other sessions handled by a respective voice server 208.

[0037] Traffic rate monitors 502 may be implemented either internally or externally to network processor 316 using software or hardware methods as will be appreciated by one of ordinary skill of this art. For example, a counter may be used and the counter value may be a stored in a register or in any memory internal or external to network processor 316.

[0038] Network processor 316 determines which session each packet 500 received belongs to, i.e., classifies a packet, by analyzing the packet 500. For example, network processor 316 may read a source and destination IP address and a source and destination user datagram protocol (UDP) port number, or any subset combination of these values from packet 500 to determine which session the packet is associated with. As a packet is classified to a particular session, the associated traffic rate monitor 502 attributes the packet to the session for traffic rate monitoring purposes.

[0039] FIG. 6 is a flow chart illustrating a method for per-session traffic rate policing in a media gateway according to an aspect of the subject matter disclosed herein. In FIG. 6, VoIP packets are received at a media gateway in step 600. Network interface 210 determines whether each VoIP packet is associated with an existing VoIP session in the media gateway in step 602. A per-session traffic rate policing policy is applied to the packets associated with the existing sessions in the media gateway in step 604. In step 606, it is determined whether a packet violates the per-session traffic rate policing policy. In response to determining that a packet violates the per-session traffic rate policing policy, the packet is discarded in step 608. In response to determining that a packet does not violate the per-session traffic rate policing policy, the process returns to step 600.

[0040] FIG. 7 is a flow chart illustrating one method of applying a per-session traffic rate policing policy to the packets (step 604 in FIG. 6) according to an aspect of the subject matter disclosed herein. At least one per-session bandwidth-limited path established between a network interface and a voice server in the media gateway in step 700. Packet switch fabric 206 determines whether packets associated with an existing session exceed bandwidth allocated to any of the at least one per-session bandwidth-limited paths in step 702.

[0041] FIG. 8 is a flow chart illustrating another method of applying a per-session traffic rate policing policy to the packets (step 604 in FIG. 6) according to another aspect of the subject matter disclosed herein. At least one per-session traffic rate at network interface 210 where the packets associated with the existing sessions enter the media gateway in step 800. Network processor 316 of network interface 210 determines whether packets associated with an existing session exceed a respective per-session traffic rate for the existing session in step 802.

[0042] Using either of the approaches described above, the per-session traffic rate policy is established. When that policy is violated, appropriate steps may be taken in the media gateway. For example, packets in excess of the per-session traffic rate established by the per-session traffic rate policy may be discarded as described above. In addition, in response to determining that a packet violates the per-session traffic rate policing policy, a session associated with the violating packet can be terminated at the media gateway. Another possible course of action responsive to determining that a packet violates the per-session traffic rate policing policy is to send an indication from the media gateway to a source of the violating packet, i.e., the corresponding subscriber, which conveys information to the subscriber. For example, the indication can inform a subscriber that excessive packets have been received in a session and that corrective measures were taken, such as discarding additional packets or terminating the session. In addition, a proactive approach to preventing future problems may be employed in response to determining that a packet violates the per-session traffic rate policing policy by limiting or banning other sessions involving the subscriber in the future at least until the source of the problem can be further investigated. For example, control module 202 can inform media gateway controller 210 to prevent establishment of other sessions involving the subscriber at a call signaling level. Yet another action that can be taken for packets that repeatedly violate the per-session traffic rate control policy is to add the source of IP address of the packet to a firewall maintained by the media gateway to prevent future packets from the source IP address from entering the media gateway.

[0043] It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the invention is defined by the claims as set forth hereinafter.