Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces
draft-ietf-pim-multiple-upstreams-reqs-07
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Luis M. Contreras , Carlos J. Bernardos , Hitoshi Asaeda , Nicolai Leymann | ||
Last updated | 2018-11-06 (Latest revision 2018-10-22) | ||
Replaces | draft-contreras-pim-multiple-upstreams-reqs | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Stig Venaas | ||
Shepherd write-up | Show Last changed 2017-11-20 | ||
IESG | IESG state | AD is watching | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Alvaro Retana | ||
Send notices to | Stig Venaas <stig@venaas.com>, aretana.ietf@gmail.com |
draft-ietf-pim-multiple-upstreams-reqs-07
PIM Working Group LM. Contreras Internet-Draft Telefonica Intended status: Informational CJ. Bernardos Expires: April 25, 2019 Universidad Carlos III de Madrid H. Asaeda NICT N. Leymann Deutsche Telekom October 22, 2018 Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces draft-ietf-pim-multiple-upstreams-reqs-07 Abstract The purpose of this document is to define the requirements for a MLD (for IPv6) or IGMP (for IPv4) proxy with multiple interfaces covering a variety of applicability scenarios. 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 April 25, 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 Contreras, et al. Expires April 25, 2019 [Page 1] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Scenarios of applicability . . . . . . . . . . . . . . . . . 5 4.1. Fixed network scenarios . . . . . . . . . . . . . . . . . 6 4.1.1. Multicast wholesale offer for residential services . 6 4.1.1.1. Requirements . . . . . . . . . . . . . . . . . . 6 4.1.2. Multicast resiliency . . . . . . . . . . . . . . . . 6 4.1.2.1. Requirements . . . . . . . . . . . . . . . . . . 7 4.1.3. Load balancing for multicast traffic in the metro segment . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3.1. Requirements . . . . . . . . . . . . . . . . . . 7 4.1.4. Network merging with different multicast services . . 8 4.1.4.1. Requirements . . . . . . . . . . . . . . . . . . 8 4.1.5. Multicast service migration . . . . . . . . . . . . . 9 4.1.5.1. Requirements . . . . . . . . . . . . . . . . . . 9 4.2. Mobile network scenarios . . . . . . . . . . . . . . . . 9 5. Summary of requirements . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The aim of this document is to define the functionality that an IGMP/ MLD proxy with multiple upstream interfaces should have in order to support different scenarios of applicability in both fixed and mobile networks. This functionality is needed in order to simplify node functionality and to ensure an easier deployment of multicast capabilities in all the use cases described in this document. For doing that, a number of scenarios are described, representing current deployments and needs from operator's networks. From that scenarios, certain requirements are identified as needed to simplify operational situations, enable optimized service delivery, etc. Those represent functional requirements to be satisfied by IGMP/MLD proxies with multiple upstream interfaces. Contreras, et al. Expires April 25, 2019 [Page 2] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 Any Source Multicast (ASM) [RFC1112] and Source-Specific Multicast (SSM) [RFC4607] represent different service models at the time of subscribing to multicast groups by means of IGMPv3 [RFC3376], [RFC5790] and MLDv2 [RFC3810]. When using ASM a receiver joins a group indicating only the desired group address to be received. In the case of SSM, a receiver indicates the specific source address as well as a group address from where the multicast content is received. Both service models are taken into account along this document, and the specific requirements are derived from them. 2. Terminology This document uses the terminology defined in [RFC4605]. Specifically, the definition of Upstream and Downstream interfaces, which are repeated here for completeness. Upstream interface: A proxy device's interface in the direction of the root of the tree. Also called the "Host interface". Downstream interface: Each of a proxy device's interfaces that is not in the direction of the root of the tree. Also called the "Router interfaces". 3. Problem statement The concept of IGMP/MLD proxy with several upstream interfaces has emerged as a way of optimizing (and in some cases enabling) service delivery scenarios where separate multicast service providers are reachable through the same access network infrastructure. Figure 1 presents the conceptual model under consideration. Contreras, et al. Expires April 25, 2019 [Page 3] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 downstream upstream interface interface A | | | | _______________ | +-------+ v / \ | | O-------( Multicast Set 1 ) +----------+ v | IGMP/ | \_______________/ | Listener |------| MLD | _______________ +----------+ | Proxy | / \ | O-------( Multicast Set 2 ) +-------+ ^ \_______________/ | | upstream interface B Figure 1: Concept of IGMP/MLD proxy with multiple upstream interfaces This document is focused on both fixed and mobile network scenarios. Applicability of IGMP/MLD proxies with multiple upstream interfaces in mobile environments has been previously identified as beneficial in scenarios as the ones described in [RFC6224] and [RFC7287]. In the case of fixed networks, multicast wholesale services in a competitive residential market require an efficient distribution of multicast traffic from different operators or content providers, i.e. the incumbent operator and a number of alternative providers, on the network infrastructure of the former. Existing proposals are based on the use of PIM routing from the metro/core network, and multicast traffic aggregation on the same tree. A different approach could be achieved with the use of an IGMP/MLD proxy with multiple upstream interfaces, each of them pointing to a distinct multicast router in the metro/core border which is part of separated multicast trees deep in the network. Figure 2 graphically describes this scenario. Contreras, et al. Expires April 25, 2019 [Page 4] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 downstream upstream interface interface A | | | | _______________ | +--------+ v / \ | | Aggr. O-------( Multicast Set 1 ) | | Switch | \_______________/ +----+ v | | (e.g. from the Incumbent | AN |-------| (IGMP | Operator) +----+ | /MLD | _______________ (e.g. | Proxy) | / \ DSLAM | O-------( Multicast Set 2 ) /OLT) +--------+ ^ \_______________/ | (e.g. from an Alternative | Provider) | upstream interface B Figure 2: Example of usage of an IGMP/MLD proxy with multiple upstream interfaces in a fixed network scenario Since those scenarios can motivate distinct needs in terms of IGMP/ MLD proxy functionality, it is necessary to consider a comprehensive approach, looking at the possible scenarios, and establishing a minimum set of requirements which can allow the operation of a versatile IGMP/MLD proxy with multiple upstream interfaces as a common entity to all of them (i.e., no different kinds of proxies depending on the scenario, but a common proxy applicable to all the potential scenarios). 4. Scenarios of applicability Having multiple upstream interfaces creates a new decision space for delivering the proper multicast content to the subscriber. Basically it is now possible to implement channel-based or subscriber-based upstream selection, according to mechanisms or policies that could be defined for the multicast service provisioning. This section describes in detail a number of scenarios of applicability of an IGMP/MLD proxy with multiple upstream interfaces in place. A number of requirements for the IGMP/MLD proxy functionality are identified from those scenarios. All the exemplary scenarios here described are based on the support of two upstream interfaces. However, all of them are applicable also to the support of more than two upstream interfaces. Contreras, et al. Expires April 25, 2019 [Page 5] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 4.1. Fixed network scenarios Residential broadband users get access to multiple IP services through fixed network infrastructures. End user's equipment is connected to an access node, and the traffic of a number of access nodes is collected in aggregation switches. For the multicast service, the use of an IGMP/MLD proxy with multiple upstream interfaces in those switches appears as a simple and straightforward solution. 4.1.1. Multicast wholesale offer for residential services This scenario has been already introduced in the previous section, and can be seen in Figure 2. There are two different operators, the one operating the fixed network where the end user is connected (e.g., typically an incumbent operator), and the one providing the Internet service to the end user (e.g., an alternative Internet service provider). Both can offer multicast streams that can be subscribed by the end user, independently of which provider contributes with the content. Note that it is assumed that both providers offer distinct multicast groups. However, more than one subscription to multicast channels of different providers could take place simultaneously. 4.1.1.1. Requirements o The IGMP/MLD proxy should be able to deliver multicast control messages sent by the end user to the corresponding provider's multicast router. o The IGMP/MLD proxy should be able to deliver multicast control messages sent by each of the providers to the corresponding end user. o The IGMP/MLD proxy should be able to support ASM and SSM at the time of requesting the content. Since the use case assumes that each provider offers distinct multicast groups, the IGMP/MLD proxy should be able to identify inconsistencies in the SSM requests, that is, the case in which for an (S, G) request the source S does not deliver a the group G. 4.1.2. Multicast resiliency In current PIM-based solutions [RFC7063], the resiliency of the multicast distribution relays on the routing capabilities provided by protocols like PIM [RFC7761] and VRRP [RFC5798]. A simpler scheme Contreras, et al. Expires April 25, 2019 [Page 6] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 could be achieved by implementing different upstream interfaces on IGMP/MLD proxies, providing path diversity through the connection to distinct leaves of a given multicast tree. It is assumed that only one of the upstream interfaces is active in receiving the multicast content, while the other is up and in standby mode for fast switching. The objective is to avoid video delivery affection that could imply play out interruption or buffering on the user side. Service parameters like the ones defined in [Y.1540] (such as packet loss ratio) or in [RFC4445] (like the delay factor) can be considered as parameters to be assesed from the service perspective. For instance, [TECH.3361-1] could be considered as a SLA framework to be satisfied in this case. 4.1.2.1. Requirements o The IGMP/MLD proxy should be able to deliver multicast control messages received in the active upstream to the end users, while ignoring the control messages of the standby upstream interface. o The IGMP/MLD proxy should be able of rapidly switching from the active to the standby upstream interface in case of network failure, transparently to the end user. o The IGMP/MLD proxy should be able to deliver IGMP/MLD messages sent by the end user (for both ASM and SSM modes) to the corresponding active upstream interface. 4.1.3. Load balancing for multicast traffic in the metro segment A single upstream interface in existing IGMP/MLD proxy functionality [RFC4605] typically forces the distribution of all the channels on the same path in the last segment of the network. The metro and backhaul network is usually built using ring topologies. The devices in the ring implement IGMP/MLD functionality to join the content. Multiple upstream interfaces could naturally help to split the content demand, alleviating the bandwidth requirements in the overall metro segment by allowing some of the channels to follow the protection path, where spare capacity is vacant under normal conditions. This will allow, for instance, to absorb traffic peaks when a high number of channels (more than the expected on average) is requested. 4.1.3.1. Requirements o The IGMP/MLD proxy should be able to deliver multicast control messages sent by the end user to the corresponding multicast router which provides the channel of interest. Contreras, et al. Expires April 25, 2019 [Page 7] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 o The IGMP/MLD proxy should be able to deliver multicast control messages sent by each of the multicast routers to the corresponding end user. o The IGMP/MLD proxy should be able to decide which upstream interface is selected for any new channel request according to defined criteria (e.g., load balancing). o In the case of ASM, the IGMP/MLD proxy should be able to balance the traffic as a function of the group G requested. In the case of SSM, the load balancing mechanism could also consider the source S for the decision. 4.1.4. Network merging with different multicast services In some network merging situations, the multicast services provided before in each of the merged networks are maintained for the respective customer base (usually in a temporal fashion until the multicast service is redefined in a new single offer, but not necessarily, or not in short term, e.g. because of commercial agreements for each of the previous service offers). In order to assist that network merging situations, IGMP/MLD proxies with multiple upstream interfaces can help in the transition simplifying the service provisioning and facilitating service continuity. 4.1.4.1. Requirements o The IGMP/MLD proxy should be able to deliver multicast control messages sent by the end user to the corresponding multicast router which provides the channel of interest, according to the service subscription. o The IGMP/MLD proxy should be able to deliver multicast control messages sent by each of the multicast routers to the corresponding end user, according to the service subscription. o The IGMP/MLD proxy should be able to decide which upstream interface is selected for any new channel request according to defined criteria (e.g., service subscription). o For this use case, the usage of SSM can simplify the decision of the IGMP/MLD proxy. For ASM the decision should be assisted by further information like the service to which the end user is subscribed (e.g., taking into account what is the original network from where the end user was part previous to the network merge situation). Contreras, et al. Expires April 25, 2019 [Page 8] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 4.1.5. Multicast service migration This scenario considers the situation where a multicast service needs to be migrated from one upstream interface to another upstream interface (e.g. because of changes inside the service provider's network). The migration should be "smooth" and without any service interruption. In this case the multicast content is initially offered in both upstream interfaces and the proxy dynamically switches from the first to the second upstream interface, according to certain policies, and enabling to shut down the first upstream interface once the migration is completed. 4.1.5.1. Requirements o The IGMP/MLD proxy should be able to deliver multicast control messages sent by the end user to the corresponding multicast router before and after the service migration. o The IGMP/MLD proxy should be able to deliver multicast control messages sent by each of the multicast routers to the corresponding end user, according to the situation of the user with respect to the service migration. o The IGMP/MLD proxy should be able to decide which upstream interface corresponds to each user, according to the situation of the user with respect to the service migration. o The IGMP/MLD proxy should be able to decide which upstream interface corresponds to each ASM or SSM request, according to the situation of the group and source included in the request with respect to the service migration. 4.2. Mobile network scenarios Mobile networks offer different alternatives for multicast distribution. One of them is defined by 3GPP [TS23.246] for the Multimedia Broadcast Multicast Service (MBMS). In this case, a MBMS gateway (MBMS GW) is connected to multiple evolved Node B (eNodeB) -- which are the base stations connecting the mobile handsets with the network wirelessly [TS36.300] -- for data distribution by means of IP multicast. The MBMS GW delivers the IP multicast groups. The eNodeB joins the appropriate group multicast address allocated by the MBMS GW to receive the content data. At this distribution level, an IGMP/ MLD proxy could be part of the transport infrastructure providing connectivity to several distributed eNodeBs. The potential scenarios from this case do not essentially differentiate from the ones Contreras, et al. Expires April 25, 2019 [Page 9] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 described for the fixed network scenarios, so the same situations and requirements apply. Another alternative is given by Proxy Mobile IPv6 (PMIPv6) protocol for IP mobility management [RFC5213]. PMIPv6 is one of the mechanisms adopted by the 3GPP to support the mobility management of non-3GPP terminals in future Evolved Packet System (EPS) networks. PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct bi-directional tunnel with different Local Mobility Anchors (LMAs), being each tunnel shared by the attached Mobile Nodes (MNs). Each mobile node is associated with a corresponding LMA, which keeps track of its current location, that is, the MAG where the mobile node is attached. As the basic solution for the distribution of multicast traffic within a PMIPv6 domain, [RFC6224] makes use of the bi- directional LMA-MAG tunnels. The use of an MLD proxy supporting multiple upstream interfaces can improve the performance and the scalability of multicast-capable PMIPv6 domains, for both multicast listener and multicast source mobility. Once again, the potential scenarios in this case are contained into the ones described for the fixed network scenarios, so the same situations and requirements apply. 5. Summary of requirements Following the analysis above, a number of different requirements can be identified by the IGMP/MLD proxy to support multiple upstream interfaces. The following table summarizes these requirements. Contreras, et al. Expires April 25, 2019 [Page 10] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 +---------+-----------+-----------+-----------+-----------+-----------+ |Functio- | Multicast | Multicast | Load | Network | Network | |nality | Wholesale | Resiliency| Balancing | Merging | Migration | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstream | | | | | | |Control | X | X | X | X | X | |Delivery | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Downstr. | | | | | | |Control | X | X | X | X | X | |Delivery | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Active / | | | | | | |Standby | | X | | | | |Upstream | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstr i/f| | | | | | |selection| | | X | X | | |per group| | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstr i/f| | | | | | |selection| | X | | | X | |all group| | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ | | | | | | | | ASM | X | X | X | X | X | | | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ | | | | | | | | SSM | X | X | X | | X | | | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ Figure 3: Functionality needed on IGMP/MLD proxy with multiple upstream interfaces per application scenario 6. Security Considerations All the security considerations in [RFC4605] are directly applicable to this proposal. 7. IANA Considerations There are no IANA considerations. Contreras, et al. Expires April 25, 2019 [Page 11] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 8. Acknowledgements The authors would like to thank (in alphabetical order) Alvaro Retana, Thomas C. Schmidt, Stig Venaas and Dirk von Hugo for their comments and suggestions. 9. References 9.1. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, <https://www.rfc-editor.org/info/rfc4605>. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>. 9.2. Informative References [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>. [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>. [RFC4445] Welch, J. and J. Clark, "A Proposed Media Delivery Index (MDI)", RFC 4445, DOI 10.17487/RFC4445, April 2006, <https://www.rfc-editor.org/info/rfc4445>. Contreras, et al. Expires April 25, 2019 [Page 12] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <https://www.rfc-editor.org/info/rfc5213>. [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>. [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>. [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224, April 2011, <https://www.rfc-editor.org/info/rfc6224>. [RFC7063] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013, <https://www.rfc-editor.org/info/rfc7063>. [RFC7287] Schmidt, T., Ed., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 7287, DOI 10.17487/RFC7287, June 2014, <https://www.rfc-editor.org/info/rfc7287>. [TECH.3361-1] European Broadcasting Union, "Service Level Agreement for media transport services", EBU TECH.3361-1, September 2014. [TS23.246] "TS 23.246 Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 14) V14.1.0.", 3GPP TS 23.246 V14.1.0 , December 2016. [TS36.300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 10.11.0, September 2013. Contreras, et al. Expires April 25, 2019 [Page 13] Internet-Draft Reqs for MLD proxy with multiple upstream October 2018 [Y.1540] ITU-T, "Internet protocol data communication service - IP packet transfer and availability performance parameters", ITU-T Y.1540, July 2016. Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp Nic Leymann Deutsche Telekom Germany Email: n.leymann@telekom.de Contreras, et al. Expires April 25, 2019 [Page 14]