ICN Research Group J. Hong
Internet-Draft ETRI
Intended status: Informational L. Dong
Expires: January 3, 2019 Huawei
T. You
ETRI
C. Westphal
Huawei
Y-G. Hong
ETRI
GQ. Wang
Huawei
J. Wang
City University Hong Kong
July 2, 2018

Requirements for Name Resolution Service in ICN
draft-jhong-icnrg-nrs-requirements-04

Abstract

This document discusses the motivation and requirements for Name Resolution Service (NRS) in ICN. The NRS in ICN is to translate an object name into some other information such as locator and another name which is used for forwarding the object request.

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 https://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 January 3, 2019.

Copyright Notice

Copyright (c) 2018 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 (https://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

The current Internet is a host-centric networking, where hosts are uniquely identified with IP addresses and communication is possible between any pair of hosts. Thus, information in the current Internet is identified by the name of host where the information is stored. In contrast to the host-centric networking, the primary communication objects in Information-centric networking (ICN) are the named data objects (NDOs) and they are uniquely identified by the location-independent names. Thus, ICN aiming to the efficient dissemination and retrieval of the NDOs in a global scale has been identified and acknowledged as a promising technology for the future Internet architecture to overcome the limitations of the current Internet such as scalability, mobility, etc.[Ahlgren] [Xylomenos]. ICN also has been emerged as a candidate architecture for IoT environment since IoT focuses on data and information rather than end-to-end communications [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].

Since naming data independently from the current location where it is stored is a primary concept of ICN, how to find the NDO using the location-independent name is one of the most important design challenges in ICN. Such ICN routing may comprise three steps [RFC7927] :

In three steps of ICN routing, this document focuses only the name resolution step which translates a content name to its locators. In addition, this document considers all other types of name resolution in ICN such as name to name, name to manifest.

Thus, this document presents the definition of the Name Resolution Service (NRS) in ICN and discusses the motivation and the requirements in designing the NRS for ICN.

2. Conventions and 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].

3. Name Resolution Service in ICN

The Name Resolution Service (NRS) in ICN is defined as the service that provides the name resolution function translating an object name into some other information such as locator and another name that is used for forwarding the object request. In other words, the NRS is the service that shall be provided by ICN infrastructure to help a consumer to reach a specific piece of content, service, or host using a persistent name when the name resolution is needed.

The name resolution is a necessary process in ICN routing although the name resolution either can be separated from the content discovery as a standalone process or can be integrated with the content discovery as one combined process. The former is referred as standalone name resolution approach, the latter is referred as name based routing approach in this document.

3.1. Standalone name resolution approach

The NRS could take the standalone name resolution approach to return the client with the locators of the content, which will be used by the underlying network as the identifier to route the client's request to one of the producers. There are several ICN projects that use the standalone name resolution approach such as DONA[Koponen], PURSUIT [PURSUIT], SAIL [SAIL], MobilityFirst [MF], IDNet [Jung], etc.

3.2. Name based routing approach

The NRS could take the name based routing approach, which integrates the name resolution with the content request message routing as in NDN [NDN]/CCN [CCN].

In the case that the content request also specifies the reverse path, as in NDN/CCN, the name resolution mechanism also determines the routing path for the data. This adds a requirement on the name resolution service to propagate request in a way that is consistent with the subsequent data forwarding. Namely, the request must select a path for the data based upon the finding the copy of the content, but also properly delivering the data.

3.3. Hybrid approach

The NRS could also take hybrid approach which can perform name based routing approach from the beginning, when it fails at certain router, the router can go back to the standalone name resolution approach. The alternative hybrid NRS approach also works, which can perform standalone name resolution approach to find locators of routers which can carry out the name based routing of the client's request.

A hybrid approach would combine name resolution as a subset of routers on the path with some tunneling in between (say, across an administrative domain) so that only a few of the nodes in the architecture perform name resolution in the name-based routing approach.

3.4. Comparisons of name resolution approaches

The following compares the standalone name resolution and name based routing approaches from different aspects:

4. Motivation of NRS in ICN

This section presents the motivation and use cases of NRS in ICN.

4.1. Heterogeneous names in ICN

In ICN design, a name is used to identify an entity, such as named data content, a device, an application, a service. ICN requires uniqueness and persistency of the name of any entity to ensure the reachability of the entity within certain scope and with proper authentication and trust guarantees. The name does not change with the mobility and multi-home of the corresponding entity. A client can always use this name to retrieve the content from network and verify the binding of the content and the name.

Ideally, a name can include any form of identifier, which can be flat, hierarchical, and human readable or non-readable.

There are heterogeneous content naming schemes [ID.Zhang] [RFC1498] and name resolution approaches from different ICN architectures. For example:

Although the existing naming schemes are different, they all need to provide basic functions for identifying a content, supporting trust provenance, content lookup and routing. The NRS may combine the advantages of different mechanisms. The NRS may be able to provide a generic naming schema to resolve any type of content name, either it is flat or hierarchical.

4.2. Dynamism in ICN

In ICN literature, it is said that mobility can be achieved in fundamental feature of ICN. Especially, consumer or client mobility can be achieved by allowing information requests to basic procedure from different interfaces or through attachment point of the new network. Moreover, seamless mobility service in ICN ensures that content reception continues without any disruption in ICN application, so in consumer point of view, seamless mobility can be easily supported.

However, producer or publisher mobility in ICN is more complicated to be supported. If a publisher moves into different authority domain or network location, then the request for a content published by the moving publisher with origin name would be hardly forwarded to the moving publisher. Especially in a hierarchical name scheme, publisher mobility support is much harder than in a flat name scheme since the routing tables related in broad area should be updated according to the publisher movement. Therefore, various ICN literatures would adopt NRS to achieve the publisher mobility, where NRS can be implemented in different ways such as rendezvous mechanism, mapping, etc.

Besides mobility, ICN has challenge to support the dynamism features like multi-homing, migration, and replication of named resources such as content, devices, services, etc. and NRS may help to support the dynamism features.

4.3. Routing system in ICN

In ICN, data objects must be identified by names regardless their location or container [RFC7927] and the names are divided into two types of schemes: hierarchical and flat namespaces. A hierarchical scheme used in CCN and NDN architectures has a structure similar to current URIs, where the hierarchy improves scalability of routing system. It is because the hierarchy enables aggregation of the name resulting in reducing the size of RIB or FIB as similar to IP routing system. In a flat scheme, on the other hand, name routing is not easy since names in a flat namespace cannot be aggregated anymore, which would cause more the scalability problem in routing system. In order to address such problem, a flat name can be resolved to some information which is routable through NRS.

In ICN, application names identifying contents are used directly for packet delivery, so ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Regardless of name scheme, if non-aggregated name prefixes are injected to the Default Route Free Zone (DFZ) of ICN, then they would be driving the growth of the DFZ routing table size, which is the same as the scalability issue of IP routing. Thus a solution to keep the routing table size under control is needed, which can be done by defining indirection layer.

4.4. Use cases of NRS

This subsection describes NRS used in many other ways in ICN literature.

4.4.1. Flat name based routing support

In PURSUIT [PURSUIT], names are flat and the rendezvous functions are defined for NRS, which is implemented by a set of Rendezvous Nodes (RNs), the Rendezvous Network (RENE). Thus a name consisted of a sequence of scope IDs and a single rendezvous ID is routed by RNs in RENE. Thus, PURSUIT decouples name resolution and data routing, where NRS is performed by the RENE.

In MobilityFirst [MF], a name called a global unique Identifier (GUID) derived from a human-readable name via a global naming service is flat typed 160-bits strings with self-certifying function. Thus, MobilityFirst defines a global name resolution service (GNRS) which resolves GUIDs to network addresses and decouples name resolution and data routing as similar to PURSUIT.

4.4.2. Producer mobility support

In NDN [Zhang2], for producer mobility support, rendezvous mechanisms have been proposed to build interests rendezvous (RV) with data generated by a mobile producer (MP). There can be classified two approaches such as chase mobile producer and rendezvous data. Regarding MP chasing, rendezvous acts as a mapping service that provides the mapping from the name of the data produced by the MP to the MP's current point of attachment (PoA) name. Alternatively, the RV serves as a home agent like as IP mobility support, so the RV enables consumer's interest message to tunnel towards the MP at the PoA. Regarding rendezvous data, moving the data produced by the MP have been hosting at data depot instead of forwarding interest messages. Thus a consumer's interest message can be forwarded to stationary place as called data rendezvous, so it would either return the data or fetch it using another mapping solution. Therefore, RV or other mapping functions are in the role of NRS in NDN.

In [Ravindran], forwarding-label (FL) object is referred to enable identifier (ID) and locator (LID) namespaces to be split in ICN. Generally, IDs are managed by applications, while locators are managed by a network administrator, so that IDs are mapping to heterogeneous name schemes and LIDs are mapping to network domains or specific network elements. Thus the proposed FL object acts as a locator (LID) and provides the flexibility to forward Interest messages through mapping service between IDs and LIDs. Therefore, the mapping service in control plane infrastructure can be considered as NRS in this draft.

In MobilityFirst [MF], both consumer and publisher mobility can be primarily handled by the global name resolution service (GNRS) which resolves GUIDs to network addresses. Thus, the GNRS must be updated for mobility support when a network attached object changes its point of attachment, which differs from NDN/CCN.

4.4.3. Scalable routing support

In [Afanasyev], in order to address the routing scalability problem in NDN's DFZ, a well-known concept of Map-and-Encap is applied to provide a simple and secure namespace mapping solution. In the proposed map-and-encap design, data whose name prefixes do not exist in the DFZ forwarding table can be retrieved by a distributed mapping system called NDNS, which maintains and lookups the mapping information from a name to its globally routed prefixes, where NDNS is a kind of NRS.

4.4.4. Off-Path cache support

Caching in-network is considered to be a basic architectural component of an ICN architecture. It may be used to provide a Quality-of-Service (QoS) experience to users, reduce the overall network traffic, prevent network congestion and Denial-of-Service (DoS) attacks and increase availability. Caching approaches can be categorized into off-path caching and on-path caching based on the location of caches in relation to the forwarding path from a original server to a consumer. Off-path caching, also referred as content replication or content storing, aims to replicate content within a network in order to increase availability, regardless of the relationship of the location to the forwarding path. Thus, finding off-path cached objects is not trivial in name based routing of ICN. In order to support off-path caches, replicas are usually advertised into a name- based routing system or into NRS.

In [Bayhan], a NRS used to find off-path copies in the network, which may not be accessible via content discovery mechanisms. Such capability is essential for an Autonomous System (AS) to avoid the costly inter-AS traffic for external content, to yield higher bandwidth efficiency for intra-AS traffic, and to decrease the data access latency for a pleasant user experience.

4.4.5. Nameless object support

In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a Content Object without a Name is introduced to provide a means to move Content between storage replicas without having to rename or re-sign the content objects for the new name. Nameless Objects can be addressed by the ContentObjectHash that is to restrict Content Object matching by using SHA-256 hash.

An Interest message would still carry a Name and a ContentObjectHash, where a Name is used for routing, while a ContentObjectHash is used for matching. However, on the reverse path, if the Content Object's name is missing, it is a "Nameless Object" and only matches against the ContentObjectHash. Therefore, a consumer needs to resolve proper name and hashes through an outside system, which can be considered as NRS.

4.4.6. Menifest support

In collection of data objects which were organized as large and file like contents [FLIC], the manifests are used as data structures to transport this information. Thus, the manifests may contain hash digests of signed content objects or other manifests, so that large content objects which represent large piece of application data can be collected by using the manifest.

In order to request content objects, a consumer needs to know a manifest root name to acquire the manifest. In case of FLIC, a manifest name can be represented by a nameless root manifest, so that outside system may be involved to give this information to the consumer. Therefore, NRS can be considered as a kind of mapping database system.

5. Requirements for NRS in ICN

This section presents the requirements for designing NRS in ICN in terms of service, system and security aspects, respectively.

5.1. Requirements as a service

This subsection presents the requirements for NRS as a service.

5.1.1. Delay sensitivity

The name resolution process provided by the NRS must be completed within a minimum delay. If the name resolution takes too long, then the content request packet may get dropped or it will yield the high content retrieval time for content requestor. Thus, the content retrieval time has to be content requestor-tolerant.

5.1.2. Accuracy

The NRS must provide accurate and up-to-date information on how to discover the requested content with minimum overhead in propagating the update information. For example, a content can be moved from one domain to another domain due to the mobility of the producer, then the old name record should be deleted from the NRS system and a new name record should be added and updated with minimum delay.

5.1.3. Resolution guarantee

The NRS must ensure the name resolution success if the matching content exists in the network, regardless of its popularity, number of cached copies.

5.2. Requirements as a system

This subsection presents the requirements for NRS as a system.

5.2.1. Scalability

The NRS system must be extremely scalable to support a large number of content objects as well as billions of users, who may access the system through various connection methods and devices. Especially in IoT applications, the data size is small but frequently generated by sensors. Message forwarding and processing, routing table building-up and name records propagation must be efficient and scalable.

5.2.2. Manageability

The NRS system must be manageable since some parts of the system may grow or shrink dynamically and a NRS system node may be added or deleted.

5.2.3. Deployability

The NRS system must be deployable since deployability is important for a real world system. If the NRS system can be deployed from the edges, then the deployment can be simplified.

5.2.4. Fault tolerance

The NRS system must ensure resilience to node failures. After a NRS node fails, the NRS system must be able to restore the name records stored in the NRS node.

5.3. Requirements on Security aspect

This subsection presents the requirements for NRS on security aspect for both node and data in the NRS system.

5.3.1. Accessibility

The name records must have proper access rights such that the information contained in the name record would not be revealed to unauthorized users. In other words, The NRS system must be prevented from the malicious users attempting to hijack or corrupt name records.

5.3.2. Authentication

Users/nodes that register themselves in the NRS system must require the authentication to ensure who claims to be. For example, the attacker can act as a fake NRS server which causes disruption or intercepts the data.

5.3.3. Data confidentiality

NRS must keep the data confidentiality to prevent a lot of sensitive data from reaching unauthorized data requestor such as in IoT environment.

5.3.4. Dat privacy

When a private data is registered in the system, the NRS system must support the privacy to avoid the information leaking. Otherwise, unauthorized entity may disclose the privacy.

6. IANA Considerations

There are no IANA considerations related to this document.

7. Security Considerations

[TBD]

8. Acknowledgements

[TBD]

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T. and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016.

9.2. Informative References

[Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D. and B. Ohlman, "A Survey of Information-Centric Networking", IEEE Communications Magarzine Vol.50, Issue 7, 2012.
[Xylomenos] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C., Vasilako, X., Katsaros, K. and G. Polyzos, "A Survey of Information-Centric Networking Research,Communications Surveys and Tutorials", IEEE Communications Surveys and Tutorials vol. 16, no. 2, 2014.
[Baccelli] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T. and M. Wahlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM ICN 2014, 2014.
[Amadeo] Amadeo, M., Campolo, C., Iera, A. and A. Molinaro, "Named data networking for IoT: An architectural perspective", European Conference on Networks and Communications (EuCNC) , 2014.
[Quevedo] Quevedo, J., Corujo, D. and R. Aguiar, "A case for ICN usage in IoT environments", IEEE GLOBECOM , 2014.
[Amadeo2] Amadeo, M. et al., "Information-centric networking for the internet of things: challenges and opportunitiesve", IEEE Network vol. 30, no. 2, July 2016.
[ID.Zhang2] Zhang, Y., "Design Considerations for Applying ICN to IoT", draft-zhang-icnrg-icniot-01 , June 2017.
[Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K., Shenker, S. and I. Stoica, "A Data-Oriented (and Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 181-192, 2007.
[PURSUIT] , "FP7 PURSUIT project.", http://www.fp7-pursuit.eu/PursuitWeb/
[SAIL] , "FP7 SAIL project.", http://www.sail-project.eu/
[NDN] , "NSF Named Data Networking project.", http://www.named-data.net
[CCN] , "Content Centric Networking project.", https://wiki.fd.io/view/Cicn
[MF] , "NSF Mobility First project.", http://mobilityfirst.winlab.rutgers.edu/
[Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI Jouranl vol. 37, no. 5, October 2015.
[Jacobson] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N. and R. Braynard, "Networking Named Content", ACM CoNEXT , 2009.
[Baid] Baid, A., Vu, T. and D. Raychaudhuri, "Comparing Alternative Approaches for Networking of Named Objects in the Future Internet", IEEE Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN) , 2012.
[Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R. and B. Mathieu, "A Survey of Naming and Routing in Information-Centric Networks", IEEE Communications Magazine Vol. 50, No. 12, P.44-53, 2012.
[Rajahalme] Rajahalme, J., Sarela, M., Visala, K. and J. Riihijarvi, "On Name-based Inter-domain Routing", Computer Networks Vol. 55, No. 4, P. 975-986, March 2011.
[Katsaros] Katsaros, K., Fotiou, N., Vasilakos, X., Ververidis, C., Tsilopoulos, C., Xylomenos, G. and G. Polyzos, "On Inter-Domain Name Resolution for Information-Centric Networks", Proc.IFIP-TC6 Networking Conference , 2012.
[ID.Wang] Wang, J., Li, S. and C. Wetphal, "Namespace Resolution in Future Internet Architectures", draft-wang-fia-namespace-01 , October 2015.
[ID.Zhang] Zhang, X., Ravindran, R., Xie, H. and G. Wang, "PID: A Generic Naming Schema for Information-centric Network", draft-zhang-icnrg-pid-naming-scheme-03 , August 2013.
[D.Zhang] Zhang, D. and H. Liu, "Routing and Name Resolution in Information-Centric Networks", 22nd International Conference on Computer Communications and Networks (ICCCN) , 2013.
[Sevilla] Sevilla, S., Mahadevan, P. and J. Garcia-Luna-Aceves, "iDNS: Enabling Information Centric Networking Through The DNS", Name Oriented Mobility (workshop co-located with Infocom 2014) , 2014.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, DOI 10.17487/RFC1498, August 1993.
[oneM2M] , "oneM2M Functional Architecture TS 0001.", http://www.onem2m.org/technical/published-documents.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[ID.Shelby] Shelby, Z., "CoRE Resource Directory", draft-ietf-core-resource-directory-10 , March 2017.
[CoRE] , "Constrained RESTful Environments, CoRE", https://datatracker.ietf.org/wg/core/charter/ , March 2013.
[Westphal] Westphal, C. and E. Demirors, "An IP-based Manifest Architecture for ICN", ACM ICN , 2015.
[Mosko] Mosko, M., Scott, G., Solis, I. and C. Wood, "CCNx Manifest Specification", draft-wood-icnrg-ccnxmanifests-00 , July 2015.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013.
[Zhang] Zhang, L. et al., "Named data networking", ACM SIGCOMM Computer Communication Review vol. 44, no. 3, July 2014.
[Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, ALGORITHMS, AND APPLICATIONS(NOM) , 2016.
[Dannewitz] Dannewitz, C. et al., "Network of Information (NetInf)-An information centric networking architecture", Computer Communications vol. 36, no. 7, April 2013.
[Seskar] Seskar, I., Nagaraja, K., Nelson, S. and D. Raychaudhuri, "MobilityFirst Future Internet Architecture Project", 7th Asian Internet Engineering Conference , November 2011.
[Dannewitz2] Dannewitz, C., DAmbrosio, M. and V. Vercellone, "Hierarchical DHT-based name resolution for Information-Centric Networks", Computer Communications vol. 36, no. 7, April 2013.
[Vu] Vu, T. et al., "DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mapping in the Global Internet", IEEE 32nd International Conference on Distributed Computing Systems , 2012.
[Hong] Hong, J., Chun, W. and H. Jung, "Demonstrating a Scalable Name Resolution System for Information-Centric Networking", ACM ICN , September 2015.
[Ravindran] Ravindran, R. et al., "Forwarding-Label support in CCN Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 2017.
[Afanasyev] Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to Scale NDN Forwarding", IEEE Global Internet Symposium , April 2015.
[Mosko2] Mosko, M., "Nameless Objects", , July 2015.
[Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path Caching in Information-Centric Networks", ACM ICN , September 2016.
[FLIC] Tschudin, C. and C. Wood, "File-Like ICN Collection (FLIC)", draft-irtf-icnrg-flic-01, , June 2018.

Authors' Addresses

Jungha Hong ETRI 218 Gajeong-ro, Yuseung-Gu Daejeon, 34129 Korea Phone: +82 42 860 0926 EMail: jhong@etri.re.kr
Lijun Dong Huawei 10180 Telesis Court San Diego, CA 92121 USA EMail: lijun.dong@huawei.com
Tae-Wan You ETRI 218 Gajeong-ro, Yuseung-Gu Daejeon, 34129 Korea Phone: +82 42 860 0642 EMail: twyou@etri.re.kr
Cedric Westphal Huawei 2330 Central Expressway Santa Clara, CA 95050 USA EMail: cedric.westphal@huawei.com
Yong-Geun Hong ETRI 218 Gajeong-ro, Yuseung-Gu Daejeon, 34129 Korea Phone: +82 42 860 6557 EMail: yghong@etri.re.kr
GQ Wang Huawei 2330 Central Expressway Santa Clara, CA 95050 USA EMail: gq.wang@huawei.com
Jianping Wang City University Hong Kong EMail: jianwang@cityu.edu.hk