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

Versions: 00

Network Working Group                                            P. Yang
Internet-Draft                                  Hitachi (China) R&D Corp
Intended status: Standards Track                                P. Seite
Expires: August 31, 2009                                  France Telecom
                                                             C. Williams
                                                                  J. Qin
                                                                     ZTE
                                                       February 27, 2009


         Requirements on multiple Interface (MIF) of simple IP
                         draft-yang-mif-req-00

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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 31, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Yang, et al.             Expires August 31, 2009                [Page 1]

Internet-Draft                   mif-req                   February 2009


Abstract

   This draft makes a summary on the requirements of supporting multiple
   interfaces (MIF) in hosts with simple IP.  These requirements result
   from examining scenarios for multiple interface host usages.  The
   differentiation between MIF and other related IETF works are
   interpreted as well.


Table of Contents

   1.  introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Challenges for multi-homed simple IP support . . . . . . .  6
   2.  Scenarios of service sets for Multi-interfaced Hosts . . . . .  7
     2.1.  Sets of services are the same  . . . . . . . . . . . . . .  7
     2.2.  Set of services are different  . . . . . . . . . . . . . .  7
     2.3.  Set of services are partially overlapping  . . . . . . . .  8
     2.4.  Inclusion of a set of services . . . . . . . . . . . . . .  8
     2.5.  Combination of services  . . . . . . . . . . . . . . . . .  9
   3.  Requirements of MIF  . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  General Requirements . . . . . . . . . . . . . . . . . . . 10
     3.2.  Requirements on MIF routing  . . . . . . . . . . . . . . . 10
     3.3.  Requirements on merging of IP layer autoconfiguration  . . 11
     3.4.  split DNS  . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Related IETF works . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  relationship with current internet hosts (RFC1122) . . . . 13
     4.2.  Network Discovery and Selection Problem (RFC5113)  . . . . 13
     4.3.  PMIPv6 & Monami6 . . . . . . . . . . . . . . . . . . . . . 13
     4.4.  Default address selection (RFC3484)  . . . . . . . . . . . 14
     4.5.  Site Multi-homing of IPv6 (SHIM6)  . . . . . . . . . . . . 14
     4.6.  Default Router Preferences (RFC4191) . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20















Yang, et al.             Expires August 31, 2009                [Page 2]

Internet-Draft                   mif-req                   February 2009


1.  introduction

   Currently most of the network hosts (such as mobile phones, note PCs,
   etc) are equiped with multiple interfaces physically or virtually.
   The interfaces may connect with same or different network domains.
   Such scenarios result in connectivity issues as configuration
   information may be local to the interface or gobal to the node.
   Various challenges arise when multiple configuration objects that are
   global to the node are received on the many interfaces the multi-
   homed host has. for example, as figure 1 shows, a mobile phone may
   connect with multiple access networks at the same time.

   Another example is given by figure 2.  A notePC could reach the
   Internet via If1 for web browsing, while maintaining a VPN connection
   to the remote private

   Multi-homing problem in Monami6/MEXT has been discussed for issues
   related to simultaneous use of multiple addresses for either mobile
   hosts using Mobile IPv6 or mobile routers using NEMO Basic Support
   and their variants (FMIPv6, HMIPv6,etc).  NETLMM WG also has the work
   to support the mobile nodes with multiple interfaces in proxy mobile
   IPv6.  However, the solutions of both multihoming support in MEXT and
   PMIPv6 leverage on a mobility anchor (Home Agent (HA) or Local
   Mobility Anchor (LMA)).

                      +-------------+
                      | Destination |
                      | Peers       |
                      +-------------+
                             |
                    ***  ***  ***  ***
                   *   **   **   **   *
                  *                    *
                 *       Internet       *
                //*                    *\\
              //   *   **   **   **   *   \\
            //      ***  ***  ***  ***      \\
          //        //      \\       \\       \\
       +----+    +----+   +----+   +------+ +----+
       | GW |    |GGSN|   | GW |   |ASN-GW| | AR |
       +----+    +----+   +----+   +------+ +----+
         |          |        |        |        |
         |          |        |        |        |
       +----+    +----+   +----+   +-----+ +-----+
       |WiFi|    |HSPA|   |LTE |   + 16e | |Wired|
       |AP  |    |NB  |   |eNB |   + BS  | |CPE  |
       +----+    +----+   +----+   +-----+ +-----+




Yang, et al.             Expires August 31, 2009                [Page 3]

Internet-Draft                   mif-req                   February 2009


          \        \        |         /      |
            \       \       |        /       /
               +     +      +       +       /
               |     |      |       |       |
       +---+--------------+------+------+-----+----+
       |   |              |      |      |     |    |
       | +-+-+ +-----+  +---+  +---+  +---+ +---+  |
       | |if0| | if2     If3|  |If4|  |If5| |Ifn|  |
       | +---+ |(VPN)|  +---+  +---+  +---+ +---+  |
       |    |  +-----+    |      |      |     |    |
       |    |             |      |      |     |    |
       |   ++-----+-------+------+------+-----+-+  |
       |   |            MIF                     |  |
       |   | (Interface monitoring and control) |  |
       |   +--.---------------------------------+  |
       |      |                                    |
       |      |        +......................+    |
       |      |        :  Mobility management :    |
       |      |        :   protocols (MIP,...):    |
       |      |        :  (not in MIF Scope)  :    |
       |      |        +......................+    |
       |      |                                    |
       |   +--'---------------------------------+  |
       |   |           MIF                      |  |
       |   | (address selection, policies       |  |
       |   | management, ....                   |  |
       |   +------------+------------------- ---+  |
       |                |                          |
       |       +--------'---------+                |
       |       |   Applications   |                |
       |       +------------------+                |
       +-------------------------------------------+
                    Mobile Terminal

   Figure 1: Mobile Terminals connected to multiple networks


                             ** *** **
                            *  *   *  *
                           *  Private  *
                           *  Network  *
                            *  *   *  *
        +-------------+      ** *** **
        | Destination |           \\
        | Peers       |          +-----+
        +-------------+          | VPN |
               \                 +-----+
                \                 //



Yang, et al.             Expires August 31, 2009                [Page 4]

Internet-Draft                   mif-req                   February 2009


                 \  ***  ***  ***  ***
                   *   **   **   **   *
                  *                    *
                 *       Internet       *
                  *                    *
                   *   **   **   **   *
                    ***  ***  ***  ***
                    ||               \\
                 +-----+           +-----+
                 | NW2 |           | NW1 |
                 +-----+           +-----+
                /                     |
               |                      |
               |                      |
        +----+----------------------+----------+
        |    |                      |          |
        | +--+----+   +--------+  --+---+      |
        | |  if0  |   |  if2   |   If1  |      |
        | +--.----+   | (VPN)  |  ---.--+      |
        |    |        +--------+     |         |
        |    |                       |         |
        |   ++-----------------------+---+     |
        |   |            MIF             |     |
        |   | (Interface monitoring and  |     |
        |   |           control)         |     |
        |   +--.-------------------------+     |
        |      |                               |
        |      |  +......................+     |
        |      |  :  Mobility management :     |
        |      |  :   protocols (MIP,...):     |
        |      |  :  (not in MIF Scope)  :     |
        |      |  +......................+     |
        |      |                               |
        |   +--'---------------------------+   |
        |   |           MIF                |   |
        |   | (address selection, policies |   |
        |   | management, ....             |   |
        |   +------------+-----------------+   |
        |                |                     |
        |                |                     |
        |       +--------'---------+           |
        |       |   Applications   |           |
        |       |                  |           |
        |       +------------------+           |
        +--------------------------------------+
                      VPN client





Yang, et al.             Expires August 31, 2009                [Page 5]

Internet-Draft                   mif-req                   February 2009


   Figure 2: clients interconnect with Internet and VPN server

   Some problem statements ([hui08] and [Blanchet08]) have been proposed
   for MIF problems as well.  In MIF framework, different interfaces of
   MIF node will have different addresses, which may be allocated from
   different networks.

1.1.  Challenges for multi-homed simple IP support

   Several issues below are considered for multi-homed simple IP host.

   o selection of access networks: which network(s) to attach to using
   the physical interface(s) that the host has.  Already covered in RFC
   5113.

   o Flow-based Routing: access networks may be different in bandwidth,
   delay, pricing, etc. if a host is attached to a number of different
   point of attachment, there should have the way to help decide the
   right interfaces and source addresses for specific flows of
   application.

   o Configuration reconciliation: A multi-homed host receives node
   configuration information from each of its access networks.  Some
   configuration objects are global to the node, some are local to the
   interface.  Various issues arise when multiple configuration objects
   that are global to the node are received on the many interfaces the
   multi-homed host has.

   o Split DNS: If a host is attached to a number of different
   interfaces, how does it resolve a FQDN if more than one interface has
   provided a DNS server address?  [Savolainen08] gives an example on
   solving this issue.

   o Protocols for Policy delivery: the MN and the network should
   support mechanisms, e.g. [802.21], to communicate about interface
   management policies.















Yang, et al.             Expires August 31, 2009                [Page 6]

Internet-Draft                   mif-req                   February 2009


2.  Scenarios of service sets for Multi-interfaced Hosts

   The MIF work is looking at a multi-homed host whereby it receives
   node configuration information from each of its access networks.
   This section enumerates scnearios of service sets for multi-homed
   hosts so that analysis can be made to the problem goals of the IETF
   work.

   Combinations of the above - configurations with both multiple network
   interfaces and multiple IP addresses assigned to some or all of these
   interfaces - are also possible.

2.1.  Sets of services are the same

   Here the host has two or more unlimited Internet Connections.  The
   sets of services for these connections are the same.

       A and B are Internet connections both having the same set of
                                 services.


                                    ___________
                                   /           \
                                  /             \
                                 (     A, B      )
                                 (               )
                                  \             /
                                   \___________/


                       Case I: Same set of services

                                 Figure 1

2.2.  Set of services are different

   Next on the list of complexity is the scenario case a host has
   multiple Internet connections but the set of services for these are
   different.  Here the host for example may have a physical and/or
   logical VPN connection to different private networks and services.
   Another example is connecting a host to 2 logically separate but
   physically connected networks.  Here a host has one Internet
   connection and one VPN connection through which only private network
   and services can be reached.







Yang, et al.             Expires August 31, 2009                [Page 7]

Internet-Draft                   mif-req                   February 2009


    In the diagram A and B are the Internet Connections of a host each
         having a different set of services associated with them.


                              ______          ______
                             /      \        /      \
                            /        \      /        \
                           (    A     )    (    B     )
                           (          )    (          )
                            \        /      \        /
                             \______/        \______/


                    Case II: Different set of services

                                 Figure 2

2.3.  Set of services are partially overlapping

   Here the multi-connected host networking services are partially
   overlapping.

              Connection A and B having overlapping services.


                                   _____  _____
                                  /     \/     \
                                 /      / \     \
                                (   A  (   )  B  )
                                (      (   )     )
                                 \      \ /     /
                                  \______/_____/


              Case III: Partially overlapping set of services

                                 Figure 3

2.4.  Inclusion of a set of services

   In this usage scenario services provided by one network the host
   connects to are completely included by the provision of another.  For
   example, the host has one Internet connection and one VPN connection,
   while it can also access the Internet services through NATs and
   proxies provided in the VPN besides some private services.






Yang, et al.             Expires August 31, 2009                [Page 8]

Internet-Draft                   mif-req                   February 2009


                                         _______
                                        /    B  \
                                       /  ____   \
                                      (  /    \   )
                                      ( (  A   )  )
                                       \ \____/  /
                                        \_______/


                            Case IV: Inclusion

                                 Figure 4

2.5.  Combination of services

   A realistic scenario is the combination of the above mentioned
   scenarios.  A multi-homed host has multiple network interfaces both
   physical and logical.  If the host has all physical connections, the
   host may be connected to different networks through various ways, for
   instance, wired LAN, 802.11 LAN or a 3G cellular network.  For the
   case that multiple interfaces on the same network, connection issues
   should be handled by lower-layer protocols, the MIF focuses on upper-
   layer routing and service reachability.  If there is one logical
   connection the host may have logical connections built on its
   physical connection, this may be handled by some third-party tools.
   While the data forwarding process needs to be defined further such as
   in a BCP document.
























Yang, et al.             Expires August 31, 2009                [Page 9]

Internet-Draft                   mif-req                   February 2009


3.  Requirements of MIF

   In accord with the considerations in section 1, new requirements
   arise for MIF from the following aspects:

   o Packet routing in MIF

   o Merging of autoconfigurations in MIF

   o Split DNS

   o the way to communicate the policies between MIF node and network.
   DHCP ([rfc2131] and [rfc3315]) may be a possible way to do it.

3.1.  General Requirements

   Note: the items in this sub-section are applicable for all the
   scenarios in section 2.

   R0 - MIF nodes must have at least two physical/virtual interfaces,
   which may be interconnecting with same/different domains

   R1 - MIF MUST cover IPv4 only, IPv6 only, and dual-stack MIF node.

   R2 - MIF solution must compatible with existing IPv4, IPv6
   architecture and protocols.

   R3 - MIF covers routing issues with multihomed nodes.  This includes
   multicast routing, knowing that multicast mobility is not in the
   scope (see R4).

   R4 - MIF does not require to support IP mobily management protocols
   (e.g.  MIPv6, MIPv4).

3.2.  Requirements on MIF routing

   Note: the items in this sub-section are applicable for all the
   scenarios in section 2.

   R5 - MIF must decide the interface for a specific outgoing IP flow,
   before the default route is applied, if applications are agnostic of
   MIF functions.

   R6 - MIF should provide support for interface selection according
   different applications needs (in term of QoS required, etc.), if
   applications have interfaces with MIF.

   R7 - MIF must not remove the default route mechanism as defined by



Yang, et al.             Expires August 31, 2009               [Page 10]

Internet-Draft                   mif-req                   February 2009


   RFC1122.

   R8 - MIF must provide applications/users the inforamtion related to
   the interfaces.

   R9 - MIF must have the protocols to communicate the routing policies
   between MIF node and network.

   R10 - MIF must be able to get information from interfaces in order to
   feed the access selection process.

   R11 - MIF nodes may start, stop and dynamically change flows and
   connection status.

3.3.  Requirements on merging of IP layer autoconfiguration

   Note: the items in this sub-section are applicable for all the
   scenarios in section 2.

   R12 - MIF must be capable of collecting the global/local
   configuration objects from different interfaces

   R13 - MIF must support specific policies to merge the configuration
   objects when they are conflicting

   R14 - MIF must provide the way to users/network to exchange the
   policies for merging of configurations.

   R15 - MIF node must provide the way to update the configurations.

3.4.  split DNS

   Note: the items in this sub-section are not necessary for the
   scenario in section 2.1, wherein the service sets of different
   interfaces are same.  The other scenarios in section 2 have the
   requirements in this sub-section

   R16 - MIF must be able to get DNS services from different networks.

   R17 - MIF must be configured with policies for DNS service access.

   R18 - MIF must provide the way to users/network to change the
   policies for DNS access.

   R19 - MIF must provide the way to update the policies of DNS service
   access.

   R20 - MIF must have the protocols to communicate the DNS access



Yang, et al.             Expires August 31, 2009               [Page 11]

Internet-Draft                   mif-req                   February 2009


   policies between MIF node and network.


















































Yang, et al.             Expires August 31, 2009               [Page 12]

Internet-Draft                   mif-req                   February 2009


4.  Related IETF works

4.1.  relationship with current internet hosts (RFC1122)

   RFC1122 specified the requirements on the internet host softwares
   related to link layer, IP layer, and transport layer.  MIF will not
   change the basic routing policies of outbound packets in RFC1122.  On
   the contrary, MIF will add new ways to decide the route of outbound
   packets before the default route is applied.  As for multihoming
   support, if the datagram is sent in response to a received datagram,
   MIF will also select the source address for the response SHOULD be
   the specific-destination address of the request, which is the same as
   the definition of RFC1122.  Otherwise, more rules will be provided by
   MIF besides the specified rules to select the source addresses.  The
   rules of MIF are applicable for both strong and weak end systems
   (ES).  In MIF, An application is not required to explicitly specify
   the source address for initiating a connection or a request.

4.2.  Network Discovery and Selection Problem (RFC5113)

   RFC5113 defines the ways to help users to select which network to
   connect to and how to authenticate with that network, when multiple
   access networks are available.  Basically, it divides the problems of
   network discovery and selection into multiple sub- problems,
   including Discovery of Points of Attachment, Identity Selection, AAA
   Routing, Network Capabilities Discovery, etc.  Some constraints on
   potential solutions are outlined, and the limitations of several
   solutions (including existing ones) are discussed as well.  In RFC
   5113, the routing of data packets, in the situation where mechanisms
   more advanced than destination-based routing are thought to be
   necessary.  But, it explicitly specified that payload routingis not
   discussed further in RFC5113.  MIF will have solution for this issue.

   MIF will rely on RFC5113 for network discovery and selection.  Before
   the MIF works for routing/configuration/split DNS, the network
   discrovery and attachment must be finished beforehand by ways of
   RFC5113.  In this sense, MIF will not cover the network selection and
   discovery at all.

4.3.  PMIPv6 & Monami6

   As discussed in section 1, the solutions of both multihoming support
   in MEXT and NetLMM need the support from Home Agent (HA) or Local
   Mobility Anchor (LMA).  MIF will work on multiple interface solutions
   of generic simple IP model.  Anyhow, some experiences in these WG
   will be good references in MIF as well.





Yang, et al.             Expires August 31, 2009               [Page 13]

Internet-Draft                   mif-req                   February 2009


4.4.  Default address selection (RFC3484)

   RFC 3484 proposed default address selection and destination address
   for IPv6 could be a refernce to MIF work.

4.5.  Site Multi-homing of IPv6 (SHIM6)

   SHIM6 provides multi-homed site with a new sub-layer (shim) into the
   IP stack of end-system hosts, for the purposes of redundancy, load
   sharing, operational policy or cost.  It will enable hosts on multi-
   homed sites to use a set of provider-assigned IP address prefixes and
   switch between them without upsetting transport protocols or
   applications.  It's different from MIF in the following two items:

   o MIF will handling the routing of multiple flows via multiple
   interfaces based on the MIF policies.  SHIM6 only schedules the
   interfaces for the purposes of redundancy, load sharing, etc. o SHIM6
   is more on swtiching the prefixes without the invovlement of
   transport protocols or applications.

   o SHIM6 assumes the configuration of multiple interfaces has been
   done beforehand.  MIF will work on the reconciliation of these
   configuration objects.

4.6.  Default Router Preferences (RFC4191)

   RFC 4191 already specify to extend RA to communicate the prefernce
   and specific routing prefix.  However, considering the requirements
   of MIF, it doesn't cover a full fledges information for a routing and
   also not include for DHCP support.





















Yang, et al.             Expires August 31, 2009               [Page 14]

Internet-Draft                   mif-req                   February 2009


5.  Security Considerations

   MIF must have the security capabilities to protect MIF node from any
   malicious attempts caused by security holes such as denial of service
   attacks.

   - The MIF solution must not compromise the security architecture of
   the basic IPv4/IPv6 networks.

   - MIF is required to provide an admission control mechanism to
   regulate any MIF events.

   - MIF could rely on the security mechanism of each interface on MIF
   node.

   - Mechanisms used by MIF to exchange policies MUST support security
   feature to protect this flow of information.


































Yang, et al.             Expires August 31, 2009               [Page 15]

Internet-Draft                   mif-req                   February 2009


6.  Conclusion

   This draft is basically about the requirements on MIF.  The related
   considerations are given firstly, followed by the requirements of MIF
   on different aspect.  Lastly, the relationship and differentiation
   are made between perspective work of MIF and the related IETF work.













































Yang, et al.             Expires August 31, 2009               [Page 16]

Internet-Draft                   mif-req                   February 2009


7.  IANA Considerations

   This document makes no requests to IANA.
















































Yang, et al.             Expires August 31, 2009               [Page 17]

Internet-Draft                   mif-req                   February 2009


8.  Normative References

   [802.21]   "IEEE 802.21 Standard for Local and Metropolitan Area
              Networks: Media Independent Handover Services".

   [Blanchet08]
              Blanchet, M., "Multiple Interfaces Problem Statement",
              draft-blanchet-mif-problem-statement-00.txt (work in
              progress), December 2008.

   [Nordmark09]
              Nordmark, E., "Shim6: Level 3 Multihoming Shim Protocol
              for IPv6", draft-ietf-shim6-proto-12.txt (work in
              progress), February 2009.

   [OMA-DM]   "Enabler Test Specification for Device Management v1.2",
              Open Mobile Alliance OMA-ETS-DM-V1_2-20080718-C,
              July 2008.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC5113]  Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network
              Discovery and Selection Problem", RFC 5113, January 2008.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [Savolainen08]
              Savolainen , T., "Domain name based network interface
              selection", IETF Internet-draft
              draft-savolainen-6man-fqdn-based-if-selection-00.txt,
              October 2008.

   [Wakikawa09]



Yang, et al.             Expires August 31, 2009               [Page 18]

Internet-Draft                   mif-req                   February 2009


              Wakikawa , R., "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-11 (work in progress),
              January 2009.

   [hui08]    Hui, M., "Problem Statement and Requirement of Simple IP
              Multi-homing of the  Host",
              draft-hui-ip-multiple-connections-ps-01 (work in
              progress), November 2008.











































Yang, et al.             Expires August 31, 2009               [Page 19]

Internet-Draft                   mif-req                   February 2009


Authors' Addresses

   Peng Yang
   Hitachi (China) R&D Corp

   Email: peng.yang.chn@gmail.com


   Pierrick Seite
   France Telecom

   Email: pierrick.seite@orange-ftgroup.com


   Carl Williams
   ZTE
   Consultant
   Palo Alto
   United States

   Email: carl.williams@mcsr-labs.org


   Jacni Qin
   ZTE
   Shanghai
   China

   Email: jacniq@gmail.com






















Yang, et al.             Expires August 31, 2009               [Page 20]


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