idnits 2.17.1 draft-yokota-opsawg-virtnw-service-management-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2011) is 4574 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Standards Track F. J. Lin 5 Expires: April 20, 2012 Telcordia Technologies 6 A. Dutta 7 NIKSUN 8 C. Williams 9 MCSR Labs 10 V. Manral 11 IPInfusion Inc. 12 October 18, 2011 14 Managing Service Mobility for Virtualized Networks 15 draft-yokota-opsawg-virtnw-service-management-02.txt 17 Abstract 19 In virtualized networks, machines with processing and storage are 20 virtualized resources on which network functional entities can be 21 allocated and relocated dynamically. Such dynamic allocation and 22 relocation of network entities imposes the challenge of service 23 mobility, i.e., how to maintain not only coupling relations between 24 those network entities but also sessions established between those 25 entities in a virtualized environment. This document provides a 26 reference model for managing service mobility in the virtual 27 environment and defines the control protocol between the virtualized 28 platform and the managing controller to realize service mobility. 29 Such capability is especially longed for realizing more scalable and 30 reliable telecom networks. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 20, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Overview and Terminology . . . . . . . . . . . . . . . . . . . 6 81 4. Service Mobility Requirements . . . . . . . . . . . . . . . . 10 82 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 11 83 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.1. Common header format . . . . . . . . . . . . . . . . . . . 15 85 6.2. Control messages . . . . . . . . . . . . . . . . . . . . . 17 86 6.2.1. REGISTRATION . . . . . . . . . . . . . . . . . . . . . 17 87 6.2.2. KEEP-ALIVE . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2.3. OPERATION . . . . . . . . . . . . . . . . . . . . . . 17 89 6.2.4. STATUS-UPDATE . . . . . . . . . . . . . . . . . . . . 17 90 6.2.5. DE-REGISTRATION . . . . . . . . . . . . . . . . . . . 18 91 6.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 6.3. Operation commands . . . . . . . . . . . . . . . . . . . . 19 93 6.3.1. GET Operation . . . . . . . . . . . . . . . . . . . . 19 94 6.3.2. ADD Operation . . . . . . . . . . . . . . . . . . . . 19 95 6.3.3. DELETE Operation . . . . . . . . . . . . . . . . . . . 20 96 6.3.4. MOVE Operation . . . . . . . . . . . . . . . . . . . . 20 97 6.3.5. COPY Operation . . . . . . . . . . . . . . . . . . . . 21 98 6.3.6. MOVE_SESSION Operation . . . . . . . . . . . . . . . . 22 99 6.4. Option values . . . . . . . . . . . . . . . . . . . . . . 22 100 6.4.1. IPv4 address . . . . . . . . . . . . . . . . . . . . . 22 101 6.4.2. IPv6 address . . . . . . . . . . . . . . . . . . . . . 23 102 6.4.3. Port number . . . . . . . . . . . . . . . . . . . . . 23 103 6.4.4. Node ID . . . . . . . . . . . . . . . . . . . . . . . 23 104 6.4.5. Function ID . . . . . . . . . . . . . . . . . . . . . 23 105 6.4.6. Node information . . . . . . . . . . . . . . . . . . . 23 106 6.4.7. Function information . . . . . . . . . . . . . . . . . 24 107 6.4.8. Session information . . . . . . . . . . . . . . . . . 24 108 6.4.9. Vendor-specific information . . . . . . . . . . . . . 25 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 111 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 10.1. Normative references . . . . . . . . . . . . . . . . . . . 29 114 10.2. Informative references . . . . . . . . . . . . . . . . . . 29 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 117 1. Requirements notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Introduction 125 There is a growing consensus that a significant number of services 126 will be delivered using a virtualized network. These applications 127 and services will be hosted in data centers located in various parts 128 of the network. New services will be instantiated by deploying a 129 service delivery system when needed such that the network and data 130 center resources are allocated dynamically. 132 At the same time, telecom networks are moving toward all-IP based 133 systems such as 3GPP SAE (System Architecture Evolution), IMS (IP 134 Multimedia Subsystem) and SDP (Service Delivery Platform), whereby 135 the transport and services are being handled by IP technology. These 136 systems are composed of a number of components or functional entities 137 closely coupled with each other, which makes the whole telecom 138 network even more complex. Wide variety of services ranging from 139 conventional voice, gaming to Web2.0 type of ones such SNS (Social 140 Networking Service), are being introduced and the number of users 141 also dynamically changes. In such environments, the telecom network 142 needs to scale on demand with efficient use of infrastructure as well 143 as to improve reliability and availability. 145 It is imperative that such ever-evolving new services be seen by the 146 user as having no delay and can be accessed from anywhere with high 147 reliability. If service components or functional entities in the 148 telecom networks (e.g., call control function or policy control 149 function) can be located and moved without any topological or 150 geographical constraint, higher reliability can be achieved than 151 conventional redundancy systems. By tapping into network 152 virtualization technology, telecom network deployed in a virtualized 153 environment (or virtualized telecom network), will be able to scale 154 telecom services on demand, to improve reliability and availability 155 and to efficiently use the infrastructure [IMSAA09]. One of the key 156 features provided by the virtualized telecom network is service 157 mobility. A general property of service mobility is to ensure 158 service location is transparent to service user, that is, the on- 159 going service must be continued in a transparent manner no matter 160 where it is allocated and existing protocols or interfaces used by 161 the service should not be affected. 163 This document provides a reference model for managing service 164 mobility in a virtual environment and defines the control protocol 165 between the virtualized platform (e.g., virtual machines) and the 166 managing controller to enable service mobility. 168 3. Overview and Terminology 170 The components in the virtualized network include "Manager Node", 171 "Execution Node" and optional "Information Server". The management 172 role for the Execution Nodes can be realized in both a centralized 173 way as well as a distributed (Peer-to-peer) way. The Execution Node 174 is a physical or virtual machine on which target functions (software) 175 are running. For example, in the context of IMS (IP Multimedia 176 Subsystem), the CSCF (Call Session Control Function) and HSS (Home 177 Subscriber Server) are candidates of such functions. Information 178 servers include DHCP, DNS, etc. used for discovery and assignment of 179 Execution Nodes for hosting these IMS functions (Proxy-CSCF at a UE's 180 registration). 182 Execution Node: 183 Logical entity that can execute functions. A well-known example 184 is a virtual machine or VM. 186 Manager Node: 187 Logical entity that manages functions running on the execution 188 nodes. 189 [Editor's Note] It is for further study if the Manager of 190 Managers (hierarchical structure for Manager Nodes) should be 191 included in the architecture. 193 Information Server: 194 Logical entity used for discovery of Manager Node or Execution 195 Node via IETF standardized protocols (e.g., DNS server or DHCP 196 server). This entity and the mechanisms of discovery are so far 197 outside the scope of this document's specifications. 199 Function: 200 Logical unit that provides a specific service such as 201 "authentication" or "call control" 203 Session: 204 Relationship between functions providing a specific service. 205 Each function maintains a state related to the session. 207 Service mobility: 208 Capability to move function(s) among Execution Nodes while 209 maintaining the ongoing service. 211 Node ID: 212 Uniquely identifies the execution node, which is provided and 213 managed by the manager node. 215 Function ID: 216 Uniquely identifies the function, which is provided and managed 217 by the manager node. 219 The reference model for service mobility is shown in Figure 1. The 220 service user on the upper layer utilizes service units provided by 221 the service provider via the service access point (SAP). By 222 interacting with the management plane, the service unit may move its 223 physical or topological location. This movement must be transparent 224 to the service user meaning that the on-going service must be 225 continued. Existing protocols and interfaces should not be affected 226 by this capability. 228 +-----------------------------------+ +-------+ 229 | | | | 230 | Service User | | | 231 | | | | 232 | | | | |Service| 233 +-------------| SAP |-------------+ | Mgmt | 234 | | | | | | 235 |+-------+ +-------+ +-------+| | | 236 ||Service| |Service| <...> |Service||<==>| | 237 || Unit | | Unit | | Unit || | | 238 |+-------+ +-------+ +-------+| | | 239 | Service Provider | | | 240 +-----------------------------------+ +-------+ 242 Figure 1: Reference model 244 Service mobility in the virtual environment is depicted in Figure 2. 245 The virtual environment provides the capability to move Execution 246 Nodes among physical hardware. An Execution Node can run on one 247 physical hardware unit (e.g., a server machine) or on multiple 248 hardware units. How the virtual environment is provided is outside 249 the scope of this document. Functions run on the Execution Nodes and 250 one or more session(s) may be established with the corresponding 251 status information. When functions and/or sessions move from one 252 Execution Node to another, consistency in the status information must 253 be maintained to continue the sessions. 255 ^ Session ^ 256 * ******************* * 257 +-----*------*-----+ +---------*-----*-----------+ 258 | (Status) * | | (Status)* | 259 | +-*+ * | | +--+ +*-+ * +--+ | 260 | |FN|*** <.........> |FN| |FN|* |FN| | 261 | +--+ | | +--+ +--+ +--+ | 262 | +-------------+ | | +---------+ +---------+ | 263 | | Execution | | | |Execution| |Execution| | 264 | |Node(e.g.,VM)| | | | Node | | Node | | 265 | +-------------+ | | +---------+ +---------+ | 266 +------------------+ +---------------------------+ 267 ^ ^ 268 | | 269 Physical hardware 271 FN=Function 272 VM=Virtual Machine 274 Figure 2: Service mobility in virtual environment 276 The roles of the Manager Node and Execution Nodes and their 277 relationship are depicted in Figure 3. The Manager Node communicates 278 with the Execution Nodes to control the mobility of functions. The 279 Manager Node can be deployed in a centralized or distributed fashion. 280 Physical limitations (CPU, Memory, Bandwidth, etc.) may occur if the 281 number of nodes managed by a single physical server is large. The 282 physical entities comprising the Manager Node may distribute the 283 management functions among themselves; however, that must be 284 transparent to the execution nodes. The Execution Nodes communicate 285 with each other to move functions between the nodes. An external 286 information server or repository may be involved to support those 287 nodes to discover other nodes. The main focus of this document is 288 the control protocol between the Manager Node and execution nodes. 290 +-------------+ ............. 291 | Manager |<......>:Information: 292 | Node | : Server : 293 +-------------+ :...........: 294 / \ ^ 295 / \ : 296 v v : 297 +---------+ +---------+ : 298 |Execution| |Execution|<.........: 299 | Node | | Node | 300 +---------+ +---------+ 301 ^ ^ 302 :..............: 304 Figure 3: Roles and relationship between components 306 4. Service Mobility Requirements 308 This section describes the functional requirements to realize service 309 mobility in a virtualized environment. In the virtualized 310 environment there are multiple Execution Nodes with multiple 311 Functions on each Node, service sessions are set up by utilizing 312 these Functions. A Manager Node is used to enable service mobility 313 for the session in this virtualized environment where Execution Nodes 314 and Functions can be dynamically added, deleted, re-allocated and 315 migrated. The detailed specifications of how the virtualized network 316 is provided and how the migration is executed are outside the scope 317 of this document. 319 o The Execution Node MUST be able to report the available resources 320 (e.g., CPU or memory usage) of its own to the Manager Node. The 321 Execution Node SHOULD be able to obtain statistics on how much 322 resources are consumed by each Function and to report them to the 323 Manager Node. The Execution Node SHOULD be able to spontaneously 324 report to the Manager Node according to the running condition of 325 its own. The Manager Node MAY use such information for service 326 mobility. 328 o Execution Node may migrate to another hardware unit during the 329 operation. The IP address and/or data-link address to reach that 330 Execution Node may change due to this migration. The Manager Node 331 MUST be able to identify and keep track of the Execution Node 332 wherever it moves. This requires a unique identifier for each 333 Execution Node that is independent of the physical address for 334 service mobility. 336 o A service may involve multiple Functions, which establish a 337 session to interwork together for initiating and maintaining the 338 service. Service mobility mandates the consistency of a session 339 even if some of those Functions migrate to a different Execution 340 Node, which could further migrate to a different hardware unit. 341 This requires that each session and Function MUST be uniquely 342 identified and manipulated by the Manager Node regardless of the 343 hardware unit(s) that is/are providing resources. 345 o Security and reliability in communications between the Manager 346 Node and Execution Node MUST be provided. The Manager Node MUST 347 be able to control the admission of information exchange between 348 Execution Nodes. In order to support these properties, existing 349 architectures and mechanisms (e.g., AAA, IPsec, reliable transport 350 protocols) SHOULD be taken into consideration for early adoption 351 and deployment. 353 5. Protocol Operations 355 Figure 4 shows the signaling flow between the manager and execution 356 nodes. When the Execution Node boots up, it registers itself with 357 the manger node by sending the Registration message. If the IP 358 address of the Manager Node is not known, the Information Server 359 SHOULD be used for its discovery. The Manager Node SHOULD 360 periodically check the status of each registered Execution Node by 361 sending the Keep-Alive message [Editor's Note: the default interval 362 time should be defined]. According to the situation on the execution 363 nodes, the Manager Node sends various types of operation commands to 364 the execution node. If the status of the Execution Node changes, it 365 sends the Status-Update message to the manager node. If the 366 Execution Node goes out of the scope of the management by the Manager 367 Node or is going to be shut down, it sends the De-registration 368 message to the manager node. The Error message is asynchronously 369 sent by either node to notify the other peer when an erroneous event 370 happens (e.g., when the Manager Node becomes unable to perform the 371 management tasks). For each message, the recipient MUST send back 372 the ACK message. These signaling messages are conveyed over a 373 reliable transport mechanism. The Manager Node and Execution Node 374 MUST support TCP and SHOULD support SCTP. 376 Execution Manager 377 Node Node 378 | | 379 | Registration | 380 |------------------------>| 381 | Ack | 382 |<------------------------| 383 | | 384 | Keep-Alive | 385 |<------------------------| 386 | Ack | 387 |------------------------>| 388 | | 389 | <*> Operation | 390 |<------------------------| 391 | Ack | 392 |------------------------>| 393 | | 394 | Status-Update | 395 |------------------------>| 396 | Ack | 397 |<------------------------| 398 | | 399 | De-registration | 400 |------------------------>| 401 | Ack | 402 |<------------------------| 403 | | 404 | Error | 405 |<----------------------->| 406 | Ack | 407 |<----------------------->| 408 | | 410 Figure 4: Signaling flow between the manager and execution nodes 412 In this document, the following control messages are defined: 414 Registration: 415 Used for the Execution Node to register itself with the manager 416 node, by which the Execution Node goes under the control of the 417 manager node. 419 Keep-Alive: 420 Used for the Manager Node to check the status of the managed 421 execution node. 423 Operation: 424 Used for the Manager Node to indicate the Execution Node to do a 425 specific action to the function or sessions on that execution 426 node. 428 Status-Update: 429 Used for the Execution Node to notify the Manager Node on the 430 updated status. 432 De-registration: 433 Used for the Execution Node to release the registration from the 434 manager node. The Manager Node can also send this message to 435 the Execution Node to force de-registration. 437 Ack: 438 Used to respond to the above messages for acknowledgment and 439 returning requested information and/or status code (success or 440 failure). 442 Error: 443 Asynchronous messaging mechanism that can be initiated by either 444 the Manager Node or Execution Node to notify the peer of an 445 error condition. 447 Further, the following operations are defined: 449 GET operation: 450 Used for the Manager Node to obtain specific information from 451 the target execution node. 453 ADD operation: 454 Used to instruct the target Execution Node to run a new 455 function. 457 DELETE operation: 458 Used to instruct the target Execution Node to terminate a 459 running function. 461 MOVE operation: 462 Combination of ADD and DELETE operation, but the status 463 information on the related function is also passed to a new 464 execution node. 466 COPY operation: 467 Similar to ADD operation, but the status information on the 468 related function is also passed to a new execution node. 470 MOVE_SESSION operation: 471 Used to instruct the target Execution Node to move sessions to 472 another execution node. 474 These control messages are conveyed over a reliable transport 475 mechanism. The Manager Node and Execution Node MUST support TCP and 476 SHOULD support SCTP. 478 6. Message Format 480 6.1. Common header format 482 Figure 5 shows the common header format for all messages. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type | Sub-Type | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Code | Sequence Number | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 : Options : 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 : ... : 497 | | 499 Figure 5: Common header format 501 Type 503 Control message type. In this document, the following 504 operations are defined: Registration (1)/Keep-alive 505 (2)/Operation (3)/Status-Update (4)/De-registration (5)/Ack 506 (6). 508 Sub-Type 510 If the Type value is 3 (Operation) or 6 (Ack), the Sub-type 511 represents the operation command. Otherwise, this value 512 MUST be zero and ignored by the receiver. 514 Length 516 16-bit unsigned integer indicating the length of the whole 517 message in octets, excluding the type and length fields. 519 Code 521 An 8-bit unsigned integer used for containing the status 522 code in the Ack message. For the other message, this field 523 MUST be filled with zero and ignored by the receiver. 525 Sequence Number 527 A 24-bit unsigned integer used by the receiving node to 528 sequence the operation command and by the sending node to 529 match a returned Acknowledgement with this operation 530 command. 532 Options 534 Variable-length field that contains a command message 535 and/or one or more option(s). 537 Figure 6 shows the TLV-encoded option format: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | OP-Type | Sub-OP-Type | Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 : Value : 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 6: Option format 551 OP-Type 553 8-bit unsigned integer indicating the type of the option 554 value. 556 Sub-OP-Type 558 8-bit unsigned integer indicating the sub-type of the 559 option value. MUST be set to zero if not defined. 561 Length 563 16-bit unsigned integer indicating the length of the option 564 in octets, excluding the OP-Type, Sub-OP-Type and Length 565 fields. 567 Value 569 value for the specified option type is contained. 571 6.2. Control messages 573 6.2.1. REGISTRATION 575 Type: 1 577 Mandatory options: 579 o Node ID 581 Additional options: 583 o Node Information 585 6.2.2. KEEP-ALIVE 587 Type: 2 589 Mandatory options: 591 o Node ID 593 Additional options: 595 o Node Information 597 o Function ID 599 o Function Information 601 6.2.3. OPERATION 603 Type: 3 605 Sub-Type: Requested operation (See Section 6.3) 607 Mandatory options: 609 o Node ID 611 6.2.4. STATUS-UPDATE 613 Type: 4 615 Mandatory options: 617 o Node ID 619 Additional options: 621 o Node Information 623 o Function ID 625 o Function Information 627 6.2.5. DE-REGISTRATION 629 Type: 5 631 Mandatory options: 633 o Node ID 635 6.2.6. ACK 637 Type: 6 639 Sequence number: MUST be copied from the corresponding control 640 message. 642 Sub-Type: MUST be copied from the corresponding control message. 644 Code: Result code for the requested operation. In this document, the 645 following code values are defined: 647 0: Successful 649 128: Failed 651 129: Insufficient resources 653 130: Administratively prohibited 655 131: Status unknown 657 Mandatory options: 659 o Node ID 661 The Vendor-specific information option can be used to convey more 662 detailed information, for example, to notify the sender about the 663 reason for the failure. 665 6.3. Operation commands 667 6.3.1. GET Operation 669 Type: 3 671 Sub-Type: 1 673 Mandatory options: 675 o Node ID 677 o Function ID 679 o List of options (with zero values in the value field) 681 Expected options in ACK: 683 o Node ID 685 o Function ID 687 o List of options (with non-zero values in the value field) 689 o Result Code 691 o Running Status 693 6.3.2. ADD Operation 695 Type: 3 697 Sub-Type: 2 699 Mandatory options: 701 o Node ID 703 o Function ID 705 Some function takes time to boot up, thus when it successfully booted 706 up, the Execution Node sends Status-update message to the manager 707 node. 709 Expected options in ACK: 711 o Node ID 713 o Function ID 715 o Result Code 717 o Running Status 719 6.3.3. DELETE Operation 721 Type: 3 723 Sub-Type: 3 725 Mandatory options: 727 o Node ID 729 o Function ID 731 Expected options in ACK: 733 o Node ID 735 o Function ID 737 o Result Code 739 o Running Status 741 Some function takes time to terminate, thus when termination is 742 completed, the Execution Node sends Status update message to the 743 manager node. 745 6.3.4. MOVE Operation 747 Type: 3 749 Sub-Type: 4 751 Mandatory options: 753 o Source Node ID 755 o Destination Node ID 756 o Function ID 758 Expected options in ACK: 760 o Source Node ID 762 o Destination Node ID 764 o Function ID 766 o Result Code 768 o Running Status 770 The source Node ID and destination Node ID MUST be listed in this 771 order. 773 6.3.5. COPY Operation 775 Type: 3 777 Sub-Type: 5 779 Mandatory options: 781 o Source Node ID 783 o Destination Node ID 785 o Function ID 787 Expected options in ACK: 789 o Source Node ID 791 o Destination Node ID 793 o Function ID 795 o Result Code 797 o Running Status 799 The source Node ID and destination Node ID MUST be listed in this 800 order. 802 6.3.6. MOVE_SESSION Operation 804 Type: 3 806 Sub-Type: 6 808 Mandatory options: 810 o Source Node ID 812 o Destination Node ID 814 o Session information 816 Additional options: 818 o Function ID 820 Expected options in ACK: 822 o Function ID, if specified in the corresponding operation 823 command. 825 o Result Code 827 o Running Status 829 The source Node ID and destination Node ID MUST be listed in this 830 order. When Function ID is specified, all the sessions related to 831 that Function ID are the target for movement. 833 6.4. Option values 835 In this document, the following attributes are defined. Sub-OP-type 836 MUST be set zero if not defined. 838 6.4.1. IPv4 address 840 OP-Type: 1 842 Length: 4 844 Value: Unsigned integer. IPv4 address (e.g., for the target 845 execution node) 847 6.4.2. IPv6 address 849 OP-Type: 2 851 Length: 16 853 value: Unsigned integer. IPv6 address (e.g., for the target 854 execution node) 856 6.4.3. Port number 858 OP-Type: 3 860 Length: 2 862 value: Unsigned integer. Port number (e.g., for the target session) 864 6.4.4. Node ID 866 OP-Type: 4 868 Length: 4 870 Value: Unsigned integer. Node ID for the target Execution Node 872 6.4.5. Function ID 874 OP-Type: 5 876 Length: 4 878 Value: Unsigned integer. Function ID for the target function 880 6.4.6. Node information 882 OP-Type: 6 884 Length: variable 886 Value: Octet string. Node information specified by the Sub-OP-Type. 887 In this document, the following types are defined: 889 Sub-OP-Type 890 1: Processing capacity (GHz) 891 2: Current load (number of waiting processes) 892 3: Average load (number of waiting processes) 893 10: Total memory size (byte) 894 11: Available memory size (byte) 895 20: Total storage size (byte) 896 21: Available storage size (byte) 897 30: Total bandwidth (bps) 898 31: Current used bandwidth (bps) 899 32: Average used bandwidth (bps) 900 40: Boot time (NTP timestamp format) 902 6.4.7. Function information 904 OP-Type: 7 906 Length: variable 908 Value: Octet string. Used to describe the type or status of the 909 function. In this document, the following values are defined: 911 Sub-OP-Type 912 1: Function name (e.g., "P-CSCF" or "HSS") 913 2: Current load (number of waiting processes) 914 3: Average load (number of waiting processes) 915 10: Required memory size (byte) 916 11: Available memory size (byte) 917 20: Required storage size (byte) 918 21: Available storage size (byte) 919 31: Current used bandwidth (bps) 920 32: Average used bandwidth (bps) 921 40: Boot time (NTP timestamp format) 922 50: Running status ("Starting", "Running", "Terminating" or 923 "Unknown") 925 6.4.8. Session information 927 OP-Type: 8 929 Length: variable 931 Value: Octet string to represent one or group of session(s). This 932 value MUST be understood by both the manager and execution nodes. In 933 this document, the following values are defined: 935 Sub-OP-Type 936 1: SIP URI (e.g., sip:alice@example.com) 937 2: Contact address (IPv4 or v6 address) 938 3: the ratio to the whole sessions (e.g., 0.3) 939 4: the number of sessions (e.g., 1000) 941 6.4.9. Vendor-specific information 943 OP-Type: 9 945 Length: variable 947 Value: Octet string to convey vendor-specific information. This 948 value MUST be understood by both the Manager and Execution Nodes. In 949 this document, the following value is defined: 951 Sub-OP-Type 952 1: Information message (e.g., "Protocol error") 954 7. IANA Considerations 956 This specification requests one TCP and SCTP port number for 957 exchanging the defined control messages. 959 8. Security Considerations 961 It is assumed that necessary level of security between the Manager 962 Node and Execution Nodes is provided by other means and a secure 963 connection between them is not mandated in this document. 965 9. Acknowledgments 967 The authors would like to thank Christian Makaya for his valuable 968 comments to and reviews of this document. 970 10. References 972 10.1. Normative references 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 10.2. Informative references 979 [IMSAA09] Dutta, A., Makaya, C., Das, S., Chee, D., Lin, F., 980 Komorita, S., Chiba, T., Yokota, H., and H. Schulzrinne, 981 "Self Organizing IP Multimedia Subsystem", IEEE IMSAA, 982 December 2009. 984 Authors' Addresses 986 Hidetoshi Yokota 987 KDDI Lab 988 2-1-15 Ohara, Fujimino 989 Saitama, 356-8502 990 JP 992 Email: yokota@kddilabs.jp 994 Fuchun J. Lin 995 Telcordia Technologies 996 One Telcordia Drive 997 Piscataway, NJ 08854-4157 998 US 1000 Email: fjlin@research.telcordia.com 1002 Ashutosh Dutta 1003 NIKSUN 1004 100 Nassau Park Boulevard, Princeton, NJ 1005 08540 1006 US 1008 Email: ashutosh.dutta@ieee.org 1010 Carl Williams 1011 MCSR Labs 1012 Palo Alto, CA 1013 94306 1014 US 1016 Email: carlw@mcsr-labs.org 1018 Vishwas Manral 1019 IPInfusion Inc. 1020 1188 E. Arques Ave. 1021 Sunnyvale, CA 94085 1022 US 1024 Phone: 408-400-1900 1025 Email: vishwas@ipinfusion.com