As per Relevance of the word utilization, we have this rfc below:
Network Working Group I.
Request For Comments: 2682 Fujitsu Network
Category: Informational A.
Bell Labs, Lucent
September 1999
Performance Issues in VC-Merge Capable ATM
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
VC merging allows many routes to be mapped to the same VC label
thereby providing a scalable mapping method that can
thousands of edge routers. VC merging requires reassembly buffers
that cells belonging to different packets intended for the
destination do not interleave with each other. This
investigates the impact of VC merging on the additional
required for the reassembly buffers and other buffers. The
result indicates that VC merging incurs a minimal overhead
to non-VC merging in terms of additional buffering. Moreover,
overhead decreases as utilization increases, or as the
becomes more bursty
1.0
Recently some radical proposals to overhaul the legacy
architectures have been presented by several organizations,
the Ipsilon's IP switching [1], Cisco's Tag switching [2], Toshiba'
CSR [3], IBM's ARIS [4], and IETF's MPLS [5]. Although the
of their implementations vary, there is one fundamental concept
is shared by all these proposals: map the route information to
fixed-length labels so that next-hop routers can be determined
direct indexing
Although any layer 2 switching mechanism can in principle be applied
the use of ATM switches in the backbone network is believed to be
very attractive solution since ATM hardware switches have
extensively studied and are widely available in many
Widjaja & Elwalid Informational [Page 1]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
architectures. In this document, we will assume that layer 2
switching uses ATM technology. In this case, each IP packet may
segmented to multiple 53-byte cells before being switched
Traditionally, AAL 5 has been used as the encapsulation method
data communications since it is simple, efficient, and has a
error detection mechanism. For the ATM switch to forward
cells to the correct outputs, the IP route information needs to
mapped to ATM labels which are kept in the VPI or/and VCI fields
The relevant route information that is stored semi-permanently in
IP routing table contains the tuple (destination, next-hop router).
The route information changes when the network state changes and
typically occurs slowly, except during transient cases. The
"destination" typically refers to the destination network (or
prefix), but can be readily generalized to (destination network
QoS), (destination host, QoS), or many other granularities. In
document, the destination can mean any of the above or other
granularities
Several methods of mapping the route information to ATM labels exist
In the simplest form, each source-destination pair is mapped to
unique VC value at a switch. This method, called the non-VC
case, allows the receiver to easily reassemble cells into
packets since the VC values can be used to distinguish the senders
However, if there are n sources and destinations, each switch
potentially required to manage O(n^2) VC labels for full-
connectivity. For example, if there are 1,000 sources/destinations
then the size of the VC routing table is on the order of 1,000,000
entries. Clearly, this method is not scalable to large networks.
the second method called VP merging, the VP labels of cells that
intended for the same destination would be translated to the
outgoing VP value, thereby reducing VP consumption downstream.
each VP, the VC value is used to identify the sender so that
receiver can reconstruct packets even though cells from
packets are allowed to interleave. Each switch is now required
manage O(n) VP labels - a considerable saving from O(n^2).
the number of label entries is considerably reduced, VP merging
limited to only 4,096 entries at the network-to-network interface
Moreover, VP merging requires coordination of the VC values for
given VP, which introduces more complexity. A third method,
VC merging, maps incoming VC labels for the same destination to
same outgoing VC label. This method is scalable and does not have
space constraint problem as in VP merging. With VC merging, cells
the same destination is indistinguishable at the output of a switch
Therefore, cells belonging to different packets for the
destination cannot interleave with each other, or else the
will not be able to reassemble the packets. With VC merging,
boundary between two adjacent packets are identified by the "End-of
Packet" (EOP) marker used by AAL 5.
Widjaja & Elwalid Informational [Page 2]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
It is worthy to mention that cell interleaving may be allowed if
use the AAL 3/4 Message Identifier (MID) field to identify the
uniquely. However, this method has some serious drawbacks as: 1)
MID size may not be sufficient to identify all senders, 2)
encapsulation method is not efficient, 3) the CRC capability is
as powerful as in AAL 5, and 4) AAL 3/4 is not as widely supported
AAL 5 in data communications
Before VC merging with no cell interleaving can be qualified as
most promising approach, two main issues need to be addressed
First, the feasibility of an ATM switch that is capable of
VCs needs to be investigated. Second, there is widespread
that the additional amount of buffering required to implement
merging is excessive and thus making the VC-merging
impractical. Through analysis and simulation, we will dispel
concerns in this document by showing that the additional
requirement for VC merging is minimal for most practical purposes
Other performance related issues such as additional delay due to
merging will also be discussed
2.0 A VC-Merge Capable MPLS Switch
In principle, the reassembly buffers can be placed at the input
output side of a switch. If they are located at the input, then
switch fabric has to transfer all cells belonging to a given
in an atomic manner since cells are not allowed to interleave.
requires the fabric to perform frame switching which is not
nor desirable when multiple QoSs need to be supported. On the
hand, if the reassembly buffers are located at the output, the
fabric can forward each cell independently as in normal
switching. Placing the reassembly buffers at the output makes
output-buffered ATM switch a natural choice
We consider a generic output-buffered VC-merge capable MPLS
with VCI translation performed at the output. Other
architectures may also be adopted. The switch consists of a non
blocking cell switch fabric and multiple output modules (OMs),
is associated with an output port. Each arriving ATM cell
appended with two fields containing an output port number and
input port number. Based on the output port number, the
fabric forwards each cell to the correct output port, just as
normal ATM switches. If VC merging is not implemented, then the
consists of an output buffer. If VC merging is implemented, the
contains a number of reassembly buffers (RBs), followed by a
unit, and an output buffer. Each RB typically corresponds to
incoming VC value. It is important to note that each buffer is
logical buffer, and it is envisioned that there is a common pool
memory for the reassembly buffers and the output buffer
Widjaja & Elwalid Informational [Page 3]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
The purpose of the RB is to ensure that cells for a given packet
not interleave with other cells that are merged to the same VC.
mechanism (called store-and-forward at the packet level) can
accomplished by storing each incoming cell for a given packet at
RB until the last cell of the packet arrives. When the last
arrives, all cells in the packet are transferred in an atomic
to the output buffer for transmission to the next hop. It is
pointing out that performing a cut-through mode at the RB is
recommended since it would result in wastage of bandwidth if
subsequent cells are delayed. During the transfer of a packet to
output buffer, the incoming VCI is translated to the outgoing VCI
the merging unit. To save VC translation table space,
incoming VCIs are merged to the same outgoing VCI during
translation process if the cells are intended for the
destination. If all traffic is best-effort, full-merging where
incoming VCs destined for the same destination network are mapped
the same outgoing VC, can be implemented. However, if the traffic
composed of multiple classes, it is desirable to implement
merging, where incoming VCs destined for the same (
network, QoS) are mapped to the same outgoing VC
Regardless of whether full merging or partial merging is implemented
the output buffer may consist of a single FIFO buffer or
buffers each corresponding to a destination network or (
network, QoS). If a single output buffer is used, then the
essentially tries to emulate frame switching. If multiple
buffers are used, VC merging is different from frame switching
cells of a given packet are not bound to be transmitted back-to-back
In fact, fair queueing can be implemented so that cells from
respective output buffers are served according to some
requirements. Note that cell-by-cell scheduling can be
with VC merging, whereas only packet-by-packet scheduling can
implemented with frame switching. In summary, VC merging is
flexible than frame switching and supports better QoS control
3.0 Performance Investigation of VC
This section compares the VC-merging switch and the non-VC
switch. The non-VC merging switch is analogous to the
output-buffered ATM switch, whereby cells of any packets are
to interleave. Since each cell is a distinct unit of information
the non-VC merging switch is a work-conserving system at the
level. On the other hand, the VC-merging switch is non-
conserving so its performance is always lower than that of the non-
merging switch. The main objective here is to study the effect of
merging on performance implications of MPLS switches such
additional delay, additional buffer, etc., subject to
traffic conditions
Widjaja & Elwalid Informational [Page 4]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
In the simulation, the arrival process to each reassembly buffer
an independent ON-OFF process. Cells within an ON period form
single packet. During an OFF periof, the slots are idle. Note
the ON-OFF process is a general process that can model any
process
3.1 Effect of Utilization on Additional Buffer
We first investigate the effect of switch utilization on
additional buffer requirement for a given overflow probability.
carry the comparison, we analyze the VC-merging and non-VC
case when the average packet size is equal to 10 cells,
geometrically distributed packet sizes and packet interarrival times
with cells of a packet arriving contiguously (later, we
other distributions). The results show, as expected, the VC-
switch requires more buffers than the non-VC merging switch. When
utilization is low, there may be relatively many incomplete
in the reassembly buffers at any given time, thus wasting
resource. For example, when the utilization is 0.3, VC
requires an additional storage of about 45 cells to achieve the
overflow probability. However, as the utilization increases to 0.9,
the additional storage to achieve the same overflow probability
to about 30 cells. The reason is that when traffic
increases, the VC-merging system becomes more work-conserving
It is important to note that ATM switches must be dimensioned at
utilization value (in the range of 0.8-0.9) to withstand
traffic conditions. At the utilization of 0.9, a VC-merge ATM
requires a buffer of size 976 cells to provide an
probability of 10^{-5}, whereas an non-VC merge ATM switch requires
buffer of size 946. These numbers translate the additional
requirement for VC merging to about 3% - hardly an
buffering cost
3.2 Effect of Packet Size on Additional Buffer
We now vary the average packet size to see the impact on the
requirement. We fix the utilization to 0.5 and use two
average packet sizes; that is, B=10 and B=30. To achieve the
overflow probability, VC merging requires an additional buffer
about 40 cells (or 4 packets) compared to non-VC merging when B=10.
When B=30, the additional buffer requirement is about 90 cells (or 3
packets). As expected, the additional buffer requirement in terms
cells increases as the packet size increases. However, the
buffer requirement is roughly constant in terms of packets
Widjaja & Elwalid Informational [Page 5]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
3.3 Additional Buffer Overhead Due to Packet
There may be some concern that VC merging may require too
buffering when the number of reassembly buffers increases,
would happen if the switch size is increased or if cells for
going to different destinations are allowed to interleave. We
show that the concern is unfounded since buffer sharing becomes
efficient as the number of reassembly buffers increases
To demonstrate our argument, we consider the overflow probability
VC merging for several values of reassembly buffers (N); i.e., N=4,
8, 16, 32, 64, and 128. The utilization is fixed to 0.8 for
case, and the average packet size is chosen to be 10. For a
overflow probability, the increase in buffer requirement becomes
pronounced as N increases. Beyond a certain value (N=32),
increase in buffer requirement becomes insignificant. The reason
that as N increases, the traffic gets thinned and
approaches a limiting process
3.4 Effect of Interarrival time Distribution on Additional
We now turn our attention to different traffic processes. First,
use the same ON period distribution and change the OFF
distribution from geometric to hypergeometric which has a
Square Coefficient of Variation (SCV), defined to be the ratio of
variance to the square of the mean. Here we fix the utilization
0.5. As expected, the switch performance degrades as the
increases in both the VC-merging and non-VC merging cases.
achieve a buffer overflow probability of 10^{-4}, the
buffer required is about 40 cells when SCV=1, 26 cells when SCV=1.5,
and 24 cells when SCV=2.6. The result shows that VC merging
more work-conserving as SCV increases. In summary, as
interarrival time between packets becomes more bursty, the
buffer requirement for VC merging diminishes
3.5 Effect of Internet Packets on Additional Buffer
Up to now, the packet size has been modeled as a
distribution with a certain parameter. We modify the packet
distribution to a more realistic one for the rest of this document
Since the initial deployment of VC-merge capable ATM switches
likely to be in the core network, it is more realistic to
the packet size distribution in the Wide Area Network. To this end
we refer to the data given in [6]. The data collected on Feb 10,
1996, in FIX-West network, is in the form of probability
function versus packet size in bytes. Data collected at other
closely resemble this one
Widjaja & Elwalid Informational [Page 6]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
The distribution appears bi-modal with two big masses at 40
(about a third) due to TCP acknowledgment packets, and 552
(about 22 percent) due to Maximum Transmission Unit (MTU)
in many routers. Other prominent packet sizes include 72 bytes (
4.1 percent), 576 bytes (about 3.6 percent), 44 bytes (about 3
percent), 185 bytes (about 2.7 percent), and 1500 bytes (about 1.5
percent) due to Ethernet MTU. The mean packet size is 257 bytes,
the variance is 84,287 bytes^2. Thus, the SCV for the Internet
size is about 1.1.
To convert the IP packet size in bytes to ATM cells, we assume AAL 5
using null encapsulation where the additional overhead in AAL 5 is 8
bytes long [7]. Using the null encapsulation technique, the
packet size is about 6.2 ATM cells
We examine the buffer overflow probability against the buffer
using the Internet packet size distribution. The OFF period
assumed to have a geometric distribution. Again, we find that
same behavior as before, except that the buffer requirement
with Internet packets due to smaller average packet size
3.6 Effect of Correlated Interarrival Times on Additional
To model correlated interarrival times, we use the DAR(p)
(discrete autoregressive process of order p) [8], which has been
to accurately model video traffic (Star Wars movie) in [9].
DAR(p) process is a p-th order (lag-p) discrete-time Markov chain
The state of the process at time n depends explicitly on the
at times (n-1), ..., (n-p).
We examine the overflow probability for the case where
interarrival time between packets is geometric and independent,
the case where the interarrival time is geometric and correlated
the previous one with coefficient of correlation equal to 0.9.
empirical distribution of the Internet packet size from the
section is used. The utilization is fixed to 0.5 in each case
Although, the overflow probability increases as p increases,
additional amount of buffering actually decreases for VC merging
p, or equivalently the correlation, increases. One can
conclude that higher-order correlation or long-range dependence
which occurs in self-similar traffic, will result in
qualitative performance
Widjaja & Elwalid Informational [Page 7]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
3.7 Slow
The discussions up to now have assumed that cells within a
arrive back-to-back. When traffic shaping is implemented,
cells within the same packet would typically be spaced by idle slots
We call such sources as "slow sources". Adjacent cells within
same packet may also be perturbed and spaced as these cells
downstream due to the merging and splitting of cells at
nodes
Here, we assume that each source transmits at the rate of r_s (0 <
r_s < 1), in units of link speed, to the ATM switch. To capture
merging and splitting of cells as they travel in the network, we
also assume that the cell interarrival time within a packet is ran
domly perturbed. To model this perturbation, we stretch the
ON period by 1/r_s, and flip a Bernoulli coin with parameter r_
during the stretched ON period. In other words, a slot would
a cell with probability r_s, and would be idle with probability 1-r_
during the ON period. By doing so, the average packet size
the same as r_s is varied. We simulated slow sources on the VC-
ATM switch using the Internet packet size distribution with r_s=1
r_s=0.2. The packet interarrival time is assumed to be
distributed. Reducing the source rate in general reduces
stresses on the ATM switches since the traffic becomes smoother
With VC merging, slow sources also have the effect of increasing
reassembly time. At utilization of 0.5, the reassembly time is
dominant and causes the slow source (with r_s=0.2) to require
buffering than the fast source (with r_s=1). At utilization of 0.8,
the smoother traffic is more dominant and causes the slow
(with r_s=0.2) to require less buffering than the fast source (
r_s=1). This result again has practical consequences in ATM
design where buffer dimensioning is performed at reasonably
utilization. In this situation, slow sources only help
3.8 Packet
It is of interest to see the impact of cell reassembly on
delay. Here we consider the delay at one node only; end-to-end
are subject of ongoing work. We define the delay of a packet as
time between the arrival of the first cell of a packet at the
and the departure of the last cell of the same packet. We study
average packet delay as a function of utilization for both VC-
and non-VC merging switches for the case r_s=1 (back-to-back cells
a packet). Again, the Internet packet size distribution is used
adopt the more realistic scenario. The interarrival time of
is geometrically distributed. Although the difference in the worst
case delay between VC-merging and non-VC merging can be
very large, we consistently observe that the difference in
Widjaja & Elwalid Informational [Page 8]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
delays of the two systems to be consistently about one average
time for a wide range of utilization. The difference is due to
average time needed to reassemble a packet
To see the effect of cell spacing in a packet, we again simulate
average packet delay for r_s=0.2. We observe that the difference
average delays of VC merging and non-VC merging increases to a
packet times (approximately 20 cells at high utilization). It
be noted that when a VC-merge capable ATM switch reassembles packets
in effect it performs the task that the receiver has to do otherwise
From practical point-of-view, an increase in 20 cells translates
about 60 micro seconds at OC-3 link speed. This additional
should be insignificant for most applications
4.0 Security
There are no security considerations directly related to
document since the document is concerned with the
implications of VC merging. There are also no known
considerations as a result of the proposed modification of a
ATM LSR to incorporate VC merging
5.0
This document has investigated the impacts of VC merging on
performance of an ATM LSR. We experimented with various
processes to understand the detailed behavior of VC-merge capable
LSRs. Our main finding indicates that VC merging incurs a
overhead compared to non-VC merging in terms of additional buffering
Moreover, the overhead decreases as utilization increases, or as
traffic becomes more bursty. This fact has important
consequences since switches are dimensioned for high utilization
stressful traffic conditions. We have considered the case where
output buffer uses a FIFO scheduling. However, based on
investigation on slow sources, we believe that fair queueing will
introduce a significant impact on the additional amount of buffering
Others may wish to investigate this further
6.0
The authors thank Debasis Mitra for his penetrating questions
the internal talks and discussions
Widjaja & Elwalid Informational [Page 9]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
7.0
[1] P. Newman, Tom Lyon and G. Minshall, "Flow Labelled IP
Connectionless ATM Under IP", in Proceedings of INFOCOM'96, San
Francisco, April 1996.
[2] Rekhter,Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, "
Systems' Tag Switching Architecture Overview", RFC 2105,
1997.
[3] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's
Architecture Extensions for ATM: Overview", RFC 2098,
1997.
[4] A. Viswanathan, N. Feldman, R. Boivie and R. Woundy, "ARIS
Aggregate Route-Based IP Switching", Work in Progress
[5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A
Viswanathan, "A Framework for Multiprotocol Label Switching",
Work in Progress
[6] WAN Packet Size Distribution
http://www.nlanr.net/NA/Learn/packetsizes.html
[7] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.
[8] P. Jacobs and P. Lewis, "Discrete Time Series Generated
Mixtures III: Autoregressive Processes (DAR(p))",
Report NPS55-78-022, Naval Postgraduate School, 1978.
[9] B.K. Ryu and A. Elwalid, "The Importance of Long-Range
of VBR Video Traffic in ATM Traffic Engineering", ACM SigComm'96,
Stanford, CA, pp. 3-14, August 1996.
Widjaja & Elwalid Informational [Page 10]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
Authors'
Indra
Fujitsu Network
Two Blue Hill
Pearl River, NY 10965,
Phone: 914 731-2244
EMail: indra.widjaja@fnc.fujitsu.
Anwar
Bell Labs, Lucent
600 Mountain Ave, Rm 2C-324
Murray Hill, NJ 07974,
Phone: 908 582-7589
EMail: anwar@lucent.
Widjaja & Elwalid Informational [Page 11]
RFC 2682 Issues in VC Merge Capable ATM LSRs September 1999
9. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Widjaja & Elwalid Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
