Multiplex communications – Data flow congestion prevention or control – Control of data admission to the network
Reexamination Certificate
1997-12-10
2001-02-13
Pham, Chi H (Department: 2731)
Multiplex communications
Data flow congestion prevention or control
Control of data admission to the network
C370S253000, C370S254000
Reexamination Certificate
active
06188671
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention is directed to systems and methods for implementing improved network architectures, and more specifically to systems and methods for routing internet protocol (IP) packets using modified frame relay protocols.
2. Description of the Related Arts
Recently, the popularity of large “meshed” networks has been increasing. However, large-scale highly-meshed networks can be difficult to implement, maintain, and manage using conventional network technologies.
An example of a conventional mesh configuration is shown in
FIG. 1. A
wide-area network (WAN)
900
includes a plurality of routers R
A
, R
B
, R
C
, R
D
, (customer premises equipment (CPE)) respectively disposed at a plurality of end user locations A, B, C, and D and interconnected to a service provider's network (SPN)
901
via respective user-network interfaces (UNI)
920
-
1
, -
2
, . . . , -n. The user-network interfaces
920
may be variously configured to be, for example, an asynchronous transfer mode (ATM) switch having a frame relay interface to CPE. Connecting the sites together are logical paths called, for example, permanent virtual circuits (PVCs) P
A-C
, P
A-D
, P
B-D
, P
A-B
, P
C-B
, that are characterized by their endpoints at the UNIs
920
-
1
,
920
-
2
, . . . ,
920
-n and a guaranteed bandwidth called the committed information rate (CIR).
FIG. 2
provides a detailed view of the flow of data across the WAN
900
. There exists a plurality of layers of protocol over which communications may occur. For example, the well-known layers of the International Standards Organization's (ISO) Open Systems Interconnect Model having layers from a physical layer (layer
1
), a datalink layer (layer
2
), a network layer (layer
4
), up through and including an application layer (layer
7
). Under this model, user data
902
is generated by a user application running at the application layer
903
. At the transport layer (layer
4
)
904
, a source and destination port address
906
(as part of the TCP header (layer
4
)) may be added to the user data
902
. At the network layer (layer
3
)
905
, an additional header (i.e., an IP header (layer
3
)) containing source and destination IP addresses)
908
may be added. Thus, the layer
3
user data field includes the layer
4
user data
902
plus the layer
4
header
906
. The layer
3
protocol data unit (PDU)
902
,
906
,
908
, which makes up, for example, an IP packet
950
, is then passed down to layer
2
909
in the CPE (routers R
A
, R
B
, R
C
, R
D
) that interfaces to the SPN
901
. In the router, a table maps one or more IP addresses (layer
3
)
908
to an appropriate PVC or PVCs (P
A-C
, P
A-D
, P
B-D
, P
A-B
, P
C-B
). The router table is maintained by the customer. Once the correct PVC is located in the routing table, the corresponding data link connection identifier (DLCI) (layer
2
)
912
is coded into the header of the frame relay frame
914
(packet). Thereafter, the remainder of the frame relay frame is included and a frame check sum (FCS) is computed. The frame is then passed down to the physical layer and transmitted to the SPN
901
.
At the UNI
920
, the frame is checked for validity to determine if there is a predefined PVC associated with the DLCI
912
. If so, the frame
914
is then forwarded on that PVC through the network along the same path and in the same order as other frames with that DLCI, as depicted in FIG.
2
. The layer
2
frame information remains as the packet traverses the frame relay network whether this network is actually implemented as a frame relay network or other network such as an ATM network. The frame is carried to its destination without any further routing decisions being made in the network. The FCS is checked at the egress UNI, and if the frame is not corrupted, it is then output to the UNI associated with the end user.
As is well known in the art,
FIGS. 1-3
provide exemplary diagrams of how the frame relay data packets are assembled at the various ISO layers using the example of TCP/IP protocol transport over a frame relay data link layer. The example shows how the user data at the application layer is “wrapped” in succeeding envelopes, making up the PDUs, as it passes down the protocol stack. Specifically, the composition of the Header field is expanded for detail and is shown in FIG.
5
. The data link connection identifier (DLCI) field comprises 10 bits spread over the first and second octet, and allows for 1023 possible addresses, of which some are reserved for specific uses by the standards. As shown in
FIG. 3
, the DLCI is added to the frame relay header according to what destination IP address is specified in the IP packet. This decision about what DLCI is chosen is made by the CPE, usuually a router, based on configuration information provided by the customer that provides a mapping of IP addresses into the PVCs that connect the current location with others across the WAN
900
.
In conventional frame relay, a layer
2
Q.
922
frame carries the layer
3
customer data packet across the network in a permanent virtual circuit (PVC) which is identified by a data link connection identifier (DLCI). Thus, the DLCIs are used by the customer as addresses that select the proper PVC to carry the data to the desired destination. The customer data packet is carried across the network transparently and its contents is never examined by the network.
The conventional meshed frame relay network discussed above has a number of limitations. For example, every time a new end user location is added to the meshed network, a new connection is required to be added to every other end user location. Consequently, all of the routing tables must be updated at every end user location. Thus, a “ripple” effect propagates across the entire network whenever there is a change in the network topology. For large networks with thousands of end user locations, this ripple effect creates a large burden on both the network provided to supply enough permanent virtual circuits (PVCs) and on the network customers in updating all of their routing tables. Further, most routers are limited to peering with a maximum of 10 other routers which makes this network topology difficult to implement. As networks grow in size, the number of PVCs customers need to manage and map to DLCIs increases. Further complicating the problem is a trend toward increasing “meshedness” of networks, meaning more sites are directly connected to each other. The result is a growth in the number and mesh of PVCs in networks that does not scale well with current network technologies.
A possible solution for handling large meshed networks is to use a virtual private network (VPN) which interconnects end user locations using encrypted traffic sent via “tunneling” over the internet. However, VPNs are not widely supported by internet service providers (ISPs), have erratic information rates, and present a number of security concerns.
Another possible solution is the use of frame relay based switched virtual circuits (SVCs). While PVCs (discussed above) are usually defined on a subscription basis and are analogous to leased lines, SVCs are temporary, defined on an as-needed basis, and are analogous to telephone calls. However, SVCs require continuous communications between all routers in the system to coordinate the SVCs. Further, because the tables mapping IP addresses to SVC addresses are typically manually maintained, SVCs are often impractical for large highly-meshed networks. Security is a major concern for SVC networks where tables are mismanaged or the network is spoofed. Further, frame SVCs are difficult to interwork with asynchronous transfer mode (ATM) SVCs.
None of the above solutions adequately address the growing demand for large mesh networks. Accordingly, there is a need for network architectures which enable implementation of large mesh networks having security, low maintenance costs, efficient operations, and scalability.
SUMMARY OF THE INVENTION
Aspects of the present invention solve one
Chase Christopher J.
Holmgren Stephen L.
Medamana John Babu
Saksena Vikram R.
AT&T Corp
Pham Brenda H.
Pham Chi H
LandOfFree
Traffic management for frame relay switched data service does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Traffic management for frame relay switched data service, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Traffic management for frame relay switched data service will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2604203