Abstract
Focusing on the principles and the paradigm of OBS an overview addressing expectable performance and application issues is presented. Proposals on OBS were published over a decade and the presented techniques spread into many directions. The paper comprises discussions of several challenges that OBS meets, in order to compile the big picture. The OBS principle is presented unrestricted to individual proposals and trends. Merits are openly discussed, considering basic teletraffic theory and common traffic characterisation. A more generic OBS paradigm than usual is impartially discussed and found capable to overcome shortcomings of recent proposals. In conclusion, an OBS that offers different connection types may support most client demands within a sole optical network layer.
1. Introduction
Optical burst switching (OBS) has been discussed intensely since its introduction. Celebrated as the next major development in information transport technology after the invention of packet switching, recent studies on efficiency query the one-way control proposals, the just in time (JIT) scheme as well as the more efficient and today more popular just enough time (JET) scheme [1]. The efficiency is inferior to circuit switched trunks if it is used as pure underlay network connecting IP routers transporting packet streams only. This applies in both, provided transport quality and average resource utilization, and ratifies why OBS is not widely used today.
Contention, or more precisely the statistical burst collision potential that results inevitably from the presumed one-way signaling, challenges OBS. The utilization may be increased to competitive levels if contention resolution mechanisms are considered [2]. In addition, specific service requirements can be served better with OBS, if we look at OBS more openly and assume two-way signaling possible for certain traffic flows.
Evidently, IP will remain the primary interface to applications for long. A different issue is if IP should be the only network protocol within backbone networks. The introduction of multiprotocol label-switching (MPLS) has shown that better is possible. The current introduction of generalised MPLS (GMPLS) [3] reintroduces circuit switching, showing that there is a strong demand for differentiated transport qualities. Consequently, also OBS needs to provide diversity to be successful. A pitfall would be to assume that the principles of packet switching may be mapped from electronics directly into optics [4]. There exists no optical replacement of the omnipresent random access memory (RAM). At least not if no device that can store and release photons on demand is invented. Solutions not biased to buffering need to be found.
Employing a cut-through switching paradigm, OBS not necessarily requires buffering of the passing data. This facilitates negligible transmission latencies determined only by the speed of light. However, OBS is challenged by the need for an efficient and dynamic management of optical spans [5], if not combined with frequent 3R (amplitude, shape, timing) regeneration. Still, the amenities of information transport via light over fibres are overwhelming. Low attenuation that enables huge spans and less signal power lost to the medium, intrinsic environmental shielding and safety, and the tremendous capacity that can be increased on demand by adding more fibres, are among the most important features of fibre-based communication networks. However, the coarse granularity of 25/50/100 GHz wide wavelength division-multiplexed (WDM) channels can hardly be efficiently exploited by a single service. This issue is solved by OBS: it provides an all-optical network alternative that combines wavelength and time multiplexing in the optical domain.
Current “optical” backbone networks use fibres and wavelength channels to connect electrical switches. The capacity of optical channels is electrically split into many digital communication channels. This requires converting all signals at every node to the digital domain for routing/switching. Considering that a single fibre can transport digital signals with a summed bit-rate of several Terra-bit per second, we recognize that a core switch with, for example, 80 fibre-ports (to interconnect 5 fibre-cables with 16 strands each) would need tremendous processing power to handle the potentially passing digital signals. OBS evades electrical storing of transported data and thereby solves this scalability limiting, power consuming, thus cost driving factor [6–11].
The achievable performance and service support are the key issues considered in this overview. Sections 2, 3, and 4 recapitulate the principles of basic OBS and its elementary network layer performance. Selected implementation options are presented in Sections 4, 5, and 6, where also comparisons to current systems are made and consequences discussed to foster a big picture of burst switching. Integration issues and potential services are outlined in Section 7, based on an example application scenario. Finally, Section 8 concludes the impartial overview by summarising potentials and options.
2. Optical Burst Switching
In OBS the transport of information is organized via bursts. Every burst is an autonomous unit associated with a Burst Control Packet (BCP), as shown in Figure 1. The information is encapsulated in a so-called Data Burst (DB), which is switched through transparently end-to-end. This separates OBS from Optical Packet Switching (OPS), where the header information is an integral part of the transported information unit.
Whether the BCP is transported on a dedicated wavelength, a dedicated fibre, or between bursts, is an implementation option. Note that the DB is a time-frame including any start-of-frame indications and internal guard-bits/-times inserted at the source. The burst internal formatting is in general unknown to the intermediate nodes, because indication and monitoring of DB content passing in the optical domain is not possible.
Without contention resolution OBS faces performance problems if a sufficient number of parallel channels is not available [12]. Deflection routing can efficiently tackle the problem without added hardware effort and enables 70% and more utilization at realistic loss rates for common channel numbers and uneven (dynamic) load distribution [13]. Fibre delay line arrays (FDLAs) can be added to solve the contention problem [2, 14–16]. Special (optional) burst assembly schemes could be applied to allow truncation of contending bursts. This can be used as add-on contention resolution mechanism [17–19] but requires additional information to be enclosed in the BCP. However, the thereby achievable improvement is logarithmic, compared to the exponential improvement that adding more channels yields.
Given the OBS transport unit, the block-architecture of an OBS core node is evident and shown in Figure 2, where we assume that BCPs are transported on a dedicated wavelength. The basic building blocks are the all-optical cross-point switching matrix and the BCP processing unit.
Whether and where to integrate wavelength conversion and/or fibre delay lines in order to solve concurring resource demands is a vendor decision. Channels available per link can be identical wavelengths on different fibres, different wavelengths on one fibre, or a combination of both, depending on the OXC features locally available. Applicable routing strategies are not bound to the node design. However, the achievable performance and the variables to be considered for routing relate to the capabilities of the implemented contention resolution mechanisms.
2.1. BCP Handling Performance
Prior looking at the optical transport plane we analyse the control plane performance demand. BCP processing time can be in general assumed deterministic, because BCPs most likely have the same size and demand similar actions. Although practical realizations of BCP processing units (e.g., network-processors) presumably are based on highly efficient, pipelined, multiscalar processor architectures, for simplicity and generality we assume a single processing unit with an effective processing speed to approximate any architecture. Inter-arrival time distribution is a priori unknown and cannot be determined by design, if a specific customer-type with dedicated characteristics is not postulated. Thus, we can model the BCP processing unit by a G/D/1/s queueing system, where G indicates a general distribution, D a deterministic distribution, and is the system size (number of BCPs that simultaneously can be present in the modelled BCP processing unit). An upper bound for BCP loss-rate (1) is derived according to [20]: where is the probability that in an equivalent G/D/1 queueing system with infinite queue more than customers are present and is the inverse load, that is, service speed over arrival-rate .
This clearly needs to be minimized as every lost BCP causes the loss of the represented DB. The BCP flow time (time from BCP arrival till completion of BCP processing) is equally important, because forwarding a BCP too late causes the loss of the associated DB. Flow-time of finite systems is upper bound by those found for infinite systems. For Poisson distributed inter-arrival times (M) and as coarse approximation for any distribution, we can use the M/D/1 queueing model studied by Erlang in 1909ff [21] to get an upper bound. Using the Pollaczek-Kinchin formula for M/G/1 and setting to get system filling for M/D/1, we can use Littles formula to get the flow-time bound (2), being the expectation value of the flow-time distribution : where is the expectation operator, the mean load, and M/D/1/s the indicator for the used model.
To get the loss-probability we insert in (1). Searching a bound only, we can replace the deterministic service time with a distributed one, for example, a negative exponential distributed. Note that a deterministic service process causes lower loss-rate than any distributed, if arrival and service process are uncorrelated. Thus, we can use the results available for M/M/1/s [22] to get (3): where is the probability that the M/M/1/s queueing system is in the state of customers being in the system, that is, the blocking state in which arriving control packets cannot enter the processing unit because its queue is fully occupied. In Figure 3 both the BCP loss-probability and the BCP flow-time caused by the BCP processing unit are shown in relation to normalized control plane load (BCP-load over the processing units effective service-rate).
(a)
(b)
To calculate BCP-loss due to flow-time distribution we need to calculate the probability that a BCP needs more time to pass the BCP processing unit than considered for offset-time specification. To diminish losses caused by BCP flow-times (e.g., to ≤10−9) effective service rates magnitudes faster than actual arrival-rates are necessary. The system-size can be optimized according to the requested total (combined) BCP loss-rate being a principal design criterion.
2.2. Resource Utilization and DB Blocking
The probability that two requests for resources collide can be determined by modelling an outgoing link as G/G/n/n loss system. General assumptions here are as follows: inter-arrival times of bursts routed to the same outgoing link are not correlated (independent), and there are parallel resources available per link. In [23] it is shown that the Erlang model [21] considerably overestimates this probability and that the Engset model [24] fits better. However, to use Engset we would need to know the relation of incoming to outgoing channels. As we do not want to restrict the study to a specific implementation variant, we use the less accurate Erlang model and keep in mind that less demand collisions actually will occur [25].
With one-way reservation and no means to individually delay a DB, demand collisions equal DB losses and the utilization in case of Poisson distributed arrivals is where is given by the Erlang_B equation [26]. Comparing this with synchronized, time-slotted circuit switching (i.e., , [22]) or store-and-forward based packet transmission over a circuit-switched channel (i.e., , [26]), we see that demand collisions (burst contention) are a problem. These are either a priory avoided, or a sufficient number of parallel channels is required (comparable to traditional telecom networks).
How parallel channels improve performance is shown in Figure 4. Sixteen parallel channels already improve the performance considerably. Considering that paths consist of several hops [27, 28], 16 channels is sufficient to achieve a burst loss-rate <10−3 over 8 hops if 30% utilization is the designs load target. For 80% utilization 256 parallel channels are required, efficiently achievable only via fully alight DWDM on 4 parallel fibres and blocking free any-to-any wavelength conversion.
(a)
(b)
The transport performance is not perfectly fair. Longer bursts suffer more from contention than shorter ones. On the other side, longer DBs cause less control overhead to transport the same bit-rate. A sever reduction of signaling is possible, if a single BCP could advertise a sequence of small DBs [29–31]. Two-way reservation for better resource planning, that is, loss avoidance, is commonly assumed too excessive if applied for individual bursts. However, for huge bursts and chains of successive bursts two-way reservation needs to be considered for fairness reasons. See [12], where this option is referred to as fast or dynamic optical circuit switching.
2.3. Contention Resolution via Local Delay Lines
Besides increasing the number of wavelength channels available in parallel, the contention potential can be addressed by fibre delay line arrays (FDLAs) and wavelength conversion units. The latter increases the number of selectable channels and therefore contributes an improvement comparable to adding more channels. The conversion ratio indicates the number of virtually equal channels: 2 for up to 12 for , if we assume 16 different wavelengths () per physical channel (fibre).
The design of the FDLA is an open issue. In [32] a model has been used to determine the optimal granularity , the size of the smallest delay unit. The size of the FDLA is the number of slots that is provided. Access to any multiple of is assumed. Different design proposals and models exist; see, for example, [14, 15, 33, 34].
Figure 5 shows simulation results. The blocking probability per channel can be reduced considerably. To which extend wavelength conversion and FDLAs are implemented is a vendor choice, because similar performance can be achieved with different designs.
(a)
(b)
2.4. Remark on the Analysis Assumptions
Actual traffic characteristics may influence the performance considerably. Negative exponentially distributed holding times are not realistic if we consider the typical burst assembly strategies discussed hereinafter. The schemes presented in Section 6 and in [29] actually create a mix of holding-time characteristics. Inter-arrival times likely are not Poisson either, and thus the M/M/n/n model does not fit perfectly [35–38]. Still, the load aggregates transported over the optical channels are composed from many assembly processes. If these are not correlated (i.e., independent processes), then we can expect that in consequence of the central limit theorem the assumed distributions represent a reasonable approximation.
To achieve favourable traffic aggregates [39] that support a reliable performance, smoothness may be assured by intelligent burst assembly and scheduling control within OBS terminals. For OBS sources, where bursts are assembled and individually scheduled in the electrical domain, network access control and traffic shaping cause negligible extra hardware effort. However, efficient coordination of these mechanisms is a challenge that demands to be studied and standardized, but out of the scope herein.
3. Burst Assembly and End-to-End Performance
A key procedure of any OBS implementation is burst assembly. The assembly process is intrinsic to OBS and dominates the quality of the service (latency and jitter) that OBS offers to client layers [40]. In the literature many proposals for assembly procedures can be found. To list and discuss all proposed options is out of the scope; see [17–19, 40, 41], for examples. Here we concentrate on issues relevant for the core network, namely, burst-length and burst scheduling (inter-arrival time) distributions. These are the characteristics relevant for network layer performance.
3.1. Burst Generation
To realize connection types that match flow characteristics we find two basic parameters that can be tuned: (a) burst-length and (b) interburst time. Basic scheduling characteristics for different flows are listed in Table 1.
To support a flow that demands a bit-rate , the capacity provided by consecutively scheduled bursts (flow of bursts) needs to be where is the average burst length, the average inter-arrival time, and line-rate the bit-rate at which an OBS terminal modulates the optical carrier (wavelength). Note that the latter is not a network constant; using OBS it may differ from terminal to terminal.
Constraints from the core network should be considered in addition to the traffic demands constraints. They are efficiency related and not as stringent as the service-related ones: (i)minimum burst-length > guard-time, (ii)mean burst-length deviation shall be small [42], (iii)generated burst-rate ≪ BCP processing capacity.
Some fairness bias results from the fact that shorter bursts are easier to schedule than extremely long ones [43]. All burst-lengths would need to be equal if this issue should be eliminated [42]. However, it may also be used for service differentiation [44].
A scheme supporting many service types enables individual and adjustable upper and lower bounds on both, burst-length and scheduling-rate. The upper bound on scheduling-rate (inverse inter-arrival time of bursts caused by one flow) will be controlled by the network to avoid congestion in the control plane and thereby prevent that a DB overtakes its BCP. An adaptive, window-based scheme alike TCP (transport control protocol) might be used as well as more sophisticated access control and flow shaping mechanisms. A lower bound on scheduling-rate is necessary to obey the services jitter constraint: small scheduling-intervals introduce less jitter.
This contradicts the suggestion to use global targets on burst-size and inter-arrival time. Any theoretically optimal solution is in reality out of reach if individual traffic demands cannot be met. However, in general one of the two parameters may be tuned to network needs.
3.2. Burst Assembly Model
In this section we present a model for the assembly of IP packets into bursts. Both, time and size limits are applied, and in literature this scheme is often referred to as hybrid burst assembly [45–47]. For means of consistency and analytic usability we assume that IP packets arrive according to a Poisson process with negative exponentially distributed inter-arrival times and packet lengths, and that the assembly process is 100% utilized ().
Figure 6 depicts this assembly strategy. If the time-bound is reached, the burst assembly is instantly stopped, meaning that no more packets become added. This limits the jitter because it bounds the time between the arrival of the first packet assembled into a burst and the time this burst becomes ready for transmission. On the other side, the burst size is bound by stopping the assembly immediately if the size-bound is exceeded. Thereby, the burst loss probability due to decreased scheduling performance is handled. The Markov chain modelling this behaviour is shown in Figure 7.
A problem in the evaluation is the conditional probabilities that describe the current burst-size during the assembly process, and the time that passed since the first load was assembled. Using Laplace transform this has been solved [48], and analytic results shown in Figure 8 conform with simulation.
(a)
(b)
The number of packets per burst is rather unspectacular distributed, and the influence of the two bounds exchangeable. The peak is in the proximity of the tighter bound, slightly shifted according to the distance to the other bound. The burst length distribution is more interesting. If we decompose the observed distribution, we identify a contribution similar to a Poisson distribution from the time bound, and a sharp peak with exponential decay from the length bound. However, if we assume that the burst loss probability is more or less the same for similar burst lengths, we may approximate the halve-sided peak with a narrow symmetric one and approximate the burst-size distribution by a continuous normal distribution. This is also in-line with the property that for high numbers of assembled packets the central limit theorem postulates a trend toward being normally distributed, if the contributing processes (here the individual packet-sizes) are uncorrelated. Finally, the aggregation of a sufficient number of approximated normal distributions is equivalent to the aggregation of the precise distributions, if the individual approximates show corresponding means and variances.
To complete the study we further need the burst arrival characteristic, meaning the distribution of the time in between successive bursts (inter-arrival time distribution). Previously we assumed that it follows a Poisson process. Figure 9 shows that for a sufficient superposition of burst-flows from different assembly processes a quite perfect similarity with negative exponential distribution results, although the output of each burst assembler is very different from that. Again, we observe a sudden peak and exponential decay, now inherently caused by the time bound. The initial exponential decay near zero results from the properties of the negative exponential distributions that we assumed for the packet generation.
For our study, we can always assume that a sufficient number of burst flows contribute to the traffic aggregates on links. For example, a 10 Gbps link is at least carrying 30 burst flows when 30% utilized, if the individual flows are bound to ≤100 Mbps at the ingress (access link) by the network management (admission control). Results considering self-similarity of IP traffic can be found in [2]. It is shown that approximation by Poisson fits for small time-scales, while hyper-geometric characteristic is observed for large time-scales.
3.3. End-to-End Performance
The two key performance metrics from the service side are blocking-/loss-rate and latency. Jitter is also a problem but is bound to terminals, considering the long lasting assembly process and the impact of out-of-order data in case of a burst-loss. Figure 4 depicts the relation between loss-rate and number of parallel channels. Here we compare the results with M/M/1 representing OPS. The problem of blocking in case of two-way reservation is out of the scope as it demands consideration of the actual resource assignment strategies to correctly estimate round-trip time influence and reservation success potential [25].
Since end-to-end performance is a problem of queueing-/loss-networks, we assume independence among network nodes as commonly applied. Equations (6) and (8) provide performance approximations, where is the number of hops, indicates the current node, and the next node along a path:
Equation (6) provides an approximation for the expectable end-to-end loss-rate, where for different systems we can insert the known loss-rate expectations per-hop: with accordingly calculated, where and indicate local arrival rate and load for the link providing channels with a service-rate of each. indicates the consequential loss-rate per hop, and for M/M/n/n this relates to , the blocking probability given by the Erlang_B formula depicted in Figure 4.
We note that (6) provides a secure upper bound if the M/M/n/n model represents a worst case only, that is, when the streamlining effect [49] and network access control assure traffic aggregates smoother than Poisson (e.g., as proposed in [39]).
The time needed to transport a burst containing a particular information unit is given in (8):
In (8) we introduce the round-trip time to consider delay from signaling. In case of one-way signaling only applies if a burst needs to be rescheduled (time required to inform the source about the loss equals half the round-trip time). For two-way reservation the entire round-trip time is required to signal the path, and 1.5 round-trip times in case of loss. For not managed transport (UDP like) the part weighted by does not contribute to the length of a connection and the impact of losses is shifted to upper layers.
To depict results we need to assume some load distribution. Equal load distribution is the best case. However, it represents a valid worst case approximation if we apply the maximum load from the most stressed link for all links. To calculate the curves shown in Figure 10 the following assumptions were made: OBS: assembly-time (average) burst lengths, guard-time burst length, BCP processing burst length, JET signaling; OPS: packet size = 0.1 burst length, buffer size = 10× link bandwidth (for loss-rate calculation only), OPS header processing ≤ packet size; both: link length (propagation time) burst length, path lengths are 2, 4, and 8 hops, respectively, and path delays, no reassembly of bursts in case of loss, every hop identically loaded. The reciprocal load increase due to loss is not considered; that is, iterative load-point evaluation is assumed.
(a)
(b)
Figure 10 shows that OBS with 16 parallel channels causes higher loss than OPS; for 256 parallel channels OBS is better. Considering latency, OPS clearly outperforms OBS. Actually, OBS latency relates to the designs load target and is not very load-dependent. Figure 10 shows traces for 30% and 80% load target (16, and 256 parallel channels), which differ slightly due to the difference in burst loss-rate. Due to the small average BCP processing time (required to achieve negligible BCP loss-rates from BCP queueing) latency for OBS clients is clearly dominated by the assembly process. For a detailed study see [27].
4. Just Enough Time Signaling Scheme
Switching in OBS is in principle comparable to circuit switching, though the signaling for channel set-up and channel tear-down is combined in a single message. With packet switching OBS has in common the typical one-way reservation (tell-and-go). The today most popular just enough time (JET) scheme [1] introduced the path-dependent offset-time. The optimized horizon scheduling scheme presented in [50] is mentioned as JET implementation example achieving complexity . The prime features of JET are simplicity and flexibility. Any timing and burst size is possible; no constraints are inherent. However, the path dependence caused fundamental discussions [51, 52]. In principle OBS signaling via control messages is not restricted to one-way. Acknowledged two-way reservation is rarely considered because for the commonly studied IP over OBS application the added latency seems surplus. A study on this problem is presented in [53].
Paths consist of several hops and the processing of BCPs consumes some time. Consequently the initially inserted offset-time decreases hop by hop as shown in Figure 11. That the initial offset-time inserted between BCP and DB at the source is such that at the end of the path the remaining offset-time is sufficient, is a principal demand of JET. Thus, either a constant worst-case offset-time sufficient for the longest possible path or per path determined offset-times are inserted. The latter option is preferred because offset-times add to latency. Commonly prerouted paths are assumed to cover the problem of inaccurate on-demand source routing. However, the first option needs to be chosen if in case of contention distributed routing or deflection routing is applied.
An alternative approach to this problem is proposed in [54] and briefly repeated here. The key is to get rid of the dependence between offset-time and actual path. The proposed scheme limits the influence of BCP processing performance to the proximity of the individual node by compensating the impact on offset-time via adding matching delay-lines to the data channels as shown in Figure 12.
The delay is so dimensioned that with high probability the inserted delay exceeds the time a BCP needs to pass. In average this increases the offset-times along paths, because most BCPs will not consume this worst case time. This improves effective resource utilization, because increased offset-time decreases contention likelihood and thus reduces the amount of resources wasted on bursts lost toward the end of paths [55].
With compensated BCP-delays the initial offset-time is path independent as shown in Figure 13. Inserting delay lines in general increases latency. Here, where we have to consider the BCP processing time either in the offset-time or distributed by delaying the bursts, insertion of the delay lines in the data channels has no negative influence on the latency experienced by the transported information. Comparing Figure 13 with Figure 11 we see that for the data encapsulated in a burst, the end-to-end latency is not increased; that is, the length of the virtual channel is the same.
Insertion of these delay lines improves JET significantly. It enables the use of well-studied distributed routing schemes (e.g., OSPF) and effective autonomous contention resolution schemes (e.g., deflection routing). Both increase network reliability, service availability, and maintenance durability. Consequently, JET should be considered together with this option only. Dispersion compensation and fibre amplifiers can actually be a part of the delay line, if, for example, BCPs use the 1300 nm window for their single-hop transmission, and DBs the less attenuated 1550 nm transmission window for their multihop transmission.
5. GMPLS/OBS Integration
Currently, the generalized multiprotocol label switching (GMPLS) [3] control plane (CP) is the dominating solution for integrating circuit and packet-based services. OBS does not fit well in the strict hierarchy of GMPLS and different options for the GMPLS/OBS integration can be found in the literature. A brief survey is presented to address this important issue. A more detailed discussion can be found in [56].
5.1. OBS versus GMPLS Control Plane Functionalities
The control functions any OBS network needs are as follows [57]: composing, sending, and processing of BCPs (signaling for resource allocation), searching for paths between sources and destinations (routing), determining the needed offset-time (offset-time management) if required, and supporting optional contention resolution schemes (for reduced burst loss-rates). The GMPLS control framework offers two generic functionalities: routing (finding an explicit path) and signaling (performing explicit resource reservation). Mere comparison reveals that GMPLS can cover routing, and it can be adapted to support the OBS signaling. The remaining OBS CP functionalities cannot be covered by the GMPLS control plane. Indeed, most literature on the topic focuses on the coexistence of two separate control planes, instead of morphing them together.
In [57] a feasibility analysis of GMPLS-controlled OBS is presented. Aspects such as implementation, functional integration, and advantages for the OBS network operation are studied. The authors present needed control modifications and conclude that most of the advantages of the GMPLS framework cannot be utilized directly and straightforwardly in the OBS environment.
5.2. GMPLS as a Server Layer
In [58–60] the main approach is to use GMPLS for defining the OBS network topology, and the OBS network appears to be an overlay within a GMPLS-controlled optical network. The authors of [58] suggest that the labelled unit is the BCP and both, BCPs and their corresponding DBs, are treated as client-traffic, so that both reside in the data plane of the GMPLS-controlled network. The authors of [59] propose to use the GMPLS CP for defining the OBS network topology by setting up explicit light-paths and propose protocol extensions [61] required to achieve that without strict resource reservation. From a technical point of view, this scheme proposes that the GMPLS CP defines a virtual topology, which an overlaying OBS network can use to transport bursts (Figure 14). Both suggest no explicit resource reservation during the GMPLS signaling to not contradict the statistical multiplexing feature of OBS. A proof of concept for the approach in [59] can be found in recent work from the same authors where strict QoS levels are guaranteed for a GMPLS-controlled OBS network. Guo et al. [60] propose a multilayered architecture where OBS links are GMPLS-controlled light-paths. However, they use the GMPLS network only to create interdomain LSPs over which pure OBS domains get inter-connected.
The above cited proposals suggest to define (resp., manage) the topology of the OBS network. The problem with this approach is that the performance of the OBS network improves exponentially with the amount of available resources. Consequently, resources currently not utilized should be accessible to OBS at any time. Maintaining an optimal set of LSPs between the OBS nodes is crucial. Neither of the proposals outlined above offers a complete solution for the integration of GMPLS and OBS. The inherent contention problem in OBS is assumed to be solved within the OBS CP, and the strict QoS provisioning of GMPLS is inapplicable.
5.3. GMPLS and Generic OBS Network Integration
The other option for GMPLS/OBS integration is using OBS as a generic transport solution supporting various switching capabilities. The OBS network is used as the underlying transport network, able to connect different switching domains (from GMPLS hierarchy) via different OBS connection types. This approach is described in [29] and intends to integrate all known services under the OBS framework. For regular bursts the same operation as outlined in [58–60] applies. For periodic bursts (constant bit-rate connectivity), and wavelength channels the traditional GMPLS signaling for resource reservation may be used. Unfortunately no specific details of such an adaptation and extension are given in [29].
To achieve such an integration there exist two control options: (a) the OBS CP is kept separate and independent of the overlayed CPs (Figure 15), or (b) a modified GMPLS signaling performs the DB signaling, which would facilitate a horizontal integration between GMPLS-controlled legacy services and the OBS transport as depicted in Figure 16.
To realise (a) the OBS signaling needs to be adapted as suggested in [29]. The potentially most powerful integration option is (b). The required adoption in GMPLS signaling for the latter implies changes in the GMPLS resource reservation procedure (support one-way) and specific adaptation functions at the edge of the OBS network for the translation of traditional GMPLS information into OBS-compliant information. The implications of this approach are analysed in [57], where the authors analyse possible GMPLS protocol extensions and modifications which can facilitate DB signaling using GMPLS protocols. The MAINS project outlined in [11] intends to solve this issue (besides others) for metropolitan area networks comprising OBS and OPS switching areas.
6. Flow Transfer Mode
Flow Transfer Mode (FTM) [62] is based on OBS and extends what has been proposed in PATON [29] to integrate electrical and wireless last miles in an entirely burst switched network infrastructure proposing a horizontal integration of transport options to achieve area and layer independent support for any service type. Comparable with OBS, it is a step beyond the traditionally uniform digital communication paradigm. FTM enables multiplexing of different channel types on the same transport resources without restrictions (hierarchy) limiting flexibility. FTM exploits the entire potential for statistical time division multiplexing and therefore optimal resource utilization is not impossible. Providing features identical to those known from circuit switching and packet switching it proposes a universal network paradigm.
An intrinsic feature is the principal end-to-end transparency. Information units are not restricted to certain formats and consequently FTM terminals can freely choose modulation and digital format during operation without the need to inform the network, as long as the bursts (time intervals) of a provided connection are sufficient to encapsulate the stream of frames created by the source. Not being designed only for the optical domain, FTM enables the integration of different last mile technologies. Finally, relay nodes may perform O/E/O conversion and burst rescheduling to extinct the constraints of OBS.
In the electrical and wireless field FTM represents a multi-bit-rate TDM approach. The nodes at the edges of the transparent OBS domains solely convert the electrical bursts 1 : 1 into optical bursts and vice versa, without changing the structure of the data contained, that is, without performing burst assembly. Bursts are created and disassembled at FTM terminals only.
As proposed in [62] FTM will support a number of different connection types (services). The basic types and the corresponding signaling demands are listed in Table 2.
While two-way signaling is always an option, some service types recommend it. All services that grant assured delivery without loss monitoring and rescheduling of lost bursts actually demand the use of an acknowledged reservation scheme. Also those that grant a certain channel capacity or enable capacity adjustments profit from acknowledged reservation. The relational prioritisation outlined in [63, 64] can still be applied among the services using one-way reservation. Thus, the relative service classes defined for IP are fully supported.
The design of an FTM switch (Figure 17) is identical to that of a generic OBS switch. However, FTM adds the option to realize it in the electrical domain and therefore allows to consider buffering options and rate-conversion options within the MUX/DEMUX units on line- cards.
Based on Table 2 the required signaling options are as follows: (i)infinite duration and dedicated tear-down message, (ii)request for repetitive switching of identical bursts,(iii)virtual line capacity change request, (iv)explicitly routed single burst advertisement, (v)single burst advertisement with acknowledgement, (vi)JET one-way signaling.
Not explicitly mentioned are the different acknowledgement demands and routing options. Especially for routing in combination with two-way signaling either well-known schemes need to be adopted or new developed in order to maximize the likelihood of routing success. Finally, to assure reliable network performance utile admission control mechanisms need to be defined, studied, and standardized.
7. Application/Specification Example
To better highlight the implications and features of OBS and FTM we outline an exemplary scenario. Potential candidates for pioneering application/installation are metropolitan networks and in-door networks. Primarily, if other technologies cannot efficiently provide the demanded service types or durable peak capacities. Autonomous self-managed connection provisioning according to ASTN [65] is advisable in this area, and the hardware price needs to be competitive.
7.1. Example Operation/Network Architecture
We consider a municipal fibre to the home/building/curb (FTTx) network operator under open-access regime [66]. The network operator does not offer the services accessed by consumers; instead it provides the connectivity required to connect consumers to the applications offered by different service providers. To efficiently support broadcast services nodes are able to duplicate bursts. The network terminals at customer premises are specific to the services the customer intends to consume (alike current DSL modems). For example, a DVB [67] interface may be provided to directly connect a media set-top box, a POTS or ISDN interface for telephony, and an Ethernet interface for IT services. The operator will offer connectivity to business customers wishing to connect premises as well. Consequently, the installed terminals will comprise a variety of typical and special IT interfaces supporting a wide range of services and solutions.
Consider a meshed network topology that supports redundant connectivity for service providers and business customers, and resource sharing among consumers via locally connected passive optical networks (Figure 18). The example can be scaled to country/national/international coverage, if relay nodes are added where it is needed to overcome the span-limitation imposed by transparent transmission.
7.2. Exemplary Specification of Potential Burst Characteristics
Although bursts from some nanoseconds up to hours are possible, the example applications outlined hereinafter show that a realistic mean burst length is in the area of 125 microseconds. A minimal offset-time equal 10% of the burst length provides about ten microseconds for the worst-case processing (assumed feasible and used as design parameter in [50]) plus 2.5 microseconds guard time for cross-connection setting as required for electro-optical switching hardware [68]. This DB size supports statistically efficient encapsulation of Ethernet frames (10 G interface) and IP packets, that is, the schemes known from SDH. For continuous services we can calculate the implications of such a target burst-length.
An MPEG4-encoded HDTV stream (≤20 Mbps) results in a mean burst inter-arrival time of ≤62.5 milliseconds for 10 G line-rate. This causes latency comparable to those of professional MPEG4 encoders. However, interactive HDTV video applications are assumed to be bound to latency <150 milliseconds [69] (or <100 milliseconds [70]). For unidirectional applications (via http, ftp, streaming, etc.) this does not apply. In this case the dejittering is performed by buffered reassembling of the content from the transmitted fragments.
TV signals from event locations to broadcast centres demand uncompressed transport of 1080 p HDTV signals (3 Gbps) [71]. Using 125 microseconds bursts in a 10 G capable environment results in a scheduling interval of slightly more than 0.4 milliseconds and thus yields the negligible latency required for live direction.
Finally, if we assume access line-rates of 100 Mbps per customer in the near future, bursts ≤125 microseconds cause burst assembly induced jitter <15 milliseconds among adjacent bursts within a transmission phase. This value is one magnitude below those requested by jitter sensitive IP services [69, 70] and leaves sufficient reserve for IP-induced jitter. However, the time-out for the last, not completely filled burst of a transmission phase, needs to be set conforming.
Upper layer ingress traffic shaping is contradictory in an OBS environment, because OBS serves bursty traffic best. Evidently, the methodical jitter introduced by the OBS transport plane, that is, burst-assembly, -scheduling, and -disassembly, needs to be ignored by the transfer control protocols (TCPs) of encapsulated packet flows [72]. Cutting the congestion window to a size below a single burst causes an increase of the round trip time, which is the opposite of what is commonly expected. In addition, problematic TCP reactions may result from lost-bursts or out-of-order reception caused by some congestion resolution mechanisms of OBS. The effect of this has been shown in numerous simulation experiments published. A solid discussion of the issues as well as potential solutions is summarised in [2]. It is shown that TCP SACKS performs best in OBS environments, and Tahoe worst. These issues should be less critical for the comparably small bust sizes we recommend. Still, the TCP selection and parametrisation likely influences the IP over OBS performance more than it is known from IP over SDH environments. With FTM it is possible to request a mean burst rate for jitter sensitive services. However, it would be inefficient to utilize this feature to compensate the jitter sensitivity of some TCP variants if the transported service (e.g., http, ftp) is not jitter sensitive.
7.3. Services Likely Required and Provided by the Operator
(i) IP Packet Tunnelling
OBS and FTM evidently support the transport of bursts holding IP packets. Burst assembly defines the jitter, and this makes service quality manageable and transparent. Obviously, the plain service accommodates bursty User Datagram Protocol (UDP) based traffic best. For demanding services appropriate assembly strategies and fitting transport control mechanisms need to be provided and selected.
(ii) Ethernet Frame Tunnelling
Similar to IP packets Ethernet frames can be assembled in bursts. The vulnerable Ethernet signaling messages are too small and delay sensitive to allow assembly into special bursts. An option proposed in [73] is to define BCPs that provide the space required to insert these Ethernet control messages.
(iii) Linking of Circuit Switched Nodes
To natively connect ATM and SDH switches is an important migration offer. Reusing the fibres while not demanding to switch off SDH and ATM switches and services is a compelling offer. ATM services might efficiently utilize different connection types; SDH links demand constant bit-rate lines.
(iv) Tunnelling Circuit-Based Traffic
FTM is based on the idea to directly connect terminals via virtual back-to-back connections. Effort needs to be spent on fragmentation, coding, (re)timing, and (re)synchronization. Terminal vendors will implement what they can afford and sell. The primary connection type is the CBR service. Dynamic lines [74] may be supported by the adjustable line service.
(v) Wavelength Provisioning
To support applications that use proprietary modulation formats or techniques that strictly demand time-continuous optical-bandwidth, for example, cable-TV (DVB-C) and radio-over-fibre (RoF), the only option is to dedicate them an entire wavelength. Electrical last miles can be integrated via analogous (linear) E/O and O/E conversion, if this is economic.
(vi) File Transfer
With bursts fitted to file size efficient file transfer can be done. Huge bursts are difficult to route; therefore it is important for this application to rely on a two-way reservation mechanism that by itself finds the best fragmentation and scheduling.
(vii) Multimedia Broadcast
50 HD and 200 SD MPEG4 compressed TV-channels sum-up to ≤2 Gbps. Assembling all streams in parallel allows transporting the entire live program in a single stream of bursts. No network resource needs to transport more than one burst stream, if core nodes can duplicate broadcast bursts.
(viii) Surveillance
Hundreds of video-streams propagate in parallel, wherever human supervision of areas is required. A preconfigured tree providing reserved containers that merge according to priority could efficiently support this application.
(xi) Remote Control
If control events are rare, it is not too big of a burden to use an entire high priority burst to send a control signal. Most of the bursts capacity will not be used; robustness is the issue here.
Many more potential applications could be stated, and new applications pop up with ever increasing frequency. Thus, modern technologies need to be adoptable to comfort future applications without change in core components.
The remote control application above already indicated a prime drawback: too small traffic volumes cannot be efficiently transported, if the application is not extremely latency insensitive. Traffic resulting from such applications should be transported groomed with other traffic flows. Still, it is not prohibited or impossible to transport partially empty bursts.
8. Conclusion
Having discussed the OBS switching paradigm, challenges, and options for improvements, we conclude that autonomous core nodes may be realized independent of supported applications and connection types. OBS and FTM support transparent connections between terminals. These can be freely tuned to support legacy and future application demands.
Compared to the currently omnipresent though invisible core networks that provide the links (trunks) between IP routers, the achievable resource utilization may be rather poor. Compared with the usual load transported over the trunks between IP routers (≤30% for prime operators) we realize an efficiency improvement from leaving behind the packet over circuit paradigm. The clear advantage is that PATON and FTM schemes utilize statistical multiplexing and at the same time can offer circuit-like connections within a single network layer.
Intelligent terminals performing access control and flow shaping (adaptive burst assembly) may be seen as a drawback. However, similar approaches (admission control) are currently intensely investigated for all-IP environments, and the results are equally applicable. Compared with core IP-routers and 100 GB Ethernet switches the expected power consumption should be magnitudes lower. This reduces operational costs and environmental impact, and recommends burst switching as next generation backbone technology.
A merger/integration with GMPLS poses many challenges. We surveyed two possible collaborative interactions, and both seem to be possible. However, the ability of OBS and FTM to support different switching domains in parallel recommends OBS as service layer with overlayed GMPLS control. Consequently, a virtual path signalled by GMPLS will in general not reside in a circuit-switched channel. This modification causes no problems if the required quality is reliably provided.
Performance results and the application example were intentionally based on well-known techniques and technologies to show that OBS can be realised off-the-shelf. The Erlang model was used because it is common, is well understood, and at low loads overestimates blocking. Therefore, we can expect better performance than the calculated bounds indicate, that is, assume being on the save side with our predictions.
Finally, technology-specific implementation details and alternatives confining the paradigm were intentionally left aside in order to foster the “big picture” of this potential and generically applicable network paradigm.
Acknowledgments
The authors would like to thank colleagues and partners in the joint activity within WP11 of the BONE-project (Building the Future Optical Network in Europe), a late Network of Excellence funded by the European Commission through the 7th ICT-Framework Program, for valuable feedback and discussions.