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]