ICNRG A. Rahman
Internet-Draft D. Trossen
Intended status: Informational InterDigital
Expires: September 12, 2017 D. Kutscher
March 11, 2017

Deployment Configurations for Information-Centric Networks (ICN)


This document provides technical deployment guidelines for the ICN community. First, the possible deployment configurations for ICN are described including overlay and underlay approaches. Then proposed deployment migration paths for these configurations are outlined to address the major issues facing ICN such as application migration, and core and edge network migration. Next, selected ICN trial experiences are summarized. Finally, recommendations are given for protocol areas that require further standardization to facilitate future ICN interoperable deployments.

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 12, 2017.

Copyright Notice

Copyright (c) 2017 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

The ICNRG charter identifies deployment guidelines as an important topic area for the ICN community. Specifically, the charter states that defining concrete migration paths for ICN deployments which avoid forklift upgrades, and defining practical ICN interworking configurations with the existing Internet paradigm, are key topic areas that require further investigation. Also, it is well understood that results and conclusions from any mid to large-scale ICN experiments in the live Internet will also provide useful guidance for deployments.

However, so far outside of some preliminary investigations such as [I-D.paik-icn-deployment-considerations], there has not been much progress on this topic. This draft attempts to fill some of these gaps by defining clear deployment configurations for ICN, and associated migration pathways for these configurations. Also, selected deployment trial experiences of ICN technology are summarized. Finally, recommendations are made for future IETF standardization of key protocol functionality that will facilitate interoperable ICN deployments going forward.

2. Terminology

The following key terms and concepts are defined:

3. Deployment Configurations

In this section, we present various deployment options for ICN. These are presented as "configurations" that allow for studying these options further. While this document will outline (in Section 5) experiences with various of these configurations, we will not provide an in-depth technical or commercial evaluation for any of them - for this we refer to existing literature in this space such as [Tateson].

3.1. Wholesale Replacement

ICN has often been described as a "clean-slate" approach with the goal to renew or replace the current IP routing fabric of the Internet. As such, existing routing hardware as well as ancillary services have not been taken for granted. This clean-slate view is reflected as deployment configurations we label as "wholesale replacement" of large part of the existing Internet infrastructure. For instance, such configuration would see existing IP routers being replaced by CCN routers [Jacobson] or Bloom-filter based forwarding elements [IEEE_Communications]. All major ICN flavors have explored this option as their path to deployment.

While such replacement could be seen as exclusive for ICN deployments, some ICN propositions [POINT] rely on the deployment of infrastructure upgrades, here SDN switches. Such upgrades, while being possibly utilized for a "clean slate" ICN deployment would not necessary be used exclusively for an ICN deployment. Different proposals have been made for various ICN flavors to enable the operation over an SDN transport [Reed][CONET][C_FLOW].

3.2. ICN-as-an-Overlay

Similar to other significant changes to the Internet routing fabric, particularly the transition from IPv4 to IPv6 or the introduction of IP multicast, this deployment configuration foresees the creation of an ICN overlay. Note that this overlay approach is sometimes also referred to as a tunneling approach. The overlay approach could be done directly such as ICN-over-UDP as described in [CCNx_UDP]. Alternatively, the overlay could be done via ICN-in-L2-in-IP as described in [IEEE_Communications].

Another flavor of overlay would be embedding ICN semantics into existing proposals. A recently announced approach is [Hybrid_ICN] where the ICN names are mapped to IPv6 addresses. Another approach used in the Network of Information (NetInf) is to define a convergence layer to map NetInf semantics to HTTP [I-D.kutscher-icnrg-netinf-proto]. Regardless of the flavor, however, the overlay approach results in islands of ICN deployments over existing IP-based infrastructure.

3.3. ICN-as-an-Underlay

Proposals such as [POINT] and [White] outline the deployment option of using an ICN underlay that would integrate with existing IP-based services, while possibly still allowing for native ICN applications to emerge. The main reasons for such configuration option is the backward-compatible introduction of ICN technology, while possibly reaping the benefits of ICN in terms of multicast delivery, mobility support, fast indirection due to location independence, and possibly more.

3.3.1. HTTP/IP-over-ICN

In this sub-option, a deployment configuration would utilize edge-based protocol mapping onto the native ICN underlay. For instance, [POINT] proposes to map either raw IP packets or HTTP transactions directly onto an ICN-based message exchange. This mapping is realized at the network attachment point, such as realized in access points or customer premise equipment, which in turn provides a standard IP interface to existing user devices. Towards peering networks, such network attachment point turns into a modified border gateway, preserving the perception of an IP-based network towards any peering network.

The work in [White] proposes a similar deployment configuration. Here, the target is the use of ICN for content distribution within CDN server farms, i.e., the protocol mapping is realized at the ingress of the server farm where the HTTP-based retrieval request is served, while the response is delivered through a suitable egress node translation.

3.3.2. Native ICN with Application Gateways

Native ICN networks may be found at the edge of the network, mostly proposed for Internet-of-Things deployments. The integration with the current IP protocol suite takes place at an application gateway at the edge network boundary, e.g., translating incoming CoAP request/response transactions [RFC7252] into ICN message exchanges. However, ICN will allow us to evolve the role of gateways as ICN message security should be preserved through the protocol translation function of a gateway and thus offer a substantial gain.

3.4. ICN-as-a-Slice

With the advent of network slicing, i.e., the ability to isolate network resources exclusively towards a specific set of network functions, the deployment of ICN within such isolated slice is emerging as another deployment configuration. Coupled with the view of ICN functions as being "chained service functions" [RFC7665], an ICN deployment within such a slice could be realized within the emerging control plane that is targeted for adoption in future (e.g., 5th generation mobile) network deployments. Nonetheless, at the level of the specific technologies involved, this requires compatibility for instance at the level of the forwarding/data plane. With SDN emerging as a novel data plane for new network deployments, ICN flavors will need to integrate with SDN as a data plane forwarding function, as briefly discussed in Section 3.1.

4. Deployment Migration Paths

After outlining the various ICN deployment configurations in Section 3, we now focus on the various migration paths that might have an importance to the various stakeholders that are usually involved in the deployment of a technology at (ultimately) large scale. We can identify these stakeholders as: [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of our discussion.

Note that our presentation purely focuses on technological aspects of such migration. Economic or regulatory aspects, such as studied in

4.1. Application and Service Migration

The internet is full of applications and services, utilizing the innovation capabilities of the many protocols defined over the packet level IP service. HTTP provides one convergence point for these services with many web development frameworks based on the semantics provided by the hypertext transfer protocol. In recent years, even services such as video delivery have been migrating from the traditional RTP-over-UDP delivery to the various HTTP-level streaming solutions, such as DASH [DASH] and others. Nonetheless, many non-HTTP services exist, all of which need consideration when migrating from the IP-based internet to an ICN-based one.

The configuration options presented in Section 3.3.1 and Section 3.3.2 aim at providing some level of backward compatibility to this existing ecosystem. Alternatively, introducing ICN as an overlay (Section 3.2) as well as within-a-slice (Section 3.4) aims at introducing the full capabilities of ICN through new service interfaces as well as operations in the network. The overlay and within-a-slice approaches of deployment are likely to be more disruptive at the application and service level, however more new services are expected to be introduced based on such an approach.

4.2. Content Delivery Network Migration

A significant number of services and applications are devoted to content delivery in some form, either as video delivery services, social media platforms, and many others. Content delivery networks (CDNs) are deployed to assist these services through localizing the content requests and therefore reducing latency and possibly increase utilization of available bandwidth. Similar to the previous sub-section, the deployment configurations presented in Section 3.3.1 and Section 3.3.2 aim at providing a migration path for existing CDNs. This is also highlighted in the BIER WG use case draft [I-D.ietf-bier-use-cases], specifically with potential benefits in terms of utilizing multicast in the delivery of content. We return to this benefit in the trial experiences in Section 5.

4.3. Edge Network Migration

Edge networks often see the deployment of novel network level technology, e.g., in the space of the Internet of Things (IoT). Such IoT deployments have for many years relied, and often still do, on proprietary protocols for reasons such as increased efficiency, lack of standardization incentives and others. Utilizing the deployment configuration in Section 3.3.2, application gateways can integrate such edge deployments into IP-based services, e.g., utilizing CoAP [RFC7252] based machine-to-machine (M2M) platforms such as oneM2M [oneM2M] or others.

Another area of increased edge network innovation is that mobile (access) networks, particularly in the context of the 5th generation of mobile networks (often called "5G"). With the proliferation of SDN-based transport for access networks, the deployment configuration in Section 3.4 provides a suitable migration path for integration non-IP-based edge networks into the overall system through virtue of realizing the relevant (ICN) protocols in an access network slice.

4.4. Core Network Migration

Migrating the core network of the Internet requires not only significant infrastructure renewal but also the fulfillment of the significant performance requirements, particularly in terms of throughput. For those parts of the core network that would see a migration to an SDN-based transport, such as proposed by major operators such as AT&T, the deployment configuration in Section 3.4 could see the introduction of native ICN solutions within slices provided by the SDN-enabled transport network. For ICN solutions that natively work on top of SDN, Section 3.3.1 provides an additional migration, preserving the IP-based services and applications at the edge of the network, while realizing the core network routing through an ICN solution (possibly itself realized in a slice of the SDN transport network).

5. Deployment Trial Experiences

In this section, we will outline trial experiences, often conducted within international collaborative project efforts. Our focus here is on the realization of the various deployment configurations in Section 3. While a body of work exists at the simulation or emulation level, we specifically exclude these studies from our presentation to retain the focus on real experiences. We recognize that this section is unlikely to be comprehensive. We will therefore continue to solicit input from ICNRG members for other deployment experiences to complete this section.

5.1. FP7 Pursuit Efforts

Although the FP7 PURSUIT [IEEE_Communications] efforts were generally positioned as a wholesale replacement of IP (Section 3.1), the project realized its experimental test bed as an L2 VPN-based overlay between several European, US as well as Asian sites, i.e., following the deployment configuration presented in Section 3.2. Software-based forwarders were utilized for the ICN message exchange, while native ICN applications, e.g., for video transmissions, were showcased. At the height of the project efforts, about 70+ nodes were active in the (overlay) network with presentations given at several conferences as well as to the ICNRG.

5.2. H2020 POINT and RIFE Efforts

The efforts in the H2020 POINT+RIFE projects follow the deployment configuration in Section 3.3.1, although utilizing an overlay deployment to provide multi-national connectivity. However, pure SDN-based deployments do exist at various project partner sites, e.g., at Essex University, without any overlaying being realized. Edge-based network attachment points (NAPs) provide the IP/HTTP-level protocol mapping onto ICN protocol exchanges, while the SDN underlay (or the VPN-based L2 underlay) is used as a transport network.

The multicast as well as service endpoint surrogate benefits in HTTP-based scenarios, such as for HTTP-level streaming video delivery, have been demonstrated in the deployed POINT test bed with 80+ nodes being utilized. Demonstrations of this capability have been given to the ICNRG in 2015 and 2016, respectively, while public demonstrations were provided at events such as Mobile World Congress in 2016 [MWC_Demo]. The trial has also been accepted by the ETSI MEC group as a proof-of-concept with a demonstration at the ETSI MEC World Congress in Munich in September 2016.“

While the mentioned demonstrations all use the overlay international deployment, both H2020 efforts plan pure ICN underlay trials in the summer and fall of 2017. One such trial will involve real end users located in the Primetel network in Cyprus with the use case centered on IPTV and HLS video dissemination. Another trial is planned for fall 2017 in the community network of "guifi.net" in the Barcelona region, where the solution will be deployed in 40 households, providing general Internet connectivity to the residents. Standard IPTV STBs as well as HLS video players will be utilized in accordance with the aim of this deployment configuration, namely to provide application and service migration.

5.3. H2020 FLAME Efforts

Starting in January 2017, the H2020 FLAME efforts aims at providing an experimental ground for the aforementioned POINT/RIFE solution in initially two city-scale locations, namely in Bristol and Barcelona. This trial will again follow the deployment configuration in Section 3.3.1 as per POINT/RIFE approach. Currently, experiments are ongoing,conducted by the city/university joint venture Bristol-is-Open (BIO), to ensure the readiness of the city-scale SDN transport network for such experiments. At the time of initial publication of this draft in March 2017, the deployment of the ICN underlay onto the SDN transport network will be finalized with the aim of running the third trial of the aforementioned ETSI MEC PoC in the network during April/May of 2017. This third trial will showcase operational benefits provided by the ICN underlay for the scenario of a location-based game. These benefits aim at reduced network utilization through improved video delivery performance (multicast of all captured videos to the service surrogates deployed in the city at six locations) as well as reduced latency through the playout of the video originating from the local NAP instead of a remote server.

Ensuring the technology readiness and the early trialing of the ICN capabilities lays the ground for the goal of the H2020 FLAME efforts to conduct 23 large-scale experiments in the area of Future Media Internet (FMI) throughout 2018 and 2019. Standard media service functions as well as applications will ultimately utilize the ICN underlay in the delivery of their experience. The platform, which includes the ICN capabilities, will utilize concepts of SFC, integrated with NFV and SDN capabilities of the infrastructure. The ultimate goal of these platform efforts is the full integration of ICN into the overall media function platform for the provisioning of advanced (media-centric) internet services.

5.4. FP7 SAIL Trial

The Network of Information (NetInf) is the approach to Information-Centric Networking developed by the EU FP7 SAIL project (http://www.sail-project.eu/). NetInf provides both name-based forwarding with CCNx-like semantics and name resolution (for indirection and late-binding). The NetInf architecture supports different deployment options through its convergence layer abstraction. In its first prototypes and trials, NetInf was deployed mostly in an HTTP embedding and in a UDP overlay following the deployment configuration in Section 3.2. Reference [SAIL_NetInf] describes several trials including a stadium environment large crowd scenario and a multi-site testbed, leveraging NetInf’s Routing Hint approach for routing scalability.

5.5. NDN Testbed

The Named Data Networking (NDN) is one of the research projects funded by the National Science Foundation (NSF) of the USA as part of the Future Internet Architecture Program. The original NDN proposal was positioned as a wholesale replacement of IP (Section 3.1). However, in several trials, NDN generally follows the overlay deployment configuration of Section 3.2 to connect institutions over the public Internet across several continents. The use cases covered in the trials include real-time video-conferencing, geo-locating, and interfacing to consumer applications. Typical trials involve several hundred NDN enabled nodes (https://named-data.net/ndn-testbed/).

5.6. CableLabs Content Delivery System

The work in [White] proposes a deployment configuration based on Section 3.3.1. The use case is ICN for content distribution within CDN server farms (which can be quite large and complex) to leverage ICNs superior in-network caching properties. This "island of ICN" based CDN is then used to service standard HTTP/IP-based content retrieval request coming from the general Internet. This approach acknowledges that whole scale replacement (see Section 3.1) of existing HTTP/IP end user applications and related Web infrastructure is a difficult proposition. [White] does not yet provide results but indicated that experiments will be forthcoming.

6. Deployment Issues Requiring Further Standardization

The ICN Research Challenges [RFC7927] describes key ICN principles and technical research topics. As the title suggests, [RFC7927] is research oriented without a specific focus on deployment or standardization issues. This section will address this open area by identifying key protocol functionality that that we deem relevant for further standardization effort in IETF. The focus is specifically on identifying protocols that will facilitate future interoperable ICN deployments correlating to the scenarios identified in the deployment migration paths in Section 4. The identified list of required protocol functionality is not exhaustive.

6.1. Protocols for Application and Service Migration

End user applications and services need a standardized approach to trigger ICN transactions. For example, in Internet and Web applications today, there are established socket APIs, communication paradigms such as REST, common libraries, and best practices. We see a need to study application requirements in an ICN environment further and, at the same time, develop new APIs and best practices that can take advantage of ICN communication characteristics.

6.2. Protocols for Content Delivery Network Migration

A key issue in CDNs is to quickly find a location of a copy of the object requested by an end user. In ICN, a Named Data Object (NDO) is typically defined by its name. There already exists [RFC6920] that is suitable for static naming of ICN data objects. Other ways of encoding and representing ICN names have been described in [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. Naming dynamically generated data requires different approaches (for example, hash digest based names would normally not work), and there is lack of established conventions and standards.

Another CDN issue for ICN is related to multicast distribution of content. Existing CDNs have started using multicast mechanisms for certain cases such as for broadcast streaming TV. However, as discussed in Section 5.2, certain ICN approaches provide substantial improvements over IP multicast, such as the implicit support for multicast retrieval of content in all ICN flavours.

Caching is an implicit feature in many ICN architectures that can improve performance and availability in several scenarios. The ICN in-network caching can augment managed CDN and improve its performance. The details of the interplay between ICN caching and managed CDN need further consideration.

6.3. Protocols for Edge and Core Network Migration

ICN provides the potential to redesign current edge and core network computing approaches. Leveraging ICN’s inherent security and its ability to make name data and dynamic computation results available independent of location, can enable a secure, yet light-weight insertion of traffic into the network without relying on redirection of DNS requests. For this, gateways that translate from commonly used protocols in the general Internet to ICN message exchanges in the ICN domain could be used for the migration of application and services within deployments at the network edge but also in core networks. This is similar to existing approaches for IoT scenarios where a gateway translates CoAP request/responses to other message formats. For example, [RFC8075] specifies gateway mapping between CoAP and HTTP protocols. However, as mentioned previously, ICN will allow us to evolve the role of gateways as ICN message security should be preserved through the protocol translation function of a gateway and thus offer a substantial gain. Another area is integration of ICN into networks that support virtualized infrastructure in the form of NFV/SDN. Further work is required to validate this idea and document best practices.

6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts

Without claiming completeness, Table 1 maps the open the open ICN deployment protocol issues identified in this document to potential IETF groups that could address some aspects of them. An example of a specific gap that the group could potentially address is identified in parenthesis beside the group name.

Mapping of ICN Protocol Gaps to Potential IETF Groups
ICN Protocol Gaps Potential IETF Group
1-Support of HTTPBIS and CORE WG
REST APIs (HTTP/CoAP support of ICN semantics)
2-Naming New BoF/WG
(Dynamic naming of ICN data objects)
3-Multicast BIER or new BoF/WG
distribution (Multicast enhancements for ICN)
4-In-network New BoF/WG
caching (Cache placement and sharing)
Support (Integration of ICN with NFV/SDN)
6-ICN New BoF/WG
mapping (Mapping of HTTP and other protocols onto ICN message exchanges while preserving ICN message security)

7. Conclusion

This documents describes a set of technical features in ICN that warrant future specification work. For initial and incremental deployment it can be useful to address some of these features and corresponding specification work items in existing IETF working groups. In this document, we have proposed a corresponding mapping of topics to WGs. The fundamental protocols specifications may still be best addressed by a specific WG.

8. IANA Considerations

This document requests no IANA actions.

9. Security Considerations


10. Acknowledgments

The authors want to thank Xavier de Foy for his very useful reviews and comments to the document.

11. Informative References

[C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking over OpenFlow", Open Networking Summit, April, 2012.
[CCNx_UDP] PARC, , "CCNx Over UDP", 2015.
[CONET] Veltri, L. and et al., "CONET Project: Supporting Information-Centric Functionality in Software Defined Networks", Workshop on Software Defined Networks, , 2012.
[DASH] DASH, , "DASH Industry Forum", 2017.
[Hybrid_ICN] Cisco, , "Hybrid ICN: Cisco Announces Important Steps toward Adoption of Information-Centric Networking", 2017.
[I-D.ietf-bier-use-cases] Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., Robinson, D., Arya, V. and C. Bestler, "BIER Use Cases", Internet-Draft draft-ietf-bier-use-cases-04, January 2017.
[I-D.irtf-icnrg-ccnxmessages] marc.mosko@parc.com, m., Solis, I. and c. cwood@parc.com, "CCNx Messages in TLV Format", Internet-Draft draft-irtf-icnrg-ccnxmessages-03, June 2016.
[I-D.kutscher-icnrg-netinf-proto] Kutscher, D., Farrell, S. and E. Davies, "The NetInf Protocol", Internet-Draft draft-kutscher-icnrg-netinf-proto-01, February 2013.
[I-D.mosko-icnrg-ccnxurischeme] marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx URI Scheme", Internet-Draft draft-mosko-icnrg-ccnxurischeme-01, April 2016.
[I-D.paik-icn-deployment-considerations] Paik, E., Yun, W., Kwon, T. and h. hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for Information-Centric Networking", Internet-Draft draft-paik-icn-deployment-considerations-00, July 2013.
[IEEE_Communications] Trossen, D. and G. Parisis, "Designing and Realizing an Information-Centric Internet", Information-Centric Networking, IEEE Communications Magazine Special Issue, 2012.
[Internet_Pricing] Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: Differentiated Pricing for the Future Internet", ReArch Workshop in conjunction with ACM Context, December, 2010.
[Jacobson] Jacobson, V. and et al., "Networking Named Content", Proceedings of ACM Context, , 2009.
[MWC_Demo] InterDigital, , "InterDigital Demo at Mobile World Congress (MWC)", 2016.
[oneM2M] OneM2M, , "oneM2M Service Layer Standards for M2M and IoT", 2017.
[POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better IP?", European Conference on Networks and Communications (EuCNC), , 2015.
[Reed] Reed, M. and et al., "Stateless Multicast Switching in Software Defined Networks", ICC 2016, Kuala Lumpur, Malaysia, 2016.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A. and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.
[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.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T. and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017.
[SAIL_NetInf] FP7, , "SAIL Prototyping and Evaluation", 2013.
[Tateson] Tateson, J. and et al., "Final Evaluation Report on Deployment Incentives and Business Models", 2010.
[Techno_Economic] Trossen, D. and A. Kostopolous, "Techno-Economics Aspects of Information-Centric Networking", Journal for Information Policy, Volume 2, 2012.
[White] White, G. and G. Rutz, "Content Delivery with Content Centric Networking, CableLabs White Paper", 2010.

Authors' Addresses

Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, H3A 3G4 Canada EMail: Akbar.Rahman@InterDigital.com URI: http://www.InterDigital.com/
Dirk Trossen InterDigital Communications, LLC 64 Great Eastern Street, 1st Floor London, EC2A 3QR United Kingdom EMail: Dirk.Trossen@InterDigital.com URI: http://www.InterDigital.com/
Dirk Kutscher Huawei German Research Center Riesstrasse 25 Munich, 80992 Germany EMail: ietf@dkutscher.net URI: http://www.Huawei.com/