Multiplex communications – Data flow congestion prevention or control – Control of data admission to the network
Reexamination Certificate
2001-12-17
2004-08-17
Kizou, Hassan (Department: 2662)
Multiplex communications
Data flow congestion prevention or control
Control of data admission to the network
C370S235000, C370S352000, C370S395210, C370S395420, C370S395530, C370S401000, C370S412000, C709S240000
Reexamination Certificate
active
06778498
ABSTRACT:
The following publications available through the Internet Engineering Task Force (IETF) are also incorporated by reference in their entireties as background information:
(1) Branden, R., Clark D. and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” IETF, RFC 1633, June 1994;
(2) Branden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification,” IETF, RFC 2205, September 1997;
(3) Blake, S., Black, D. Carlson, M., Davies, E., Wang, Z. and W. Weiss, “An Architecture for Differentiated Services,” IETF, RFC 2475, December 1998;
(4) Rosen, E. and Y. Rekhter, “BGP/MPLS VPNs,” IETF, RFC 2547, March 1999;
(5) Gleeson, B., Lim, A., Heinanen, J., Finland, T., Armitage. G. and A. Malis, “A Framework for IP Based Virtual Private Networks,” IETF, RFC 2764, February 2000;
(6) Muthukrishnan, K. and A. Malis, “A Core MPLS IP VPN Architecture,” IETF, RFC 2917, September 2000; and
(7) Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, “A Framework for Integrated Services Operation over Diffserv Networks,” IETF, RFC 2998, November 2000.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to communication networks and, in particular, to the prevention of denial of service attacks in a public communication network, for example, the Internet. Still more particularly, the present invention relates to method, system and apparatus for preventing denial of service attacks in a communication network having a shared network infrastructure by separating the allocation and/or prioritization of access capacity to traffic of sites within a virtual private network (VPN) from the allocation and/or prioritization of access capacity to sites in another VPN or the public network.
2. Description of the Related Art
For network service providers, a key consideration in network design and management is the appropriate allocation of access capacity and network resources between traffic originating from VPN customer sites and traffic originating from outside the VPN (e.g., from the Internet or other VPNs). This consideration is particularly significant with respect to the traffic of VPN customers whose subscription includes a Service Level Agreement (SLA) requiring the network service provider to provide a minimum communication bandwidth or to guarantee a particular Quality of Service (QoS). Such service offerings require the network service provider to implement a network architecture and protocol that achieve a specified QoS and ensure sufficient access capacity and network resources are available for communication with other VPN sites separate from communication with hosts that are not part of the VPN.
In Internet Protocol (IP) networks, a straightforward approach to achieving QoS and implementing admission control comparable to that of connection-oriented network services, such as voice or Asynchronous Transfer Mode (ATM), is to emulate the same hop-by-hop switching paradigm of signaling resource reservations for the flow of IP packets requiring QoS.
In fact, the IP signaling standard developed by the Internet Engineering Task Force (IETF) for Integrated Services (Intserv) adopts precisely this approach. As described in IETF RFC 1633, Intserv is a per-flow IP QoS architecture that enables applications to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, Intserv permits an application at a transmitter of a packet flow to use the well-known Resource ReSerVation Protocol (RSVP) defined by IETF RFC 2205 to request a desired QoS class at a specific level of capacity from all network elements along the path to a receiver of the packet flow. After receiving an RSVP PATH message requesting a resource reservation and an RSVP RESV message confirming resource reservation from an upstream node, individual network elements along the path implement mechanisms to control the QoS and capacity delivered to packets within the flow.
FIG. 1
illustrates the implications of utilizing a conventional Intserv implementation to perform admission control. As shown in
FIG. 1
, an exemplary IP network
10
includes N identical nodes (e.g., service provider boundary routers)
12
, each having L links of capacity X coupled to Customer Premises Equipment (CPE)
14
for L distinct customers. In a per-flow, connection-oriented approach, each node
12
ensures that no link along a network path from source to destination is overloaded. Looking at access capacity, a per-flow approach is able to straightforwardly limit the input flows on each of the ingress access links such that the sum of the capacity for all flows does not exceed the capacity X of any egress access link (e.g., Link
1
of node
12
a
). A similar approach is applicable to links connecting unillustrated core routers within IP network
10
.
Although conceptually very simple, the admission control technique illustrated in
FIG. 1
has a number of drawbacks. Most importantly, Intserv admission control utilizing RSVP has limited scalability because of the processing-intensive signaling RSVP requires in the service provider's boundary and core routers. In particular, RSVP requires end-to-end signaling to request appropriate resource allocation at each network element between the transmitter and receiver, policy queries by ingress node
12
b
-
12
d
to determine which flows to admit and police their traffic accordingly, as well as numerous other handshake messages. Consequently, the processing required by Intserv RSVP signaling is comparable to that of telephone or ATM signaling and requires a high performance (i.e., expensive) processor component within each boundary or core IP router to handle the extensive processing required by such signaling. RSVP signaling is soft state, which means the signaling process is frequently refreshed (by default once every 30 seconds) since the forwarding path across the IP network may change and therefore information about the QoS and capacity requested by a flow must be communicated periodically. This so-called soft-state mode of operation creates an additional processing load on a router even greater than that of an ATM switch. Furthermore, if the processor of a boundary router is overloaded by a large number of invalid RSVP requests, the processor may crash, thereby disrupting service for all flows for all customers being handled by the router with the failing processor.
In recognition of the problems associated with implementing admission control utilizing conventional Intserv RSVP signaling, the IETF promulgated the Differentiated Services (Diffserv or DS) protocol defined in RFC 2475. Diffserv is an IP QoS architecture that achieves scalability by conveying an aggregate traffic classification within a DS field (e.g., the IPv4 Type of Service (TOS) byte or IPv6 traffic class byte) of each IP-layer packet header. The first six bits of the DS field encode a Diffserv Code Point (DSCP) that requests a specific class of service or Per Hop Behavior (PHB) for the packet at each node along its path within a Diffserv domain.
In a Diffserv domain, network resources are allocated to aggregates of packet flows in accordance with service provisioning policies, which govern DSCP marking and traffic conditioning upon entry to the Diffserv domain and traffic forwarding within the Diffserv domain. The marking (i.e., classification) and conditioning operations need be implemented only at Diffserv network boundaries. Thus, rather than requiring end-to-end signaling between the transmitter and receiver to establish a flow having a specified QoS, Diffserv enables an ingress boundary router to provide the QoS to aggregated flows simply by examining and/or marking each IP packet's header.
Although the Diffserv standard addresses Intserv scalability limitation by replacing Intserv's processing-intensive signaling with a simple per packet marking operation that can easily be performed in hardware, implem
Elallam Ahmed
Kizou Hassan
MCI Inc.
LandOfFree
Virtual private network (VPN)-aware customer premises... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Virtual private network (VPN)-aware customer premises..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Virtual private network (VPN)-aware customer premises... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3349334