2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia
Redefining Flow Label in IPv6 and MPLS Headers for
End to End QoS in Virtual Networking for Thin Client
Mohammad Aazam1, Adeel M. Syed2, Eui-Nam Huh3
Innovative Cloud and Security Lab, Department of Computer Engineering
Kyung Hee University, Suwon, South Korea.
2
Bahria University, Islamabad, Pakistan
1
aazam@ieee.org
2
adeelmuzaffar@gmail.com
3
johnhuh@khu.ac.kr
Abstract— Applications that require timeliness such as; video
conferencing, Voice over IP (VoIP), Video-on-Demand (VoD)
etc., require quantified and well managed Quality of Service
(QoS). For this, the flow label field in IPv6 header and the Label
field in MPLS header should be used for efficient QoS
provisioning. In this paper, flow label specifications were first
investigated and then a new structure is proposed for QoS
provisioning. The 20-bit field in IPv6 as well as MPLS is meant to
provide QoS, other than labeling or identification purpose. But
its usage is not standardized and defined that how these 20-bits
must effectively be used to provide maximum possible QoS in a
better way. This paper discusses it by proposing portions for QoS
by explicitly specifying bandwidth, delay, and packet loss. By
keeping the QoS parameters open in this way, it would be easy
for a flow to decide what to reserve and how much to reserve.
After that, mapping of flow label with class fields of IPv6 and
MPLS is presented. In virtual networks, specially for Thin
client, service quality degradation is a major issue, when IPv4-
IPv6 virtual networks co-exist. This is also where this
redefinition can come very handy.
Keywords—Flow label; IPv6; MPLS; QoS; virtual networking;
Thin client
I. INTRODUCTION
Quality of Service is among the major concerns in today’s
overwhelming and demanding multimedia content abundance.
User’s demands for QoS are increasing as multimedia content
is becoming ubiquitous, since, high definition videos and
other multimedia content is easily accessible through mobile
devices as well. In the core networks, MPLS is preferred
because of its fast packet forwarding through the label field.
But for the identification of flows, the whole 20-bit label field
is not used. So, if those 20-bits are wisely used, they can be
very useful for QoS provisioning as well [1, 2, and 3]. In the
access network, where IPv6 is under deployment after the
address exhaustion of its predecessor IPv4, also has a 20-bit
field, known as flow label. Other than the address space
increase, introduction of flow label field was another major
change in IPv4 header, for QoS purpose [1]. IPv6 over MPLS
978-1-4673-6050-0/13/$31.00 ©2013 IEEE 585
is considered to be the best available and most efficient
combination of protocols on layer 2 and layer 3 for routing of
packets. So, the same specification of label field can be used
with both these protocols to allow the stability in QoS for a
particular flow, throughout the communication, from MAC to
the network layer. A ‘flow’ can be defined as a sequence of
packets sent from a particular source to a particular (unicast or
multicast) destination for which the source desires special
handling for QoS by the intermediate routers [8]. The flow is
uniquely identified within the network by the flow label and
its source address. All packets belonging to one flow should
be treated within the network in the same way. The usage of
the flow label is not completely specified within the RFCs [8]
and [9]. However the flow label field can be defined as a 20-
bit field that may be used by a source to label sequences of
packets for which it requests special handling by the routers,
such as non-default quality of service or real-time service [8].
During our studies [15, 16], it was realized that in virtual
networking environment, when IPv4 and IPv6 coexist, it
incurs some reasonable amount of signaling overhead, due to
which, service quality degrades. Since, redefinition of flow
label for end to end QoS is the main concern of this paper and
also due to space limit, we are not going into the details of
IPv4-IPv6 internetworking and virtualization.
A. MPLS traffic classification and Quality of Service
The experimental 3-bit field in the MPLS header, also
known as Class of Service (CoS), is a form of priority queuing
that has been used in a number of communication and
networking protocols. It is a way of classifying and
prioritizing packets based on application type (voice, video,
file transfers, transaction processing). CoS classifies traffic
into categories such as high, medium, and low. CoS is a
queuing mechanism while on the other hand, Quality of
Service (QoS) covers a wider range of techniques to manage
bandwidth and other network resources. CoS classifies
packets by examining the packet for the CoS parameters or
2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia
CoS markings and places packets in queues of different
priorities based on predefined criteria. QoS is to guarantee
certain levels of network performance to meet service
contracts or to support real-time traffic. With QoS, some
mechanism is used to reserve bandwidth across a network in
advance of sending packets. CoS is traffic differentiation or
the ability to treat packets differently based on the packet’s
importance or requirements [7]. When there is more traffic
sent over an access link than that of the link’s capacity and
congestion occurs, CoS ensures that the highest priority
packets, e.g. voice and video are delivered first. CoS is most
oftenly used on the customer access links, as these links are
frequently low-bandwidth connections. CoS is a way of
managing traffic in a network by grouping similar types of
traffic, for example: e-mail, streaming video, voice, large
document file transfer together and treating each type as a
class with its own level of service priority. Unlike the case of
QoS traffic management, CoS technologies do not guarantee a
level of service in terms of bandwidth and delivery time; they
offer a best-effort. One can think of CoS as coarsely-grained
traffic control and QoS as finely-grained traffic control.
QoS represents the set of techniques necessary to manage
network bandwidth, delay, jitter, and packet loss. If the
network bandwidth is not enough, even high-priority traffic
may not get through. Traffic engineering, which enables QoS,
is about making sure that the network can deliver the expected
traffic loads. QoS refers to control mechanisms that can
provide different priority to different users or data flows or
guarantee a certain level of performance to a data flow in
accordance with requests from the application program.
In MPLS network, when IP traffic enters a Label Switch
Path (LSP) tunnel, the ingress router marks all packets with a
CoS value, which is used to place the traffic into a
transmission priority queue. The routers within the LSP utilize
the CoS value set at the ingress router. The CoS value is
encoded using the CoS bits (also known as the EXP or
experimental bits). When traffic enters an LSP tunnel, the CoS
bits in the MPLS header are set in one of two ways. In the first
way, the number of the output queue into which the packet
was buffered and the Packet Loss Priority (PLP) bit are
written into the MPLS header and are used as the packet's CoS
value. In the second way, a fixed CoS value can be set on all
packets entering the LSP tunnel. This means that all packets
entering the LSP receive the same class of service.
In respect of provisioning QoS, MPLS relies on its 20-bit
Flow label field, which is yet to be standardized for QoS
provisioning. The packet arriving is treated with respect to the
value contained by its label, or in other words, the Flow Label
value of that arriving packet. Flow Label contains the actual
value of MPLS label. When a labeled packet is received by an
MPLS router, the top-most label is checked. Based on the
978-1-4673-6050-0/13/$31.00 ©2013 IEEE
contents of the label three kinds of operations can be
performed; swap, push (impose) or pop (dispose). In a swap
operation the label is swapped with a new label, and the
packet is forwarded along the path associated with the new
label. In a push operation a new label is pushed on top of the
existing label. This is called ‘encapsulation’. In a pop
operation the label is removed from the packet and gets the
inner label below. This process is called ‘decapsulation’. If the
popped label was the last one on the label stack, the packet
leaves the MPLS tunnel. This process is done by the egress
router. Routers have lookup tables, according to which they
perform operations based on the top-most label of the
incoming packet, so they can process the packet quickly.
In MPLS network, packet forwarding is entirely based
upon the labels. The label, or in other words, the Flow Label
field value is traversed and packet is forwarded over the
network entirely on that given value. So when any packet
enters the MPLS network, it must be labeled in such a way
that not only the forwarding become more efficient, but also,
QoS is provided as well, as it has been asked and required by
the flow itself. So it is very important that this Flow Label
field is defined very well with sufficient specifications for a
flow to mention. By this, if the field is well-defined, then the
labels are more effective to be setup for a particular flow, e.g.
a flow can tell itself that on what basis it should be forwarded,
on what basis it should be prioritized. If the bandwidth is
specified, then the Label Switch Routers (LSRs) know that
how much bandwidth this flow asks and thus how much
priority should be given to this flow while forwarding. So the
packets arriving from that flow would then be treated same
way with that particular bandwidth, which was asked or
mentioned while label setup. Similarly, other QoS
components could also be mentioned in this way, like, the
amount of delay and the packet loss this flow can tolerate. In
some cases, applications like, video conferencing, VoIP, etc.,
can tolerate more delay as compared to other traffics, like file
streams etc. so the MPLS routers know that this flow can
tolerate a bit more delay, so it can be processed and forwarded
in succession to the more demanding application (flow). So
this make MPLS network more ‘as per requirement’ and more
efficient, which is the basic theme behind the evolution of
MPLS architecture.
B. IPv6 traffic classification and Quality of Service
For the purpose of traffic classification, IPv6 has an 8-bit field
called Traffic Class (TC) [9]. The purpose of this field is also
generally the same as CoS field in MPLS header, as discussed
in the previous section. The TC field’s first 6-bits are for
differentiated services code point (DSCP) classification
purpose, for coarse-grained traffic classification, while the last
2-bits are for explicit congestion notification (ECN). With this
586
2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia
field, using the first 6-bits, 64 distinct classes of traffic can be
classified. One the other hand, for QoS and label identification
purpose, like MPLS, IPv6 has a same 20-bit label field known
as Flow Label. Mapping and redefinition of flow label is
discussed detail in section III and IV.
II. RELATED WORK
A new format for flow label field is proposed in [1, 2], shown
in figure 1.
Figure 1. Proposed flow label format in [1]
The major issue in this proposal is that the authors have not
discussed how these sub-fields are going to be used and how
the routers will interpret each portion in this field. Other than
this, the identification part, which is named here as Random
Value, is too small to uniquely identify the flows. A 6-bit field
will be able to identify 64 distinct flows. This should also
have been justified. Also, mapping of traffic classes and flow
label is not mentioned.
In [3], secured flow label transmission is presented using
MD5 hash, but does not cater the interpretation of those 20-
bits.
Paper [4] proposes flow label usage with the division of 20-bit
field into three parts, as shown in figure 2.
Figure 2. Proposed flow label format in [4].
Paper [4] does not explain further the interpretation of the
divisions for QoS purpose. Also, class of service mapping
with flow label is not shown either.
Paper [5] performs an evaluation of various proposed flow
label formats. It concludes that hybrid flow label formats are
relatively better in performance, as compared to DiffServ and
IntServ. This is because DiffServ and IntServ rely mostly on
Transport layer information.
RFC [6] states that the so far proposed flow label formats are
inconsistent with the standard, thus, cannot be adapted.
In [8], the Flow Label value reuse is discussed as to avoid
accidental Flow Label value reuse, the source node must
select new Flow Label values in a well-defined sequence (e.g.,
sequential or pseudo-random) and use an initial value that
avoids reuse of recently used Flow Label values each time the
system restarts. The Flow Label value that was set by the
source must be transmitted unchanged to the destination.
978-1-4673-6050-0/13/$31.00 ©2013 IEEE
When sending data, the basic transport vehicle of IP is not
reliable. Packets can be lost, dropped, or even never delivered
for many reasons, especially when the network gets busy.
Properties of flow label are also presented as [6, 8]: the flow
label value is set to all zero, if the packets are not part of any
particular flow. The 3-tuple: source address, destination
address, and flow label, uniquely identifies packets that
belong to a particular flow. Packets can receive flow-specific
treatment if the node has been set up with flow-specific state.
The flow label set by the source node must be delivered to the
destination node; i.e., it is an end-to-end label. The same pair
of source and destination addresses must not use the same
flow label value again within a timeout of at least 120 seconds
[6, 8].
In [9], it has been mentioned that this Flow Label field is
still experimental and subject to change as the needs for QoS
become clearer. Those hosts and routers, which do not support
this field, set Flow Label field to zero, when originating the
packet. Similarly, they pass on the field unchanged while
forwarding the packets and ignore it when they receive the
packets. If the Flow Label value is zero, it means the packet is
not part of any flow. So it is treated independently with the
default values or specifications set initially.
In [10], it is discussed that for better traffic engineering,
besides all other things, the efficiency of bandwidth resources
must also be increased. Available bandwidth should be
advertised for priority traffic. Bandwidth should also be
advertised for best-effort traffic.
Discussed in [11], in addition to packet drops, two other
QoS measurements must be considered: jitter and latency.
Combined together, these elements are experienced by the end
user as a transmission delay. Controlling bandwidth utilization
can in turn control jitter and dropped packet percentage
(packet loss rate). Since latency is a measurement of delay that
is caused by the movement of electrons across a system,
latency cannot be controlled in real time. Low latency must be
designed into a network from the start. Hosts or routers that
do not support the functions of the Flow Label field are
required to set the field to zero when originating a packet, pass
on the field unchanged when forwarding a packet, and ignore
the field when receiving a packet.
The label-setup and label-release policies are presented in
[12]. Paper [12] also proposed a close-loop queuing model for
MPLS switch. A distributed web-based MPLS management
architecture is presented focusing on bandwidth,
throughput, and error-rate of LSPs in [13]. The architecture in
[13] suggests six services in case of MPLS; LSP service
(configuration and tracing of LSPs), monitoring service
(monitoring of performance parameters), topology service
(provisioning of neighborhood information), Traffic
587
2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia

Engineering (TE) service (configuration of tunnels), Label

Distribution Protocol (LDP) service (configuration of LDP-
related parameters), and Virtual Private Network (VPN)
service (configuration of VPNs). The architecture in [13]
combines the positive aspects of conventional distributed
Figure 3. Flow label field
applications with web-based access from arbitrary (random)
client systems.

In paper [14], the solutions MPLS provides and the

solutions IP provides are discussed. Paper [14] says that in
case of MPLS, traffic engineering and network layer VPNs
are two services that rely on different label distribution
protocols and carry different flows of traffic. For traffic
engineering, resource reservation protocol-traffic engineering
(RSVP-TE) provides label along a path, while for VPNs, the
multi protocol-border gateway protocol (MP-BGP) provides
the facility of inter-site VPN connectivity by distributing
labels to participating routers. In the context of IP tunneling,
generic routing encapsulation (GRE) is a simple scheme for
tunneling network layer packets across an IP network.
Similarly for security, IPsec provides authentication and
encryption of IPv4/IPv6 packets traveling through the tunnel.
Paper [14] suggests that these protocols must be enhanced to
provide tunneling of L2 frames.
III. REDEFINITION OF FLOW LABEL FIELD FOR QOS
The RFCs [8, 9] relating Flow Label does not describe the
20-bit field that how it would provide QoS or help in QoS
provisioning. It is not mentioned that how should these 20-bits
be used to efficiently utilize for best possible QoS, as required
by a particular flow. The original Flow Label format is shown
in figure 3. It is clear that the Flow Label field is left open for
use without any particular specifications about how it should
be used and for what types of QoS and flows.
This paper suggests new specifications for Flow Label for
more specific flow requirements. The redefined field is
illustrated in figure 4. Here the whole field is divided into five
portions; Special Treatment (S) (yes or no), Bandwidth
(Kbps), Delay (milliseconds), Packet Loss (%), and an
Identification field to identify the ongoing flow. Bandwidth,
Delay, and Packet Loss are set to 2-bit each. While Bandwidth
is composed of 3 bits. S field is 1-bit and the Identification
field is 12-bit. So, the QoS part in flow label comprises of 8
bits in total. The division of this 20-bit field and the lenghth of
each sub-field is decided based upon the usual requirements
today’s multimedia and critical data experiences. This
specification makes easy for the application to decide itself
that the flow belongs to it must be provided with how much
bandwidth, how much delay it can tolerate, and what
percentage of packet loss is endurable.
Figure 4. Redefined flow label field
The 1-bit S field determines whether the flow requires special
QoS treatment or not? If the bit is set on (1) then it means that
the other sub-fields (Bandwidth, Delay, Packet Loss) of flow
label must also be examined. If the bit is off (0), then it means
that the flow does not require special QoS requirements and
other sub-fields of flow label are not examined and default
treatment is done, which saves precious processing time.
For the bandwidth requirements, 3 bits are reserved. 3 bits
are reserved keeping in view the current trend and
requirements of the applications. If no extra bandwidth is
required, then all these bits are set off and no extra bandwidth
is provided, except the default one. For maximum bandwidth,
all bits are set on. The formula for bandwidth calculation is:
Bandwidth = (2n * 64) Kbps (1)
Where ‘n’ is the decimal equivalent of the value of this field,
and the constant 64 Kbps is set which would be the minimum
bandwidth provided in the case when all bits are off.
TABLE I. BANDWIDTH SPECIFICATIONS
Bit pattern Bandwidth Value
000 64 Kbps
001 128 Kbps
010 256 Kbps
011 512 Kbps
100 1024 Kbps
101 2048 Kbps
110 4096 Kbps
111 8192 Kbps
Same is the case with Delay sub-field. If no need to
mention about delay tolerance, then the default delay would
be assigned to that flow. The flow could be assigned with a
particular delay which it can tolerate during transmission and
processing. If any flow is sensitive, then it can explicitly
mention through this field that how much delay is acceptable
in maximum.
The formula to calculate delay is given in equation 2:

978-1-4673-6050-0/13/$31.00 ©2013 IEEE 588

2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia
Delay = (2n * 50) milliseconds (2)
Here ‘n’ is the decimal equivalent of the value of the field and
the constant value 50ms is set which is the minimum delay
flow has to tolerate in case all the bits are off.
TABLE II. DELAY SPECIFICATIONS
Bit pattern Delay Value
00 50 ms
01 100 ms
10 200 ms
11 400 ms
The Packet Loss sub-field specifies that how much loss in
percentage is endurable and affordable for this flow by
specifying bit values in this field. Some applications, like
Video on Demand (VoD), Voice over IP (VoIP), Video
Conferencing etc., can tolerate comparatively more packet
loss because for such applications few packets loss does not
cost them that much data which could be crucial enough to
understand the contents.
The formula is given in equation 3:
Packet Loss = 10(n-8) % (3)
Where ‘n’ is the decimal equivalent of the field value.
In case all the bits are off, the minimum inevitable packet loss
would then be 10-8 = 0.00000001%. While specifying this sub-
field, the intentions were that the flow would endure
maximum of 10-5 % loss of its packets and not more than this,
so that is the basic reason why this field is restricted to just 2-
bits. Because if both these two bits are on, it makes 3 in
decimal (1+2), so 8 has been subtracted from this so that the
maximum value still not exceeds 10-5%.
TABLE III. PACKET LOSS SPECIFICATIONS
Bit pattern Packet Loss Value
00 10-8 = 0.00000001 %
01 10-7 = 0.0000001 %
10 10-6 = 0.000001 %
11 10-5 = 0.00001 %
The remaining bits after the QoS portioning, 12-bit
Identification field will be used to identify a flow on the
MPLS network on data link layer and IPv6 network on the
network layer. At one time there would be many flows on the
network. By setting this field to 12 bits means that a
maximum of 212 (i.e. 4096) flows could be uniquely
represented or identified over the MPLS network.
IV. MAPPING OF FLOW LABEL WITH IPV6 AND MPLS CLASS
FIELDS
978-1-4673-6050-0/13/$31.00 ©2013 IEEE
The QoS is provided based on the classes defined through
Class of Service (CoS) field in MPLS and Traffic Class (TC)
field in IPv6. After the flow label field has been redefined, the
other issue rises is that how flow belonging to a particular
QoS specification be mapped with the CoS/TC and how the
algorithm would process MPLS and IPv6 header while
addressing QoS issue. As discussed in the earlier sections,
CoS/TC is a coarse-grained classification, so it must be having
some mapping of flow label for guaranteed QoS, so that the
router knows that what kind of class to be treated in what way
exactly.
Considering the MPLS header first, as the CoS field in
MPLS is a 3-bit field, so it means there can be 8 distinct
classes. After redefining flow label in this paper, the total
number of bits for QoS is 8. Which means that there can be
256 distinct flow treatments, with which, 8 distinct classes are
to be mapped. It means it would be 1-to-32 mapping, shown
in figure 5. This means that for each class, there would be 32
distinct QoS possibilities. So, after reading the CoS field bit
pattern, the router puts 32 different flows into same class.
Now it is up to the router and the application requirement that
each flow is further treated differently, in a fine-grained way,
or the QoS treatment is done in the same way for all those 32
flows, based upon the class type they lie in. Former case
would be mostly better, since this is the purpose of making
distinct flow that they should be treated distinctly or according
to their requirements.
Figure 5. MPLS CoS mapping with redefined flow label
In case of IPv6, the classification field TC is 8-bit in length.
Out of these 8-bits, first 6-bits are used for DSCP purpose (i.e.
for classification), while last 2-bits are for explicit congestion
notification (ECN). So, the first 6-bits can make 64 distinct
classes. Mapping of this with the redefined flow label would
be 1-to-4, as shown in figure 6.
589
2013 19th Asia-Pacific Conference on Communications (APCC), Bali - Indonesia
Figure 6. IPv6 TC mapping with redefined flow label
Since IP over MPLS is the best and most efficient possible
solution for QoS provisioning and packet forwarding from
layer 2 through to layer 3, so, this mapping presented in this
paper is going to be very useful, because the same flow label
format can be used for the data link layer to the network layer
and same QoS parameter will go along.
V. CONCLUSION
The new proposal in this paper can be very effective in
better and efficient provisioning of QoS, as there are clear
options for the application to decide itself what it wants and
how much it requires for its flow to be treated with. Separate
values for bandwidth, delay and packet loss tolerance can be
allocated with this proposal. Instead of using the whole 20-
bits, it would be lot better to mention the most important
components of QoS, which this proposal tries to do. If flow
label is standardized in this way, it can be efficient for the
routers as well. This paper also discusses about the
algorithmic processing for QoS provisioning by discussing
mapping of QoS with CoS/TC. The mapping of classification
fields of MPLS and IPv6 with the redefined flow label field
provides a mean to take the same flow label format from layer
2 through to layer 3 and provide the same QoS in the core
network as well as the access network.
VI. FUTURE WORK
This work requires some implementations and testing,
which is part of our future plan on this study. Weak points, in
terms of implementation, will rise after testing this proposed
usage of flow label. Deeper analysis of the proposed
mechanism is also part of our future study. With different
types of traffic and varied scenarios, it would be interesting to
know the extent of workability of the mapping of flow label
and CoS/TC fields. Also, with different networking scenarios
978-1-4673-6050-0/13/$31.00 ©2013 IEEE
(including wireless, mobile, and ad hoc networks), it would be
tested in the future.
ACKNOWLEDGEMENT
This research was supported by Next-Generation Information
Computing Development Program through the National
Research Foundation of Korea (NRF) funded by the Ministry
of Education, Science and Technology (2012- 0006418).
REFERENCES
[1] Wai Yee Tai, Chong Eng Tan, Sei Ping, Lau, "Towards Utilizing Flow
Label IPv6 in Implicit Source Routing for Dynamic Source Routing
(DSR) in Wireless Ad Hoc Network", in the proceedings of 2012 IEEE
Symposium on Computers and Informatics, Penang, Malaysia, 18-20
March, 2012
[2] Wai Yee Tai, Chong Eng Tan, Sei Ping, Lau , “Improving IPv6 Wireless
Ad Hoc Networks QoS via Enhanced Flow Label with Stability Based
Dynamic Source Routing Scheme”, in the proceedings of 17th IEEE
Asia-Pacific Conference on Communications, Kota Kinabalu, Sabah,
Malaysia, 02-05 October, 2011
[3] Sha Luo, Xiaohong Huang, Lin Hu, Yan Ma, “A Secured Flow Label
Based QoS Scheme for the Evolved Packet Core in the Evolved Packet
System”, in the proceedings of 3rd IEEE International Conference on
Broadband Network & Multimedia Technology, Beijing, China, 26-28
October, 2010
[4] Zhenhua Wang, Qiong Sun, Xiaohong Huang, Yan Ma, “IPv6 End to
End QoS Provision for Heterogenous Networks Using Flow Label”, in
the proceedings of 3rd IEEE International Conference on Broadband
Network & Multimedia Technology, Beijing, China, 26-28 October,
2010
[5] Ejaz Ahmad, Mohammad Aazam, Amir Qayyum, “Comparison of
Various IPv6 Flow Label Formats for End-To-End QoS Provisioning”,
in the proceedings of 13th IEEE International Multitopic Conference,
Islamabad, Pakistan, 14-15 December, 2009
[6] Q. Hu, B. Carpenter, “Survey of Proposed Use Cases for the IPv6 Flow
Label”, RFC 6294, June 2011
[7] E. Rosen, et al, “Multiprotocol Label Switching Architecture”, RFC
3031, January 2001.
[8] J. Rajahalme, et al, “IPv6 Flow Label Specification”, RFC 3697, March
2004.
[9] S. Deering, R. Hinden, “Internet Protocol version 6 Specification”, RFC
2460, December 1998
[10] “MPLS Advanced Concepts and Developments in MPLS”, Networkers-
Cisco Systems Inc., 2004.
[11] Rick Gallaher, “Building Multiprotocol Label Switching Networks”,
Syngress Publishing, November 2003.
[12] Ling-Chih Kao, Zsehong Tsai, “Steady-State Performance Analysis of
MPLS Switching”, in the proceedings of 15th International Conference
on Information Networking, 31 Jan. – 02 Feb. 2001, Beppu City, Japan.
[13] B. Thurm, “Services-Based Architecture for Performance Monitoring of
MPLS Networks”, in the proceedings of IEEE Network Operations and
Management Symposium, April 2002, Florence, Italy
[14] Chris Metz, “Layer 2 over IP/MPLS”, IEEE Internet Computing
Journal, vol. 5, issue 4, pp: 77-82, July 2001
[15] M Aazam et. al., “Evaluation of 6to4 and ISATAP on a Test LAN”, in
the proceedings of IEEE Symposium on Computers and Informatics,
Kuala Lumpur, Malaysia, 20-22 March, 2011
[16] M Aazam et. al., “Deployment and Performance Evaluation of Teredo
and ISATAP over Real Test-bed Setup”, in the proceedings of ACM
Management of Emergent Digital EcoSystems, Bangkok, Thailand, 26-
29 October, 2010
590