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

Versions: 00

IPv6 Operations Working Group                             Z. Kanizsai
Internet Draft                                                    BME
Intended status: Experimental                                L. Bokor
Expires: September 2011                                           BME
                                                             G. Jeney
                                                                  BME
                                                             G. Panza
                                                              CEFRIEL
                                                         March 8, 2011



               IPv6 anycast based feedback data aggregation
            draft-kanizsai-v6ops-anycast-data-aggregation-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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 8, 2011.



Kanizsai              Expires September 8, 2011               [Page 1]


Internet-Draft    Anycast based feedback aggregation        March 2011


Copyright Notice

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

Abstract

   This document describes how to use anycast addresses for collecting
   feedback information on the reverse link in case of multicast forward
   transmission. The application for anycast addressing in the case of
   multicast transmission is the novelty. The draft describes the
   fundamentals and requirements about how to collect and aggregate
   feedback information if anycasting is applied.

Table of Contents


   1. Introduction................................................3
   2. IPv6 anycast based feedback data aggregation.................3
      2.1. Application and usage scenarios.........................3
      2.2. Terminology............................................4
      2.3. Protocol Operation Overview and Addressing..............5
   3. Benefits of using anycast based aggregation..................7
   4. Security Considerations......................................7
   5. IANA Considerations.........................................7
   6. References..................................................7
      6.1. Normative References....................................7
      6.2. Informative References..................................7
   7. Acknowledgments.............................................8









Kanizsai               Expires August 8, 2011                 [Page 2]


Internet-Draft    Anycast based feedback aggregation        March 2011


1. Introduction

   Cross-optimized communication architectures deeply rely on collection
   and evaluation of different feedback information provided by network
   nodes periodically or on-demand. However, information is often
   represented in a redundant way (e.g., series of measurement data with
   same values can be shortly represented by a single value together
   with zero standard deviation). As a technique to remove redundancy
   and achieve efficient communication, data aggregation has been
   introduced and widely investigated in the literature. The aim of data
   aggregation is to cut back the amount of data to be transmitted while
   still distributing the required information about events of interest.
   An adequate aggregation scheme can reduce the usage of
   bandwidth/energy/computational power of all architectural components
   and nodes in the network. Data aggregation considers two main
   aspects. On one hand, data-centric aggregation schemes are designed
   to address the encoding, calculation, and compression of aggregatable
   data coming from multiple sources (using aggregation functions such
   as MAX, MIN, AVERAGE, or the probabilistic aggregation). On the other
   hand, routing-centric aggregation mechanisms are supposed to cover
   routing problems: how (e.g., when and where) information pieces
   (i.e., datagrams) can meet each other in order to be aggregated. In
   the sections below we provide a general solution for the latter issue
   by introducing a feedback data aggregation architecture deploying
   designated entities inside the network (called aggregation servers)
   that collect individual feedback information pieces and relay the
   newly composed aggregated data towards further processing in an
   optimal way, all based on IPv6 anycasting.

2. IPv6 anycast based feedback data aggregation

   In this section anycast based feedback aggregation is introduced
   according to different points of view, such as the typical scenario
   where this technique can be used, the required new entities
   introduced in the network and the newly proposed addressing
   architecture for efficient operation.

2.1. Application and usage scenarios

   The typical scenario where the application of IPv6 anycast based
   feedback aggregation can be beneficial is depicted in Figure 1.

   This scenario includes one single Server or Source of a general
   service (S), i.e. content(s), which requires feedback information
   from the subscribers called User Entities (UE). The UEs' connection
   type can be fixed or mobile as well. The feedback information helps
   the server to provide the best service given the current network


Kanizsai               Expires August 8, 2011                 [Page 3]


Internet-Draft    Anycast based feedback aggregation        March 2011


   conditions by adaptively modifying the server working parameters as
   required.

                  +-----+
                  |  S  |   Server or Source (S)
                  +-----+
                     |
                     |
            +-----------------+
            |  R              |   Network cloud with IP Routers (R)
            |             R   |
            |      R          |
            | R            R  |
            |                 |
            |   R      R      |
            +-----------------+
             //    \\       \\
            //      \\       \\
          +----+  +----+   +----+
          | UE |  | UE |   | UE |   User Entities (UE)
          +----+  +----+   +----+

         Figure 1 A typical scenario for anycast based aggregation

   A feedback message is usually composed of several small numeric
   values which provide information about the actual quality of the
   service (QoS), network parameters, etc. These values are more often
   generated with high frequency and are only a few bits or bytes long,
   so sending each one to the server separately in an IP packet is a
   critical waste of bandwidth [FeedAgg]. To avoid this, a good solution
   is using IPv6 anycasting [RFC1546] and feedback aggregation in
   combination.

2.2. Terminology

   o Server or Source (S): A node in the network which provides for
      example adaptive multimedia streaming to the User Entities. This
      service is identified with a service anycast address which is
      practically identical and indistinguishable from the IPv6 unicast
      address of the server [RFC4291].

   o User Entity (UE): A user terminal which is able to subscribe to
      the service provided by the Server or Source. It measures some
      parameters of the received service data (e.g. multimedia stream)
      continuously and sends this information back to the adaptive
      Server to keep the QoS of the service as high as possible despite
      the constantly changing network conditions.


Kanizsai               Expires August 8, 2011                 [Page 4]


Internet-Draft    Anycast based feedback aggregation        March 2011


   o Anycast Capable Router (ACR): An IP packet router which is capable
      of handling anycast addresses and services in the network. The
      anycast service providers (i.e. the Feedback Aggregation Servers)
      are registering themselves in the closest ACR. They send their
      unicast address and the ID of the anycast service they are
      intended to participate in. During the operation of the ACR the
      packets that are addressed to the service's anycast address are
      forwarded to "at least one and preferably only one" service
      provider according to a parameter like hop count, the load of the
      servers, etc [RFC1546] [RFC4786].

   o Anycast routing protocol: A routing protocol running on the ACRs
      besides the normal routing process. This protocol maintains the
      anycast group information which is updated by the service
      providers periodically. A packet addressed to an anycast address
      is routed according to the current group state information to "at
      least one and preferably only one" service provider [RFC1546].

   o Feedback Aggregation Server (FAS): A server node which processes
      the incoming IP messages addressed to the anycast address of the
      service. The individual feedback messages are decapsulated and the
      FAS, which is aware of the feedback types of the given service,
      stores them in separate queues. Every feedback type has a
      lifetime, so the various types of feedback messages must be sent
      within different time constraints. When the timer expires for the
      first message in a queue, the complete content of this queue is
      placed in a new IP packet and sent to the server of the service.

   o Feedback Aggregation Address (FAA): This is the address the IPv6
      packets, containing individual feedback messages, are addressed
      to. The FAA identifies the anycast group of the FASs and the
      Source. In practice, this address should be one of the Source's
      unicast addresses. This provides feedback delivery also in the
      cases when no ACR is present in the path from the UE back to the
      Source.

2.3. Protocol Operation Overview and Addressing

   The service Source and the Feedback Aggregation Servers are in the
   same anycast group, addressable with the same anycast address, which
   should be one of the unicast addresses of the server [RFC4291]. The
   Source and the Feedback Aggregation Server are marked in the same way
   in Figure 2 according to the above reason. The Server should have
   assigned at least two unicast addresses, one used as the anycast
   group address and the other used by the aggregated IP packets sent by
   the FASs. The unicast packet forwarding between the FASs and the
   Source prevents packet looping between ACRs and FASs (Figure 2).


Kanizsai               Expires August 8, 2011                 [Page 5]


Internet-Draft    Anycast based feedback aggregation        March 2011


                              {Anycast routing}
                        ------------(...)------------
     +----+    +-----+ /                             \  #######
     | UE |--->| ACR |/                               ->#  S  #
     +----+    +-----+\                               ->#######
                       \                +---+        /     ^
                        \            -->| R |--(...)-      /
      {Anycast routing}  \  ####### /   +---+             /
                          -># FAS #/                     /
                            #######\  {Unicast routing} /
                                    \  +-----+         /
                                     ->| ACR |--(...)--
                                       +-----+

              Figure 2 Possible paths for a feedback message

   Using one of the unicast addresses of the service Source as anycast
   group address ensures that a packet is delivered to the proper
   destination even if it crosses only unicast capable routers along the
   path back to the source (Figure 3).

                     +----+    +---+            +-----+
                     | UE |--->| R |---(...)--->|  S  |
                     +----+    +---+            +-----+

                Figure 3 Feedback message path without ACRs

   IPv6 anycasting helps reaching the aggregation servers in an optimal
   way: a UE addresses the feedback packets to the anycast address (FAA)
   of the aggregation servers (FAS), ensuring packets are delivered to
   the "closest" aggregation server (or directly to the service Source
   if this is the closest member of the anycast group (Figure 2 upper
   arrow)) using anycast routing protocol which is implemented in the
   intermediate Anycast Capable Routers (ACR). Note, that it is not
   necessary that all the routers be anycast capable: however, in this
   case, only sub-optimal transmission of feedback data is achievable.
   Furthermore, in this network scenario the stateless property of
   anycast communication [RFC1546] does not raise any problem, since the
   UEs send individual feedback packets and it makes no difference which
   aggregation server they are delivered to.

   Aggregation servers supported by anycast communication provide
   Network-level (or System-level) aggregation in a (sub-)optimal way.
   After receiving feedback data from individual UEs the FASs aggregate
   the information and relay this newly composed aggregated data towards
   the adaptive service Source.



Kanizsai               Expires August 8, 2011                 [Page 6]


Internet-Draft    Anycast based feedback aggregation        March 2011


3. Benefits of using anycast based aggregation

   In accordance with the literature, the aggregation ratio at network-
   level is determined by the length of the tracking history and the MTU
   size on the aggregation server's uplink. On average an aggregation
   ratio between 2 and 10 can be achieved. By applying this solution the
   overhead in the core network can be significantly reduced allowing
   also for an increased number of servable UEs for a given uplink
   transmission capacity of the Source.

4. Security Considerations

   The above introduced solution does not raise new security issues or
   requirements, thus the considerations from [RFC1546] and [RFC4786]
   apply as well to this document.

5. IANA Considerations

   This document has no new IANA considerations.

6. References

6.1. Normative References

   [RFC1546] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
             Service", RFC 1546, November 1993.

   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 4291, February 2006.

   [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
             Services", RFC 4786, December 2006.

6.2. Informative References

   [FeedAgg] Kanizsai, Z., Bokor, L. and G. Jeney, "An Anycast based
             Feedback Aggregation Scheme for Efficient Network
             Transparency in Cross-layer Design", Submitted to Periodica
             Polytechnica Special Issue, Under review process

   [AnyTerm] Hashimoto, M., Ata, S., Kitamura, H. and M. Murata, "IPv6
             Anycast Terminolgy Definition", IETF Internet Draft, draft-
             doi-ipv6-anycast-func-term-05.txt, January 2006, work in
             progress


Kanizsai               Expires August 8, 2011                 [Page 7]


Internet-Draft    Anycast based feedback aggregation        March 2011


   [AnyApp]  Matsunaga, S., Ata, S., Kitamura, H. and M. Murata,
             "Applications of IPv6 Anycasting", IETF Internet Draft,
             draft-ata-ipv6-anycast-app-01.txt, February 2005, work in
             progress

7. Acknowledgments

   This proposal results from the work carried out within the framework
   of OPTIMIX project (www.ict-optimix.eu) which is partly funded by the
   7th Framework Programme (FP7) of the European Union's Information and
   Communication Technologies (ICT) under the contract FP7 No. INFSO-
   ICT-214625. The authors would like to thank all participants and
   contributors who take part in the studies.

   The support of the Hungarian Government through the
   TAMOP-4.2.1/B-09/1/KMR-2010-0002 project at the Budapest University
   of Technology and Economics is also acknowledged.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Zoltan Kanizsai
   Department of Telecommunications
   Budapest University of Technology and Economics (BME)
   Magyar Tudosok krt. 2. IB121
   H-1117, Budapest
   Hungary

   Email: kanizsai@hit.bme.hu


   Laszlo Bokor
   Mobile Innovation Centre
   Budapest University of Technology and Economics (BME)
   Bertalan Lajos u. 2. Z301
   H-1111, Budapest
   Hungary

   Email: goodzi@mcl.hu









Kanizsai               Expires August 8, 2011                 [Page 8]


Internet-Draft    Anycast based feedback aggregation        March 2011


   Gabor Jeney
   Department of Telecommunications
   Budapest University of Technology and Economics (BME)
   Magyar Tudosok krt. 2. IE450
   H-1117, Budapest
   Hungary

   Email: jeneyg@hit.bme.hu


   Gianmarco Panza
   Digital Platform and Pervasive ICT Division
   CEFRIEL - Politecnico di Milano
   via Fucini 2, 20133 Milan
   Italy

   Email: Gianmarco.panza@cefriel.com































Kanizsai               Expires August 8, 2011                 [Page 9]


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