idnits 2.17.1 draft-smith-opflex-00.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 date (April 2, 2014) is 3670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft M. Dvorkin 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: October 4, 2014 Y. Laribi 6 Citrix 7 V. Pandey 8 IBM 9 P. Garg 10 Microsoft Corporation 11 N. Weidenbacher 12 Sungard Availability Services 13 April 2, 2014 15 OpFlex Control Protocol 16 draft-smith-opflex-00 18 Abstract 20 The OpFlex architecture provides a distributed control system based 21 on a declarative policy information model. The policies are defined 22 at a logically centralized policy repository (PR) and enforced within 23 a set of distributed policy elements (PE). The PR communicates with 24 the subordinate PEs using the OpFlex Control protocol. This protocol 25 allows for bidirectional communication of policy, events, statistics, 26 and faults. This document defines the OpFlex Control Protocol. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 4, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Policy Repository . . . . . . . . . . . . . . . . . . . . 4 68 3.1.1. Management Information Model . . . . . . . . . . . . . 4 69 3.1.1.1. Managed Object . . . . . . . . . . . . . . . . . . 5 70 3.2. Endpoint Registry . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Observer . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.4. Policy Element . . . . . . . . . . . . . . . . . . . . . . 6 73 4. OpFlex Control Protocol . . . . . . . . . . . . . . . . . . . 6 74 4.1. JSON Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. RPC Methods . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2.2. Policy Resolution . . . . . . . . . . . . . . . . . . 10 78 4.2.3. Policy Update . . . . . . . . . . . . . . . . . . . . 12 79 4.2.4. Echo . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.2.5. Policy Trigger . . . . . . . . . . . . . . . . . . . . 13 81 4.2.6. Endpoint Declaration . . . . . . . . . . . . . . . . . 14 82 4.2.7. Endpoint Request . . . . . . . . . . . . . . . . . . . 15 83 4.2.8. Endpoint Policy Update . . . . . . . . . . . . . . . . 17 84 4.2.9. State Report . . . . . . . . . . . . . . . . . . . . . 18 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 As software development processes merge with IT operations, there is 94 an increasing demand for automation and agility within the IT 95 infrastructure. Application deployment has been impeded due to the 96 existing IT infrastructure operational models. Management at scale 97 is a very difficult problem and existing imperative management models 98 typically falter when challenged with the heterogeneity of various 99 platforms, applications, and releases. In such environments, 100 declarative management models have shown to cope quite well. In 101 these systems, agents have autonomy of control and provide a 102 declaration of intent regarding behavior. Declarative policy is 103 rendered locally to provide desired system behavior. The OpFlex 104 architecture is founded in these concepts. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 1.2. Terminology 114 AD: Administrative Domain. A logical instantiation of 115 the OpFlex system components controlled by a single 116 administrative policy. 118 EP: Endpoint. A device connected to the system. 120 EPR: Endpoint Registry. A logically centralized entity 121 containing the endpoint registrations within 122 associated administrative domain. 124 OB: Observer. A logically centralized entity that serves 125 as a repository for statistics, faults, and events. 127 PE: Policy Element. A function associated with entities 128 comprising the policy administrative domain that is 129 responsible for local rendering of policy. 131 PR: Policy Repository. A logically centralized entity 132 containing the definition of all policies governing 133 the behavior of the associated administrative domain. 135 OpFlex Device: Entity under the management of a Policy Element. 137 JSON: Javascript Object Notation [RFC4627] 139 XML: Extensible Markup Language [XML] 141 2. Scope 143 This document defines the OpFlex Control Protocol used between OpFlex 144 system components. It does not define the policy object model or the 145 policy object model schemas. A System Overview section is provided 146 for reference. 148 3. System Overview 150 OpFlex is a policy driven system used to control a large set of 151 physical and virtual devices. The OpFlex system architecture 152 consists of a number of logical components. These are the Policy 153 Repository (PR), Endpoint Registry (EPR), Observer, and the Policy 154 Elements (PE). These components and their interactions are described 155 in the following subsections. 157 3.1. Policy Repository 159 Within each administrative domain of the OpFlex system, there is a 160 single logical entity referred to as the Policy Repository (PR) that 161 serves as the single source of all policies. The PR handles policy 162 resolution requests from the Policy Elements within the same 163 administrative domain. An example scope of an administrative domain 164 would be a datacenter fabric. These policies are configured directly 165 by the user via a policy administration interface (API/UI/CLI/etc.) 166 or indirectly (implicitly through the application of higher order 167 policy constructs). These policies represent a declarative statement 168 of desired state. Policies are typically abstracted from the 169 underlying implementation. 171 3.1.1. Management Information Model 173 All of the physical and logical components that comprise the 174 administrative domain are represented in a hierarchical management 175 information model (MIM), also referred to as the management 176 information tree (MIT). The hierarchical structure starts at a root 177 node and all policies within the system can be reached via parent and 178 child containment relationships. Each node has a unique Uniform 179 Resource Identifier (URI) [RFC3986] that indicates its place in the 180 tree. 182 3.1.1.1. Managed Object 184 Each node in the tree represents a managed object (MO) or group of 185 objects and contains its administrative state and operational state. 186 An MO can represent a concrete object, such as a switch or adapter, 187 or a logical object, such as a policy or fault. An MO consists of 188 the following items: 190 Properties: A property is a named instance of policy data and 191 is interpreted by the Policy Element in local 192 rendering of the policy. 194 Child Relations: A containment relationship between MOs where the 195 children MOs are contained within the parent MO. 197 Parent Relation: The inverse of the children relationship. This 198 relation is implicit and is implied through the 199 hierarchical name of the MO name. 201 MO Relations: Relationships with other MOs in the system that are 202 not containment relationships. These relationships 203 can be unidirectional or bidirectional. The 204 relationships can also be 1:1, 1:n, or m:n. 206 Statistics: These are child MOs that track statistics relevant 207 to the parent MOs. These MOs are reported to the 208 Observer. 210 Faults: These are child MOs that track faults relevant to 211 the parent MOs. These MOs are reported to the 212 Observer. 214 Health: These are child MOs that track the overall health 215 relevant to the parent MOs. This is often 216 represented in the form of a health score. These 217 MOs are reported to the Observer. 219 MOs that contain statistic, fault, or health MOs are said to be 220 observable. 222 3.2. Endpoint Registry 224 The Endpoint Registry (EPR) is the component that stores the current 225 operational state of the endpoints (EP) within the system. PEs 226 register the EPs with the EPR upon EP attachment to the local device 227 where the PE is resident. Upon EP detachment, the registration will 228 be withdrawn. The EP registration information contains the scope of 229 the EP such as the Tenant or logical network as well as location 230 information such as the hypervisor where the EP resides. The EPR can 231 be used by PEs to query the current EPR registrations as well as 232 receive updates when the information changes. 234 3.3. Observer 236 The Observer serves as the monitoring subsystem that provides a 237 detailed view of the system operational state and performance. It 238 serves as a data repository for information related to trending, 239 forensics, and long-term visibility data such as statistics, events, 240 and faults. Statistical data is reported to the Observer at 241 expiration of reporting intervals and statistics will be rolled up 242 for longer-term trend analysis. 244 3.4. Policy Element 246 Policy elements (PEs) are logical functional abstractions of member 247 elements within the administrative domain. Policy elements reside on 248 physical or virtual devices that are subjected to policy control 249 under a given administrative domain. PEs receives policy triggers 250 through local triggers or triggers invoked by other PEs. Local 251 triggers involve local MO state transitions such as new control node 252 additions, removals, or other operational events. Policy triggers 253 invoked by other PEs are transmitted using the OpFlex Control 254 Protocol. Both types of policy triggers result in policy resolution. 255 Policies are resolved with the PR using the OpFlex protocol. This 256 protocol allows bidirectional communication, and allows the exchange 257 of policy information. Policies are represented as managed object 258 "sub-trees". Upon policy resolution, the PE renders the policy to 259 the configuration of the underlying subsystem, and continuously 260 performs health monitoring of the subsystem. PEs perform local 261 corrective actions as needed for the enforcement of policies in its 262 scope. Operational transitions can also cause new or additional/ 263 incremental policy resolutions such as the attachment of new EPs to 264 the corresponding device. 266 4. OpFlex Control Protocol 268 The OpFlex Control Protocol is used by OpFlex system components to 269 communicate policy and operational data. The protocol uses JSON, 270 XML, or OpFlex-Binary-RPC as the wire encoding. This document 271 describes the JSON format and uses JSON-RPC version 1.0 [JSON-RPC]. 272 The JSON-RPC transport SHOULD be over TCP. The description of the 273 encoding and transport of XML and OpFlex-Binary-RPC are left to later 274 revisions of this document. 276 4.1. JSON Usage 278 The descriptions below use the following shorthand notations for JSON 279 values. Terminology follows [RFC4627]. 281 : 282 A JSON string. Any Unicode string is allowed. 283 Implementations SHOULD disallow null bytes. 285 : 286 A JSON number with an integer value, within the range 287 -(2**63)...+(2**63)-1. 289 : 290 Any JSON value. 292 : 293 Any JSON value except null. 295 : 296 A JSON string in the form of a Uniform Resource 297 Identifier[RFC3986]. 299 : 300 An enumeration specifying one of the following set of 301 strings: "created", "modified", or "deleted". 303 : 304 An enumeration specifying one of the following set of 305 strings: "policy_element", "observer", "policy_repository", 306 or "endpoint_registry". 308 : 309 A JSON object with the following members: 311 "name": 312 "properties": [{"name":, "data": }*] 313 "children": [*] 314 "statistics": [*] 315 "from_relations": [*] 316 "to_relations": [*] 317 "faults": [*] 318 "health": [*] 320 All of the members of the JSON object are REQUIRED. However, 321 the corresponding value MAY consist of the empty set for all 322 members except for "name". It is REQUIRED that the "name" be 323 specified. 325 The "name" uniquely identifies the managed object within the 326 scope of the administrative domain and indicates its location 327 within the MIT. 329 The "properties" holds a set of named policy data. 331 The "children" identifies a set of MOs where each MO is 332 considered a child of this particular MO. 334 The "statistics" identifies a set of MOs containing statistic 335 data maintained by the policy rendered from this particular 336 MO. 338 The "from_relationships" identifies a set of relationship 339 MOs. Each relationship MO has a reference to the MOs that 340 have relationship to this particular MO. 342 The "to_relationships" identifies a set of relationship MOs. 343 Each relationship MO has a reference to the MOs that have 344 relationship from this particular MO. 346 The "faults" identifies a set of MOs containing fault 347 information maintained by the policy rendered from this 348 particular MO. 350 The "health" identifies a set of MOs containing health 351 metrics maintained by the policy rendered from this 352 particular MO. 354 In the case of MOs used as policies, there will be no 355 statistics, faults, or health. 357 4.2. RPC Methods 359 The following subsections describe the RPC methods that are 360 supported. As described in the JSON-RPC 1.0 specification, each 361 request comprises a string containing the name of the method, a 362 (possibly null) array of parameters to pass to the method, and a 363 request ID, which can be used to match the response to the request. 364 Each response comprises a result object (non-null in the event of a 365 successful invocation), an error object (non-null in the event of an 366 error), and the ID of the matching request. More details on each 367 method, its parameters, and its results are described below. 369 A Policy Element is configured with the connectivity information of 370 at least one peer OpFlex Control Protocol participant. The 371 connectivity information consists of the information necessary to 372 establish the initial connection such as the IP address and wire 373 encapsulation. A Policy Element MAY be configured with the 374 connectivity information for one or more of the OpFlex logical 375 components. A Policy Element MUST connect to each of the configured 376 OpFlex logical components. 378 4.2.1. Identity 380 This method identifies the participant to its peer in the protocol 381 exchange and MUST be sent as the first OpFlex protocol method. The 382 method indicates the transmitter's role and the administrative domain 383 to which it belongs. Upon receiving an Identity message, the 384 response will contain the configured connectivity information that 385 the participant is using to communicate with each of the OpFlex 386 components. If the response receiver is a Policy Element and is not 387 configured with connectivity information for certain OpFlex logical 388 components, it SHOULD use the peer's connectivity information to 389 establish communication with the OpFlex logical components that have 390 not been locally configured. 392 The Identity request contains the following members: 394 o "method": "send_identity" 396 o "params": [ 398 "name": 399 "domain": 400 ["my_role": ]+ 401 ] 403 o "id": 405 The "name" is an identifier of the OpFlex Control Protocol 406 participant that is unique within the administrative domain. 408 The "domain" is a globally unique identifier indicating the 409 administrative domain that this participant exists. 411 The "my_role" states the particular OpFlex component contained within 412 this participant. Since a participant may be capable of acting as 413 more than 1 type of component, there may be multiple "my_role" 414 parameters passed. 416 The response object contains the following members: 418 o "result": [ 419 "name": 420 [ "my_role": ]+ 421 "domain": 422 [ {"role": 423 "connectivity_info": }* ] 424 ] 426 o "error": null 428 o "id": same "id" as request 430 The "name" is the identifier of the OpFlex Control Protocol 431 participant sending the response. 433 The "my_role" states the OpFlex component roles contained within the 434 participant sending the response. 436 The "domain" is a globally unique identifier indicating the 437 administrative domain that the participant sending the response 438 exists. 440 The "role" and associated "connectivity_info" give the reachability 441 information (i.e. IP address or DNS name) and the role of the entity 442 that the participant is communicating using the OpFlex Control 443 Protocol. This information MAY be gleaned by a receiving participant 444 to resolve reachability for various OpFlex components. 446 In the event that the administrative domains do not match, an error 447 response of the following form: 449 o "result": null 451 o "error": "Domain mismatch" 453 o "id": same "id" as request 455 4.2.2. Policy Resolution 457 This method retrieves the policy associated with the given policy 458 name. The policy is returned as a set of managed objects. This 459 method is typically sent by the PE to the PR. 461 The request object contains the following members: 463 o "method": "resolve_policy" 465 o "params": [ 466 "subject": 467 "context": 468 "policy_name": 469 "on_behalf_of": 470 "data": 471 ] 473 o "id": 475 The "subject" provides the class of entity for which the policy is 476 being resolved. The applicable object classes are dependent on the 477 particular MIT. 479 The "context" is used to scope the policy resolution request. Common 480 examples would be scoping within a particular tenant name. 482 The "policy_name" is the name of the policy needs to be resolved. 484 The "on_behalf_of" indicates the MO that triggered this policy 485 resolution. 487 The "data" provides additional opaque data that may be used to assist 488 in the policy resolution. 490 Upon successful policy resolution, the response object contains the 491 following members: 493 o "result": [ 495 "policy": +, 496 "prr": ] 498 o "error": null 500 o "id": same "id" as request 502 The "policy" parameter contains the managed objects that represent 503 the resolved policy. These objects are used by the Policy Element to 504 render and apply the local policy. The application of the local 505 policy may cause the local PE to deliver policy triggers to other PEs 506 in the system. 508 The "prr" or Policy Refresh Rate provides the amount of time that a 509 PE should use the policy as provided in the request. The 510 indicates the time in seconds that the policy should be kept by the 511 PE. A PE SHOULD issue another policy resolution request before the 512 expiration of the prr timer if the PE still requires the policy. If 513 the PE is unable to subsequently resolve the policy after the prr 514 timer expires, the PE MAY continue to use the resolved policy. The 515 PE SHOULD raise an alarm if the policy cannot be resolved after 516 multiple attempts. 518 In the event that the policy named in the resolution request does not 519 exist, an error response of the following form: 521 o "result": null 523 o "error": "unknown policy name" 525 o "id": same "id" as request 527 4.2.3. Policy Update 529 This method is sent to Policy Elements when there has been a change 530 of policy definition for policies which the Policy Element has 531 requested resolution. Policy Updates will only be sent to Policy 532 Element for which the policy refresh rate timer has not expired. 534 The Policy Update contains the following members: 536 o "method": "update_policy" 538 o "params": [ 540 "context": 541 ["subtree": +]+ 542 "prr": 543 ] 545 o "id": 547 The "context" is used to indicate the scope of the policy. This is 548 typically the same as the context in the original policy resolution 549 request but it may be different. 551 The "subtree" contains one or more subtrees of the MIT. Each subtree 552 is a collection of MOs that represent the changed policy. 554 The "prr" or Policy Refresh Rate provides the amount of time that a 555 PE should use the policy as provided in the request. The 556 indicates the time in seconds that the policy should be kept by the 557 PE. A PE SHOULD issue another policy resolution request before the 558 expiration of the prr timer if the PE still requires the policy. If 559 the PE is unable to subsequently resolve the policy after the prr 560 timer expires, the PE MAY continue to use the resolved policy. The 561 PE SHOULD raise an alarm if the policy cannot be resolved after 562 multiple attempts. 564 The response object contains the following members: 566 o "result": {} 568 o "error": null 570 o "id": same "id" as request 572 4.2.4. Echo 574 The "echo" method can be used by OpFlex Control Protocol peers to 575 verify the liveness of a connection. It MUST be implemented by all 576 participants. The members of the request are: 578 o "method": "echo" 580 o "params": JSON array with any contents 582 o "id": 584 The response object has the following members: 586 o "result": same as "params" 588 o "error": null 590 o "id": same "id" as request 592 4.2.5. Policy Trigger 594 A policy trigger is issued from one Policy Element to a peer Policy 595 Element in order to trigger a policy resolution on the peer. It is 596 typically done to indicate a attachment state change or a change in 597 the consumption of the peer resources. For example, a Policy Element 598 in a switch may cause a policy trigger in the upstream switch to 599 enable a particular VLAN on the peer's interface. It may also be 600 issued upon receiving a Policy Update or Policy Resolution response. 602 The Policy Trigger contains the following members: 604 o "method": "trigger_policy" 606 o "params": [ 607 "policy_type": 608 "context": 609 "policy_name": 610 "prr": 611 ] 613 o "id": 615 The response object contains the following members: 617 o "result": {} 619 o "error": null 621 o "id": same "id" as request 623 4.2.6. Endpoint Declaration 625 This method is used to indicate the attachment and detachment of an 626 endpoint. It is sent from the Policy Element to the Endpoint 627 Registry. 629 The Endpoint Declaration contains the following members: 631 o "method": "endpoint_declaration" 633 o "params": [ 635 "subject": 636 "context": 637 "policy_name": 638 "location": 639 ["identifier": ]+ 640 ["data": ]* 641 "status": 642 "prr": 643 ] 645 o "id": 647 The "subject" provides the class of entity for which the declaration 648 applies. This will typically be the class representing the endpoint. 649 The applicable object classes are dependent on the particular MIT. 651 The "context" is used to scope the endpoint declaration. 653 The "policy_name" is used to identify the policy that must be 654 resolved and applied when this endpoint attaches, detaches, or is 655 otherwise modified. 657 The "location" is used to identify the managed object indicating the 658 point where the endpoint connects to the system. An example would be 659 a managed object representing a certain physical port on a ethernet 660 switch. 662 The "identifier" is a label that is used in identifying the 663 particular instance of the endpoint. Some examples of an identifier 664 would be a MAC address, VLAN, and IP address. 666 The "data" are used along with the context, endpoint class, endpoint 667 MO, and the policy_name to select the policy that will be applied to 668 the particular endpoint. These are typically labels used in 669 identifying particular endpoint or endpoint location characteristics. 670 Some examples would include trusted, untrusted, production, test, 671 etc. 673 The "status" indicates whether this declaration is an endpoint 674 attachment, detachment, or modification. 676 The "prr" or Policy Refresh Rate provides provides the amount of time 677 that the endpoint declaration will remain valid. The 678 indicates the time in seconds that the endpoint declaration should be 679 kept by the EPR. A PE SHOULD issue another endpoint declaration 680 before the expiration of the prr timer if the endpoint is to continue 681 existing within the system. 683 The response object contains the following members: 685 o "result": {} 687 o "error": null 689 o "id": same "id" as request 691 4.2.7. Endpoint Request 693 This method queries the EPR for the registration of a particular EP. 694 The request is made using the identifiers of the endpoint. Since 695 multiple identifiers may be used to uniquely identify a particular 696 endpoint, there may be more than 1 endpoint returned in the reply if 697 the identifiers presented do not uniquely specify the endpoint. 699 The Endpoint Request contains the following members: 701 o "method": "endpoint_request" 703 o "params": [ 705 "subject": 706 "context": 707 ["identifier": ]+ 708 ] 710 o "id": 712 The "subject" provides the class of entity for which the request 713 applies. This will typically be the class representing the endpoint. 714 The applicable object classes are dependent on the particular MIT. 716 The "context" is used to scope the endpoint resolution. 718 The "identifier" is a label that is used in identifying the 719 particular instance of the endpoint. Some examples of an identifier 720 would be a MAC address, VLAN, and IP address. 722 The "prr" or Policy Refresh Rate provides provides the amount of time 723 that the endpoint information will remain valid. The 724 indicates the time in seconds that the endpoint information should be 725 kept by the PE. A PE SHOULD issue another endpoint request before 726 the expiration of the prr timer if the communication is still 727 required with the endpoint. 729 The response object contains the registrations of one or more 730 endpoints. Each endpoint contains the same information that was 731 present in the original registration. The following members are 732 present in the response: 734 o "result": { 736 [ endpoint : 737 {"subject": 738 "context": 739 "policy_name": 740 "location": 741 ["identifier": ]+ 742 ["data": ]* 743 "status": 744 "prr": 745 } ]+ 746 } 748 o "error": null 750 o "id": same "id" as request 752 The following error response object is returned if no endpoints match 753 the identifiers presented in the request: 755 o "result": {} 757 o "error": "No endpoints found." 759 o "id": same "id" as request 761 4.2.8. Endpoint Policy Update 763 This method is sent to Policy Elements by the EPR when there has been 764 a change relating to the EP Declaration for an Endpoint that the 765 Policy Element has requested. Policy Updates will only be sent to 766 Policy Elements for which the Policy Refresh Rate timer timer for the 767 Endpoint Request has not expired. 769 The Endpoint Policy Update contains the following members: 771 o "method": "endpoint_update_policy" 773 o "params": [ 775 "subject": 776 "context": 777 "policy_name": 778 "location": 779 ["identifier": ]+ 780 ["data": ]* 781 "status": 782 "ttl": 783 ] 785 o "id": 787 All of the "params" contain identical information to the descriptions 788 given as part of the Endpoint Declaration. 790 The response object contains the following members: 792 o "result": {} 794 o "error": null 795 o "id": same "id" as request 797 4.2.9. State Report 799 This method is sent by the Policy Element to the Observer. It 800 provides fault, event, statistics, and health information in the form 801 of managed objects. 803 The State Report contains the following members: 805 o "method": "report_state" 807 o "params": [ 809 "subject": 810 "context": 811 "object": 812 ["fault": ]* 813 ["event": ]* 814 ["statistics": ]* 815 ["health": ]* 816 ] 818 o "id": 820 The "subject" provides the class of entity for which the State Report 821 applies. The applicable object classes are dependent on the 822 particular MIT. 824 The "context" is used to scope the subject. 826 The "object" is the specific managed object that the faults, events, 827 statistics, and health reports in this method apply. 829 The "fault" is an optional field that contains one or more managed 830 objects representing faults. 832 The "events" is an optional field that contains one or more managed 833 objects representing events. 835 The "statistics" is an optional field that contains one or more 836 managed objects representing statistics. 838 The "health" is an optional field that contains one or more managed 839 objects representing health statistics applicable. 841 The response object contains the following members: 843 o "result": {} 845 o "error": null 847 o "id": same "id" as request 849 5. IANA Considerations 851 A TCP port will be requested from IANA for the OpFlex Control 852 Protocol. 854 6. Security Considerations 856 The OpFlex Control Protocol itself does not address authentication, 857 integrity, and privacy of the communication between the various 858 OpFlex components. In order to protect the communication, the OpFlex 859 Control Protocol SHOULD be secured using Transport Layer Security 860 (TLS) [RFC5246]. The distribution of credentials will vary depending 861 on the deployment. In some deployments, existing secure channels can 862 be used to distribute the credentials. 864 7. Acknowledgements 866 The authors would like to thank Vijay Chander, Mike Cohen, and Brad 867 McConnell for their comments and contributions. 869 8. Normative References 871 [JSON-RPC] 872 "JSON-RPC Specification, Version 1.0", 873 . 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, March 1997. 878 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 879 Resource Identifier (URI): Generic Syntax", STD 66, 880 RFC 3986, January 2005. 882 [RFC4627] Crockford, D., "The application/json Media Type for 883 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 885 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 888 [XML] Bray, T., Jean Paoli, Sperberg-McQueen, C., and E. Maler, 889 Ed., "Extensible Markup Language (XML) 1.0 (Second 890 Edition)", October 2000, . 892 Authors' Addresses 894 Michael Smith 895 Cisco Systems, Inc. 896 170 West Tasman Drive 897 San Jose, California 95134 898 USA 900 Email: michsmit@cisco.com 902 Mike Dvorkin 903 Cisco Systems, Inc. 904 170 West Tasman Drive 905 San Jose, California 95134 906 USA 908 Email: midvorki@cisco.com 910 Youcef Laribi 911 Citrix 912 4988 Great America Parkway 913 Santa Clara, California 95054 914 USA 916 Email: Youcef.Laribi@citrix.com 918 Vijoy Pandey 919 IBM 920 4400 N First Street 921 San Jose, California 95134 922 USA 924 Email: vijoy.pandey@us.ibm.com 925 Pankaj Garg 926 Microsoft Corporation 927 1 Microsoft Way 928 Redmond, Washington 98052 929 USA 931 Email: pankajg@microsoft.com 933 Nik Weidenbacher 934 Sungard Availability Services 935 Philadelphia, Pennsylvania 936 USA 938 Email: nik.weidenbacher@sungard.com