PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6
draft-rpcw-pcp-pmipv6-serv-discovery-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Prashanth Patil , Ravikumar Chandrasekaran, Dan Wing | ||
| Last updated | 2013-02-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rpcw-pcp-pmipv6-serv-discovery-02
PCP Working Group T. Reddy
Internet-Draft P. Patil
Intended status: Standards Track R. Chandrasekaran
Expires: August 15, 2013 D. Wing
Cisco
February 11, 2013
PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6
draft-rpcw-pcp-pmipv6-serv-discovery-02
Abstract
This document proposes a solution to PCP Server Discovery problems in
Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic
and traffic off-loaded to local access network require traversing a
gateway implementing NAT and/or Firewall. This draft proposes
enhancements to DHCPv4 Relay Agent by introducing a new sub-option
under DHCPv4 Relay Option and to PMIPv6 signaling through additional
options to Proxy Binding Update/Acknowledgement messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 15, 2013.
Copyright 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
Reddy, et al. Expires August 15, 2013 [Page 1]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 6
5. DHCPv4 Relay Agent co-located with MAG . . . . . . . . . . . . 8
5.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Relay Agent behavior . . . . . . . . . . . . . . . . . . . 9
5.3. DHCPv4 Server behavior . . . . . . . . . . . . . . . . . . 9
6. DHCPv4 Server co-located with MAG . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-01
to -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Reddy, et al. Expires August 15, 2013 [Page 2]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
1. Introduction
Given the exponential growth in the mobile data traffic, Mobile
Operators are looking for ways to offload some of the IP traffic
flows at the nearest access edge that has an Internet peering point.
This approach results in efficient usage of the mobile packet core
and helps lower the transport cost.
[I-D.ietf-netext-pmipv6-sipto-option] defines a way to signal the
Traffic Offload capability of a Mobile Access Gateway (MAG) to the
Local Mobility Anchor (LMA) in Proxy Mobile IP Networks. There are
scenarios in PMIPv6 Mobile Networks where the traffic going through
the Mobile Packet Core as well as the traffic that is off-loaded to
the Local Access Networks end up going through a NAT or Firewall
gateway. If the mobile node applications desire to find or control
the external addresses assigned to the internal address used by the
Mobile Node (MN), it could be achieved by having a Port Control
Protocol (PCP) Client on the mobile node.
[I-D.ietf-pcp-dhcp] specifies DHCP (IPv4 and IPv6) options to
configure hosts with Port Control Protocol (PCP) Server addresses.
However, PCP Client on the mobile node will not know whether a flow
will traverse the Mobile Packet Core or will get offloaded at the
local access network and hence will not know which PCP server to send
its queries to. Even if the mobile node tries to find its PCP server
using DHCP, it may only find out about the PCP server in the Home
Network since the source of information is the DHCP server in the
Home Network. The mobile node may never learn the presence of the
PCP server in the Local Access Network. This requires mobile access
gateway to act as a PCP Proxy for the PCP server in the mobile node's
home network and as a PCP server/PCP Proxy for the NAT that the
offloaded traffic at the Local Access Network have to traverse
through. However, this alone does not solve this problem since the
mobile node needs to be informed of the PCP proxy on the MAG. This
draft proposes an extension to DHCPv4 Relay Information Option and
PMIPv6 Options to achieve these objectives.
2. 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 [RFC2119].
All the mobility related terms used in this document are to be
interpreted as defined in the Proxy Mobile IPv6 specifications
[RFC5213], [RFC5844]. This note also uses terminology defined in
[I-D.ietf-pcp-base].
Reddy, et al. Expires August 15, 2013 [Page 3]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
Additionally, this document uses the following abbreviations:
o IP Flow - IP Flow represents a set of IP packets that match a
traffic selector. The selector is typically based on the source
IP address, destination IP address, source port, destination port
and other fields in upper layer headers.
o IP Traffic Offload - The approach of selecting specific IP flows
and routing them to the local network, as supposed to tunneling
them to the home network.
o NAT (Network Address Translation) - Network Address Translation
[RFC2663] is a method by which IP addresses are mapped from one
address realm to another, providing transparent routing to end
hosts.
o Firewall (FW) - A packet filtering device that matches packets
against a set of policy rules and applies the actions.
o peer-to-peer (P2P) - Applications and protocols, such as
teleconferencing, multiplayer online gaming, BitTorrent etc
o Internal Address - The address of Mobile Node assigned by the home
agent.
o Remote Peer IP Address - The address of a Remote Peer, as seen by
the Mobile Node. A Remote Address is generally a publicly
routable address.
o External Address - The address of the Mobile Node as seen by other
Remote Peers on the Internet with which the Mobile Node is
communicating, after translation by any NAT gateways on the path.
3. Solution overview
The following illustrates a scenario where the Mobile Node is a PCP
client, Mobile Access Gateway in the access network is a PCP server
with PCP proxy functionality [I-D.ietf-pcp-proxy], the home network
has a PCP server.
Mobile access gateway has the ability to offload some of the IPv4
traffic flows based on the traffic selectors it receives from the
local mobility anchor. Using IP Traffic Offload Selector option
[I-D.ietf-netext-pmipv6-sipto-option] mobile access gateway will
negotiate IP Flows that can be offloaded to the local access network
or internet. For example, consider a mobile node acting as both
client and server for FTP, VoIP and P2P. In this case FTP flows for
Reddy, et al. Expires August 15, 2013 [Page 4]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
that mobility session may be offloaded at the mobile access gateway
and P2P, Voice over IP (VoIP) flows tunneled back to the local
mobility anchor. Mobile node uses PCP to create mappings between
external IP address/port and internal IP address/port. These
mappings will be used for successful inbound communication destined
to the mobile node behind NAT and/or firewall.
The mobile node learns the PCP server domain name from DHCPv4 server
using DHCPv4 option OPTION_PCP_SERVER [I-D.ietf-pcp-dhcp]. If IP
Flows are offloaded at the mobile access gateway then the mobile node
needs to learn the domain name of the mobile access gateway acting as
PCP proxy. Mobile access gateway will compare the Remote Peer IP
Address and Port fields set in PCP PEER request from the mobile node
with the Traffic Selector fields and IP Traffic Offload Mode Flag in
IP Traffic Offload Selector Option to determine if the dynamic
outbound mapping is to be created in the local access network or home
network. In case of PCP MAP request mobile access gateway will
compare the Remote Peer IP Address and Port fields in FILTER Option
with the Traffic Selector fields and IP Traffic Offload Mode Flag in
IP Traffic Offload Selector Option to determine if dynamic outbound
mapping is to be created in the local access network or home network.
For PCP MAP request without FILTER option since the Remote Peer IP
Address is not available the mobile access gateway will function as a
PCP proxy and forward the PCP MAP request to the PCP server in the
home network. Mobile Nodes which require communication with well
known peers (For e.g. applications like SIP proxy, FTP server) will
use PCP MAP with FILTER option. When MNs act as servers (such as P2P
server, Web Server) i.e., when the remote peer IP address is not
known, PCP client will use PCP MAP request in which case the MAG
cannot make a decision as per the traffic selector fields and hence
will relay the request to a PCP server based on local configuration.
If the dynamic outbound mapping is for Internet Offload, then the
mobile access gateway will function as a PCP server for the mobile
node if the NAT is co-located on the MAG. If the NAT is not co-
located, then MAG will act as a proxy and forward the PCP requests to
the respective PCP server in the Local Access Network.
NAT may not always be required for traffic offloaded for local
access. If there is NAT required for traffic offloaded for Local
Access, then, the dynamic outbound mapping is for the Local Access
Network. In this case, the Mobile Access Gateway will function as a
PCP server if NAT device for the Local Access Network is co-located
on the MAG, otherwise, it will act as a PCP proxy forwarding the PCP
requests to the respective PCP server on the Local Access Network.
If dynamic outbound mapping is for the home network then mobile
access gateway will function as PCP proxy and forward the accepted
Reddy, et al. Expires August 15, 2013 [Page 5]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
PCP requests to the PCP server in the home network.
_----_
_( )_
:-----------------( Internet )---------------:
| (_ _) |
| '----' |
| |
: |
(IPv4 Traffic Offload Point) |
: |
| |
........................................................|....
| | |
+--------+ | +---------------------+ |
| Local | | | Services requiring | |
|Services| | | mobility, or service| |
+--------+ | | treatment | |
| | +---------------------+ |
| +---+ | |
| |NAT| | |
| +---+ | |
+-----| _----_ | |
+-----+ _( )_ +-----+ |
[MN]----| MAG |======( IP )======| LMA |----------
+-----+ (_ _) +-----+ Internet
'----'
.
.
[Access Network] . [Home Network]
..........................................................
Figure 1: PCP-Enabled Proxy Mobile IPv6
4. Mobility Options
A new mobility option, Capability Exchange Option is defined for use
with Proxy Binding Update sent by the mobile access gateway to the
local mobility anchor. The option is used for conveying device
capabilities such as PCP Sever, smart PCP Proxy.
Reddy, et al. Expires August 15, 2013 [Page 6]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Capability Exchange Option
Type: <IANA-1>
Length: An 8-bit unsigned integer indicating the length of the
option in octets, excluding the Type and Length fields. This
field MUST be set to 2.
Reserved (R): This 14-bit field is unused for now. The value MUST
be initialized to (0) by the sender and MUST be ignored by the
receiver.
PCP Server Support Mode (S): A 1-bit field that specifies the PCP
server support mode. The flag value of (1) indicates that mobile
access gateway is capable of functioning as PCP Server to the
Mobile node.
PCP Proxy Support Mode (P): A 1-bit field that specifies the smart
PCP proxy support mode. The flag value of (1) indicates that
mobile access gateway is capable of functioning as smart PCP Proxy
to the Mobile node.
A new mobility option, PCP Server Option is defined for use with
Proxy Binding Acknowledgement sent by the local mobility anchor to
the mobile access gateway . The option is used to provide PCP server
domain name of the home network to the mobile access gateway.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP Server Domain Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PCP Server Option
Reddy, et al. Expires August 15, 2013 [Page 7]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
Type: <IANA-2>
Length: An 8-bit unsigned integer indicating the length of the
option in octets, excluding the Type and Length fields.
Reserved (R): This 16-bit field is unused for now.
PCP Server Domain Name: The domain name of the PCP Server to be
used by the mobile access gateway. The domain name is encoded as
specified in Section 8 of [RFC3315].
5. DHCPv4 Relay Agent co-located with MAG
When DHCPv4 Relay Agent is co-located with the mobile access gateway,
the proposal is for the relay agent to influence the DHCPv4 Server to
opt for the PCP server domain name proposed by the Relay Agent over
the one configured on the DHCPv4 Server. The DHCPv4 Relay Agent will
insert a a new suboption under relay agent information option
indicating the domain name of the appropriate PCP server/proxy only
after successful Tunnel/Route setup. For this to happen, the MN MUST
ensure that it includes OPTION_PCP_SERVER in the Parameter Request
List Option in the DHCPv4 Discover/Request message. The mobile
access gateway will also have to act as a PCP-Proxy in this case so
that it can handle PCP Servers of both the local access network and
the home network. This will ensure that the right PCP Server is
picked by the proxy based on IP Flow.
MN MAG(DHCP-R) LMA DHCP-S
|------>| | | 1. Mobile Node Attach
| |------->| | 2. Proxy Binding Update
| |<-------| | 3. Proxy Binding Acknowledgement
| | | | (IPTS Option)
| |========| | 4. Tunnel/Route Setup
| + | | 5. Installing the traffic offload rules
|<----->|<----------->| 6. DHCP OFFER/REQUEST/ACK exchange
| | | | OPTION_PCP_SERVER inserted by DHCP-R
|------>| | | 7. IPv4 packet from mobile node
| + | | 8. Forwarding rule - Tunnel home/offload
| | | |
5.1. Format
To realize the mechanism described above, the document proposes a new
PCP Server suboption for the DHCPv4 relay agent information option
that carries the domain name of PCP Server/Proxy.
Reddy, et al. Expires August 15, 2013 [Page 8]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
Code Length PCP Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+--
| TBA | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
Code: TBA
Length: Includes the length of the "PCP Server Domain Name" field
in octets; The maximum length is 255 octets.
PCP Server Domain Name: The domain name of the PCP Server to be used
by the PCP Client when issuing PCP messages. The domain name is
encoded as specified in Section 8 of [RFC3315].
5.2. Relay Agent behavior
DHCPv4 relay agents MAY be configured to include a PCP Server
suboption if they include a relay agent information option in relayed
DHCPv4 messages. The PCP Server Domain name is assigned and
configured through mechanisms that are outside the scope of this
memo.
5.3. DHCPv4 Server behavior
This suboption provides additional information to the DHCP server.
Upon receiving a DHCPv4 Discover/Request containing the suboption,
the DHCPv4 server, if configured to support this suboption, MUST
populate the DHCPv4 Offer/Ack with the suggested PCP server domain
name overriding any other PCP server domain name configuration that
it may already have. There is no special additional processing for
this suboption.
6. DHCPv4 Server co-located with MAG
When the DHCPv4 Server is co-located with the mobile access gateway,
the DHCPv4 Server will have to provide the appropriate PCP server
domain name in the DHCP Offer/Ack based on traffic offload
negotiation between the mobile access gateway and local mobility
anchor.
If traffic offload is successfully negotiated between the mobile
access gateway and the local mobility anchor, the proposal is for the
DHCPv4 Server to include the domain name of the PCP Proxy in the DHCP
Offer/Ack. The mobile access gateway will act as a PCP-Proxy in this
case to ensure that it can handle PCP Servers of both the local
access network and the home network. This will ensure that the right
PCP Server is picked by the proxy based on IP Flow.
Reddy, et al. Expires August 15, 2013 [Page 9]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
If traffic offload is not negotiated between the mobile access
gateway and the local mobility anchor, the proposal is for the DHCPv4
Server to include the domain name of the home network PCP server in
the DHCPv4 Offer/Ack. The domain name of the PCP server in the home
network is obtained from Proxy Binding message exchange explained in
Section 4. Option OPTION_PCP_SERVER will be used as described in
[I-D.ietf-pcp-dhcp].
MN MAG(DHCP-S) LMA
|------>| | 1. Mobile Node Attach
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement
| | | (IPTS Option)
| |========| 4. Tunnel/Route Setup
| + | 5. Installing the traffic offload rules
|<----->| | 6. DHCP OFFER/REQUEST/ACK exchange
| | | OPTION_PCP_SERVER inserted by DHCP-S
|------>| | 7. IPv4 packet from mobile node
| + | 8. Forwarding rule - Tunnel home/offload
| | |
7. Security Considerations
The Capability Exchange option defined in this specification is for
use in Proxy Binding Update messages. The PCP server option defined
in this specification is for the Proxy Binding Acknowledgement
messages. These options are carried like any other mobility header
option as specified in [RFC5213] and does not require any special
security considerations. When IPv4 traffic offload support is
enabled for a mobile node, the mobile access gateway selectively
offloads some of the mobile node's traffic flows to the local access
network. Typically, these offloaded flows go through a NAT gateway
and that essentially introduces certain vulnerabilities which are
common to any NAT deployment. These vulnerabilities and the related
considerations have been well documented in the NAT specification
[RFC2663]. There are no additional considerations above and beyond
what is already documented by the NAT specifications and which are
unique to the approach specified in this document.
The security considerations in [I-D.ietf-pcp-base] ,
[I-D.ietf-pcp-proxy] and section 5 of [RFC3046] also apply to this
use.
8. IANA Considerations
This specification defines two new Mobility Header options -
Capability Exchange option, PCP server option. These options are
Reddy, et al. Expires August 15, 2013 [Page 10]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
described in Section 4. The Type value for this option needs to be
assigned from the same numbering space as allocated for the other
mobility options [RFC6275].
IANA is requested to assign a suboption number for the PCP Server
Suboption from the DHCP Relay Agent Information Option [RFC3046]
suboption number space.
9. Acknowledgements
The authors would like to thank Sri Gundavelli and Gang Chen for
their valuable comments.
10. Change History
[Note to RFC Editor: Please remove this section prior to
publication.]
10.1. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-01 to -02
Updated Section 1, Section 3, Section 5, Section 6 and Section 9.
11. References
11.1. Normative References
[I-D.ietf-netext-pmipv6-sipto-option]
Gundavelli, S., Zhou, X., Korhonen, J., and R. Koodli,
"IPv4 Traffic Offload Selector Option for Proxy Mobile
IPv6", draft-ietf-netext-pmipv6-sipto-option-09 (work in
progress), February 2013.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-29 (work in progress), November 2012.
[I-D.ietf-pcp-dhcp]
Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05
(work in progress), September 2012.
[I-D.ietf-pcp-proxy]
Boucadair, M., Dupont, F., Penno, R., and D. Wing, "Port
Control Protocol (PCP) Proxy Function",
Reddy, et al. Expires August 15, 2013 [Page 11]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
draft-ietf-pcp-proxy-01 (work in progress), August 2012.
[I-D.penno-pcp-nested-nat]
Penno, R., Wing, D., and M. Boucadair, "PCP Support for
Nested NAT Environments", draft-penno-pcp-nested-nat-03
(work in progress), January 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
11.2. Informative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Authors' Addresses
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Reddy, et al. Expires August 15, 2013 [Page 12]
Internet-Draft PCP Server Discovery for PMIPv6 February 2013
Prashanth Patil
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marthalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: praspati@cisco.com
Ravikumar Chandrasekaran
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marthalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: sravikum@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Reddy, et al. Expires August 15, 2013 [Page 13]