Clouds                                                         H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Standards Track                               F. J. Lin
Expires: August 15, 2011                          Telcordia Technologies
                                                                A. Dutta
                                                                  NIKSUN
                                                             C. Williams
                                                               MCSR Labs
                                                               V. Manral
                                                         IPInfusion Inc.
                                                       February 11, 2011


              Service Management for Virtualized Networks
               draft-yokota-cloud-service-mobility-01.txt

Abstract

   Network virtualization technique leveraged by a virtual machine makes
   it possible to dynamically relocate functional entities without
   topological and physical constraints.  By tapping into this
   technique, service mobility, which deals with not only functional
   entities but also sessions established between those entities, will
   become possible and such capability is especially longed for
   realizing more scalable and reliable telecom networks.  This document
   provides the reference model for service mobility in a virtual
   environment and defines the control protocol between the virtualized
   platform and the managing controller to realize service mobility.

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 August 15, 2011.

Copyright Notice




Yokota, et al.           Expires August 15, 2011                [Page 1]


Internet-Draft       Virtualized Service Management        February 2011


   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.

   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.



























Yokota, et al.           Expires August 15, 2011                [Page 2]


Internet-Draft       Virtualized Service Management        February 2011


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview and Terminology . . . . . . . . . . . . . . . . . . .  6
   4.  Service Mobility Requirements  . . . . . . . . . . . . . . . . 10
   5.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Common header format . . . . . . . . . . . . . . . . . . . 15
     6.2.  Control messages . . . . . . . . . . . . . . . . . . . . . 17
       6.2.1.  REGISTRATION . . . . . . . . . . . . . . . . . . . . . 17
       6.2.2.  KEEP-ALIVE . . . . . . . . . . . . . . . . . . . . . . 17
       6.2.3.  OPERATION  . . . . . . . . . . . . . . . . . . . . . . 17
       6.2.4.  STATUS-UPDATE  . . . . . . . . . . . . . . . . . . . . 17
       6.2.5.  DE-REGISTRATION  . . . . . . . . . . . . . . . . . . . 18
       6.2.6.  ACK  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.3.  Operation commands . . . . . . . . . . . . . . . . . . . . 19
       6.3.1.  GET Operation  . . . . . . . . . . . . . . . . . . . . 19
       6.3.2.  ADD Operation  . . . . . . . . . . . . . . . . . . . . 19
       6.3.3.  DELETE Operation . . . . . . . . . . . . . . . . . . . 20
       6.3.4.  MOVE Operation . . . . . . . . . . . . . . . . . . . . 20
       6.3.5.  COPY Operation . . . . . . . . . . . . . . . . . . . . 21
       6.3.6.  MOVE_SESSION Operation . . . . . . . . . . . . . . . . 22
     6.4.  Option values  . . . . . . . . . . . . . . . . . . . . . . 22
       6.4.1.  IPv4 address . . . . . . . . . . . . . . . . . . . . . 22
       6.4.2.  IPv6 address . . . . . . . . . . . . . . . . . . . . . 23
       6.4.3.  Port number  . . . . . . . . . . . . . . . . . . . . . 23
       6.4.4.  Node ID  . . . . . . . . . . . . . . . . . . . . . . . 23
       6.4.5.  Function ID  . . . . . . . . . . . . . . . . . . . . . 23
       6.4.6.  Node information . . . . . . . . . . . . . . . . . . . 23
       6.4.7.  Function information . . . . . . . . . . . . . . . . . 24
       6.4.8.  Session information  . . . . . . . . . . . . . . . . . 24
       6.4.9.  Vendor-specific information  . . . . . . . . . . . . . 25
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative references . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative references . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30











Yokota, et al.           Expires August 15, 2011                [Page 3]


Internet-Draft       Virtualized Service Management        February 2011


1.  Requirements notation

   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 [RFC2119].














































Yokota, et al.           Expires August 15, 2011                [Page 4]


Internet-Draft       Virtualized Service Management        February 2011


2.  Introduction

   There is a growing consensus that a significant number of services
   will be delivered using a cloud-computing model.  These applications
   and services will be hosted in data centers located in various parts
   of the network.  New services will be instantiated by deploying a
   service delivery system in a dynamic manner such that the network and
   data center resources are allocated dynamically.

   At the same time, telecom networks are moving toward all-IP based
   systems such as 3GPP SAE (System Architecture Evolution), IMS (IP
   Multimedia Subsystem) and SDP (Service Delivery Platform), whereby
   the transport and services are being handled by IP technology.  These
   systems are composed of a number of components or functional entities
   connected with each other, which makes the whole telecom network even
   more complex.  Wide variety of services ranging from conventional
   voice, gaming to Web2.0 type of ones such SNS (Social Network
   Service), are being introduced and the number of users is also
   dynamically changes.  In such environments, the telecom network needs
   to scale on demand with efficient use of infrastructure as well as to
   improve reliability and availability.

   It is imperative that such ever-evolving new services be seen by the
   user as having no delay and can be accessed from anywhere with high
   reliability.  If service components or functional entities in the
   telecom networks (e.g., call control function or policy control
   function) can be located and moved without any topological or
   geographical constraint, higher reliability can be achieved than
   conventional redundancy systems.  By tapping into cloud-computing
   technology, telecom network deployed in a virtualized environment (or
   virtualized telecom network), will be able to scale telecom services
   on demand, to improve reliability and availability and to efficiently
   use the infrastructure [IMSAA09].  One of the key features provided
   by the virtualized telecom network is service mobility.  A general
   property of service mobility is to ensure it is transparent to
   service user, that is, the on-going service must be continued in a
   transparent manner and existing protocols or interfaces should not be
   affected.

   This document provides the reference model for service mobility in a
   virtual environment and defines the control protocol between the
   virtualized platform (e.g., virtual machines) and the managing
   controller to enable service mobility.








Yokota, et al.           Expires August 15, 2011                [Page 5]


Internet-Draft       Virtualized Service Management        February 2011


3.  Overview and Terminology

   The components in the virtualized network include "Manager Node",
   "Execution Node" and optional "Information Server".  The management
   role for the Execution Nodes can be realized in both a centralized
   way as well as a distributed (Peer-to-peer) way.  The Execution Node
   is a physical or virtual machine on which target functions (software)
   are running.  For example, in the context of IMS (IP Multimedia
   Subsystem), the CSCF (Call Session Control Function) and HSS (Home
   Subscriber Server) are candidates of such functions.  Information
   servers include DHCP, DNS, etc. used for discovery and assignment of
   Execution Nodes for hosting these IMS functions (Proxy-CSCF at a UE's
   registration).

   Execution Node:
        Logical entity that can execute functions.  A well-know example
        is a virtual machine or VM.

   Manager Node:
        Logical entity that manages functions running on the execution
        nodes.
        [Editor's Note] Should the Manager of Managers (hierarchical
        structure for Manager Nodes) be included in the architecture?

   Information Server:
        Logical entity used for discovery of Manager Node or Execution
        Node via IETF standardized protocols (e.g., DNS server or DHCP
        server).  This entity and the mechanisms of discovery are so far
        outside the scope of this document's specifications.

   Function:
        Logical unit that provides a specific service such as
        "authentication" or "call control"

   Session:
        Relationship between functions providing a specific service.
        Each function maintains a state related to the session.

   Service mobility:
        Capability to move function(s) among Execution Nodes with
        maintaining the ongoing service.

   Node ID:
        Uniquely identifies the execution node, which provided and
        managed by the manager node.






Yokota, et al.           Expires August 15, 2011                [Page 6]


Internet-Draft       Virtualized Service Management        February 2011


   Function ID:
        Uniquely identifies the function, which is provided and managed
        by the manager node.

   The reference model for service mobility is shown in Figure 1.  The
   service user on the upper layer utilizes service units provided by
   the service provider via the service access point (SAP).  By
   interacting with the management plane, the service unit may move its
   physical or topological location.  This movement must be transparent
   to the service user meaning that the on-going service must be
   continued.  Existing protocols and interfaces should not be affected
   by this capability.

             +-----------------------------------+    +-------+
             |                                   |    |       |
             |            Service User           |    |       |
             |                                   |    |       |
             |             |       |             |    |Service|
             +-------------|  SAP  |-------------+    |  Mgmt |
             |             |       |             |    |       |
             |+-------+ +-------+       +-------+|    |       |
             ||Service| |Service| <...> |Service||<==>|       |
             || Unit  | |  Unit |       |  Unit ||    |       |
             |+-------+ +-------+       +-------+|    |       |
             |          Service Provider         |    |       |
             +-----------------------------------+    +-------+

                         Figure 1: Reference model

   Service mobility in the virtual environment is depicted in Figure 2.
   The virtual environment provides the capability to move Execution
   Nodes among physical hardware.  An Execution Node can run on one
   physical hardware unit (e.g., a server machine) or on multiple
   hardware units.  How the virtual environment is provided is outside
   the scope of this document.  Functions run on the Execution Nodes and
   one or more session(s) may be established with the corresponding
   status information.  When functions and/or sessions move from one
   Execution Node to another, consistency in the status information must
   be maintained to continue the sessions.












Yokota, et al.           Expires August 15, 2011                [Page 7]


Internet-Draft       Virtualized Service Management        February 2011


                   ^            Session              ^
                   *       *******************      *
             +-----*------*-----+ +---------*-----*-----------+
             |  (Status)  *     | |      (Status)*            |
             |    +-*+   *      | |   +--+ +*-+ *   +--+      |
             |    |FN|*** <.........> |FN| |FN|*    |FN|      |
             |    +--+          | |   +--+ +--+     +--+      |
             | +-------------+  | |  +---------+ +---------+  |
             | |  Execution  |  | |  |Execution| |Execution|  |
             | |Node(e.g.,VM)|  | |  |  Node   | |  Node   |  |
             | +-------------+  | |  +---------+ +---------+  |
             +------------------+ +---------------------------+
                           ^            ^
                           |            |
                          Physical hardware

             FN=Function
             VM=Virtual Machine

             Figure 2: Service mobility in virtual environment

   The roles of the Manager Node and Execution Nodes and their
   relationship are depicted in Figure 3.  The Manager Node communicates
   with the Execution Nodes to control the mobility of functions.  The
   Manager Node can be deployed in a centralized or distributed fashion.
   Physical limitations (CPU, Memory, Bandwidth, etc.) may occur if the
   number of nodes managed by a single physical server is large.  The
   physical entities comprising the Manager Node may distribute the
   management functions among themselves; however, that must be
   transparent to the execution nodes.  The Execution Nodes communicate
   with each other to move functions between the nodes.  An external
   information server or repository may be involved to support those
   nodes to discover other nodes.  The main focus of this document is
   the control protocol between the Manager Node and execution nodes.

















Yokota, et al.           Expires August 15, 2011                [Page 8]


Internet-Draft       Virtualized Service Management        February 2011


                             +-------------+        .............
                             |   Manager   |<......>:Information:
                             |     Node    |        :  Server   :
                             +-------------+        :...........:
                                /      \                   ^
                               /        \                  :
                              v          v                 :
                        +---------+   +---------+          :
                        |Execution|   |Execution|<.........:
                        |  Node   |   |  Node   |
                        +---------+   +---------+
                            ^              ^
                            :..............:

            Figure 3: Roles and relationship between components




































Yokota, et al.           Expires August 15, 2011                [Page 9]


Internet-Draft       Virtualized Service Management        February 2011


4.  Service Mobility Requirements

   This section describes the functional requirements to realize service
   mobility in a virtualized environment.  In the virtualized
   environment there are multiple Execution Nodes with multiple
   Functions on each Node, service sessions are set up by utilizing
   these Functions.  A Manager Node is used to enable service mobility
   for the session in this virtualized environment where Execution Nodes
   and Functions can be dynamically added, deleted, re-allocated and
   migrated.  The detailed specifications of how the virtualized network
   is provided and how the migration is executed are outside the scope
   of this document.

   o  The Execution Node MUST be able to report the available resources
      (e.g., CPU or memory usage) of its own to the Manager Node.  The
      Execution Node SHOULD be able to obtain statistics on how much
      resources are consumed by each Function and to report them to the
      Manager Node.  The Execution Node SHOULD be able to spontaneously
      report to the Manager Node according to the running condition of
      its own.  The Manager Node MAY use such information for service
      mobility.

   o  Execution Node may migrate to another hardware unit during the
      operation.  The IP address and/or data-link address to reach that
      Execution Node may change due to this migration.  The Manager Node
      MUST be able to identify and keep track of the Execution Node
      wherever it moves.  This requires a unique identifier for each
      Execution Node that is independent of the physical address for
      service mobility.

   o  A service may involve multiple Functions, which establish a
      session to interwork together for initiating and maintaining the
      service.  Service mobility mandates the consistency of a session
      even if some of those Functions migrate to a different Execution
      Node, which could further migrate to a different hardware unit.
      This requires that each session and Function MUST be uniquely
      identified and manipulated by the Manager Node regardless of the
      hardware unit(s) that is/are providing resources.

   o  Security and reliability in communications between the Manager
      Node and Execution Node MUST be provided.  The Manager Node MUST
      be able to control the admission of information exchange between
      Execution Nodes.  In order to support these properties, existing
      architectures and mechanisms (e.g., AAA, IPsec, reliable transport
      protocols) SHOULD be taken into consideration for early adoption
      and deployment.





Yokota, et al.           Expires August 15, 2011               [Page 10]


Internet-Draft       Virtualized Service Management        February 2011


5.  Protocol Operations

   Figure 4 shows the signaling flow between the manager and execution
   nodes.  When the Execution Node boots up, it registers itself with
   the manger node by sending the Registration message.  If the IP
   address of the Manager Node is not known, the Information Server
   SHOULD be used for its discovery.  The Manager Node SHOULD
   periodically check the status of each registered Execution Node by
   sending the Keep-Alive message [Editor's Note: the default interval
   time should be defined].  According to the situation on the execution
   nodes, the Manager Node sends various types of operation commands to
   the execution node.  If the status of the Execution Node changes, it
   sends the Status-Update message to the manager node.  If the
   Execution Node goes out of the scope of the management by the Manager
   Node or is going to be shut down, it sends the De-registration
   message to the manager node.  The Error message is asynchronously
   sent by either node to notify the other peer when an erroneous event
   happens (e.g., when the Manager Node becomes unable to perform the
   management tasks).  For each message, the recipient MUST send back
   the ACK message.

   These signaling messages are conveyed over a reliable transport
   mechanism.
   [Editor's note] It is for further study which transport is used: TCP
   or SCTP or both.


























Yokota, et al.           Expires August 15, 2011               [Page 11]


Internet-Draft       Virtualized Service Management        February 2011


                        Execution                 Manager
                          Node                      Node
                            |                         |
                            |      Registration       |
                            |------------------------>|
                            |          Ack            |
                            |<------------------------|
                            |                         |
                            |       Keep-Alive        |
                            |<------------------------|
                            |          Ack            |
                            |------------------------>|
                            |                         |
                            |     <*> Operation       |
                            |<------------------------|
                            |          Ack            |
                            |------------------------>|
                            |                         |
                            |      Status-Update      |
                            |------------------------>|
                            |          Ack            |
                            |<------------------------|
                            |                         |
                            |      De-registration    |
                            |------------------------>|
                            |          Ack            |
                            |<------------------------|
                            |                         |
                            |         Error           |
                            |<----------------------->|
                            |          Ack            |
                            |<----------------------->|
                            |                         |

     Figure 4: Signaling flow between the manager and execution nodes

   In this document, the following control messages are defined:

   Registration:
        Used for the Execution Node to register itself with the manager
        node, by which the Execution Node goes under the control of the
        manager node.

   Keep-Alive:
        Used for the Manager Node to check the status of the managed
        execution node.





Yokota, et al.           Expires August 15, 2011               [Page 12]


Internet-Draft       Virtualized Service Management        February 2011


   Operation:
        Used for the Manager Node to indicate the Execution Node to do a
        specific action to the function or sessions on that execution
        node.

   Status-Update:
        Used for the Execution Node to notify the Manager Node on the
        updated status.

   De-registration:
        Used for the Execution Node to release the registration from the
        manager node.  The Manager Node can also send this message to
        the Execution Node to force de-registration.

   Ack:
        Used to respond to the above messages for acknowledgment and
        returning requested information and/or status code (success or
        failure).

   Error:
        Asynchronous messaging mechanism that can be initiated by either
        the Manager Node or Execution Node to notify the peer of an
        error condition.

   Further, the following operations are defined:

   GET operation:
        Used for the Manager Node to obtain specific information from
        the target execution node.

   ADD operation:
        Used to instruct the target Execution Node to run a new
        function.

   DELETE operation:
        Used to instruct the target Execution Node to terminate a
        running function.

   MOVE operation:
        Combination of ADD and DELETE operation, but the status
        information on the related function is also passed to a new
        execution node.

   COPY operation:
        Similar to ADD operation, but the status information on the
        related function is also passed to a new execution node.





Yokota, et al.           Expires August 15, 2011               [Page 13]


Internet-Draft       Virtualized Service Management        February 2011


   MOVE_SESSION operation:
        Used to instruct the target Execution Node to move sessions to
        another execution node.

   These control messages are conveyed over a reliable transport
   mechanism.
   [Editor's note] It is for further study which transport is used: TCP
   or SCTP or both.











































Yokota, et al.           Expires August 15, 2011               [Page 14]


Internet-Draft       Virtualized Service Management        February 2011


6.  Message Format

6.1.  Common header format

   Figure 5 shows the common header format for all messages.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |   Sub-Type    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Code     |                Sequence Number                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                            Options                            :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |

                      Figure 5: Common header format

   Type

             Control message type.  In this document, the following
             operations are defined: Registration (1)/Keep-alive
             (2)/Operation (3)/Status-Update (4)/De-registration (5)/Ack
             (6).

   Sub-Type

             If the Type value is 3 (Operation) or 6 (Ack), the Sub-type
             represents the operation command.  Otherwise, this value
             MUST be zero and ignored by the receiver.

   Length

             16-bit unsigned integer indicating the length of the whole
             message in octets, excluding the type and length fields.

   Code

             An 8-bit unsigned integer used for containing the status
             code in the Ack message.  For the other message, this field
             MUST be filled with zero and ignored by the receiver.





Yokota, et al.           Expires August 15, 2011               [Page 15]


Internet-Draft       Virtualized Service Management        February 2011


   Sequence Number

             A 24-bit unsigned integer used by the receiving node to
             sequence the operation command and by the sending node to
             match a returned Acknowledgement with this operation
             command.

   Options

             Variable-length field that contains a command message
             and/or one or more option(s).

   Figure 6 shows the TLV-encoded option format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     OP-Type   |  Sub-OP-Type  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                             Value                             :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 6: Option format

   OP-Type

             8-bit unsigned integer indicating the type of the option
             value.

   Sub-OP-Type

             8-bit unsigned integer indicating the sub-type of the
             option value.  MUST be set to zero if not defined.

   Length

             16-bit unsigned integer indicating the length of the option
             in octets, excluding the OP-Type, Sub-OP-Type and Length
             fields.

   Value

             value for the specified option type is contained.






Yokota, et al.           Expires August 15, 2011               [Page 16]


Internet-Draft       Virtualized Service Management        February 2011


6.2.  Control messages

6.2.1.  REGISTRATION

   Type: 1

   Mandatory options:

      o Node ID

   Additional options:

      o Node Information

6.2.2.  KEEP-ALIVE

   Type: 2

   Mandatory options:

      o  Node ID

   Additional options:

      o  Node Information

      o  Function ID

      o  Function Information

6.2.3.  OPERATION

   Type: 3

   Sub-Type: Requested operation (See Section 6.3)

   Mandatory options:

      o  Node ID

6.2.4.  STATUS-UPDATE

   Type: 4

   Mandatory options:






Yokota, et al.           Expires August 15, 2011               [Page 17]


Internet-Draft       Virtualized Service Management        February 2011


      o  Node ID

   Additional options:

      o  Node Information

      o  Function ID

      o  Function Information

6.2.5.  DE-REGISTRATION

   Type: 5

   Mandatory options:

      o  Node ID

6.2.6.  ACK

   Type: 6

   Sequence number: MUST be copied from the corresponding control
   message.

   Sub-Type: MUST be copied from the corresponding control message.

   Code: Result code for the requested operation.  In this document, the
   following code values are defined:

             0: Successful

             128: Failed

             129: Insufficient resources

             130: Administratively prohibited

             131: Status unknown

   Mandatory options:

      o  Node ID

   The Vendor-specific information option can be used to convey more
   detailed information, for example, to notify the sender about the
   reason for the failure.




Yokota, et al.           Expires August 15, 2011               [Page 18]


Internet-Draft       Virtualized Service Management        February 2011


6.3.  Operation commands

6.3.1.  GET Operation

   Type: 3

   Sub-Type: 1

   Mandatory options:

      o Node ID

      o Function ID

      o List of options (with zero values in the value field)

   Expected options in ACK:

      o Node ID

      o Function ID

      o List of options (with non-zero values in the value field)

      o Result Code

      o Running Status

6.3.2.  ADD Operation

   Type: 3

   Sub-Type: 2

   Mandatory options:

      o  Node ID

      o  Function ID

   Some function takes time to boot up, thus when it successfully booted
   up, the Execution Node sends Status-update message to the manager
   node.

   Expected options in ACK:






Yokota, et al.           Expires August 15, 2011               [Page 19]


Internet-Draft       Virtualized Service Management        February 2011


      o  Node ID

      o  Function ID

      o  Result Code

      o  Running Status

6.3.3.  DELETE Operation

   Type: 3

   Sub-Type: 3

   Mandatory options:

      o  Node ID

      o  Function ID

   Expected options in ACK:

      o  Node ID

      o  Function ID

      o  Result Code

      o  Running Status

   Some function takes time to terminate, thus when termination is
   completed, the Execution Node sends Status update message to the
   manager node.

6.3.4.  MOVE Operation

   Type: 3

   Sub-Type: 4

   Mandatory options:

      o  Source Node ID

      o  Destination Node ID






Yokota, et al.           Expires August 15, 2011               [Page 20]


Internet-Draft       Virtualized Service Management        February 2011


      o  Function ID

   Expected options in ACK:

      o  Source Node ID

      o  Destination Node ID

      o  Function ID

      o  Result Code

      o  Running Status

   The source Node ID and destination Node ID MUST be listed in this
   order.

6.3.5.  COPY Operation

   Type: 3

   Sub-Type: 5

   Mandatory options:

      o  Source Node ID

      o  Destination Node ID

      o  Function ID

   Expected options in ACK:

      o  Source Node ID

      o  Destination Node ID

      o  Function ID

      o  Result Code

      o  Running Status

   The source Node ID and destination Node ID MUST be listed in this
   order.






Yokota, et al.           Expires August 15, 2011               [Page 21]


Internet-Draft       Virtualized Service Management        February 2011


6.3.6.  MOVE_SESSION Operation

   Type: 3

   Sub-Type: 6

   Mandatory options:

      o  Source Node ID

      o  Destination Node ID

      o  Session information

   Additional options:

      o Function ID

   Expected options in ACK:

      o  Function ID, if specified in the corresponding operation
      command.

      o  Result Code

      o  Running Status

   The source Node ID and destination Node ID MUST be listed in this
   order.  When Function ID is specified, all the sessions related to
   that Function ID are the target for movement.

6.4.  Option values

   In this document, the following attributes are defined.  Sub-OP-type
   MUST be set zero if not defined.

6.4.1.  IPv4 address

   OP-Type: 1

   Length: 4

   Value: Unsigned integer.  IPv4 address (e.g., for the target
   execution node)







Yokota, et al.           Expires August 15, 2011               [Page 22]


Internet-Draft       Virtualized Service Management        February 2011


6.4.2.  IPv6 address

   OP-Type: 2

   Length: 16

   value: Unsigned integer.  IPv6 address (e.g., for the target
   execution node)

6.4.3.  Port number

   OP-Type: 3

   Length: 2

   value: Unsigned integer.  Port number (e.g., for the target session)

6.4.4.  Node ID

   OP-Type: 4

   Length: 4

   Value: Unsigned integer.  Node ID for the target Execution Node

6.4.5.  Function ID

   OP-Type: 5

   Length: 4

   Value: Unsigned integer.  Function ID for the target function

6.4.6.  Node information

   OP-Type: 6

   Length: variable

   Value: Octet string.  Node information specified by the Sub-OP-Type.
   In this document, the following types are defined:

   Sub-OP-Type
        1: Processing capacity (GHz)
        2: Current load (number of waiting processes)
        3: Average load (number of waiting processes)
        10: Total memory size (byte)
        11: Available memory size (byte)



Yokota, et al.           Expires August 15, 2011               [Page 23]


Internet-Draft       Virtualized Service Management        February 2011


        20: Total storage size (byte)
        21: Available storage size (byte)
        30: Total bandwidth (bps)
        31: Current used bandwidth (bps)
        32: Average used bandwidth (bps)
        40: Boot time (NTP timestamp format)

6.4.7.  Function information

   OP-Type: 7

   Length: variable

   Value: Octet string.  Used to describe the type or status of the
   function.  In this document, the following values are defined:

   Sub-OP-Type
        1: Function name (e.g., "P-CSCF" or "HSS")
        2: Current load (number of waiting processes)
        3: Average load (number of waiting processes)
        10: Required memory size (byte)
        11: Available memory size (byte)
        20: Required storage size (byte)
        21: Available storage size (byte)
        31: Current used bandwidth (bps)
        32: Average used bandwidth (bps)
        40: Boot time (NTP timestamp format)
        50: Running status ("Starting", "Running", "Terminating" or
        "Unknown")

6.4.8.  Session information

   OP-Type: 8

   Length: variable

   Value: Octet string to represent one or group of session(s).  This
   value MUST be understood by both the manager and execution nodes.  In
   this document, the following values are defined:

   Sub-OP-Type
        1: SIP URI (e.g., sip:alice@example.com)
        2: Contact address (IPv4 or v6 address)
        3: the ratio to the whole sessions (e.g., 0.3)
        4: the number of sessions (e.g., 1000)






Yokota, et al.           Expires August 15, 2011               [Page 24]


Internet-Draft       Virtualized Service Management        February 2011


6.4.9.  Vendor-specific information

   OP-Type: 9

   Length: variable

   Value: Octet string to convey vendor-specific information.  This
   value MUST be understood by both the Manager and Execution Nodes.  In
   this document, the following value is defined:

   Sub-OP-Type
        1: Information message (e.g., "Protocol error")







































Yokota, et al.           Expires August 15, 2011               [Page 25]


Internet-Draft       Virtualized Service Management        February 2011


7.  IANA Considerations

   This specification requests one TCP and SCTP port number for
   exchanging the defined control messages.















































Yokota, et al.           Expires August 15, 2011               [Page 26]


Internet-Draft       Virtualized Service Management        February 2011


8.  Security Considerations

   It is assumed that necessary level of security between the Manager
   Node and Execution Nodes is provided by other means and a secure
   connection between them is not mandated in this document.














































Yokota, et al.           Expires August 15, 2011               [Page 27]


Internet-Draft       Virtualized Service Management        February 2011


9.  Acknowledgments

   The authors would like to thank Christian Makaya for his valuable
   comments to and reviews of this document.















































Yokota, et al.           Expires August 15, 2011               [Page 28]


Internet-Draft       Virtualized Service Management        February 2011


10.  References

10.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative references

   [IMSAA09]  Dutta, A., Makaya, C., Das, S., Chee, D., Lin, F.,
              Komorita, S., Chiba, T., Yokota, H., and H. Schulzrinne,
              "Self Organizing IP Multimedia Subsystem", IEEE IMSAA,
              December 2009.






































Yokota, et al.           Expires August 15, 2011               [Page 29]


Internet-Draft       Virtualized Service Management        February 2011


Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama, 356-8502
   JP

   Email: yokota@kddilabs.jp


   Fuchun J. Lin
   Telcordia Technologies
   One Telcordia Drive
   Piscataway, NJ 08854-4157
   US

   Email: fjlin@research.telcordia.com


   Ashutosh Dutta
   NIKSUN
   100 Nassau Park Boulevard, Princeton, NJ
   08540
   US

   Email: ashutosh.dutta@ieee.org


   Carl Williams
   MCSR Labs
   Palo Alto, CA
   94306
   US

   Email: carlw@mcsr-labs.org


   Vishwas Manral
   IPInfusion Inc.
   1188 E. Arques Ave.
   Sunnyvale, CA  94085
   US

   Phone: 408-400-1900
   Email: vishwas@ipinfusion.com





Yokota, et al.           Expires August 15, 2011               [Page 30]