Browse Prior Art Database

Congestion Avoidance and Congestion Control in OBS/OPS Networks

IP.com Disclosure Number: IPCOM000020047D
Published in the IP.com Journal: Volume 3 Issue 11 (2003-11-25)
Included in the Prior Art Database: 2003-Nov-25
Document File: 2 page(s) / 69K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

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.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

S

© SIEMENS AG 2003 file: 2003J14153.doc page: 1

Congestion Avoidance and Congestion Control in OBS/OPS Networks

Idea: Miguel de Vega Rodrigo, DE-Munich

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.

To avoid these problems, it is proposed to tunnel the bursts/packets that are formed in the ingress edge node (see Figure 1) via a TCP connection which ends at the egress edge node. The TCP connection runs exclusively over the optical domain and is hence able to monitor the congestion level in the domain. Therefore, this TCP connection can react fast enough to avoid or control congestion, since acknowledgements now only need to travel back to the source through the optical domain.

Figure 2 illustrates the basic principle of this configuration. The ingress node sends all the bursts/packets going to a certain egress edge node through the tunneled TCP connection. The egress node does the inverse operation. For each pair of edge nodes there is a (bidirectional) TCP connection. These connections need to be established only once, at the beginning of the network operation. Since the traffic in an OBS/OPS network is expected to be symmetric, the tunneled TCP connection can take advantage of ,piggybacking'. The acknowledgements from one edge node to another can be sent in the TCP packets that the latter node sends to the first, thus saving bandwidth.

The details of the TCP tunneling process are described in detail in Figure 3. In the first...