Internet DRAFT - draft-arumuganainar-rtgwg-dps-requirements
draft-arumuganainar-rtgwg-dps-requirements
INTERNET-DRAFT Arunkumar Arumuga Nainar
Intended Status: Informational draft Tata Communications Ltd
Expires: April 5, 2014 October 2, 2014
Dynamic Path Selection Requirements
draft-arumuganainar-rtgwg-dps-requirements-01
Abstract
The high availability puzzle can be resolved by building in
resiliency to network designs. Whilst active/backup routing schemes
are sufficient to create redundancy with low convergence times the
following deficiencies and customer demands are not addressed
comprehensively.
1. IP routing is essentially best path based. This will lead to
underutilized or over utilized links.
2. WAN application performance could be adversely impacted due to
congestion whilst the backup link remains idle. Techniques such as
DiffServ QoS do address the problem effectively, but those approaches
address only the symptoms and not the root cause.
3. Half of the network resources that the end customer has paid for,
always remains unused. This is a matter of huge concern for small and
mid-size customers as WAN circuit costs are very high and recurring.
Hence there is genuine requirement to offload some of the traffic to
an alternate path while the primary path is still active and running.
This document defines this requirement in detail.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
Arunkumar Arumuganainar Expires April 5, 2014 [Page 1]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic assumption . . . . . . . . . . . . . . . . . . . . . . . 3
3.Problem statement :- . . . . . . . . . . . . . . . . . . . . . . 5
4. DPS Routing Requirements . . . . . . . . . . . . . . . . . . . 5
5. Dynamic Path selection Framework . . . . . . . . . . . . . . . 7
6. Packet flow in DPS Environment . . . . . . . . . . . . . . . . 10
8. Implementation Details and Gap Analysis. . . . . . . . . . . . 10
8.1 DPS Routing domain:- . . . . . . . . . . . . . . . . . . . . 10
8.2 DPS Signaling:- . . . . . . . . . . . . . . . . . . . . . . 12
8.3 Profile based Filter . . . . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 15
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Arunkumar Arumuganainar Expires April 5, 2014 [Page 2]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
1 Introduction
In a large enterprise environment, network locations are often
distributed over large geographical areas (often it spans different
countries and continents). In such a case enterprise network managers
often buy virtual private networks from service providers. Such a
network is built over either MPLS or Internet/IPSEC extension to MPLS
networks.
Generally the enterprise end user location connects in to the service
provider using last mile connections. These last mile circuits comes
in various technology options and bandwidth capacities. While the
service provider core is very resilient and virtually has infinite
capacity in terms of bandwidth, the weak link in the enterprise
network is indeed the last mile.
Last miles are the costliest component for the enterprise and most of
the times it contributes to 50-60% of total network costs. Yet these
are the weakest link in the network. They constitute single point of
failures and do fail frequently. Hence in order to increase the
network availability the network managers buy redundant links.
With redundant links in place, the availability puzzle is fully
resolved, however, it does pose a significant question. Half of the
costliest resource that they have purchased will remain idle through
out the life of this network. This happens while network managers
work over time to resolve the issues that arise out of congestion on
the primary circuit.
There is a genuine need to identify few select application and off
load them on to a path that is considered to be the best path by the
routing protocols. This draft defines and documents this requirement.
This draft also describes the high level framework based on which
such application off loading could be accomplished. The scope of
draft also includes the evaluation of the existing techniques and
their gap analysis.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Basic assumption
This draft addresses a problem faced in an enterprise network.
Typical enterprises comprise of collection of sites/Local Area
Arunkumar Arumuganainar Expires April 5, 2014 [Page 3]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
Networks (LANs) that are spread across a large geographical area
(across cities, countries and continents). These sites are
interconnected via a virtual private network of some form. Such
enterprises typically go to single or even multiple service providers
to establish this connectivity.
In such a case, the service provider will interconnect the site at
their POP location via a last mile circuit. The choice of last mile
technology could be diverse such as Ethernet, Frame-Relay, ATM, DSL,
T1/E1/T3/E3, etc. Bandwidth capacity also varies from location to
location (as low as 512 Kbps DSL to as high as 10 Gbps Ethernet). In
cases where VPN connectivity is not possible, the VPN network can be
extended in to a remote location via Internet/IPSEC technologies as
well. Due to the diverse nature of the connectivity option, any frame
work should be agonistic to technologies and choice of providers.
Router 1--------(POP1)------|
|
|-----Customer VPN
| (SP Managed Core)
Router 2--------(POP2)------|
This draft assumes availability is very important for the target
enterprises, hence there will be at least two last mile circuits that
link them to the service provider core. Again, technology and the
last mile provider can be chosen independently. Often enterprises
selects a good or premium primary circuit and cheaper option for the
secondary connectivity. For example
1) Primary: 10 Mbps Ethernet to MPLS; Secondary:- 10 Mbps Ethernet to
MPLS
2) Primary: 10 Mbps Ethernet to MPLS; secondary:- 2 MBPS E1 circuit
to MPLS
3) Primary: 1.5 Mbps T1; Secondary:- ADSL 2+ Internet/IPSEC
The above samples are for illustration taken from typical examples
found in the field.
Routing schemes usually designate the premium circuit option as
primary. Routing protocol metrics will hence be better for the link
and all the traffic goes over it as long as they are active. Traffic
shift to the secondary if the primary circuit goes down. This kind of
routing scheme is called classical routing or Active-passive routing
scheme.
Arunkumar Arumuganainar Expires April 5, 2014 [Page 4]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
3.Problem statement :-
In the classical routing scheme, all traffic goes over the primary
circuit. Sizing of the circuit will depend on the bandwidth
requirements of all the applications running on the LAN side which
need remote connectivity. Last mile circuits generally constitute a
large bulk of the wan network cost. In some networks that are
geographically well spread this could constitute 50-60% of total WAN
network costs, hence over sizing the network is not an option.
As an alternative, the Network Administrator could resort to Quality
of Service. This will ensure applications that are critical to the
business get enough bandwidth, but as collateral damage, applications
that are not so critical could be starved of the bandwidth. This
starvation could happen even while secondary circuit is active and
contains lots of unused bandwidth.
Key challenge here is to find a way to select certain applications
that are considered not-so critical for the business and off load
them on to secondary circuit. This would ensure applications that
would otherwise be starved of bandwidth in the primary circuit will
have lots of room in the secondary circuit. This kind of active-
active routing scheme will hence forth be called as DPS ( Dynamic
Path Selection) routing. This when achieved, will improve the overall
user experience for the not-so-critical applications without
compromising the critical applications. In majority of the situations
this will result in a slightly better experience for the critical
applications.
It should be noted that during the event of a primary circuit
failure, both critical and non-critical applications will go over the
secondary circuit. Hence the QoS mechanism will have to be applied
even on the secondary circuit so as to punish the not-so-critical
applications. Though this is a real problem, the occurrence of such
an event is very rare. SLA for a premium circuit such as Carrier or
Metro Ethernet could be as high as 99.5% . With this SLA in place
network administrators can guarantee acceptable level of performance
for all applications 99.5% of the time whilst for critical
applications the experience can be guaranteed 99.999% of times.
If this DPS routing can be achieved, then it will directly translate
in to greater user experience for users with out compromising the
cost that the Network managers will have to spend on the WAN
networks.
4. DPS Routing Requirements
Arunkumar Arumuganainar Expires April 5, 2014 [Page 5]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
The DPS requirements can be summarized in 5 simple steps.
1) Any two sites participating in the DPS routing, will have to agree
on off loading patterns. This pattern is referred to as DPS Profiles.
Example of a profile is illustrated below.
Profile 1: Critical Application: SAP, Citrix, VOIP ,Telnet; Non-
Critical: remaining applications
Profile 2: Critical Application: SAP, Citrix, VOIP, Telnet, SMTP,
HTTP; Non-Critical: remaining applications
Profile 3: Critical Application: All non-Internet traffic; Non-
Critical: Internet-traffic
If three sites wanted to participate in DPS routing, they need to
exchange the profile information and agree on a common profile to
off load. It should be possible that the first site will negotiate to
use profile 1 for the second site, and profile 2 with the third. The
underling requirement is if two sites communicate they should be able
to agree on a common profile.
2) Traffic hitting the input interface of router will have to be
first classified based on application. Here the application can be
defined as follows:
a) A specific known TCP port number
b) Combination of TCP Port and Server's IP Address
c) A known Layer 7 Signature
For example:
a) Traffic sent to TCP Port (80) could be classified as HTTP
application.
b) Traffic sent to TCP Port 80 and Server IP (ex: proxy server)
can be classified as Internet
c) Traffic sent to TCP Port 80 and Server IP (ex. proxy
server)sent to the URL www.example.com can be classified as
"EXAMPLE.COM APP". Here the classification was based on the Layer
7 Signature.
3) If the profile is agreed and classification is done, then the
participating router should be able to filter the traffic and send it
Arunkumar Arumuganainar Expires April 5, 2014 [Page 6]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
across available paths.
4) During step 2, if the traffic is pushed to the secondary circuit
(not the best path as per the routing protocol)it should stick with
the circuit end to end. For example an application that has been off
loaded will have to enter the remote site via the secondary circuit.
Return path for that flow will have to take the secondary path at
both locations so as to prevent asymmetric routing.
As the quality of the link does vary largely at any given site
asymmetric routing will invariably create a application performance
issues and hence should be avoided at all times.Hence, path symmetry
should be honored even during positive and negative events on the
network. For example if the secondary circuit fails, either locally
or at the remote site, it is treated as a negative event and during
this time path symmetry should not be compromised.
5. Dynamic Path selection Framework
+-------------+ +----------------+
| DPS Routing | Fault in DPS Domain | Normal Routing |
| DOMAIN | --------------------> | Domain |
+-------------+ +----------------+
^ ^
| |
| |
| |
---------------- -----------------------
| |
| |
+-------------+ +----------------+
|Profile based|<-----|DPS Signaling |
| Filter | +----------------+
+-------------+
The objective of DPS is to achieve end-to-end application separation
with out introducing asymmetric routing within the network. In order
to ensure the above objectives, we should have a comprehensive
mechanism to achieve the following tasks.
Task 1: Any two sites participating in DPS will have to agree on a
common set of applications that will be off loaded to secondary path
(also referred to as DPS path on this draft).
Arunkumar Arumuganainar Expires April 5, 2014 [Page 7]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
Task 2: At the time of forwarding the packets, packet should be
filtered based on agreed application set. Packets should then be
pushed in to appropriate paths.
Task 3: If the packet is pushed on to a DPS path, it should always
use the secondary link end to end. .
Task 4: A comprehensive fault detection mechanism should be put in
place to detect the faults in the DPS domain. In such a case, the DPS
traffic should be re-routed via the normal routing domain.
To achieve the above four tasks, this draft recommends four
functional blocks as described in the above diagram. These functional
blocks are individually designed and fine tuned to achieve various
level of sophistication. Details of the building blocks are described
in the below section.
Normal Routing Domain:
This is the Active-Passive or classical routing as described in
section 2. Any site that is not running DPS (DPS unaware), will have
only this module. Here, the routing protocol will configured in a
traditional fashion. The primary circuit will have a best metric and
will be preferred and the secondary will be acting as backup.
DPS Routing domain:
This will be overlay routing domain that will be built over the
existing Normal Routing domain. However some of the paths will not be
considered while building the domain. For example Primary Circuits
can be ignored while building the overlay domain. Alternatively
overlay domain can be built in such a way that it prefers secondary
circuit as a path with better metric and hence primarily route over
secondary path.
It is mandatory that all the LAN routes that are available on the
normal routing domain is fully injected in to the overlay DPS Routing
domain. However, in order to separate the traffic, the overlay DPS
Routing domain will be put into a separate VRF. Once a packet is
pushed in to the overlay DSP Routing domain, the Normal Routing
domain is never consulted, until the time the fault tolerance
mechanism pushes traffic out of the overlay DPS Routing domain.
DPS Signaling
One of the core objective of DPS is to avoid asymmetry while routing.
Hence, if a particular application is off loaded, then the remote
network should also off load the same application. The signaling
Arunkumar Arumuganainar Expires April 5, 2014 [Page 8]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
module will provide a mechanism for participating sites to
communicate with each other and agree about the applications that
need to be off loaded.
During the signaling, sites will exchange the Application Profiles as
described in section 4. Sites could be able to support more than one
profile, however when they communicate a common profile must be
chosen. For example, profiles can be defined as follows:
Profile 1: Critical Application: SAP, Citrix, VoIP, Telnet; Non-
Critical: remaining applications
Profile 2: Critical Application: SAP, Citrix, VoIP, Telnet, SMTP,
HTTP; Non-Critical: remaining applications
Site A & B can support both profile 1 and profile 2 Site C can
support profile 1 Site D can support Profile 2
When Site A talks to Site C, applications will be off loaded as per
definition of Profile 1
When Site A talks to Site C, applications will be off loaded as per
definition of Profile 2
When Site A talks with Site B, off loading can be done either by
choosing one profile or by choosing a combination of both profiles.
One of the profiles can be dynamically chosen based on the network
conditions prevailing at the time.
For example Site A could signal to Site B its preference for profile
1 when the link utilization level is very high. At all other times it
can prefer profile 2 when dealing with Site B. Such a constraint
based profile selection should be explicitly acknowledged and agreed
by site B. If agreement could not be reached then it will default to
normal routing.
It should be noted that the profile definition as such is static. All
of the application sets will have to be individually defined by the
network administrator. But selection of profiles as such can be
dynamic and it could depend on a) local or remote network conditions
and b) capability of the site of which the target IP address belongs
to.
Profile Based Filtering Module
Once off loaded applications are defined, the framework should
support a classification and filtering engine. Classification could
be done via variety of application signatures. For example an
Arunkumar Arumuganainar Expires April 5, 2014 [Page 9]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
application signature can be defined as:
1) specific TCP port or an Server IP address
2) A combination of TCP port and IP Address
3) A Layer 7 Signature (eg: specific URL like http://www.example.com)
The profile based filter should be able to classify the packets and
then push the off loaded application traffic in to the DPS Routing
domain. Other traffic should be routed normally.
6. Packet flow in DPS Environment
If a site is deployed conforming to the above specifications, the
following things will happen when the packet hits router.
1) When the packet hits the input interface, it gets classified based
on the Application Signature.
2)If signaling happens in the forwarding plane, then the Signaling
Module will communicate with the remote site and agree on the profile
that will be used. If the signaling is implemented in the control
plane, then the profile negotiation would have already taken place.
In both the scenarios, the profile information are fed in to the
profile filter.
3) Once the profile and application signature is determined, the
profile based filter will push the packet in to the appropriate
routing domain.
4) In the case of the packet being pushed in to the DPS Routing
domain, the forwarding happens based on information available in the
DPS Routing domain.
5) Failures might happen in the network and this might result in loss
of routing information in the DPS routing domain. In such a case the
DPS routing domain will push the packet out of the domain and in to
the Normal Routing domain. Under no circumstances should the packet
be dropped due to non-availability of routing information in the DPS
routing domain.
8. Implementation Details and Gap Analysis.
8.1 DPS Routing domain:-
Arunkumar Arumuganainar Expires April 5, 2014 [Page 10]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
The main constraint is that provider devices should be transparent to
DPS Domain routing. This adds more complexity to the design. The
following techniques were considered for implementation:
a) Multi-Topology routing:
Multi-Topology Routing was considered but found unsuitable for DPS
routing. This is because it requires dependency on providers
supporting the DPS Routing scheme. Also, it forces packets to be
marked only with two DSCP values (1 for normal routing and another
other for DPS routing). Some implementations mandate usage of the
same or similar DSCP/IP Precedence values for traffic traveling
through both routing domains.
And hence it was found that MTR as not suitable for this purpose.
b) A separate VPN for DPS:
This does work fine for the DPS Routing domain. Here we extend a
second sub-interface to the same POP via the secondary last mile
circuit. The second sub-interface could be put on a separate VPN.
Technically this is feasible. There few implementations in the field
of this type. However this is not a preferred option. Any new VPN on
a MPLS network will come with extra cost and most of the time, the
costs are prohibitively high.
c) Overlay VPN Using Dynamic Mesh VPN tunnels:
Here the overlay network is built using DMVPN (Dynamic Mesh VPN).
Details of DMVPN is described in detail in the draft-detienne-dmvpn.
There is a vendor implementation that exists today that supports a
multi-point overlay tunnel as described in the draft. This could be
used to create an overlay DPS Routing domain. A standard routing
protocol can be run over this overlay network.
This technique is the widely deployed technique used in field
deployments today. In the production environment, several
implementations were done with largest one consisting of 300 sites &
2000 prefixes.
It should be noted that the proposed draft draft-detienne-dmvpn
suggests that binding IPSEC encryption on to the DMVPN tunnel is
mandatory. DPS Routing does not require IPSEC. Current
implementations were all done without encryption. This draft
recommends the DMVPN draft to be amended so that IPSEC binding
requirement is de-linked from the DMVPN standard.
Arunkumar Arumuganainar Expires April 5, 2014 [Page 11]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
8.2 DPS Signaling:-
DPS signaling can be implemented in both forwarding plane and also in
the control plane.
Control plane implementations are done via BGP. Here, BGP will be
used as a routing protocol for the Normal Routing domain. Profile
information can be exchanged via standard community. For example:
1) Profile 1 can be represented by community 100:1
2) Profile 2 can be represented by community 100:2
If a given site supports only profile 1, it will advertise site
prefixes with a community 100:1. If the same site wanted to support
both the profiles then the prefix would be sent with both
communities, 100:1 and 100:2. At the remote end, the site will
understand the capabilities based on the communities associated with
the prefix.
For example Site 1 supports both profile 1 and profile 2 and hence it
advertise the prefix with community 100:1 and 100:2. But site 2
supports only profile 1 (100:1). The common profile between both the
sites is 100:1 and hence profile 1 will be used. It should noted that
both site 1 and site 2 with full certainty will use profile 1. Under
such a scenario asymmetric routing will not happen.
Currently this scheme has been implemented using one vendor specific
implementation. In the current implementation, the router will colour
the packet with IP Precedence values. There will be one to one
correspondence between the profile chosen and the IP Precedence
values used for colouring. Once the packet is coloured, the profile
based filter can applied. Filtering will involve inspecting both the
colouring done by the Signaling Module and the application to which
the packet belongs to.
While this works perfectly well on large scale network, a couple of
short comings remains.
1) The trust model could not be supported when DPS is enabled. This
is because the DPS Signaling Module will remark the TOS bits during
the colouring operation. Hence an alternate mechanism needs to
developed to color the packet with out modifying the TOS bits.
2)Because profiles are exchanged via BGP, the router negotiates the
off loaded applications list at the time of exchanging the BGP
routing information. This would mean routers will not be able to
react to local or remote network condition. For example, the choice
Arunkumar Arumuganainar Expires April 5, 2014 [Page 12]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
of profiles can not be changes if the link utilization is very high.
The draft draft-arumuganainar-rtgwg-DPS-L4-path-preference-
negotiation-00 suggests an alternate mechanism that will allow
profile negotiation to happen when the TCP connection gets
established. This will enable link preference to be negotiated for
each TCP connection and hence such a mechanism will be more dynamic
then the BGP one
8.3 Profile based Filter
Each profile is associated with a pre-determined list of
applications. These applications are determined by the network
administrator as an application that can be offloaded.
The administrator can define multiple profiles and associate this
with one or more sites. When two sites communicate, they signal each
other and agree on a single common profile. The Signaling Module will
then colour the packet indicating which profile to be used while
deciding the application to be off loaded.
Once the steps are complete, the profile based filter can be applied.
The filter will look for the colour and then matches the protocol
with corresponding off loaded application. If a match is found the
packet will be pushed in to the DPS Routing domain, otherwise the
packet will be normally routed.
Current implementations are done using Policy Based Routing (PBR).
Here, filtering is done using a special PBR policy. This will check
the colour of the packet and the pre-determined list of applications.
It could then push the packet in to the appropriate routing domain.
While in theory PBR works perfectly fine, PBR is a processor
intensive mechanism and hence when it is applied, the throughput of
the router is adversely impacted. Hence, router scalability should be
kept in mind while sizing the router for any particular site. In the
future a light weight mechanism optimised for profile based filtering
could be developed as well.
7. Summary
To summarise, by adopting the DPS frame work, true end to end
application based routing scheme could be achieved. The DPS framework
has the following advantages:
1. Give lots of room for Network Manager to determine which path
should be used for which application.
2. DPS also provides a scalable frame work for achieving the above
Arunkumar Arumuganainar Expires April 5, 2014 [Page 13]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
objective.
3. By modularizing the DPS components, advanced development of
individual components becomes possible. Troubleshooting will also
get greatly simplified.
4. DPS capable sites can co-exist with non-DPS sites and this
capability provides enough room for a phased migration. Thus DPS
technology adoption is easy and simple.
5. It should be noted that DPS frame work and signaling, needs to
be understood only by edge devices and any other devices in the
path such as provider routers need not be aware of DPS.
Definitions and code {
line 1
line 2
}
Special characters examples:
The characters , , ,
However, the characters \0, \&, \%, \" are displayed.
.ti 0 is displayed in text instead of used as a directive.
.\" is displayed in document instead of being treated as a comment
C:\dir\subdir\file.ext Shows inclusion of backslash "\".
Arunkumar Arumuganainar Expires April 5, 2014 [Page 14]
INTERNET DRAFT Dynamic Path Selection Requirements October 02, 2014
8 Security Considerations
TBD
9 IANA Considerations
TBD
10 References
10.1 Normative References
10.2 Informative References
11 Acknowledgements
The authors would like to thank Hesham Moussa for his review and
comments.
Authors' Addresses
Arunkumar Arumuga Nainar
Tata Communications (UK) Limited
1st Floor
20 Old Bailey
London EC4M 7AN
United Kingdom
EMail: arun.arumuganainar@tatacommunications.com
Arunkumar Arumuganainar Expires April 5, 2014 [Page 15]
