[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

V6OPS WG                                                   S. Gundavelli
Internet-Draft                                                M. Grayson
Intended status: Informational                                     Cisco
Expires: September 8, 2012                                      P. Seite
                                                 France Telecom - Orange
                                                                  Y. Lee
                                                                 Comcast
                                                           March 7, 2012


             Wi-Fi Services Over Residential Architectures
           draft-gundavelli-v6ops-community-wifi-svcs-02.txt

Abstract

   The tremendous growth in Wi-Fi technology adoption over the last
   decade has met the ultimate possible goal of 100% adoption rate.  All
   most every new mobile device is now equipped with IEEE 802.11-based
   wireless interface and with pre-configured policy to prefer Wi-Fi to
   cellular access.  Matching this evolution is every service provider's
   desire to offer Wi-Fi based broadband services; a new business
   opportunity even for fixed line operators.  Operators are exploring
   options to monetize their existing networks, most with nation-wide
   footprint, to build a high-speed Wi-Fi service that can be the basis
   for offering new wireless broadband services.  This document
   identifies the requirements for supporting these new Wi-Fi community
   services and the mobility tools which have been standardized in IETF
   that can be used for enabling these architectures.

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 September 8, 2012.

Copyright Notice




Gundavelli, et al.      Expires September 8, 2012               [Page 1]


Internet-Draft               Wi-Fi Services                   March 2012


   Copyright (c) 2012 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
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Deployment Models  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Subscriber Authentication & Service Authorization  . . . .  7
     4.2.  Location-based Services  . . . . . . . . . . . . . . . . .  7
     4.3.  Local Services Access & Internet Traffic Offload . . . . .  7
     4.4.  Web-based Authentication Support . . . . . . . . . . . . .  8
     4.5.  Transparent Auto Login (TAL) . . . . . . . . . . . . . . .  8
     4.6.  Multiple WLAN SSID Support . . . . . . . . . . . . . . . .  8
     4.7.  Multiple Home Network Service (APN) Access . . . . . . . .  8
     4.8.  CPE Identity and Authorization . . . . . . . . . . . . . .  9
     4.9.  Mobility within the WLAN Access Network  . . . . . . . . .  9
     4.10. Mobility across WLAN and Macro Access  . . . . . . . . . .  9
     4.11. Differentiated Services for Users behind CPE . . . . . . .  9
     4.12. Lawful Intercept (LI)  . . . . . . . . . . . . . . . . . . 10
     4.13. Charging & Accounting  . . . . . . . . . . . . . . . . . . 11
     4.14. Overlapping IPv4 Address Support . . . . . . . . . . . . . 11
     4.15. Policy Provisioning  . . . . . . . . . . . . . . . . . . . 11
   5.  Solution Approach  . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  PMIPv6 MAG in the Residential CPE  . . . . . . . . . . . . 11
     5.2.  PMIPv6 MAG in the Access Gateway . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




Gundavelli, et al.      Expires September 8, 2012               [Page 2]


Internet-Draft               Wi-Fi Services                   March 2012


1.  Introduction

   The tremendous growth in Wi-Fi technology adoption over the last
   decade has met the ultimate possible goal of 100% adoption rate.  All
   most every new mobile device is now equipped with IEEE 802.11-based
   wireless interface and with pre-configured policy to prefer Wi-Fi to
   cellular access.  This so called, "cheap access based on unlicensed
   spectrum", is no longer considered an unreliable access, but with all
   the available protocol tools and with maturity in technology,
   building a reliable broadband service that can meet the committed
   service-level agreements is a non-issue.

   Matching this evolution is every service provider's desire to offer
   Wi-Fi based broadband services; a new business opportunity even for
   both fixed and mobile operators.  The demand for bandwidth is only
   growing with the availability of new smart devices, new technology
   applications and with all the content in the Internet.  Furthermore,
   an increasing percentage of mobile consumption is happening in the
   home and so DSL/Cable operators are exploring options to monetize
   their existing networks, most with nation-wide footprint, to build a
   high-speed Wi-Fi service that can be the basis for offering new
   wireless broadband services and for building roaming agreements with
   traditional mobile operators, who are unable to meet the mobile
   subscriber growth due to the finite licensed spectrum available for
   macro-cell deployments.  Every residential CPE device that the
   operator owns can now be enabled to provide Wi-Fi service and new
   community Wi-Fi hotspots can be built in any location where there is
   fixed line coverage.  A wireless service based on unlicensed
   spectrum, and leveraging existing transport is a huge incentive for
   operators to enter this new market.

   To support these business goals, operators are looking at mobility
   architectures for supporting various requirements.  Not all
   requirements are well understood, and neither are the implications
   with the chosen solution approaches for each of those requirements.
   The choice of the architecture has an implication on the CPE
   evolution and on the core infrastructure feature requirements.
   Therefore, the sole purpose and the goal of this document is to
   present all the requirements, identify the protocol tools and any
   potential gaps.  This analysis is important for enabling the network
   vendors and the mobile operators to make the right design choices and
   leverage the existing tools that the mobility groups in IETF have
   already developed and discourage them from adopting proprietary, non-
   standard mechanisms or developing redundant alternatives.

   Work in progress ...





Gundavelli, et al.      Expires September 8, 2012               [Page 3]


Internet-Draft               Wi-Fi Services                   March 2012


2.  Conventions and Terminology

2.1.  Conventions

   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.2.  Terminology

   This document uses the following abbreviations and definitions:

   Customer Premises Equipment (CPE)

      It is a network device that is located in the Customer premises.
      This device is connected to service providers network and defines
      the demarcation point between the provider and the customer.

   Access Point Name (APN)

      Its the name of a packet data network.  This APN concept was first
      introduced in GPRS by 3GPP to enable legacy Intelligent Networking
      (IN) approaches to be applied to the newly deployed IP packet data
      services.  In roaming deployments, the APN construct was visible
      to the visited network and allowed legacy IN charging solutions to
      be supported.  Defining an application specific APN then allowed
      application charging to be supported.

   WLAN controller (WLC)

      The entity that provides the centralized forwarding, routing
      function for the user traffic.

   Community Wi-Fi

      It is a residential Wi-Fi network where CPEs provide connectivity
      to the home user as well as visitors.

   home user

      The home user is the customer where the CPE is located.

   Mobile Gateway








Gundavelli, et al.      Expires September 8, 2012               [Page 4]


Internet-Draft               Wi-Fi Services                   March 2012


      It is network entity anchoring IP traffic in the mobile core
      network.  This entity allocates an IP address which is
      topologically valid in the mobile network and may act as a
      mobility anchor if handover between mobile and Wi-Fi is supported.


3.  Deployment Models

   Figure 1 illustrates the most common residential and hotspots Wi-Fi
   deployment models.









































Gundavelli, et al.      Expires September 8, 2012               [Page 5]


Internet-Draft               Wi-Fi Services                   March 2012


          _----_           _----_           _----_
        _(      )_       _(      )_       _(      )_
       (Operator-1)     (Operator-2)     (Operator-3)
        (_      _)       (_      _)       (_      _)
           -+--             -+--            '-+--'
        +--------+       +--------+       +--------+
        | Mobile |       | Mobile |       | Mobile |
        |gateway |       |gateway |       |gateway |
        +--------+       +--------+       +--------+
             |                |                |
             +-------------.  |  .-------------+
                           |  |  |
                           |  |  |
                           |  |  |
                           |  |  |
                          +--------+             _----_
       +---+              |        |           _(      )_
       |AAA|. . . . . . . | Access |----------( Internet )
       +---+       ...... | Aggreg |           (_      _)
         |         .      | Gateway|             '----'
     +--------+    .      +--------+
     |Web Auth|.....       |  |   |
     | Portal |            |  |   +-------------+
     +--------+            |  |                 |
                           |  |              +-----+
           +---------------+  |              | AR  |
           |               +-----+           +-----+
        +-----+            | WLC |        * ---------*
        | CPE |            |     |        (    LAN    )
        |(AR) |            +-----+        * ---------*
        +-----+            /    \             /    \
           .           +----+  +----+     +----+  +----+
          / \          |WiFi|  |WiFi|     |WiFi|  |WiFi|
         MN MN         | AP |  | AP |     | AP |  | AP |
                       +----+  +----+     +----+  +----+
      Community          .                  .
       WiFi user        / \                / \
                       MN MN              MN MN


                  Figure 1: WLAN Service for Retail Model


4.  Requirements







Gundavelli, et al.      Expires September 8, 2012               [Page 6]


Internet-Draft               Wi-Fi Services                   March 2012


4.1.  Subscriber Authentication & Service Authorization

   When subscriber attaches to Wi-Fi SP network, the subscriber must
   authenticate her identity to the network.  The network will offer
   service to the subscriber based on the subscriber's identity.  The
   authentication process should be seamless and support auto sign-in
   when possible.

4.2.  Location-based Services

   In many deployments, there is a need for the mobile operator to
   provide differentiated services and policing to the mobile nodes
   based on the access network to which they are attached.  Policy
   systems in mobility architectures such as PCC and ANDSF in 3GPP
   system allow configuration of policy rules with conditions based on
   the access network information.  For example, the service treatment
   for the mobile node's traffic may be different when they are attached
   to a access network owned by the home operator than when owned by a
   roaming partner.  The service treatment can also be different based
   on the configured Service Set Identifiers (SSID) in case of IEEE
   802.11 based access networks.  Other examples of location services
   include the operator's ability to display a location specific Web
   Page, or apply tariff based on the location.

4.3.  Local Services Access & Internet Traffic Offload

   In the integrated access architectures, the mobile node's IP traffic
   is always tunneled back from the access network to the mobile gateway
   in the home network.  However, with the exponential growth in the
   mobile data traffic, mobile operators are exploring new ways to
   offload some of the IP traffic flows at the nearest access edge where
   ever there is an internet peering point, as supposed to carrying it
   all the way to the mobility anchor in the home network.  Not all IP
   traffic need to be routed back to the home network, some of the non-
   essential traffic which does not require IP mobility support can be
   offloaded at the mobile access gateway in the access network.  This
   approach provides greater leverage and efficient usage of the mobile
   packet core which help lowering transport cost.

   IP traffic offload can be managed at the access aggregation gateway
   or can also take place at the terminal side.  Here, the mobile node
   shall play with two IP addresses: an IP address anchored at the Wi-Fi
   aggregation gateway for traffic to be offloaded and a second IP
   address anchored at the mobile gateway for traffic to be conveyed via
   the mobile network.  The offload is thus a source address selection
   problem and the terminal must be able to distinguish the address
   anchored in the mobile network from the address anchored at the Wi-Fi
   aggregation gateway.



Gundavelli, et al.      Expires September 8, 2012               [Page 7]


Internet-Draft               Wi-Fi Services                   March 2012


4.4.  Web-based Authentication Support

   Most Public Wireless LAN (PWLAN) deployments today use web-based
   authentication for authorizing the user for network access.  Web-
   based mode of authentication is considered a legacy mode, for its
   weak security properties, and there are efforts to replace it with
   802.1x-based security mechanisms.  However, a very high percentage of
   the PWLAN deployments are still using using this authentication mode
   and operators are not willing to move away from this mode any time
   soon.  The reason being, lack of support for 802.1x/EAP support on
   the 100's of millions of handsets that are out there, and for the
   lack of client software in the laptops running various operating
   systems versions.  This is forcing the operators to support web-based
   authentication.

4.5.  Transparent Auto Login (TAL)

   In many deployments, there is a need to support Transparent Auto
   Login capability.  This is essentially an approach for maintaining
   Authenticated state for a user, for a duration of time.  Once an
   authenticated user disconnects and reattaches to the network, the
   network should allows instant access without forcing the user to re-
   authenticate.

4.6.  Multiple WLAN SSID Support

   Wi-Fi SP may broadcast multiple SSIDs.  For example, Wi-Fi SP A may
   partner with Wi-Fi SP B. Both will broadcast the partner's SSID along
   with its own SSID.  In this scenario, Wi-Fi SP must be able to
   execute different policy based on SSID.  For example: when a
   subscriber attaches to partner's SSID, the Wi-Fi SP should forward
   the authentication request to the partner authentication server.

4.7.  Multiple Home Network Service (APN) Access

   The 3GPP system architecture supports the concept of an Access Point
   Name (APN).  An APN can identify a particular routing domain and can
   be used by 3GPP operators to segment user traffic.  APNs are included
   in the session establishment signaling sent by 3GPP User Equipments
   (UEs), identifying which routing domain they want to be connected to.
   Furthermore, 3GPP has defined a system architecture which supports
   the ability of a single UE to have simultaneous connectivity to a
   plurality of APNs, and be allocated multiple IPv4 addresses and/or
   IPv6 prefixes from the network.

   There is a need to ensure multiple APN access for a subscriber in the
   community Wi-Fi network.




Gundavelli, et al.      Expires September 8, 2012               [Page 8]


Internet-Draft               Wi-Fi Services                   March 2012


4.8.  CPE Identity and Authorization

   There are two known models with respect to CPE roll out.  The
   consumer may purchase a device off the shelf and plugin to the
   network, or the operator at the time of service creation may have
   shipped a new device with the pre-provisioned service configuration.
   In either case, the operator needs to be able to identify the device
   based on the IP address and associate that to a given location.

   The Wi-Fi network performs access control of UEs, via the CPE acting
   as AAA supplicant.  As a result, the mobile network does not
   authenticate directly the user but shall trust the CPE performing the
   authentication.

4.9.  Mobility within the WLAN Access Network

   The mobile node should have the ability to roam within the wi-fi
   domain.  Depending on the deployment model, the mobile node may roam
   across across different IP subnets.  To survive to such handover,
   some applications (e.g.  VPN, streaming) need the IP address to be
   preserved.

   A WLAN network may include a large number of Wi-Fi base stations.  In
   some occasions, two or more Wi-Fi base stations may cover the same
   area.  When a subscriber receives Wi-Fi service in this overlapped
   area, the device may bounce between different base stations.  This is
   typical Proximity problem.  In this scenario, it is important for the
   WLAN to offer mobility to the subscriber as such the subscriber can
   continue the services without changing its IP address.

4.10.  Mobility across WLAN and Macro Access

   A mobile node should have the ability to handover from macro network
   to the Wi-Fi network and be able to retain IP address configuration
   and be able to access the home operator services.

4.11.  Differentiated Services for Users behind CPE

   Some Wi-Fi SPs enable Wi-Fi base station function on home CPE.  A
   Wi-Fi enabled home CPE may offer multiple services such as VoIP and
   data service for home user.  It is important for the Wi-Fi SP to
   differentiate services and offer different service policies.  For
   example, Wi-Fi SP may decide to give higher priority to home
   generated packets over public Wi-Fi services.







Gundavelli, et al.      Expires September 8, 2012               [Page 9]


Internet-Draft               Wi-Fi Services                   March 2012


4.12.  Lawful Intercept (LI)

   Lawful Intercept [RFC2119] stands for legally authorized interception
   and monitoring of communications to and from a subscriber under
   Surveillance by a Law Enforcement Agency.  In most of the countries,
   there are legal obligations for Service Providers to facilitate the
   intercept of any subscriber's communication if requested by law
   enforcement agencies.  Communications Assistance for Law Enforcement
   Act (CALEA), the United States wiretapping law passed in 1994 is an
   example for such legal mandates.  This section talks about Lawful
   Intercept solution requirements that are operators are required to
   support when offering WLAN services.

   The following are the key considerations with respect to supporting
   Lawful Intercept capability in Wi-Fi architectures.

   o  The operator should have the ability to capture IP traffic from
      any of the mobile nodes for which the operator is offering Wi-Fi
      services.

   o  The ability to identify the Geo-location of the mobile node to the
      nearest WLAN access point.

   o  The ability to track the mobile node's roaming within the network,
      even when there are no active IP flows.

   o  The ability to pre-provision Lawful Intercept for an inactive
      mobile node so that that the capture of IP traffic can be
      initiated anytime new IP flows associated to that mobile node are
      detected.

   o  Lawful Intercept (LI) should be undetectable by the intercept
      subject

   o  Mechanisms should be in place to limit unauthorized personnel from
      performing or knowing about lawfully authorized intercepts

   o  If the information being intercepted is encrypted by the service
      provider and the service provider has access to the keys, then the
      information should be decrypted before delivery to the Law
      Enforcement Agency (LEA) or the encryption keys should be passed
      to the Law Enforcement Agency to allow them to decrypt the
      information.








Gundavelli, et al.      Expires September 8, 2012              [Page 10]


Internet-Draft               Wi-Fi Services                   March 2012


4.13.  Charging & Accounting

   TBD

4.14.  Overlapping IPv4 Address Support

   Wi-Fi Service Provider may segment the network into regions.  Two
   regions may use overlap IPv4 address space.  This is particularly
   important when the Internet is transitioning to IPv6.  The Wi-Fi SP
   may not have enough unique public IPv4 addresses to globally address
   large number of Wi-Fi device.

4.15.  Policy Provisioning

   IP traffic offload can be managed at the access aggregation gateway.
   In such a case, the mobile gateway can potentially deliver offload
   policies (i.e.  IP flow selectors identifying the IP flows that need
   to be offloaded) to the access aggregation gateway in the access
   network.

   The offload management can also take place at the terminal side.
   Here, the mobile node shall play with two IP addresses: an IP address
   anchored at the Wi-Fi aggregation gateway for traffic to be offloaded
   and a second IP address anchored at the mobile gateway for traffic to
   be conveyed via the mobile network.  The offload is thus a source
   address selection problem.  The mobile gateway can potentially
   deliver source address selection policies (i.e. association of IP
   flow selectors and IP source address).

   A single operator has deployed both a fixed access network and a
   mobile access network.  In this scenario, the operator may wish a
   harmonized QoS management on both accesses.  However the fixed access
   network does not implement a QoS control framework.  So, the operator
   may choose to rely on the mobile network, specifying the standard
   framework to provide a QoS control, to enforce the QoS policy from
   the mobile gateway to the Wi-Fi Access network.


5.  Solution Approach

5.1.  PMIPv6 MAG in the Residential CPE

5.2.  PMIPv6 MAG in the Access Gateway








Gundavelli, et al.      Expires September 8, 2012              [Page 11]


Internet-Draft               Wi-Fi Services                   March 2012


6.  IANA Considerations

   This document does not require any IANA actions.


7.  Security Considerations

   This specification identifies the requirements for enabling Community
   Wi-Fi Services over Residential architectures and the potential
   solution approaches for addressing those requirements.  The security
   analysis for each of those requirements are covered in those
   respective sections.


8.  Acknowledgements

   The authors would like to thank Byju Pularikkal for all the
   discussions related to Lawful Interception and the related text.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.gundavelli-netext-multiple-apn-pmipv6]
              Gundavelli, S., Grayson, M., Lee, Y., Deng, H., and H.
              Yokota, "Multiple APN Support for Trusted Wireless LAN
              Access", draft-gundavelli-netext-multiple-apn-pmipv6-01
              (work in progress), February 2012.

   [I-D.gundavelli-netext-pmipv6-wlan-applicability]
              Gundavelli, S., "Applicability of Proxy Mobile IPv6
              Protocol for WLAN Access Networks",
              draft-gundavelli-netext-pmipv6-wlan-applicability-02 (work
              in progress), October 2011.

   [I-D.ietf-netext-access-network-option]
              Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and
              R. Pazhyannur, "Access Network Identifier (ANI) Option for
              Proxy Mobile IPv6",
              draft-ietf-netext-access-network-option-07 (work in
              progress), February 2012.




Gundavelli, et al.      Expires September 8, 2012              [Page 12]


Internet-Draft               Wi-Fi Services                   March 2012


   [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-04 (work in
              progress), February 2012.

   [I-D.liebsch-netext-pmip6-authiwk]
              Liebsch, M., Seite, P., and S. Gundavelli, "PMIPv6 inter-
              working with WiFi access authentication",
              draft-liebsch-netext-pmip6-authiwk-03 (work in progress),
              October 2011.

   [I-D.liebsch-netext-pmip6-qos]
              Seite, P., Liebsch, M., Korhonen, J., Gundavelli, S., and
              H. Yokota, "Quality of Service Option for Proxy Mobile
              IPv6", draft-liebsch-netext-pmip6-qos-00 (work in
              progress), October 2011.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3924]  Baker, F., Foster, B., and C. Sharp, "Cisco Architecture
              for Lawful Intercept in IP Networks", RFC 3924,
              October 2004.

   [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.

   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
              2010.


Authors' Addresses

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com






Gundavelli, et al.      Expires September 8, 2012              [Page 13]


Internet-Draft               Wi-Fi Services                   March 2012


   Mark Grayson
   Cisco
   11 New Square Park
   Bedfont Lakes, FELTHAM  TW14 8HA
   ENGLAND

   Email: mgrayson@cisco.com


   Pierrick Seite
   France Telecom - Orange
   4, rue du clos courtel BP 91226
   Cesson-Sevigne,   35512
   France

   Email: pierrick.seite@orange-ftgroup.com


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   U.S.A.

   Email: yiu_lee@cable.comcast.com
   URI:   http://www.comcast.com

























Gundavelli, et al.      Expires September 8, 2012              [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/