Internet DRAFT - draft-vonhugo-multimob-dmm-context

draft-vonhugo-multimob-dmm-context





MULTIMOB Group                                               D. von Hugo
Internet-Draft                           Telekom Innovation Laboratories
Intended status: Experimental                                  H. Asaeda
Expires: September 20, 2013                                         NICT
                                                                P. Seite
                                                 France Telecom - Orange
                                                          March 19, 2013

     Context Transfer for Multicast support in Distributed Mobility
                            Management (DMM)
                 draft-vonhugo-multimob-dmm-context-02

Abstract

   This document describes a context transfer based concept to support
   overarching IP multicast services applicable to various existing
   approaches for Distributed Mobility Management.

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 20, 2013.

Copyright Notice

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



von Hugo, et al.          Expires September 20, 2013            [Page 1]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  5
   3.  Handover Process . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Multicast Context Transfer Data Format . . . . . . . . . .  7
     3.2.  Multicast Context Transfer with MLD Proxy  . . . . . . . .  7
     3.3.  Multicast Context Transfer with PIM-SM . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16




















von Hugo, et al.        Expires September 20, 2013              [Page 2]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


1.  Introduction

   This document describes an application of various existing approaches
   for Distributed Mobility Management (DMM) [15] to support overarching
   IP multicast services with Proxy Mobile IPv6 (PMIPv6) [3] and Client
   Mobile IPv6 (MIPv6) [2], respectively.  Key concept of Distributed
   Mobility Management (DMM) in a flat network architecture where core
   entities and functionalities are deployed in a distributed manner
   assumes a mobile node to use the first access router (AR) it attaches
   to as principal mobility anchor, i.e.  Home Agent (HA) in MIPv6 or
   Local Mobility Anchor (LMA) in PMIPv6.  Requirements for future DMM
   protocols are listed and discussed in [22].  Current proposals for
   DMM based Mobility such as MIP-based Distributed Mobility Anchoring
   (DMA) [16] and [21] as well as PMIP-based solutions for Distributed
   Mobility Management [17], [20] ... and so forth define new AR
   capabilities applicable to a flat architecture.  Common idea of the
   various approaches is to distribute functionalities for local
   attachment of a MN to the network and for dynamically keeping track
   of a MN and its current sessions, also in case of MN attachment to a
   different AR, to all Access Routers.  These ARs are denoted here by
   DMM ARs (DARs) which are responsible for hosting (anchoring) newly
   attached MNs and their started sessions (flows), and for relaying old
   sessions to the MNs' previous DAR(s), respectively.  Some solutions
   refer to a common data base containing all relevant MN information
   for retrieval which may be co-located with existing logical entities
   such as DMM-defined Local Mobility Anchor (LMA) or a new common
   central Mobility Database (MDB).

   The MultiMob Base Protocol [12] specifies a mechanism for supporting
   multicast reception within a PMIPv6 domain using Multicast Listener
   Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") [7].
   Several extensions have been proposed to optimize Routing or session
   continuity during Handover of a MN.  While some approaches rely on
   the LMA anchoring of a MN to speed up the subscription process during
   handover as proposed in [19] others apply on an extension of Context
   Transfer Protocol (CXTP) [10] specification directly [11] or via the
   established fast HO approach using FPMIP/FMIP [14] to support
   forwarding of multicast group subscription and traffic data between
   MAGs.  Within a DMM-like approach where location (i.e. anchoring) and
   access functionality can be handled by the same entity a data
   exchange between the current AR and a prior one to ensure low delay
   and loss could be achieved without enhancing complexity too much by
   applying the CTXP modification directly.  In case of node mobility
   during an ongoing multicast reception session the node should be able
   to continuously receive the multicast data through the new AR just
   after handover completion without any MLD signaling on the new
   wireless link.  This procedure is multicast context transfer that
   provides multicast session continuity and avoids extra packet loss
   and session disruption.  Multicast context transfer will be the



von Hugo, et al.        Expires September 20, 2013              [Page 3]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


   required function to support seamless handover, while for its
   effective procedure, interaction with multicast communication
   protocols should be taken into account.  To synchronize multicast
   with unicast traffic measures to prevent delay extension due to
   waiting for multicast information should be established as proposed
   in [19]

   The Context Transfer Protocol (CXTP) specification [10] describes the
   mechanism that allows better support for minimizing service
   disruption during handover.  This document proposes to extend CXTP
   for forwarding of multicast context transfer in a DMM domain.
   "Multicast-Context Transfer Data (M-CTD)" message as defined in [11]
   is applied here for transferring multicast membership states between
   the previously attached DAR (p-DAR) to a newly attached DAR (n-DAR)
   within a DMM domain.  The context transfer is either started from the
   n-DAR on its own after attachment of the mobile node or initiated by
   the p-DAR after being informed by the access network of the planned
   handover.  Existing DMM proposals assume that for data exchange
   between p-DAR and n-DAR a dedicated tunnel already is in place.
   Details of the set-up procedure for this tunnel are therefore out of
   scope of this document.

   Depending on the scenario of multicast application the real-time
   delivery of content may be more important than lossless and error-
   free transmission.  Thus to allow for temporary storage or buffering
   at a previous access router during handover and subsequent forwarding
   may be advantageous to some file transmission use cases whereas for
   real-time video services such as live IPTV the focus is on low delay.
   Here only transfer of the MN's subscription context shall be
   considered for simplicity reasons.

   To decide on a multicast flow quality requirements dedicated flags
   may be defined to be stored in and retrieved from the common data
   base or policy storage.  Deteiled considerations on these parameters
   are out of scope of this document.
















von Hugo, et al.        Expires September 20, 2013              [Page 4]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


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 RFC 2119 [1].

   The following terms used in this document are to be interpreted as
   defined in existing proxy and client mobility protocols and in future
   upcoming Distributed Mobility Management (DMM) protocol
   specifications, see e.g. [15]: Distributed Access Router (DAR),
   Mobility Data Base (MDB), Mobile Node (MN), Proxy Care-of Address
   (Proxy-CoA), Mobile Node Identifier (MN-Identifier), Distributed
   Binding Update (DBU), and Distributed Binding Acknowledgement (DBA).






































von Hugo, et al.        Expires September 20, 2013              [Page 5]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


3.  Handover Process

   DAR is responsible for detecting the mobile node's movements to and
   from the access link and for initiating a per-flow binding
   registration either as mobility anchor (primary point of attachment).
   In case a MN attaches to the DAR which was already previously
   assigned to another (previous or primary) DAR (p-DAR) the new DAR
   (n-DAR) tracks the mobile node's movements to and from the access
   link and performs signaling of the status to that p-DAR and to a
   common MDB.  In DMM Multicast, it SHOULD NOT be required for mobile
   nodes to initiate re-subscription to multicast channels, and DAR
   SHOULD keep multicast membership state for mobile nodes even if they
   attach a different DAR during the ongoing session.

   For multicast context transfer, an IGMP/MLD-based explicit membership
   tracking function [18] MAY be enabled on DAR (whether the DAR behaves
   as a router or proxy).  The explicit tracking function enables a
   router to keep track of downstream multicast membership state created
   by downstream hosts attached on the router's link.  When a mobile
   node attaches to a new network, thanks to the explicit tracking
   function, the p-DAR extracts the mobile node's multicast membership
   state from complete multicast membership state the p-DAR has
   maintained and transmits it to the n-DAR.

   The assumed architecture for a DMM-based multicast mobility is shown
   in Figure 1.



                                   +--------------------+
                                   | Mobility Data Base |
                                   +--------------------+
                                  /          |          \
                                 /           |           \
                                /            |            \
                               /             |             \
                          +--------+      +--------+    + ------+
                          |  DAR1  |______|  DAR2  |____|  DAR3 |
                          | = p-DAR|______| = n-DAR|    |       |
                          +--------+      +--------+    +-------+
                                              |
                                            +----+
                                            | MN |
                                            +----+



           Figure 1: Distributed mobility for flat architecture



von Hugo, et al.        Expires September 20, 2013              [Page 6]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


3.1.  Multicast Context Transfer Data Format

   Multicast Context Transfer Data (M-CTD) is a message used with CXTP
   to transfer multicast membership state from p-DAR to n-DAR.  The
   following information is included in M-CTD to recognize mobile node's
   membership state.

   1.   Receiver address - indicates the address of the MN sending the
        Current-State Report.

   2.   Filter mode - indicates either INCLUDE or EXCLUDE as defined in
        [5].

   3.   Source addresses and multicast addresses - indicates the address
        pairs the MN has joined.

   The M-CTD message MUST contain the 'A' bit set as defined for the CTD
   message format in [10] for to initiate the transmission of a reply
   message by the new DAR.

   The following information included in a reply to M-CTD (similar to
   the CTDR message defined in [10]) is used to request the old DAR to
   store still incoming multicast data, to forward them to the new DAR,
   and finally to leave the multicast group after successful handover
   from n-DAR to p-DAR.

   1.   Receiver address - indicates the address of the MN sending the
        Current-State Report.

   2.   Flag indicating the p-DAR to start (B) buffering the received
        multicast data (in case the new connection is not yet fully set
        up), to forward (F) the buffered data after successful handover,
        or to leave (L) the multicast groups unless there are still
        other active subscriptions for the corresponding groups on the
        p-DAR.

   3.   Source addresses and multicast addresses - indicates the address
        pairs the MN has joined.

   The M-CTDR message MUST contain the 'S' bit set as defined for the
   CTD message format in [10] for to indicate the successful reception
   of context data at the new DAR.

3.2.  Multicast Context Transfer with MLD Proxy

   This section describes the case that DAR operates as an MLD proxy, as
   defined in [7] and specified in the base MultiMob solution [12].




von Hugo, et al.        Expires September 20, 2013              [Page 7]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


   The MLD listener handover with CXTP and MLD proxy shown in Figure 2
   is defined as follows.

   1.   A MN is assumed to be attached to the p-DAR wishing to receive
        multicast content and sending the corresponding MLD Report.  The
        serving p-DAR subscribes to the group as MLD proxy and forwards
        the multicast traffic to the MN via the access link.  In case
        the MN's multicast session is completed while being attached to
        p-DAR no corresponding entry into the Mobility Data Base needs
        to be created (regular IPv6 routing).  However in case the MN
        wants to maintain the multicast session (together with ongoing
        unicast connections) during movement it either registers the
        address configured at the p-DAR as home address, as described in
        [21] or the p-DAR has to create a binding entry in the central
        MDB as proposed e.g. in [20] or [16].

   2.   When the MN moves to another DAR with the multicast session
        ongoing the p-DAR detects the detachment and subsequently sends
        a request to create a Binding Cache Entry for the MN in the MBD,
        denoted by BCE Create Request (BC-Req).

   3.   After attaching a new DAR, the mobile node sends a Router
        Solicitation (RS) as specified in [8].  In case the MN shall
        remain unaware of any change in connectivity the n-DAR has to
        identify the p-DAR address during retrieving the MN's BCE from
        the mobile node's MDB e.g. via newly specified Distributed
        Binding Update (DBU) and corresponding Acknowledgement (DBA).
        n-DAR then sends a request for context transfer (CT-Req) to the
        p-DAR as defined in [10].  Since the MN cannot initiate the
        related Context Transfer Activate Request (CTAR) message that
        may be sent by the MDB.  In case the mobile node has the
        capability and the chance to signal to the p-DAR the link status
        and the potential new DAR address (e.g. as is specified in terms
        of Event Services by [9]) the p-DAR will send a CTAR message to
        n-DAR on behalf of the mobile node.  Alternatively the p-DAR or
        the n-DAR may have information on potential DARs in their
        vicinity to which such a CTAR or CT-Req message may be
        multicasted.

   4.   p-DAR provides together with the other feature data the
        multicast states corresponding to the moving MN-Identifier to
        n-DAR. p-DAR utilizes a context transfer protocol to deliver
        MN's Policy Profile to n-DAR, and sends Multicast Context
        Transfer Data (M-CTD) (defined in Section 3.1) to n-DAR.







von Hugo, et al.        Expires September 20, 2013              [Page 8]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


   5.   If there are multicast channels the MN has subscribed but the
        n-DAR has not yet subscribed, n-DAR subscribes via sending
        (potentially aggregated) MLD [5][6] Membership Report messages
        (i.e.  Join) to the corresponding MDB.

   6.   After successful completion of MN attachment the n-DAR replies
        to M-CTD with a Multicast Context Transfer Response message
        signalling the handover completion upon which p-DAR may leave
        the multicast group in case no other MN attached to p-DAR has
        subscribed to that group.


         MN           p-DAR               n-DAR                MDB
          |             |                   |                   |
          |-MLD Report->|==== MLD Report (aggregated Join) =======>
          |             |                   |                   |
          |<------------|<=========== Multicast data ==============
          |             |                   |                   |
        Detach          |                   |                   |
          |             |                   |                   |
          |             |----- BC-Req ------------------------->|
          |             |                   |                   |
        Attach          |                   |                   |
          |             |                   |                   |
          |------------- RS --------------->|                   |
          |             |                   |------- DBU ------>|
          |             |                   |                   |
          |             |                   |<-------DBA--------|
          |             |                   |                   |
          |             |<----- CT-Req -------------------------|
          |             |                   |                   |
          |             |------ CXTP ------>|                   |
          |             |      M-CTD        |                   |
          |             |                   |=== MLD Report ===>|
          |             |                   |                   |
          |<----------- RA -----------------|                   |
          |             |                   |                   |
          |             |                   |<= Multicast data =|
          |             |<------ CXTP ------|                   |
          |             |     M-CTDR        |                   |
          |             |                   |                   |
          |<-------- Multicast data --------|                   |
          |             |                   |                   |
          |             |=== potential MLD Report (leave) =====>|
          |             |                   |                   |


          Figure 2: MLD listener handover with CXTP and MLD proxy



von Hugo, et al.        Expires September 20, 2013              [Page 9]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


   After MN attaches to n-DAR, the forwarded multicast data from p-DAR
   will be delivered to the MN immediately.  Afterwards the current
   multicast data are delivered as received from MDB and the MN's
   multicast membership state at the p-DAR is cancelled.

3.3.  Multicast Context Transfer with PIM-SM

   This section describes the case that DAR operates as a PIM-SM [4]
   router, as described in a proposed solution [13].

   The MLD listener handover with CXTP and PIM-SM is identical as
   described in Section 3.2 except that instead of "MLD report
   (aggregated Join)" the DARs will send "PIM Join" messages and that
   the "MLD Report (leave)" , to be sent if there are no attached mobile
   nodes listening the multicast channels at p-DAR, is replaced by "PIM
   Prune" message.



































von Hugo, et al.        Expires September 20, 2013             [Page 10]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


4.  IANA Considerations

   This document proposes to extent messages defined by the
   experimental Context Transfer Protocol [10] for the sake of
   supporting Multicast control.  To achieve such a support the Context
   Transfer Data (CTD) Message and the Context Transfer Data Reply
   (CTDR) Message shall be modified to enable transfer of multicast
   related data, i.e. M-CTD and M-CTDR.  The such transported data
   consist of subscription states and flags indicating specific actions
   to the PMIP defined anchor MAG.  Such extensions described in sect. 
   3.1. of this draft may require an allocation process by IANA as
   already described in [11].










































von Hugo, et al.        Expires September 20, 2013             [Page 11]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


5.  Security Considerations

   Security is an important issue in all kinds of mobile and wireless
   communication to protect aspects as described in [22], i.e. both
   access security to allow only legitimate nodes to access mobile
   multicast service and end-to-end security of signaling messages which
   may contain confidential data.  As outlined in e.g. [22] sufficiently
   strong protection mechanisms mut be applied.
   Beside that to our knowledge no new security risks are introduced
   with this concept.












































von Hugo, et al.        Expires September 20, 2013             [Page 12]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


6.  Acknowledgements

   Many of the specifications described in this document are discussed
   and provided by the multimob mailing-list.  Detailed comments by Luis
   Miguel Contreras Murillo are gratefully acknowledged.














































von Hugo, et al.        Expires September 20, 2013             [Page 13]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to indicate requirement
         levels", RFC 2119, March 1997.

   [2]   Perkins, C, Ed., Johnson, D., and J. Arkko, "Mobility Support
         in IPv6", RFC 6275, July 2011.

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

   [4]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
         Protocol Specification (Revised)", RFC 4601, August 2006.

   [5]   Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

   [6]   Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
         Protocols", RFC 5790, February 2010.

   [7]   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, August 2006.

   [8]   Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The
         Relationship between Links and Subnet Prefixes", RFC 5942,
         July 2010.

   [9]   "IEEE Standard for Local and Metropolitan Area Networks - Part
         21: Media Independent Handover Services, IEEE LAN/MAN Std
         802.21-2008", January 2009.

7.2.  Informative References

   [10]  Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,
         "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

   [11]  von Hugo, D. and H. Asaeda, "Context Transfer Protocol
         extensions for Multicast",
         draft-vonhugo-multimob-cxtp-extension-03.txt (work in
         progress), February 2013.

   [12]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
         for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)



von Hugo, et al.        Expires September 20, 2013             [Page 14]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


         Domains", RFC 6224, April 2011.

   [13]  Asaeda, H. and P. Seite, "Multicast Routing Optimization by
         PIM-SM with PMIPv6",
         draft-asaeda-multimob-pmip6-extension-11.txt (work in
         progress), October 2012.

   [14]  Schmidt, TC., Waehlisch, M., Koodli, R., Fairhurst, G., and D.
         Liu, "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
         Handovers",
         draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt (work in
         progress), February 2013.

   [15]  Patil, B. (Ed.), Williams, C., and J. Korhonen, "Approaches to
         Distributed mobility management using Mobile IPv6 and its
         extensions", draft-patil-dmm-issues-and-approaches2dmm-00.txt
         (work in progress), March 2012.

   [16]  Seite, P. and P. Bertin, "Distributed Mobility Anchoring",
         draft-seite-dmm-dma-06.txt (work in progress), January 2013.

   [17]  Liu, D., Song, J., and W. Luo, "PMIP Based Distributed Mobility
         Management Appproach",
         draft-liu-dmm-pmip-based-approach-02.txt (work in progress),
         March 2012.

   [18]  Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking
         Function for Multicast Routers",
         draft-ietf-pim-explicit-tracking-05.txt (work in progress),
         February 2013.

   [19]  Contreras, LM., Bernardos, CJ., and I. Soto, "PMIPv6 multicast
         handover optimization by the Subscription Information
         Acquisition through the LMA (SIAL)",
         draft-ietf-multimob-fast-handover-03.txt (work in progress),
         October 2012.

   [20]  Bernardos, CJ., de la Oliva, A., Giust, F., and T. Melia, "A
         PMIPv6-based solution for Distributed Mobility Management",
         draft-bernardos-dmm-pmip-01.txt (work in progress), March
	 2012.

   [21]  Bernardos, CJ., de la Oliva, A., and F. Giust, "A IPv6
         Distributed Client Mobility Management approach using existing
         mechanisms", draft-bernardos-mext-dmm-cmip-00.txt (work in
         progress), March 2011.

   [22]  Chan, H. (Ed.) et al., "Requirements of distributed mobility
         management", draft-ietf-dmm-requirements-03.txt,  (work in
         progress), December 2012.



von Hugo, et al.        Expires September 20, 2013             [Page 15]

Internet-Draft     Context Transfer for DMM Multicast         March 2013


Authors' Addresses

   Dirk von Hugo
   Telekom Innovation Laboratories
   Deutsche-Telekom-Allee 7
   Darmstadt  64295
   Germany

   
   Email: Dirk.von-Hugo@telekom.de
   


   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   Network Architecture Laboratory
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan


   Email: asaeda@nict.go.jp


   Pierrick Seite
   France Telecom - Orange
   4, rue du Clos Courtel
   BP 91226
   Cesson-Sevigne  35512
   France

   Email: pierrick.seite@orange.com
   

















von Hugo, et al.        Expires September 20, 2013             [Page 16]