Skip to main content

Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN)
draft-dhody-actn-poi-use-case-04

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 Dhruv Dhody , Xian Zhang , Oscar Gonzalez de Dios , Daniele Ceccarelli , Bin Yeong Yoon
Last updated 2015-04-16
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dhody-actn-poi-use-case-04
ACTN BOF                                                        D. Dhody
Internet-Draft                                                  X. Zhang
Intended status: Informational                       Huawei Technologies
Expires: October 18, 2015                            O. Gonzalez de Dios
                                                              Telefonica
                                                           D. Ceccarelli
                                                                Ericsson
                                                                 B. Yoon
                                                                    ETRI
                                                          April 16, 2015

 Packet Optical Integration (POI) Use Cases for Abstraction and Control
                      of Transport Networks (ACTN)
                    draft-dhody-actn-poi-use-case-04

Abstract

   This document describes the Abstraction and Control of Transport
   Networks (ACTN) use cases related to Packet and Optical Integration
   (POI), that may be potentially deployed in various transport networks
   and apply to different applications.

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 October 18, 2015.

Copyright Notice

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

Dhody, et al.           Expires October 18, 2015                [Page 1]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  POI Scenario  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Packet Optical Integration  . . . . . . . . . . . . . . . . .   7
     3.1.  Traffic Planning, Monitoring and Automatic Network
           Adjustments . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Automated Congestion Management . . . . . . . . . . .   8
     3.2.  Protection and Restoration Synergy  . . . . . . . . . . .   8
     3.3.  Service Awareness . . . . . . . . . . . . . . . . . . . .   9
     3.4.  Coordination between Multiple Network Domains . . . . . .   9
   4.  Typical Workflow  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Network operators build and operate multi-layered multi-domain
   networks and these domains may be technology, administrative or
   vendor specific (vendor islands).  Interoperability for dealing with
   different domains is a perpetual problem for operators.  Due to these
   issues, new service introduction, often requiring connections that
   traverse multiple domains, need significant planning, and several
   manual operations to interface different vendor equipment and
   technology accross IP and Optical layers.

   The aim of Abstraction and Control of Transport Networks (ACTN) is to
   facilitate virtual network operation, creation of a virtualized
   environment allowing operators to view and control multi-subnet
   multi-technology networks into a single virtualized network.  This
   will accelerate rapid service deployment of new services, including
   more dynamic and elastic services, and improve overall network
   operations and scaling of existing services.

Dhody, et al.           Expires October 18, 2015                [Page 2]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   [ACTN-REQ] describes high-level ACTN requirements some of which are
   derived from the usecases described in this document.

   [ACTN-FWK] describes a business model of ACTN, comprising of
   customers, service providers and network providers.  This separates
   the network operations on physical network from the business needs
   (based on virtual network).  It further describes the architecture
   model for ACTN including the entities (Customer Network
   Controller(CNC), Mult-domain Service Coordinator(MDSC), and Physical
   Network Controller(PNC)) thier interfaces.

   Discussion with operators has highlighted a need for virtual network
   operation based on the abstraction of underlying technology and
   vendor domains.  This would be used for a variety of key use cases,
   including:

   o  Physical network infrastructure providers who want to build
      virtual network operations infrastructure via standards-based
      interfaces that facilitates automation and operation of multiple
      virtual networks for both internal and external trust domains.

   o  Data Center operators that need to lease facility from a number of
      physical network infrastructure providers to offer their global
      data center applications and services.  As they face multi-domain
      and diverse transport technology, interoperability based on
      standard-based abstraction will enable dynamic and flexible
      applications and services.

   The transport networks are in an unique position to embrace the
   concepts of software defined networking (SDN) because of the existing
   separation in control and forwarding plane via GMPLS/ASON.  The path
   computation element (PCE) [RFC4655] and its stateful extension
   [STATEFUL-PCE] can further provide a central control over the
   resources.  Also [STATEFUL-PCE-INITIATED] provides capability to
   initiate and delete LSP dynamically.  ACTN is focused on building
   over the existing blocks by adding programmability, access and
   control over abstract virtual topologies.  [ACTN-PROBLEM] and
   [ACTN-FWK] provide detailed information regarding this work.  This
   document focuses on the Packet and Optical Integration (POI) use
   cases of ACTN.  We refer to POI as packet over any connection-
   oriented transport technologies such as MPLS-TE, MPLS-TP, OTN or
   WSON.

   It is preferable to coordinate network resource control and
   utilization rather than controlling and optimizing resources at each
   network layer (packet and optical transport network) independently.
   This facilitates network efficiency and network automation.

Dhody, et al.           Expires October 18, 2015                [Page 3]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   In a multi-layer network via client and server networking roles,
   Label Switched Paths (LSPs) in a server (lower) layer are used to
   carry client (higher) layer LSPs across the server (lower) layer
   network.  POI in a distributed control plane environment may be
   achieved by some of the existing mechanism as specified in [RFC4208]
   and [RFC5623].  This document explores the POI use cases of ACTN to
   help provide programmable network services like orchestration, access
   to abstract topology and control over the resources.

   Increasingly there is a need for packet and optical transport
   networks to work together to provide accelerated services.  Transport
   networks can provide useful information to the packet network
   allowing it to make intelligent decisions and control its allocated
   resources.

1.1.  POI Scenario

   This section explores some typical scenario for packet and optical
   integration (POI).  These include, but not limited to, a single
   administrative domain as well as Carriers-of-Carrier case.

   Figure 1 shows a single administrative domain comprising of both
   Packet and Optical transport networks.  A POI coordinator would help
   build and operate a multi-layered multi-domain allowing operators to
   view and control a single virtualized network.

Dhody, et al.           Expires October 18, 2015                [Page 4]
Internet-Draft              ACTN-POI-USECASE                  April 2015

                            +------------+
         +------------------+    POI     |
         |                  |Orchestrator|
         |                  +-----+------+ (MDSC)
       +-v---+                    |
       |     |                    |
       +-----+                 +--v--+
       Packet                  |     |
       Control                 +-----+
       (PNC)               Optical Control (PNC)
     +------------+ +---------------------------+ +--------------+
     |            | |                           | |              |
     | +-+        | | +-+                +-+    | | +-+    +-+   |
     | |R|        |***|O|                |O|********|R|    |R|   |
     | +-+  +-+   |*| +-+    +-+         +-+    | | +-+    +-+   |
     |      |R|*****|        |O|                | |              |
     |      +-+*****|        +-+                | |              |
     |  +-+       |*|   +-+          +-+    +-+ | |   +-+        |
     |  |R|       |*****|O|          |O|    |O|*******|R|        |
     |  +-+       | |   +-+          +-+    +-+ | |   +-+        |
     |            | |                           | |              |
     +------------+ +---------------------------+ +--------------+
        Packet             Optical Transport           Packet
       Network                 Network                Network

                  Figure 1: POI for single adminstration

   Figure 2 shows a Carriers-of-Carrier case, where an optical transport
   infrastructure provider provides ACTN service to the ISP.

Dhody, et al.           Expires October 18, 2015                [Page 5]
Internet-Draft              ACTN-POI-USECASE                  April 2015

                         +-------------+
                         |    ISP      |
                         |  Controler  | (CNC)
            +------------+------+------+---------------+
            |                   |                      |
            |                   |                      |
            |                   V                      |
            |             +------------+               |
            |             |    MDSC    |               |
            |             |            |               |
            |             +------------+               |
            |                   |                      |
            |                   |                      |
            |                   V                      |
            |             +------------+               |
          +-+-------+     |    PNC     |      +--------+-+
          |  --     |     |            |      | --       |
          | |  |    |     +------------+      ||  |      |
          |  --     |                         | --   --  |
          |    --   |   +-----------------+   | --  |  | |
          |   |  |****  |  --         --  | ***|  |  --  |
          |    --   |*****|  |       |  |**** | --       |
          +---------+   |  --         --  |   +----------+
             ISP        |     --          |        ISP
           (Packet)     |    |  |   --    |      (Packet)
                        |     --   |  |   |
                        |           --    |
                        +-----------------+
                           Infrastructre
                              Provider
                              (optical)

                   Figure 2: POI for Carriers-of-Carrier

2.  Terminology

   The following terms are as defined in [ACTN-FWK]:

   o  CNC:Customer Network Controller

   o  PNC:Physical Network Controller

   o  MDSC:Multi-domain Service Coordinator

   The following terminology is used in this document.

   ACTN:  Abstraction and Control of Transport Networks.

Dhody, et al.           Expires October 18, 2015                [Page 6]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   POI:  Packet and Optical Integration

   VNTM:  Virtual Network Topology Manager

3.  Packet Optical Integration

   Connections (or tunnels) formed across the optical transport network,
   can be used as virtual TE links in the packet network.  The
   relationship is reduced to determining which tunnels to set up, how
   to trigger them, how to route them, and what capacity to assign them.
   As the demands in the packet network vary, these tunnels may need to
   be modified.

   One possible way to envision POI is via considering packet network as
   customer i.e. an entity in packet network - (maybe a Path Computation
   Element (PCE), Virtual Network Topology Manager (VNTM) [RFC5623],
   Controller etc..) should be aware of the abstract topology of the
   optical transport network.  This entity is the customer network
   controller (CNC) as per [ACTN-FWK] which interacts with MDSC.  This
   is shown in Figure 2.  Another way would be to consider Packet and
   Optical transport networks as domains and a POI coordinator (MDSC) to
   help build and operate a multi-layered multi-domain network allowing
   operators to view and control a single virtualized network as shown
   in Figure 1.

   In either case, the abstract topology may consist of established
   tunnels in optical transport network or ones that can be created on
   demand.  The level of abstraction is dependent on various management,
   security and policy considerations.  This abstract topology
   information in the packet network can be utilized in various cases,
   as detailed in the following sections.

3.1.  Traffic Planning, Monitoring and Automatic Network Adjustments

   Currently there is a schism between network planning for packet and
   optical transport networks.  Sometimes these networks are
   administered, operated and planned independently even when they are a
   part of a single trusted domain.  Any change in traffic requirements
   requires long business process to make changes in the network.  In
   dynamic networks this is no longer acceptable.

   A unified Packet+Optical traffic planning tool can be developed which
   uses the traffic demand matrix to plan the optical transport network.

Dhody, et al.           Expires October 18, 2015                [Page 7]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   Further based on traffic demand changes, historical data, traffic
   prediction and monitoring, changes should be made to the optical
   transport network.  An access to abstract topology of the optical
   transport network based on established and potential (on-demand)
   tunnels in optical transport network can provide mechanism to handle
   this.

   Further optical bypass may be established automatically to offload
   the continuous changing traffic to optical transport network allowing
   streamlined business process between packet and optical transport
   networks.

3.1.1.  Automated Congestion Management

   Congestion management and synergized network optimization for packet
   and optical transport networks can eliminate the need for overbooking
   of optical transport networks as dumb pipes.  Application could be
   written that provide automated congestion management and network
   optimization.  Automated congestion management recognizes prolonged
   congestion in the network and works with the controllers to add
   bandwidth at an optical transport layer, to alleviate the congestion,
   or make changes in the packet layer to reroute traffic around the
   congestion.

   For such applications there is a clear need for an abstract network
   topology of optical transport layer, further there is also a need for
   a synergy of cost and SLA across optical and packet networks.

3.2.  Protection and Restoration Synergy

   The protection and restoration are usually handled individually in
   Packet and optical layer.  There is a need for synergy and optimized
   handling of protection of resources across layers.  A lot more
   resources in the optical transport network are booked for backup then
   actually required since there is a lack of coordination between
   packet and optical layers.  The access to abstract graph of optical
   transport network with information pertaining to backup path
   information can help the packet network to handle protection, shared
   risk, fault restoration in an optimized way.  Informing the packet
   network about both working and protection path which are either
   already established, or potential path can be useful.

   A significant improvements in overall network availability that can
   be achieved by using optical transport shared-risk link group (SRLG)
   information to guide packet network decisions; for example, to avoid
   or minimize common SRLGs for the main (working) path and the loop
   free alternative or traffic engineered fast reroute (LFA/TE FRR)
   back-up path.  Shared risk information need to be synergized between

Dhody, et al.           Expires October 18, 2015                [Page 8]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   the packet and optical.  A mechanism to provide abstracted SRLG
   information can help the packet network consider this information
   while handling protection and restoration.

3.3.  Service Awareness

   In certain networks like financial information network (stock/
   commodity trading) and enterprises using cloud based applications,
   Latency (delay), Latency-Variation (jitter), Packet Loss and
   Bandwidth Utilization are associated with the SLA.  These SLAs must
   be synergized across packet and optical transport networks.  Network
   optimization evaluates network resource usage at all layers and
   recommends or executes service path changes while ensuring SLA
   compliance.  It thus makes more effective use of the network, and
   relieves current or potential congestion.

   The main economic benefits of ACTN arise from its ability to maintain
   the SLA of the services at reduced overall network cost considering
   both packet and optical transport network.  Operational benefits of
   the ACTN also stem from greater flexibility in handling dynamic
   traffic such as demand uncertainty or variations over time, or
   optimization based on cost or latency, or improved handling of
   catastrophic failures.

3.4.  Coordination between Multiple Network Domains

   In some deployments, optical transport network may further be divided
   into multiple domains, an abstracted topology comprising of multiple
   optical domains MAY be provided to the packet network.  A Seamless
   aggregation and orchestration across multiple optical transport
   domains is achieved via the MDSC, a great help in such deployments.

   Another interesting deployment involves multiple packet network
   domains.  There exist scenarios where the topology provided to the
   packet network domains may be different based on the initial demand
   matrix as well as, management, security and policy considerations.

   The ACTN framework as described in [ACTN-FWK] should support the
   aggregation and orchestration across network domains and layers.

   Further Figure 3 shows a multi-domain scenario where multiple PNC
   (each controlling a packet or optical domain) and a MDSC coordinating
   among them and providing a consolidated view.

Dhody, et al.           Expires October 18, 2015                [Page 9]
Internet-Draft              ACTN-POI-USECASE                  April 2015

                     +-------------------------+
                     |          MDSC           |
                     |                         |
                     +-------------------------+
                                  *
   +------------+---------+--+    *   +-----------+---------+--+
   |            +---------+  |    *   |           +---------+  |
   |            |   PNC   *************************  PNC    |  |
   |  +---------+---------+  |    *   | +---------+---------+  |
   |  |                   |  |    *   | |                   |  |
   |  |                   |  |    *   | |                   |  |
   |  |                   |  |    *   | |                   |  |
   |  | Packet            |  |    *   | | Packet            |  |
   |  +-------------------+  |    *   | +-------------------+  |
   |                         |    *   |                        |
   |                         |    *   |                        |
   |                         |    *   |                        |
   |                         |    *   |                        |
   |                         |    *   |                        |
   |             +---------+ |    *   |            +---------+ |
   |             |   PNC   *************************  PNC    | |
   |   +---------+---------+ |        |  +---------+---------+ |
   |   |                   | |        |  |                   | |
   |   |                   | |        |  |                   | |
   |   |                   | |        |  |                   | |
   |   |  Optical          | |        |  | Optical           | |
   |   +-------------------+ |        |  +-------------------+ |
   +---+-------------------+-+        +--+-------------------+-+

            Domain 1                          Domain 2

          Figure 3: Coordination between Multiple Network Domains

4.  Typical Workflow

   Consider a two-layer network where the higher-layer network is a
   packet-based IP/MPLS or GMPLS network and the lower-layer network is
   a GMPLS-controlled optical network both under a common administrative
   control.

   The PNC in both layers are under a common MDSC that coordinates
   between the two layers.  And this multi-layer network is used to
   interconnect DCs, where the DC controller (customer network
   controller - CNC) takes charge as shown in Figure 4.

Dhody, et al.           Expires October 18, 2015               [Page 10]
Internet-Draft              ACTN-POI-USECASE                  April 2015

                                                       Data Center
                                                 ***** Controller
            -------------------------------------*CNC*-------------
           |                                     *****             |
           |                                       |   Multi-layer |
           |                                       v   Coordinator |
           |                                    ******             |
           |                                    *MDSC*--           |
   Data    |                                    ******  |          |
   Center  |                                            |          |
   +----+  |                                     *****  |  +----+  |
   | DC1|<-                                      *PNC*<-   | DC3|<-
   +----+  |                                     *****  |  +----+  |
      .....|..                                 Packet   | ....     |
   +----+  | .   +-----------------------------------+  | .+----+  |
   | DC2|<-  .. /R          R           R      R..../...|..| DC4|<-
   +----+      /         R         R               /    |  +----+
     ........./....R     .    R    .      R    R../.....|.....
             +-----------------------------------+      |
   Packet          .     .    .    .      .    .        |
   Layer           .     .    .    .      .    .        |
                   .     .    .    .      .    . *****  |
                   .     .    .    .      .    . *PNC*<-
                   .     .    .    .      .    . *****  Optical
                 +-----------------------------------+
                /  O     .  O . O  .      O    O    /
               /         O    .    O  O            /
   Optical    / O    O        O           O    O  /
   Layer     +-----------------------------------+

                        Figure 4: Typical Workflow

   Data centre controller (as Customer Network Controller) interfaces
   the data centre application stratum, it understands multiple DC
   application requirements and their service needs.  DC Controller
   provides its traffic demand matrix that describes bandwidth
   requirements and other optional QoS parameters (e.g., latency,
   diversity requirement, etc.) for each pair of inter-DC connections.
   The MDSC (multi-layer coordinator) sits between the DC controller
   (CNC - the one issuing connectivity requests) and the physical
   network controllers (the one managing the resources).  In this case
   each layer has its own PNC managing the resources in each layer with
   MDSC acting as a multi-layer coordinator.  The PNC is in charge of
   configuring the network elements, monitoring the physical topology of
   the network and passing it, either raw or abstracted, to the MDSC.

Dhody, et al.           Expires October 18, 2015               [Page 11]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   MDSC with the help of PNC(s) coordinates network resource control and
   utilization facilitating network efficiency and network automation.
   The MDSC are also responsible for the abstract topology and the level
   of abstraction, which facilitate various DC usecases like VM
   Migrations, global load balancing among geographically distributed
   DCs, Business continuity and disaster recovery etc using the ACTN
   framework in an elastic and dynamic and way, improving overall
   network operations and scaling.

   Based on the Data centre controller's (acting as CNC) requests for
   virtual network paths, the MDSC mediates with the PNCs and maps these
   'virtual' request to inter-layer coordinated path computation and
   provisioning requests in the 'physical' domain to the PNC.  Thus MDSC
   acts as a multi-layer coordinator both in respect to multi-layer end
   to end optimized path computation as well as multi-layer signaling
   and provisioning.  The path computation and abstract topology
   creation would be based on the guidelines set by the CNC including
   the optimization criteria, traffic profile, policy etc.

   In case the PNC could not fulfill the desired request from MDSC and
   indirectly from DC controller, there should be a feedback loop to the
   MDSC so that suitable actions including path recalculation and
   signaling, negotiation of parameters and attributes with DC
   controller etc can be undertaken.  Thus MDSC effectively arbitrate
   between the customers (DC) and the existing network (PNC) in this
   example.

5.  Security Considerations

   TBD.

6.  IANA Considerations

   None, this is an informational document.

7.  Acknowledgments

8.  References

8.1.  Normative References

   [ACTN-FWK]
              Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
              Control of Transport Networks (draft-ceccarelli-actn-
              framework)", March 2015.

Dhody, et al.           Expires October 18, 2015               [Page 12]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   [ACTN-REQ]
              Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D.
              Ceccarelli, "Requirements for Abstraction and Control of
              Transport Networks (draft-lee-teas-actn-requirements)",
              April 2015.

8.2.  Informative References

   [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
              "Generalized Multiprotocol Label Switching (GMPLS) User-
              Network Interface (UNI): Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Support for the Overlay
              Model", RFC 4208, October 2005.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, September 2009.

   [STATEFUL-PCE]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE [draft-ietf-pce-stateful-
              pce]", October 2014.

   [STATEFUL-PCE-INITIATED]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model [draft-ietf-pce-pce-initiated-lsp]", October 2014.

   [ACTN-PROBLEM]
              Lee, Y., King, D., Boucadair, M., Jing, R., and L.
              Contreras Murillo, "Problem Statement for Abstraction and
              Control of Transport Networks (draft-leeking-actn-problem-
              statement)", September 2014.

Dhody, et al.           Expires October 18, 2015               [Page 13]
Internet-Draft              ACTN-POI-USECASE                  April 2015

Appendix A.  Contributor Addresses

   Udayasree Palle
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560037
   India

   EMail: udayasree.palle@huawei.com

Authors' Addresses

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560037
   India

   EMail: dhruv.ietf@gmail.com

   Xian Zhang
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R.China

   EMail: zhang.xian@huawei.com

   Oscar Gonzalez de Dios
   Telefonica
   Spain

   EMail: ogondio@tid.es

   Daniele Ceccarelli
   Ericsson
   Via E. Melen 77, Genova - Erzelli
   Italy

   EMail: daniele.ceccarelli@ericsson.com

Dhody, et al.           Expires October 18, 2015               [Page 14]
Internet-Draft              ACTN-POI-USECASE                  April 2015

   Bin-Yeong Yoon
   ETRI
   South Korea

   EMail: byyun@etri.re.kr

Dhody, et al.           Expires October 18, 2015               [Page 15]