Browse Prior Art Database

Congestion Avoidance and Congestion Control in OBS/OPS Networks

IP.com Disclosure Number: IPCOM000020047D
Original Publication Date: 2003-Nov-25
Included in the Prior Art Database: 2003-Nov-25

Publishing Venue

Siemens

Related People

Other Related People:

Abstract

Optical Burst Switching (OBS) and Optical Packet Switching (OPS) networks are extremely flexible. However, there is a certain risk that these networks might lose packets due to internal blocking. Figure 1 shows a scenario where an end-to-end TCP (Transmission Control Protocol) connection runs partly over an OBS or an OPS network and partly over Internet. The speed at which algorithms for congestion avoidance and congestion control of such TCP connections react is usually in the order of milliseconds, whereas changes in the OBS/OPS network, working at a data rate in the order of GBPS (Gigabits Per Second), occur much faster. The reason for this is that acknowledgements of the TCP have to travel back to the source via the internet. With this kind of slow feedback, the TCP does not get an accurate picture of the fast-changing optical domain. Consequently, if congestion is building up in the optical network, the TCP's congestion avoidance algorithms are far too slow to detect and measure it. At the moment, the most promising solution for the above mentioned problem is to use the so-called TCP decoupling approach. However, this method requires a modified TCP version specific for this purpose and adds a considerable amount of signaling. The TCP needs to operate on top of MPLS (Multi Protocol Label Switching) or ATM (Asynchronous Transfer Mode) VCs (Virtual Channels). Furthermore, this approach can only be used if an end-to-end TCP connection between source and destination exists. It does not work with UDP (User Datagram Protocol) or other transport protocols.