idnits 2.17.1 draft-ietf-dmm-fpc-cpdp-13.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1509 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 DMM Working Group S. Matsushima 3 Internet-Draft SoftBank 4 Intended status: Standards Track L. Bertz 5 Expires: September 10, 2020 Sprint 6 M. Liebsch 7 NEC 8 S. Gundavelli 9 Cisco 10 D. Moses 11 Intel Corporation 12 C. Perkins 13 Futurewei 14 March 9, 2020 16 Protocol for Forwarding Policy Configuration (FPC) in DMM 17 draft-ietf-dmm-fpc-cpdp-13 19 Abstract 21 This document describes a way, called Forwarding Policy Configuration 22 (FPC) to manage the separation of data-plane and control-plane. FPC 23 defines a flexible mobility management system using FPC agent and FPC 24 client functions. A FPC agent provides an abstract interface to the 25 data-plane. The FPC client configures data-plane nodes by using the 26 functions and abstractions provided by the FPC agent for the data- 27 plane nodes. The data-plane abstractions presented in this document 28 are extensible in order to support many different types of mobility 29 management systems and data-plane functions. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. FPC Design Objectives and Deployment . . . . . . . . . . . . 6 68 4. FPC Mobility Information Model . . . . . . . . . . . . . . . 9 69 4.1. Model Notation and Conventions . . . . . . . . . . . . . 9 70 4.2. Templates and Attributes . . . . . . . . . . . . . . . . 12 71 4.3. Attribute-Expressions . . . . . . . . . . . . . . . . . . 13 72 4.4. Attribute Value Types . . . . . . . . . . . . . . . . . . 14 73 4.5. Namespace and Format . . . . . . . . . . . . . . . . . . 14 74 4.6. Configuring Attribute Values . . . . . . . . . . . . . . 15 75 4.7. Entity Configuration Blocks . . . . . . . . . . . . . . . 16 76 4.8. Information Model Checkpoint . . . . . . . . . . . . . . 17 77 4.9. Information Model Components . . . . . . . . . . . . . . 18 78 4.9.1. Topology Information Model . . . . . . . . . . . . . 18 79 4.9.2. Service-Group . . . . . . . . . . . . . . . . . . . . 18 80 4.9.3. Domain Information Model . . . . . . . . . . . . . . 20 81 4.9.4. DPN Information Model . . . . . . . . . . . . . . . . 20 82 4.9.5. Policy Information Model . . . . . . . . . . . . . . 21 83 4.9.6. Mobility-Context Information Model . . . . . . . . . 24 84 4.9.7. Monitor Information Model . . . . . . . . . . . . . . 26 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 7. Work Team Participants . . . . . . . . . . . . . . . . . . . 28 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 90 8.2. Informative References . . . . . . . . . . . . . . . . . 28 91 Appendix A. Implementation Status . . . . . . . . . . . . . . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 94 1. Introduction 96 This document describes Forwarding Policy Configuration (FPC), a 97 system for managing the separation of control-plane and data-plane. 98 FPC enables flexible mobility management using FPC client and FPC 99 agent functions. A FPC agent exports an abstract interface 100 representing the data-plane. To configure data-plane nodes and 101 functions, the FPC client uses the interface to the data-plane 102 offered by the FPC agent. 104 Control planes of mobility management systems, or related 105 applications which require data-plane control, can utilize the FPC 106 client at various levels of abstraction. FPC operations are capable 107 of directly configuring a single Data-Plane Node (DPN), as well as 108 multiple DPNs, as determined by the data-plane models exported by the 109 FPC agent. 111 A FPC agent represents the data-plane operation according to several 112 basic information models. A FPC agent also provides access to 113 Monitors, which produce reports when triggered by events or FPC 114 Client requests regarding Mobility Contexts, DPNs or the Agent. 116 To manage mobility sessions, the FPC client assembles applicable sets 117 of forwarding policies from the data model, and configures them on 118 the appropriate FPC Agent. The Agent then renders those policies 119 into specific configurations for each DPN at which mobile nodes are 120 attached. The specific protocols and configurations to configure a 121 DPN from a FPC Agent are outside the scope of this document. 123 A DPN is a logical entity that performs data-plane operations (packet 124 movement and management). It may represent a physical DPN unit, a 125 sub-function of a physical DPN or a collection of physical DPNs 126 (i.e., a "virtual DPN"). A DPN may be virtual -- it may export the 127 FPC DPN Agent interface, but be implemented as software that controls 128 other data-plane hardware or modules that may or may not be FPC- 129 compliant. In this document, DPNs are specified without regard for 130 whether the implementation is virtual or physical. DPNs are 131 connected to provide mobility management systems such as access 132 networks, anchors and domains. The FPC agent interface enables 133 establishment of a topology for the forwarding plane. 135 When a DPN is mapped to physical data-plane equipment, the FPC client 136 can have complete knowledge of the DPN architecture, and use that 137 information to perform DPN selection for specific sessions. On the 138 other hand, when a virtual DPN is mapped to a collection of physical 139 DPNs, the FPC client cannot select a specific physical DPN because it 140 is hidden by the abstraction; only the FPC Agent can address the 141 specific associated physical DPNs. Network architects have the 142 flexibility to determine which DPN-selection capabilities are 143 performed by the FPC Agent (distributed) and which by the FPC client 144 (centralized). In this way, overlay networks can be configured 145 without disclosing detailed knowledge of the underlying hardware to 146 the FPC client and applications. 148 The abstractions in this document are designed to support many 149 different mobility management systems and data-plane functions. The 150 architecture and protocol design of FPC is not tied to specific types 151 of access technologies and mobility protocols. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 Attribute Expression: The definition of a template Property. This 160 includes setting the type, current value, 161 default value and if the attribute is static, 162 i.e. can no longer be changed. 164 Domain: One or more DPNs that form a logical 165 partition of network resources (e.g., a data- 166 plane network under common network 167 administration). A FPC client (e.g., a 168 mobility management system) may utilize a 169 single or multiple domains. 171 DPN: A data-plane node (DPN) is capable of 172 performing data-plane features. For example, 173 DPNs may be switches or routers, regardless 174 of whether they are realized as hardware or 175 purely in software. 177 FPC Client: A FPC Client is integrated with a mobility 178 management system or related application, 179 enabling control over forwarding policy, 180 mobility sessions and DPNs via a FPC Agent. 182 Mobility Context: A Mobility Context contains the data-plane 183 information necessary to efficiently send and 184 receive traffic from a mobile node. This 185 includes policies that are created or 186 modified during the network's operation - in 187 most cases, on a per-flow or per session 188 basis. A Mobility-Context represents the 189 mobility sessions (or flows) which are active 190 on a mobile node. This includes associated 191 runtime attributes, such as tunnel endpoints, 192 tunnel identifiers, delegated prefix(es), 193 routing information, etc. Mobility-Contexts 194 are associated to specific DPNs. Some pre- 195 defined Policies may apply during mobility 196 signaling requests. The Mobility Context 197 supplies information about the policy 198 settings specific to a mobile node and its 199 flows; this information is often quite 200 dynamic. 202 Mobility Session: Traffic to/from a mobile node that is 203 expected to survive reconnection events. 205 Monitor: A reporting mechanism for a list of events 206 that trigger notification messages from a FPC 207 Agent to a FPC Client. 209 Policy: A Policy determines the mechanisms for 210 managing specific traffic flows or packets. 211 Policies specify QoS, rewriting rules for 212 packet processing, etc. A Policy consists of 213 one or more rules. Each rule is composed of 214 a Descriptor and Actions. The Descriptor in 215 a rule identifies packets (e.g., traffic 216 flows), and the Actions apply treatments to 217 packets that match the Descriptor in the 218 rule. Policies can apply to Domains, DPNs, 219 Mobile Nodes, Service-Groups, or particular 220 Flows on a Mobile Node. 222 Property: An attribute-value pair for an instance of a 223 FPC entity. 225 Service-Group: A set of DPN interfaces that support a 226 specific data-plane purpose, e.g. inbound/ 227 outbound, roaming, subnetwork with common 228 specific configuration, etc. 230 Template: A recipe for instantiating FPC entities. 231 Template definitions are accessible (by name 232 or by a key) in an indexed set. A Template 233 is used to create specific instances (e.g., 234 specific policies) by assigning appropriate 235 values into the Template definition via 236 Attribute Expression. 238 Template Configuration The process by which a Template is referenced 239 (by name or by key) and Attribute Expressions 240 are created that change the value, default 241 value or static nature of the Attribute, if 242 permitted. If the Template is Extensible, 243 new attributes MAY be added. 245 Tenant: An operational entity that manages mobility 246 management systems or applications which 247 require data-plane functions. A Tenant 248 defines a global namespace for all entities 249 owned by the Tenant enabling its entities to 250 be used by multiple FPC Clients across 251 multiple FPC Agents. 253 Topology: The DPNs and the links between them. For 254 example, access nodes may be assigned to a 255 Service-Group which peers to a Service-Group 256 of anchor nodes. 258 3. FPC Design Objectives and Deployment 260 Using FPC, mobility control-planes and applications can configure 261 DPNs to perform various mobility management roles as described in 262 [I-D.ietf-dmm-deployment-models]. This fulfills the requirements 263 described in [RFC7333]. 265 This document defines FPC Agent and FPC Client, as well as the 266 information models that they use. The attributes defining those 267 models serve as the protocol elements for the interface between the 268 FPC Agent and the FPC Client. 270 Mobility control-plane applications integrate features offered by the 271 FPC Client. The FPC Client connects to FPC Agent functions. The 272 Client and the Agent communicate based on information models 273 described in Section 4. The models allow the control-plane to 274 configure forwarding policies on the Agent for data-plane 275 communications with mobile nodes. 277 Once the Topology of DPN(s) and domains are defined on an Agent for a 278 data plane, the DPNs in the topology are available for further 279 configuration. The FPC Agent connects those DPNs to manage their 280 configurations. 282 A FPC Agent configures and manages its DPN(s) according to forwarding 283 policies requested and Attributes provided by the FPC Client. 284 Configuration commands used by the FPC agent to configure its DPN 285 node(s) may be specific to the DPN implementation; consequently the 286 method by which the FPC Agent carries out the specific configuration 287 for its DPN(s) is out of scope for this document. Along with the 288 data models, the FPC Client (on behalf of control-plane and 289 applications) requests that the Agent configures Policies prior to 290 the time when the DPNs start forwarding data for their mobility 291 sessions. 293 This architecture is illustrated in Figure 1. A FPC Agent may be 294 implemented in a network controller that handles multiple DPNs, or 295 (more simply) an FPC Agent may itself be integrated into a DPN. 297 This document does not specify a protocol for the FPC interface; it 298 is out of scope. 300 +-------------------------+ 301 | Mobility Control-Plane | 302 | and | 303 | Applications | 304 |+-----------------------+| 305 || FPC Client || 306 |+----------^------------+| 307 +-----------|-------------+ 308 FPC interface protocol | 309 +---------------+-----------------+ 310 | | 311 Network | | 312 Controller | DPN | 313 +-----------|-------------+ +----------|---------+ 314 |+----------v------------+| |+---------v--------+| 315 || [Data-plane model] || ||[Data-plane model]|| 316 || FPC Agent || || FPC Agent || 317 |+-----------------------+| |+------------------+| 318 |+------------+----------+| | | 319 ||SB Protocol |FPC Client|| | DPN Configuration | 320 || Modules | Module || +--------------------+ 321 |+------^-----+----^-----+| 322 +-------|----------|------+ 323 | | 324 Other | | FPC interface 325 southbound | | protocol 326 protocols | | 327 | +-----------------+ 328 | | 329 DPN | DPN | 330 +----------|---------+ +----------|---------+ 331 |+---------v--------+| |+---------v--------+| 332 || Configuration || ||[Data-plane model]|| 333 || Protocol module || || FPC Agent || 334 |+------------------+| |+------------------+| 335 | | | | 336 | DPN Configuration | | DPN Configuration | 337 +--------------------+ +--------------------+ 339 Figure 1: Reference Forwarding Policy Configuration (FPC) 340 Architecture 342 The FPC architecture supports multi-tenancy; a FPC enabled data-plane 343 supports tenants of multiple mobile operator networks and/or 344 applications. It means that the FPC Client of each tenant connects 345 to the FPC Agent and it MUST partition namespace and data for their 346 data-planes. DPNs on the data-plane may fulfill multiple data-plane 347 roles which are defined per session, domain and tenant. 349 Multi-tenancy permits the paritioning of data-plane entities as well 350 as a common namespace requirement upon FPC Agents and Clients when 351 they use the same Tenant for a common data-plane entity. 353 FPC information models often configuration to fit the specific needs 354 for DPN management of a mobile node's traffic. The FPC interfaces in 355 Figure 1 are the only interfaces required to handle runtime data in a 356 Mobility Context. The Topology and some Policy FPC models MAY be 357 pre-configured; in that case real-time protocol exchanges are not 358 required for them. 360 The information model provides an extensibility mechanism through 361 Templates that permits specialization for the needs of a particular 362 vendor's equipment or future extension of the model presented in this 363 specification. 365 4. FPC Mobility Information Model 367 The FPC information model includes the following components: 369 DPN Information Model, 370 Topology Information Model, 371 Policy Information Model, 372 Mobility-Context, and 373 Monitor, as illustrated in Figure 2. 375 : 376 | 377 +-[FPC Mobility Information Model] 378 | | 379 | +-[Topology Information Model] 380 | | 381 | +-[Policy Information Model] 382 | | 383 | +-[Mobility-Context] 384 | | 385 | +-[Monitor] 386 | 388 Figure 2: FPC Information Model structure 390 4.1. Model Notation and Conventions 392 The following conventions are used to describe the FPC information 393 models. 395 Information model entities (e.g. DPNs, Rules, etc.) are defined in a 396 hierarchical notation where all entities at the same hierarchical 397 level are located on the same left-justified vertical position 398 sequentially. When entities are composed of sub-entities, the sub- 399 entities appear shifted to the right, as shown in Figure 3. 401 | 402 +-[entity2] 403 | +-[entity2.1] 404 | +-[entity2.2] 406 Figure 3: Model Notation - An Example 408 Some entities have one or more qualifiers placed on the right hand 409 side of the element definition in angle-brackets. Common types 410 include: 412 List: A collection of entities (some could be duplicated) 414 Set: A nonempty collection of entities without duplications 416 Name: A human-readable string 418 Key: A unique value. We distinguish 3 types of keys: 420 U-Key: A key unique across all Tenants. U-Key spaces typically 421 involve the use of registries or language specific mechanisms 422 that guarantee universal uniqueness of values. 424 G-Key: A key unique within a Tenant 426 L-Key: A key unique within a local namespace. For example, there 427 may exist interfaces with the same name, e.g. "if0", in two 428 different DPNs but there can only be one "if0" within each DPN 429 (i.e. its local Interface-Key L-Key space). 431 Each entity or attribute may be optional (O) or mandatory (M). 432 Entities that are not marked as optional are mandatory. 434 The following example shows 3 entities: 435 -- Entity1 is a globally unique key, and optionally can have 436 an associated Name 437 -- Entity2 is a list 438 -- Entity3 is a set and is optional 439 + 440 | 441 +-[entity1] (M), (O) 442 +-[entity2] 443 +-[entity3] (O) 444 | 445 + 447 Figure 4 449 When expanding entity1 into a modeling language such as YANG it would 450 result in two values: entity1-Key and entity1-Name. 452 To encourage re-use, FPC defines indexed sets of various entity 453 Templates. Other model elements that need access to an indexed model 454 entity contain an attribute which is always denoted as "entity-Key". 455 When a Key attribute is encountered, the referencing model element 456 may supply attribute values for use when the referenced entity model 457 is instantiated. For example: Figure 5 shows 2 entities: 459 EntityA definition references an entityB model element. 461 EntityB model elements are indexed by entityB-Key. 463 Each EntityB model element has an entityB-Key which allows it to be 464 uniquely identified, and a list of Attributes (or, alternatively, a 465 Type) which specifies its form. This allows a referencing entity to 466 create an instance by supplying entityB-Values to be inserted, in a 467 Settings container. 469 . 470 . 471 | 472 +-[entityA] 473 | +-[entityB-Key] 474 | +-[entityB-Values] 475 . 476 . 477 | 478 +-[entityB] (M) 479 | +-[entityB-Type] 480 . 481 . 483 Figure 5: Indexed sets of entities 485 Indexed sets are specified for each of the following kinds of 486 entities: 488 Domain (See Section 4.9.3) 489 DPN (See Section 4.9.4) 490 Policy (See Section 4.9.5) 491 Rule (See Section 4.9.5) 492 Descriptor (See Figure 12) 493 Action (See Figure 12) 494 Service-Group (See Section 4.9.2, and 495 Mobility-Context (See Section 4.9.6) 497 As an example, for a Domain entity, there is a corresponding 498 attribute denoted as "Domain-Key" whose value can be used to 499 determine a reference to the Domain. 501 4.2. Templates and Attributes 503 In order to simplify development and maintenance of the needed 504 policies and other objects used by FPC, the Information Models which 505 are presented often have attributes that are not initialized with 506 their final values. When an FPC entity is instantiated according to 507 a template definition, specific values need to be configured for each 508 such attribute. For instance, suppose an entity Template has an 509 Attribute named "IPv4-Address", and also suppose that a FPC Client 510 instantiates the entity and requests that it be installed on a DPN. 511 An IPv4 address will be needed for the value of that Attribute before 512 the entity can be used. 514 +-[Template] (M) 515 | +-[Attributes] (M) 516 | +-[Extensible ~ FALSE] 517 | +-[Entity-State ~ Initial] 518 | +-[Version] 520 Figure 6: Template entities 522 Attributes: A set of Attribute names MAY be included when defining a 523 Template for instantiating FPC entities. 525 Extensible: Determines whether or not entities instantiated from the 526 Template can be extended with new non-mandatory Attributes not 527 originally defined for the Template. Default value is FALSE. If 528 a Template does not explicitly specify this attribute, the default 529 value is considered to be in effect. 531 Entity-State: Either Initial, PartiallyConfigured, Configured, or 532 Active. Default value is Initial. See Section 4.6 for more 533 information about how the Entity-Status changes during the 534 configuration steps of the Entity. 536 Version: Provides a version tag for the Template. 538 The Attributes in an Entity Template may be either mandatory or non- 539 mandatory. Attribute values may also be associated with the 540 attributes in the Entity Template. If supplied, the value may be 541 either assigned with a default value that can be reconfigured later, 542 or the value can be assigned with a static value that cannot be 543 reconfigured later (see Section 4.3). 545 It is possible for a Template to provide values for all of its 546 Attributes, so that no additional values are needed before the entity 547 can made Active. Any instantiation from a Template MUST have at 548 least one Attribute in order to be a useful entity unless the 549 Template has none. 551 4.3. Attribute-Expressions 553 The syntax of the Attribute definition is formatted to make it clear. 554 For every Attribute in the Entity Template, six possibilities are 555 specified as follows: 557 '[Att-Name: ]' Mandatory Attribute is defined, but template does not 558 provide any configured value. 560 '[Att-Name: Att-Value]' Mandatory Attribute is defined, and has a 561 statically configured value. 563 '[Att-Name: ~ Att-Value]' Mandatory Attribute is defined, and has a 564 default value. 566 '[Att-Name]' Non-mandatory Attribute may be included but template 567 does not provide any configured value. 569 '[Att-Name = Att-Value]' Non-mandatory Attribute may be included and 570 has a statically configured value. 572 '[Att-Name ~ Att-Value]' Non-mandatory Attribute may be included and 573 has a default value. 575 So, for example, a default value for a non-mandatory IPv4-Address 576 attribute would be denoted by [IPv4-Address ~ 127.0.0.1]. 578 After a FPC Client identifies which additional Attributes have been 579 configured to be included in an instantiated entity, those configured 580 Attributes MUST NOT be deleted by the FPC Agent. Similarly, any 581 statically configured value for an entity Attribute MUST NOT be 582 changed by the FPC Agent. 584 Whenever there is danger of confusion, the fully qualified Attribute 585 name MUST be used when supplying needed Attribute Values for a 586 structured Attribute. 588 4.4. Attribute Value Types 590 For situations in which the type of an attribute value is required, 591 the following syntax is recommended. To declare than an attribute 592 has data type "foo", typecast the attribute name by using the 593 parenthesized data type (foo). So, for instance, [(float) Max- 594 Latency-in-ms:] would indicate that the mandatory Attribute "Max- 595 Latency-in-ms" requires to be configured with a floating point value 596 before the instantiated entity could be used. Similarly, [(float) 597 Max-Latency-in-ms: 9.5] would statically configure a floating point 598 value of 9.5 to the mandatory Attribute "Max-Latency-in-ms". 600 4.5. Namespace and Format 602 The identifiers and names in FPC models which reside in the same 603 Tenant must be unique. That uniqueness must be maintained by all 604 Clients, Agents and DPNs that support the Tenant. The Tenant 605 namespace uniqueness MUST be applied to all elements of the tenant 606 model, i.e. Topology, Policy and Mobility models. 608 When a Policy needs to be applied to Mobility-Contexts in all Tenants 609 on an Agent, the Agent SHOULD define that policy to be visible by all 610 Tenants. In this case, the Agent assigns a unique identifier in the 611 Agent namespace and copies the values to each Tenant. This 612 effectively creates a U-Key although only a G-Key is required within 613 the Tenant. 615 The notation for identifiers can utilize any format with agreement 616 between data-plane agent and client operators. The formats include 617 but are not limited to Globally Unique IDentifiers (GUIDs), 618 Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names 619 (FQDNs), Fully Qualified Path Names (FQPNs) and Uniform Resource 620 Identifiers (URIs). The FPC model does not limit the format, which 621 could dictate the choice of FPC protocol. Nevertheless, the 622 identifiers which are used in a Mobility model should be considered 623 to efficiently handle runtime parameters. 625 4.6. Configuring Attribute Values 627 Attributes of Information Model components such as policy templates 628 are configured with values as part of FPC configuration operations. 629 There may be several such configuration operations before the 630 template instantiation is fully configured. 632 Entity-Status indicates when an Entity is usable within a DPN. This 633 permits DPN design tradeoffs amongst local storage (or other 634 resources), over the wire request size and the speed of request 635 processing. For example, DPN designers with constrained systems MAY 636 only house entities whose status is Active which may result in 637 sending over all policy information with a Mobility-Context request. 638 Storing information elements with an entity status of 639 "PartiallyConfigured" on the DPN requires more resources but can 640 result in smaller over the wire FPC communication and request 641 processing efficiency. 643 When the FPC Client instantiates a Policy from a Template, the 644 Policy-Status is "Initial". When the FPC Client sends the policy to 645 a FPC Agent for installation on a DPN, the Client often will 646 configure appropriate attribute values for the installation, and 647 accordingly changes the Policy-Status to "PartiallyConfigured" or 648 "Configured". The FPC Agent will also configure Domain-specific 649 policies and DPN-specific policies on the DPN. When configured to 650 provide particular services for mobile nodes, the FPC Agent will 651 apply whatever service-specific policies are needed on the DPN. When 652 a mobile node attaches to the network data-plane within the topology 653 under the jurisdiction of a FPC Agent, the Agent may apply policies 654 and settings as appropriate for that mobile node. Finally, when the 655 mobile node launches new flows, or quenches existing flows, the FPC 656 Agent, on behalf of the FPC Client, applies or deactivates whatever 657 policies and attribute values are appropriate for managing the flows 658 of the mobile node. When a "Configured" policy is de-activated, 659 Policy-Status is changed to be "Active". When an "Active" policy is 660 activated, Policy-Status is changed to be "Configured". 662 Attribute values in DPN resident Policies may be configured by the 663 FPC Agent as follows: 665 Domain-Policy-Configuration: Values for Policy attributes that are 666 required for every DPN in the domain. 668 DPN-Policy-Configuration: Values for Policy attributes that are 669 required for every policy configured on this DPN. 671 Service-Group-Policy-Configuration: Values for Policy attributes 672 that are required to carry out the intended Service of the Service 673 Group. 675 MN-Policy-Configuration: Values for Policy attributes that are 676 required for all traffic to/from a particular mobile node. 678 Service-Data-Flow-Policy-Configuration: Values for Policy attributes 679 that are required for traffic belonging to a particular set of 680 flows on the mobile node. 682 Any configuration changes MAY also supply updated values for existing 683 default attribute values that may have been previously configured on 684 the DPN resident policy. 686 Entity blocks describe the format of the policy configurations. 688 4.7. Entity Configuration Blocks 690 As described in Section 4.6, a Policy Template may be configured in 691 several stages by configuring default or missing values for 692 Attributes that do not already have statically configured values. A 693 Policy-Configuration is the combination of a Policy-Key (to identify 694 the Policy Template defining the Attributes) and the currently 695 configured Attribute Values to be applied to the Policy Template. 696 Policy-Configurations MAY add attributes to a Template if Extensible 697 is True. They MAY also refine existing attributes by: 699 assign new values if the Attribute is not static 701 make attributes static if they were not 703 make an attribute mandatory 705 A Policy-Configuration MUST NOT define or refine an attribute twice. 706 More generally, an Entity-Configuration can be defined for any 707 configurable Indexed Set to be the combination of the Entity-Key 708 along with a set of Attribute-Expressions that supply configuration 709 information for the entity's Attributes. Figure 7 shows a schematic 710 representation for such Entity Configuration Blocks. 712 [Entity Configuration Block] 713 | +-[Entity-Key] (M) 714 | +-[Attribute-Expression] (M) 716 Figure 7: Entity Configuration Block 718 This document makes use of the following kinds of Entity 719 Configuration Blocks: 721 Descriptor-Configuration 723 Action-Configuration 725 Rule-Configuration 727 Interface-Configuration 729 Service-Group-Configuration 731 Domain-Policy-Configuration 733 DPN-Policy-Configuration 735 Policy-Configuration 737 MN-Policy-Configuration 739 Service-Data-Flow-Policy-Configuration 741 4.8. Information Model Checkpoint 743 The Information Model Checkpoint permits Clients and Tenants with 744 common scopes, referred to in this specification as Checkpoint 745 BaseNames, to track the state of provisioned information on an Agent. 746 The Agent records the Checkpoint BaseName and Checkpoint value set by 747 a Client. When a Client attaches to the Agent it can query to 748 determine the amount of work that must be executed to configure the 749 Agent to a specific BaseName / checkpoint revision. 751 Checkpoints are defined for the following information model 752 components: 754 Service-Group 755 DPN Information Model 757 Domain Information Model 759 Policy Information Model 761 4.9. Information Model Components 763 4.9.1. Topology Information Model 765 The Topology structure specifies DPNs and the communication paths 766 between them. A network management system can use the Topology to 767 select the most appropriate DPN resources for handling specific 768 session flows. 770 The Topology structure is illustrated in Figure 8 (for definitions 771 see Section 2): 773 | 774 +-[Topology Information Model] 775 | +-[Extensible: FALSE] 776 | +-[Service-Group] 777 | +-[DPN] 778 | +-[Domain] 780 Figure 8: Topology Structure 782 4.9.2. Service-Group 784 Service-Group-Set is collection of DPN interfaces serving some data- 785 plane purpose including but not limited to DPN Interface selection to 786 fulfill a Mobility-Context. Each Group contains a list of DPNs 787 (referenced by DPN-Key) and selected interfaces (referenced by 788 Interface-Key). The Interfaces are listed explicitly (rather than 789 referred implicitly by its specific DPN) so that every Interface of a 790 DPN is not required to be part of a Group. The information provided 791 is sufficient to ensure that the Protocol, Settings (stored in the 792 Service-Group-Configuration) and Features relevant to successful 793 interface selection is present in the model. 795 | 796 +-[Service-Group] , (O) 797 | +-[Extensible: FALSE] 798 | +-[Role] 799 | +-[Protocol] 800 | +-[Feature] (O) 801 | +-[Service-Group-Configuration] (O) 802 | +-[DPN-Key] 803 | | +-[Referenced-Interface] 804 | | | +-[Interface-Key] 805 | | | +-[Peer-Service-Group-Key] (O) 807 Figure 9: Service Group 809 Each Service-Group element contains the following information: 811 Service-Group-Key: A unique ID of the Service-Group. 813 Service-Group-Name: A human-readable display string. 815 Role: The role (MAG, LMA, etc.) of the device hosting the interfaces 816 of the DPN Group. 818 Protocol-Set: The set of protocols supported by this interface 819 (e.g., PMIP, S5-GTP, S5-PMIP etc.). The protocol MAY be only its 820 name, e.g. 'gtp', but many protocols implement specific message 821 sets, e.g. s5-pmip, s8-pmip. When the Service-Group supports 822 specific protocol message sub-subsets the Protocol value MUST 823 include this information. 825 Feature-Set: An optional set of static features which further 826 determine the suitability of the interface to the desired 827 operation. 829 Service-Group-Configuration-Set: An optional set of configurations 830 that further determine the suitability of an interface for the 831 specific request. For example: SequenceNumber=ON/OFF. 833 DPN-Key-Set: A key used to identify the DPN. 835 Referenced-Interface-Set: The DPN Interfaces and peer Service-Groups 836 associated with them. Each entry contains 838 Interface-Key: A key that is used together with the DPN-Key, to 839 create a key that is refers to a specific DPN interface 840 definition. 842 Peer-Service-Group-Key: Enables location of the peer Service- 843 Group for this Interface. 845 4.9.3. Domain Information Model 847 A Domain-Set represents a group of heterogeneous Topology resources 848 typically sharing a common administrative authority. Other models, 849 outside of the scope of this specification, provide the details for 850 the Domain. 852 | 853 +-[Domain] , (O) 854 | +-[Domain-Policy-Configuration] (O) 855 | 857 Figure 10: Domain Information Model 859 Each Domain entry contains the following information: 861 Domain-Key: Identifies and enables reference to the Domain. 863 Domain-Name: A human-readable display string naming the Domain. 865 4.9.4. DPN Information Model 867 A DPN-Set contains some or all of the DPNs in the Tenant's network. 868 Some of the DPNs in the Set may be identical in functionality and 869 only differ by their Key. 871 | 872 +-[DPN] , (O) 873 | +-[Extensible: FALSE] 874 | +-[Interface] 875 | | +-[Role] 876 | | +-[Protocol] 877 | | +-[Interface-Configuration] (O) 878 | +-[Domain-Key] 879 | +-[Service-Group-Key] (O) 880 | +-[DPN-Policy-Configuration] (M) 881 | +-[DPN-Resource-Mapping-Reference] (O) 883 Figure 11: DPN Information Model 885 Each DPN entry contains the following information: 887 DPN-Key: A unique Identifier of the DPN. 889 DPN-Name: A human-readable display string. 891 Domain-Key: A Key providing access to the Domain information about 892 the Domain in which the DPN resides. 894 Interface-Set: The Interface-Set references all interfaces (through 895 which data packets are received and transmitted) available on the 896 DPN. Each Interface makes use of attribute values that are 897 specific to that interface, for example, the MTU size. These do 898 not affect the DPN selection of active or enabled interfaces. 899 Interfaces contain the following information: 901 Role: The role (MAG, LMA, PGW, AMF, etc.) of the DPN. 903 Protocol (Set): The set of protocols supported by this interface 904 (e.g., PMIP, S5-GTP, S5-PMIP etc.). The protocol MAY implement 905 specific message sets, e.g. s5-pmip, s8-pmip. When a protocol 906 implements such message sub-subsets the Protocol value MUST 907 include this information. 909 Interface-Configuration-Set: Configurable settings that further 910 determine the suitability of an interface for the specific 911 request. For example: SequenceNumber=ON/OFF. 913 Service-Group-Set: The Service-Group-Set references all of the 914 Service-Groups which have been configured using Interfaces hosted 915 on this DPN. The purpose of a Service-Group is not to describe 916 each interface of each DPN, but rather to indicate interface types 917 for use during the DPN selection process, when a DPN with specific 918 interface capabilities is required. 920 DPN-Policy-Configuration: A list of Policies that have been 921 configured on this DPN. Some may have values for all attributes, 922 and some may require further configuration. Each Policy- 923 Configuration has a key to enable reference to its Policy- 924 Template. Each Policy-Configuration also has been configured to 925 supply missing and non-default values to the desired Attributes 926 defined within the Policy-Template. 928 DPN-Resource-Mapping-Reference (O): A reference to the underlying 929 implementation, e.g. physical node, software module, etc. that 930 supports this DPN. Further specification of this attribute is out 931 of scope for this document. 933 4.9.5. Policy Information Model 935 The Policy Information Model defines and identifies Rules for 936 enforcement at DPNs. A Policy is basically a set of Rules that are 937 to be applied to each incoming or outgoing packet at a DPN interface. 938 Rules comprise Descriptors and a set of Actions. The Descriptors, 939 when evaluated, determine whether or not a set of Actions will be 940 performed on the packet. The Policy structure is independent of a 941 policy context. 943 In addition to the Policy structure, the Information Model (per 944 Section 4.9.6) defines Mobility-Context. Each Mobility-Context may 945 be configured with appropriate Attribute values, for example 946 depending on the identity of a mobile node. 948 Traffic descriptions are defined in Descriptors, and treatments are 949 defined separately in Actions. A Rule-Set binds Descriptors and 950 associated Actions by reference, using Descriptor-Key and Action-Key. 951 A Rule-Set is bound to a policy in the Policy-Set (using Policy-Key), 952 and the Policy references the Rule definitions (using Rule-Key). 954 | 955 +-[Policy Information Model] 956 | +-[Extensible:] 957 | +-[Policy-Template] (M) 958 | | +-[Policy-Configuration] (O) 959 | | +-[Rule-Template-Key] (M) 960 | | | +-[Precedence] (M) 961 | +-[Rule-Template] (M) 962 | | +-[Descriptor-Match-Type] (M) 963 | | +-[Descriptor-Configuration] (M) 964 | | | +-[Direction] (O) 965 | | +-[Action-Configuration] (M) 966 | | | +-[Action-Order] (M) 967 | | +-[Rule-Configuration] (O) 968 | +-[Descriptor-Template] (M) 969 | | +-[Descriptor-Type] (O) 970 | | +-[Attribute-Expression] (M) 971 | +-[Action-Template] (M) 972 | +-[Action-Type] (O) 973 | | +-[Attribute-Expression] (M) 975 Figure 12: Policy Information Model 977 The Policy structure defines Policy-Set, Rule-Set, Descriptor-Set, 978 and Action-Set, as follows: 980 Policy-Template: A set of Policy structures, indexed by 981 Policy-Key, each of which is determined by a list of Rules 982 referenced by their Rule-Key. Each Policy structure contains the 983 following: 985 Policy-Key: Identifies and enables reference to this Policy 986 definition. 988 Rule-Template-Key: Enables reference to a Rule template 989 definition. 991 Rule-Precedence: For each Rule identified by a Rule-Template-Key 992 in the Policy, specifies the order in which that Rule must be 993 applied. The lower the numerical value of Precedence, the 994 higher the rule precedence. Rules with equal precedence MAY be 995 executed in parallel if supported by the DPN. If this value is 996 absent, the rules SHOULD be applied in the order in which they 997 appear in the Policy. 999 Rule-Template-Set: A set of Rule Template definitions indexed by 1000 Rule-Key. Each Rule is defined by a list of Descriptors (located 1001 by Descriptor-Key) and a list of Actions (located by Action-Key) 1002 as follows: 1004 Rule-Template-Key: Identifies and enables reference to this Rule 1005 definition. 1007 Descriptor-Match-Type Indicates whether the evaluation of the 1008 Rule proceeds by using conditional-AND, or conditional-OR, on 1009 the list of Descriptors. 1011 Descriptor-Configuration: References a Descriptor template 1012 definition, along with an expression which names the Attributes 1013 for this instantiation from the Descriptor-Template and also 1014 specifies whether each Attribute of the Descriptor has a 1015 default value or a statically configured value, according to 1016 the syntax specified in Section 4.2. 1018 Direction: Indicates if a rule applies to uplink traffic, to 1019 downlink traffic, or to both uplink and downlink traffic. 1020 Applying a rule to both uplink and downlink traffic, in case of 1021 symmetric rules, eliminates the requirement for a separate 1022 entry for each direction. When not present, the direction is 1023 implied by the Descriptor's values. 1025 Action-Configuration: References an Action Template definition, 1026 along with an expression which names the Attributes for this 1027 instantiation from the Action-Template and also specifies 1028 whether each Attribute of the Action has a default value or a 1029 statically configured value, according to the syntax specified 1030 in Section 4.2. 1032 Action-Order: Defines the order in which actions are executed 1033 when the associated traffic descriptor selects the packet. 1035 Descriptor-Template-Set: A set of traffic Descriptor Templates, 1036 each of which can be evaluated on the incoming or outgoing packet, 1037 returning a TRUE or FALSE value, defined as follows: 1039 Descriptor-Template-Key: Identifies and enables reference to 1040 this descriptor template definition. 1042 Attribute-Expression: An expression which defines an Attribute in 1043 the Descriptor-Template and also specifies whether the Template 1044 also defines a default value or a statically configured value 1045 for the Attribute of the Descriptor has, according to the 1046 syntax specified in Section 4.2. 1048 Descriptor-Type: Identifies the type of descriptor, e.g. an IPv6 1049 traffic selector per [RFC6088]. 1051 Action-Template-Set: A set of Action Templates defined as follows: 1053 Action-Template-Key: Identifies and enables reference to this 1054 action template definition. 1056 Attribute-Expression: An expression which defines an Attribute in 1057 the Action-Template and also specifies whether the Template 1058 also defines a default value or a statically configured value 1059 for the Attribute of the Action has, according to the syntax 1060 specified in Section 4.2. 1062 Action-Type: Identifies the type of an action for unambiguous 1063 interpretation of an Action-Value entry. 1065 4.9.6. Mobility-Context Information Model 1067 The Mobility-Context structure holds entries associated with a mobile 1068 node and its mobility sessions (flows). It is created on a DPN 1069 during the mobile node's registration to manage the mobile node's 1070 flows. Flow information is added or deleted from the Mobility- 1071 Context as needed to support new flows or to deallocate resources for 1072 flows that are deactivated. Descriptors are used to characterize the 1073 nature and resource requirement for each flow. 1075 Termination of a Mobility-Context implies termination of all flows 1076 represented in the Mobility-Context, e.g. after deregistration of a 1077 mobile node. If any Child-Contexts are defined, they are also 1078 terminated. 1080 +-[Mobility-Context] 1081 | +-[Extensible:~ FALSE] 1082 | +-[Delegating-IP-Prefix:] (O) 1083 | +-[Parent-Context] (O) 1084 | +-[Child-Context] (O) 1085 | +-[Service-Group-Key] (O) 1086 | +-[Mobile-Node] 1087 | | +-[IP-Address] (O)) 1088 | | +-[MN-Policy-Configuration] 1089 | +-[Domain-Key] 1090 | | +-[Domain-Policy-Configuration] 1091 | +-[DPN-Key] 1092 | | +-[Role] 1093 | | +-[DPN-Policy-Configuration] 1094 | | +-[ServiceDataFlow] (O) 1095 | | | +-[Service-Group-Key] (O) 1096 | | | +-[Interface-Key] 1097 | | | +-[ServiceDataFlow-Policy- 1098 Configuration] (O) 1099 | | | | +-[Direction] 1101 Figure 13: Mobility-Context Information Model 1103 The Mobility-Context Substructure holds the following entries: 1105 Mobility-Context-Key: Identifies a Mobility-Context 1107 Delegating-IP-Prefix-Set: Delegated IP Prefixes assigned to the 1108 Mobility-Context 1110 Parent-Context: If present, a Mobility Context from which the 1111 Attributes and Attribute Values of this Mobility Context are 1112 inherited. 1114 Child-Context-Set: A set of Mobility Contexts which inherit the 1115 Attributes and Attribute Values of this Mobility Context. 1117 Service-Group-Key: Service-Group(s) used during DPN assignment and 1118 re-assignment. 1120 Mobile-Node: Attributes specific to the Mobile Node. It contains 1121 the following 1123 IP-Address-Set IP addresses assigned to the Mobile Node. 1125 MN-Policy-Configuration-Set For each MN-Policy in the set, a key 1126 and relevant information for the Policy Attributes. 1128 Domain-Key: Enables access to a Domain instance. 1130 Domain-Policy-Configuration-Set: For each Domain-Policy in the set, 1131 a key and relevant information for the Policy Attributes. 1133 DPN-Key-Set: Enables access to a DPN instance assigned to a 1134 specific role, i.e. this is a Set that uses DPN-Key and Role as a 1135 compound key to access specific set instances. 1137 Role: Role this DPN fulfills in the Mobility-Context. 1139 DPN-Policy-Configuration-Set: For each DPN-Policy in the set, a key 1140 and relevant information for the Policy Attributes. 1142 ServiceDataFlow-Key-Set: Characterizes a traffic flow that has been 1143 configured (and provided resources) on the DPN to support data- 1144 plane traffic to and from the mobile device. 1146 Service-Group-Key: Enables access to a Service-Group instance. 1148 Interface-Key-Set: Assigns the selected interface of the DPN. 1150 ServiceDataFlow-Policy-Configuration-Set: For each Policy in the 1151 set, a key and relevant information for the Policy Attributes. 1153 Direction: Indicates if the reference Policy applies to 1154 uplink or downlink traffic, or to both, uplink- and downlink 1155 traffic. Applying a rule to both, uplink- and downlink 1156 traffic, in case of symmetric rules, allows omitting a 1157 separate entry for each direction. When not present the 1158 value is assumed to apply to both directions. 1160 4.9.7. Monitor Information Model 1162 Monitors provide a mechanism to produce reports when events occur. A 1163 Monitor will have a target that specifies what is to be watched. 1165 The attribute/entity to be monitored places certain constraints on 1166 the configuration that can be specified. For example, a Monitor 1167 using a Threshold configuration cannot be applied to a Mobility- 1168 Context, because it does not have a threshold. Such a monitor 1169 configuration could be applied to a numeric threshold property of a 1170 Context. 1172 | 1173 +-[Monitor] 1174 | +-[Extensible:] 1175 | +-[Target:] 1176 | +-[Deferrable] 1177 | +-[Configuration] 1179 Figure 14: Monitor Substructure 1181 Monitor-Key: Identifies the Monitor. 1183 Target: Description of what is to be monitored. This can be a 1184 Service Data Flow, a Policy installed upon a DPN, values of a 1185 Mobility-Context, etc. The target name is the absolute 1186 information model path (separated by '/') to the attribute / 1187 entity to be monitored. 1189 Deferrable: Indicates that a monitoring report can be delayed up to 1190 a defined maximum delay, set in the Agent, for possible bundling 1191 with other reports. 1193 Configuration: Determined by the Monitor subtype. The monitor 1194 report is specified by the Configuration. Four report types are 1195 defined: 1197 * "Periodic" reporting specifies an interval by which a 1198 notification is sent. 1200 * "Event-List" reporting specifies a list of event types that, if 1201 they occur and are related to the monitored attribute, will 1202 result in sending a notification. 1204 * "Scheduled" reporting specifies the time (in seconds since Jan 1205 1, 1970) when a notification for the monitor should be sent. 1206 Once this Monitor's notification is completed the Monitor is 1207 automatically de-registered. 1209 * "Threshold" reporting specifies one or both of a low and high 1210 threshold. When these values are crossed a corresponding 1211 notification is sent. 1213 5. Security Considerations 1215 Detailed protocol implementations for DMM Forwarding Policy 1216 Configuration must ensure integrity of the information exchanged 1217 between a FPC Client and a FPC Agent. Required Security Associations 1218 may be derived from co-located functions, which utilize the FPC 1219 Client and FPC Agent respectively. 1221 General usage of FPC MUST consider the following: 1223 FPC Naming Section 4.5 permits arbitrary string values but a user 1224 MUST avoid placing sensitive or vulnerable information in those 1225 values. 1227 Policies that are very narrow and permit the identification of 1228 specific traffic, e.g. that of a single user, SHOULD be avoided. 1230 6. IANA Considerations 1232 TBD 1234 7. Work Team Participants 1236 Participants in the FPSM work team discussion include Satoru 1237 Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick 1238 Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred 1239 Templin. 1241 8. References 1243 8.1. Normative References 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, 1247 DOI 10.17487/RFC2119, March 1997, . 1250 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 1251 "Traffic Selectors for Flow Bindings", RFC 6088, 1252 DOI 10.17487/RFC6088, January 2011, . 1255 8.2. Informative References 1257 [I-D.bertz-dime-policygroups] 1258 Bertz, L. and M. Bales, "Diameter Policy Groups and Sets", 1259 draft-bertz-dime-policygroups-06 (work in progress), June 1260 2018. 1262 [I-D.ietf-dmm-deployment-models] 1263 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1264 Architectural Considerations", draft-ietf-dmm-deployment- 1265 models-04 (work in progress), May 2018. 1267 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1268 Korhonen, "Requirements for Distributed Mobility 1269 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1270 . 1272 Appendix A. Implementation Status 1274 Three FPC Agent implementations have been made to date. The first 1275 was based upon Version 03 of the draft and followed Model 1. The 1276 second follows Version 04 of the document. Both implementations were 1277 OpenDaylight plug-ins developed in Java by Sprint. Version 04 is now 1278 primarily enhanced by GS Labs. Version 03 was known as fpcagent and 1279 version 04's implementation is simply referred to as 'fpc'. A third 1280 has been developed on an ONOS Controller for use in MCORD projects. 1282 fpcagent's intent was to provide a proof of concept for FPC Version 1283 03 Model 1 in January 2016 and research various errors, corrections 1284 and optimizations that the Agent could make when supporting multiple 1285 DPNs. 1287 As the code developed to support OpenFlow and a proprietary DPN from 1288 a 3rd party, several of the advantages of a multi-DPN Agent became 1289 obvious including the use of machine learning to reduce the number of 1290 Flows and Policy entities placed on the DPN. This work has driven 1291 new efforts in the DIME WG, namely Diameter Policy Groups 1292 [I-D.bertz-dime-policygroups]. 1294 A throughput performance of tens per second using various NetConf 1295 based solutions in OpenDaylight made fpcagent, based on version 03, 1296 undesirable for call processing. The RPC implementation improved 1297 throughput by an order of magnitude but was not useful based upon 1298 FPC's Version 03 design using two information models. During this 1299 time the features of version 04 and its converged model became 1300 attractive and the fpcagent project was closed in August 2016. 1301 fpcagent will no longer be developed and will remain a proprietary 1302 implementation. 1304 The learnings of fpcagent has influenced the second project, fpc. 1305 Fpc is also an OpenDaylight project but is an open source release as 1306 the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/ 1307 Project_Proposals:FpcAgent). This project is scoped to be a fully 1308 compliant FPC Agent that supports multiple DPNs including those that 1309 communicate via OpenFlow. The following features present in this 1310 draft and others developed by the FPC development team have already 1311 led to an order of magnitude improvement. 1313 Migration of non-realtime provisioning of entities such as 1314 topology and policy allowed the implementation to focus only on 1315 the rpc. 1317 Using only 5 messages and 2 notifications has also reduced 1318 implementation time. 1320 Command Sets, an optional feature in this specification, have 1321 eliminated 80% of the time spent determining what needs to be 1322 done with a Context during a Create or Update operation. 1324 Op Reference is an optional feature modeled after video delivery. 1325 It has reduced unnecessary cache lookups. It also has the 1326 additional benefit of allowing an Agent to become cacheless and 1327 effectively act as a FPC protocol adapter remotely with multi-DPN 1328 support or co-located on the DPN in a single-DPN support model. 1330 Multi-tenant support allows for Cache searches to be partitioned 1331 for clustering and performance improvements. This has not been 1332 capitalized upon by the current implementation but is part of the 1333 development roadmap. 1335 Use of Contexts to pre-provision policy has also eliminated any 1336 processing of Ports for DPNs which permitted the code for 1337 CONFIGURE and CONF_BUNDLE to be implemented as a simple nested 1338 FOR loops (see below). 1340 Initial v04 performance results without code optimizations or tuning 1341 allow reliable provisioning of 1K FPC Mobility-Contexts processed per 1342 second on a 12 core server. This results in 2x the number of 1343 transactions on the southbound interface to a proprietary DPN API on 1344 the same machine. 1346 fpc currently supports the following: 1348 1 proprietary DPN API 1350 Policy and Topology as defined in this 1351 specification using OpenDaylight North Bound 1352 Interfaces such as NetConf and RestConf 1354 CONFIG and CONF_BUNDLE (all operations) 1356 DPN assignment, Tunnel allocations and IPv4 1357 address assignment by the Agent or Client. 1359 Immediate Response is always an 1360 OK_NOTIFY_FOLLOWS. 1362 assignment system (receives rpc call): 1363 perform basic operation integrity check 1364 if CONFIG then 1365 goto assignments 1366 if assignments was ok then 1367 send request to activation system 1368 respond back to client with assignment data 1369 else 1370 send back error 1371 end if 1372 else if CONF_BUNDLE then 1373 for each operation in bundles 1374 goto assignments 1375 if assignments was ok then 1376 hold onto data 1377 else 1378 return error with the assignments that occurred in 1379 prior operations (best effort) 1380 end if 1381 end for 1382 send bundles to activation systems 1383 end if 1385 assignments: 1386 assign DPN, IPv4 Address and/or tunnel info as required 1387 if an error occurs undo all assignments in this operation 1388 return result 1390 activation system: 1391 build cache according to op-ref and operation type 1392 for each operation 1393 for each Context 1394 for each DPN / direction in Context 1395 perform actions on DPN according to Command Set 1396 end for 1397 end for 1398 end for 1399 commit changes to in memory cache 1400 log transaction for tracking and notification 1401 (CONFIG_RESULT_NOTIFY) 1403 Figure 15: fpc pseudo code 1405 For further information please contact Lyle Bertz who is also a co- 1406 author of this document. 1408 NOTE: Tenant support requires binding a Client ID to a Tenant ID (it 1409 is a one to many relation) but that is outside of the scope of this 1410 specification. Otherwise, the specification is complete in terms of 1411 providing sufficient information to implement an Agent. 1413 Authors' Addresses 1415 Satoru Matsushima 1416 SoftBank 1417 1-9-1,Higashi-Shimbashi,Minato-Ku 1418 Tokyo 105-7322 1419 Japan 1421 Email: satoru.matsushima@g.softbank.co.jp 1423 Lyle Bertz 1424 6220 Sprint Parkway 1425 Overland Park KS, 66251 1426 USA 1428 Email: lylebe551144@gmail.com 1430 Marco Liebsch 1431 NEC Laboratories Europe 1432 NEC Europe Ltd. 1433 Kurfuersten-Anlage 36 1434 D-69115 Heidelberg 1435 Germany 1437 Phone: +49 6221 4342146 1438 Email: liebsch@neclab.eu 1440 Sri Gundavelli 1441 Cisco 1442 170 West Tasman Drive 1443 San Jose, CA 95134 1444 USA 1446 Email: sgundave@cisco.com 1448 Danny Moses 1450 Email: danny.moses@intel.com 1451 Charles E. Perkins 1452 Futurewei Inc. 1453 2330 Central Expressway 1454 Santa Clara, CA 95050 1455 USA 1457 Phone: +1-408-330-4586 1458 Email: charliep@computer.org