idnits 2.17.00 (12 Aug 2021) /tmp/idnits5108/draft-ietf-dmm-fpc-cpdp-14.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 (23 September 2020) is 598 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: 27 March 2021 Sprint 6 M. Liebsch 7 NEC 8 S. Gundavelli 9 Cisco 10 D. Moses 11 Intel Corporation 12 C.E. Perkins 13 Futurewei 14 23 September 2020 16 Protocol for Forwarding Policy Configuration (FPC) in DMM 17 draft-ietf-dmm-fpc-cpdp-14 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 https://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 27 March 2021. 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. FPC Design Objectives and Deployment . . . . . . . . . . . . 6 67 4. FPC Mobility Information Model . . . . . . . . . . . . . . . 9 68 4.1. Model Notation and Conventions . . . . . . . . . . . . . 10 69 4.2. Templates and Attributes . . . . . . . . . . . . . . . . 12 70 4.3. Attribute-Expressions . . . . . . . . . . . . . . . . . . 13 71 4.4. Attribute Value Types . . . . . . . . . . . . . . . . . . 14 72 4.5. Namespace and Format . . . . . . . . . . . . . . . . . . 14 73 4.6. Configuring Attribute Values . . . . . . . . . . . . . . 15 74 4.7. Entity Configuration Blocks . . . . . . . . . . . . . . . 16 75 4.8. Information Model Checkpoint . . . . . . . . . . . . . . 17 76 4.9. Information Model Components . . . . . . . . . . . . . . 18 77 4.9.1. Topology Information Model . . . . . . . . . . . . . 18 78 4.9.2. Service-Group . . . . . . . . . . . . . . . . . . . . 18 79 4.9.3. Domain Information Model . . . . . . . . . . . . . . 20 80 4.9.4. DPN Information Model . . . . . . . . . . . . . . . . 20 81 4.9.5. Policy Information Model . . . . . . . . . . . . . . 22 82 4.9.6. Mobility-Context Information Model . . . . . . . . . 24 83 4.9.7. Monitor Information Model . . . . . . . . . . . . . . 26 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 7. Work Team Participants . . . . . . . . . . . . . . . . . . . 28 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 89 8.2. Informative References . . . . . . . . . . . . . . . . . 28 90 Appendix A. Implementation Status . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 93 1. Introduction 95 This document describes Forwarding Policy Configuration (FPC), a 96 system for managing the separation of control-plane and data-plane. 97 FPC enables flexible mobility management using FPC client and FPC 98 agent functions. A FPC agent exports an abstract interface 99 representing the data-plane. To configure data-plane nodes and 100 functions, the FPC client uses the interface to the data-plane 101 offered by the FPC agent. 103 Control planes of mobility management systems, or related 104 applications which require data-plane control, can utilize the FPC 105 client at various levels of abstraction. FPC operations are capable 106 of directly configuring a single Data-Plane Node (DPN), as well as 107 multiple DPNs, as determined by the data-plane models exported by the 108 FPC agent. 110 A FPC agent represents the data-plane operation according to several 111 basic information models. A FPC agent also provides access to 112 Monitors, which produce reports when triggered by events or FPC 113 Client requests regarding Mobility Contexts, DPNs or the Agent. 115 To manage mobility sessions, the FPC client assembles applicable sets 116 of forwarding policies from the data model, and configures them on 117 the appropriate FPC Agent. The Agent then renders those policies 118 into specific configurations for each DPN at which mobile nodes are 119 attached. The specific protocols and configurations to configure a 120 DPN from a FPC Agent are outside the scope of this document. 122 A DPN is a logical entity that performs data-plane operations (packet 123 movement and management). It may represent a physical DPN unit, a 124 sub-function of a physical DPN or a collection of physical DPNs 125 (i.e., a "virtual DPN"). A DPN may be virtual -- it may export the 126 FPC DPN Agent interface, but be implemented as software that controls 127 other data-plane hardware or modules that may or may not be FPC- 128 compliant. In this document, DPNs are specified without regard for 129 whether the implementation is virtual or physical. DPNs are 130 connected to provide mobility management systems such as access 131 networks, anchors and domains. The FPC agent interface enables 132 establishment of a topology for the forwarding plane. 134 When a DPN is mapped to physical data-plane equipment, the FPC client 135 can have complete knowledge of the DPN architecture, and use that 136 information to perform DPN selection for specific sessions. On the 137 other hand, when a virtual DPN is mapped to a collection of physical 138 DPNs, the FPC client cannot select a specific physical DPN because it 139 is hidden by the abstraction; only the FPC Agent can address the 140 specific associated physical DPNs. Network architects have the 141 flexibility to determine which DPN-selection capabilities are 142 performed by the FPC Agent (distributed) and which by the FPC client 143 (centralized). In this way, overlay networks can be configured 144 without disclosing detailed knowledge of the underlying hardware to 145 the FPC client and applications. 147 The abstractions in this document are designed to support many 148 different mobility management systems and data-plane functions. The 149 architecture and protocol design of FPC is not tied to specific types 150 of access technologies and mobility protocols. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 Attribute Expression: The definition of a template Property. This 159 includes setting the type, current value, 160 default value and if the attribute is static, 161 i.e. can no longer be changed. 163 Domain: One or more DPNs that form a logical 164 partition of network resources (e.g., a data- 165 plane network under common network 166 administration). A FPC client (e.g., a 167 mobility management system) may utilize a 168 single or multiple domains. 170 DPN: A data-plane node (DPN) is capable of 171 performing data-plane features. For example, 172 DPNs may be switches or routers, regardless 173 of whether they are realized as hardware or 174 purely in software. 176 FPC Client: A FPC Client is integrated with a mobility 177 management system or related application, 178 enabling control over forwarding policy, 179 mobility sessions and DPNs via a FPC Agent. 181 Mobility Context: A Mobility Context contains the data-plane 182 information necessary to efficiently send and 183 receive traffic from a mobile node. This 184 includes policies that are created or 185 modified during the network's operation - in 186 most cases, on a per-flow or per session 187 basis. A Mobility-Context represents the 188 mobility sessions (or flows) which are active 189 on a mobile node. This includes associated 190 runtime attributes, such as tunnel endpoints, 191 tunnel identifiers, delegated prefix(es), 192 routing information, etc. Mobility-Contexts 193 are associated to specific DPNs. Some pre- 194 defined Policies may apply during mobility 195 signaling requests. The Mobility Context 196 supplies information about the policy 197 settings specific to a mobile node and its 198 flows; this information is often quite 199 dynamic. 201 Mobility Session: Traffic to/from a mobile node that is 202 expected to survive reconnection events. 204 Monitor: A reporting mechanism for a list of events 205 that trigger notification messages from a FPC 206 Agent to a FPC Client. 208 Policy: A Policy determines the mechanisms for 209 managing specific traffic flows or packets. 210 Policies specify QoS, rewriting rules for 211 packet processing, etc. A Policy consists of 212 one or more rules. Each rule is composed of 213 a Descriptor and Actions. The Descriptor in 214 a rule identifies packets (e.g., traffic 215 flows), and the Actions apply treatments to 216 packets that match the Descriptor in the 217 rule. Policies can apply to Domains, DPNs, 218 Mobile Nodes, Service-Groups, or particular 219 Flows on a Mobile Node. 221 Property: An attribute-value pair for an instance of a 222 FPC entity. 224 Service-Group: A set of DPN interfaces that support a 225 specific data-plane purpose, e.g. inbound/ 226 outbound, roaming, subnetwork with common 227 specific configuration, etc. 229 Template: A recipe for instantiating FPC entities. 230 Template definitions are accessible (by name 231 or by a key) in an indexed set. A Template 232 is used to create specific instances (e.g., 233 specific policies) by assigning appropriate 234 values into the Template definition via 235 Attribute Expression. 237 Template Configuration The process by which a Template is referenced 238 (by name or by key) and Attribute Expressions 239 are created that change the value, default 240 value or static nature of the Attribute, if 241 permitted. If the Template is Extensible, 242 new attributes MAY be added. 244 Tenant: An operational entity that manages mobility 245 management systems or applications which 246 require data-plane functions. A Tenant 247 defines a global namespace for all entities 248 owned by the Tenant enabling its entities to 249 be used by multiple FPC Clients across 250 multiple FPC Agents. 252 Topology: The DPNs and the links between them. For 253 example, access nodes may be assigned to a 254 Service-Group which peers to a Service-Group 255 of anchor nodes. 257 3. FPC Design Objectives and Deployment 259 Using FPC, mobility control-planes and applications can configure 260 DPNs to perform various mobility management roles as described in 261 [I-D.ietf-dmm-deployment-models]. This fulfills the requirements 262 described in [RFC7333]. 264 This document defines FPC Agent and FPC Client, as well as the 265 information models that they use. The attributes defining those 266 models serve as the protocol elements for the interface between the 267 FPC Agent and the FPC Client. 269 Mobility control-plane applications integrate features offered by the 270 FPC Client. The FPC Client connects to FPC Agent functions. The 271 Client and the Agent communicate based on information models 272 described in Section 4. The models allow the control-plane to 273 configure forwarding policies on the Agent for data-plane 274 communications with mobile nodes. 276 Once the Topology of DPN(s) and domains are defined on an Agent for a 277 data plane, the DPNs in the topology are available for further 278 configuration. The FPC Agent connects those DPNs to manage their 279 configurations. 281 A FPC Agent configures and manages its DPN(s) according to forwarding 282 policies requested and Attributes provided by the FPC Client. 283 Configuration commands used by the FPC agent to configure its DPN 284 node(s) may be specific to the DPN implementation; consequently the 285 method by which the FPC Agent carries out the specific configuration 286 for its DPN(s) is out of scope for this document. Along with the 287 data models, the FPC Client (on behalf of control-plane and 288 applications) requests that the Agent configures Policies prior to 289 the time when the DPNs start forwarding data for their mobility 290 sessions. 292 This architecture is illustrated in Figure 1. A FPC Agent may be 293 implemented in a network controller that handles multiple DPNs, or 294 (more simply) an FPC Agent may itself be integrated into a DPN. 296 This document does not specify a protocol for the FPC interface; it 297 is out of scope. 299 +-------------------------+ 300 | Mobility Control-Plane | 301 | and | 302 | Applications | 303 |+-----------------------+| 304 || FPC Client || 305 |+----------^------------+| 306 +-----------|-------------+ 307 FPC interface protocol | 308 +---------------+-----------------+ 309 | | 310 Network | | 311 Controller | DPN | 312 +-----------|-------------+ +----------|---------+ 313 |+----------v------------+| |+---------v--------+| 314 || [Data-plane model] || ||[Data-plane model]|| 315 || FPC Agent || || FPC Agent || 316 |+-----------------------+| |+------------------+| 317 |+------------+----------+| | | 318 ||SB Protocol |FPC Client|| | DPN Configuration | 319 || Modules | Module || +--------------------+ 320 |+------^-----+----^-----+| 321 +-------|----------|------+ 322 | | 323 Other | | FPC interface 324 southbound | | protocol 325 protocols | | 326 | +-----------------+ 327 | | 328 DPN | DPN | 329 +----------|---------+ +----------|---------+ 330 |+---------v--------+| |+---------v--------+| 331 || Configuration || ||[Data-plane model]|| 332 || Protocol module || || FPC Agent || 333 |+------------------+| |+------------------+| 334 | | | | 335 | DPN Configuration | | DPN Configuration | 336 +--------------------+ +--------------------+ 337 Figure 1: Reference Forwarding Policy Configuration (FPC) 338 Architecture 340 The FPC architecture supports multi-tenancy; a FPC enabled data-plane 341 supports tenants of multiple mobile operator networks and/or 342 applications. It means that the FPC Client of each tenant connects 343 to the FPC Agent and it MUST partition namespace and data for their 344 data-planes. DPNs on the data-plane may fulfill multiple data-plane 345 roles which are defined per session, domain and tenant. 347 Multi-tenancy permits the paritioning of data-plane entities as well 348 as a common namespace requirement upon FPC Agents and Clients when 349 they use the same Tenant for a common data-plane entity. 351 FPC information models often configuration to fit the specific needs 352 for DPN management of a mobile node's traffic. The FPC interfaces in 353 Figure 1 are the only interfaces required to handle runtime data in a 354 Mobility Context. The Topology and some Policy FPC models MAY be 355 pre-configured; in that case real-time protocol exchanges are not 356 required for them. 358 The information model provides an extensibility mechanism through 359 Templates that permits specialization for the needs of a particular 360 vendor's equipment or future extension of the model presented in this 361 specification. 363 4. FPC Mobility Information Model 365 The FPC information model includes the following components: 367 DPN Information Model, 368 Topology Information Model, 369 Policy Information Model, 370 Mobility-Context, and 371 Monitor, as illustrated in Figure 2. 373 : 374 | 375 +-[FPC Mobility Information Model] 376 | | 377 | +-[Topology Information Model] 378 | | 379 | +-[Policy Information Model] 380 | | 381 | +-[Mobility-Context] 382 | | 383 | +-[Monitor] 384 | 386 Figure 2: FPC Information Model structure 388 4.1. Model Notation and Conventions 390 The following conventions are used to describe the FPC information 391 models. 393 Information model entities (e.g. DPNs, Rules, etc.) are defined in a 394 hierarchical notation where all entities at the same hierarchical 395 level are located on the same left-justified vertical position 396 sequentially. When entities are composed of sub-entities, the sub- 397 entities appear shifted to the right, as shown in Figure 3. 399 | 400 +-[entity2] 401 | +-[entity2.1] 402 | +-[entity2.2] 404 Figure 3: Model Notation - An Example 406 Some entities have one or more qualifiers placed on the right hand 407 side of the element definition in angle-brackets. Common types 408 include: 410 List: A collection of entities (some could be duplicated) 412 Set: A nonempty collection of entities without duplications 414 Name: A human-readable string 416 Key: A unique value. We distinguish 3 types of keys: 418 U-Key: A key unique across all Tenants. U-Key spaces typically 419 involve the use of registries or language specific mechanisms 420 that guarantee universal uniqueness of values. 422 G-Key: A key unique within a Tenant 424 L-Key: A key unique within a local namespace. For example, there 425 may exist interfaces with the same name, e.g. "if0", in two 426 different DPNs but there can only be one "if0" within each DPN 427 (i.e. its local Interface-Key L-Key space). 429 Each entity or attribute may be optional (O) or mandatory (M). 430 Entities that are not marked as optional are mandatory. 432 The following example shows 3 entities: 433 -- Entity1 is a globally unique key, and optionally can have 434 an associated Name 435 -- Entity2 is a list 436 -- Entity3 is a set and is optional 437 + 438 | 439 +-[entity1] (M), (O) 440 +-[entity2] 441 +-[entity3] (O) 442 | 443 + 445 Figure 4 447 When expanding entity1 into a modeling language such as YANG it would 448 result in two values: entity1-Key and entity1-Name. 450 To encourage re-use, FPC defines indexed sets of various entity 451 Templates. Other model elements that need access to an indexed model 452 entity contain an attribute which is always denoted as "entity-Key". 453 When a Key attribute is encountered, the referencing model element 454 may supply attribute values for use when the referenced entity model 455 is instantiated. For example: Figure 5 shows 2 entities: 457 EntityA definition references an entityB model element. 459 EntityB model elements are indexed by entityB-Key. 461 Each EntityB model element has an entityB-Key which allows it to be 462 uniquely identified, and a list of Attributes (or, alternatively, a 463 Type) which specifies its form. This allows a referencing entity to 464 create an instance by supplying entityB-Values to be inserted, in a 465 Settings container. 467 . 468 . 469 | 470 +-[entityA] 471 | +-[entityB-Key] 472 | +-[entityB-Values] 473 . 474 . 475 | 476 +-[entityB] (M) 477 | +-[entityB-Type] 478 . 479 . 481 Figure 5: Indexed sets of entities 483 Indexed sets are specified for each of the following kinds of 484 entities: 486 Domain (See Section 4.9.3) 487 DPN (See Section 4.9.4) 488 Policy (See Section 4.9.5) 489 Rule (See Section 4.9.5) 490 Descriptor (See Figure 12) 491 Action (See Figure 12) 492 Service-Group (See Section 4.9.2, and 493 Mobility-Context (See Section 4.9.6) 495 As an example, for a Domain entity, there is a corresponding 496 attribute denoted as "Domain-Key" whose value can be used to 497 determine a reference to the Domain. 499 4.2. Templates and Attributes 501 In order to simplify development and maintenance of the needed 502 policies and other objects used by FPC, the Information Models which 503 are presented often have attributes that are not initialized with 504 their final values. When an FPC entity is instantiated according to 505 a template definition, specific values need to be configured for each 506 such attribute. For instance, suppose an entity Template has an 507 Attribute named "IPv4-Address", and also suppose that a FPC Client 508 instantiates the entity and requests that it be installed on a DPN. 509 An IPv4 address will be needed for the value of that Attribute before 510 the entity can be used. 512 +-[Template] (M) 513 | +-[Attributes] (M) 514 | +-[Extensible ~ FALSE] 515 | +-[Entity-State ~ Initial] 516 | +-[Version] 518 Figure 6: Template entities 520 Attributes: A set of Attribute names MAY be included when defining a 521 Template for instantiating FPC entities. 523 Extensible: Determines whether or not entities instantiated from the 524 Template can be extended with new non-mandatory Attributes not 525 originally defined for the Template. Default value is FALSE. If 526 a Template does not explicitly specify this attribute, the default 527 value is considered to be in effect. 529 Entity-State: Either Initial, PartiallyConfigured, Configured, or 530 Active. Default value is Initial. See Section 4.6 for more 531 information about how the Entity-Status changes during the 532 configuration steps of the Entity. 534 Version: Provides a version tag for the Template. 536 The Attributes in an Entity Template may be either mandatory or non- 537 mandatory. Attribute values may also be associated with the 538 attributes in the Entity Template. If supplied, the value may be 539 either assigned with a default value that can be reconfigured later, 540 or the value can be assigned with a static value that cannot be 541 reconfigured later (see Section 4.3). 543 It is possible for a Template to provide values for all of its 544 Attributes, so that no additional values are needed before the entity 545 can made Active. Any instantiation from a Template MUST have at 546 least one Attribute in order to be a useful entity unless the 547 Template has none. 549 4.3. Attribute-Expressions 551 The syntax of the Attribute definition is formatted to make it clear. 552 For every Attribute in the Entity Template, six possibilities are 553 specified as follows: 555 '[Att-Name: ]' Mandatory Attribute is defined, but template does not 556 provide any configured value. 558 '[Att-Name: Att-Value]' Mandatory Attribute is defined, and has a 559 statically configured value. 561 '[Att-Name: ~ Att-Value]' Mandatory Attribute is defined, and has a 562 default value. 564 '[Att-Name]' Non-mandatory Attribute may be included but template 565 does not provide any configured value. 567 '[Att-Name = Att-Value]' Non-mandatory Attribute may be included and 568 has a statically configured value. 570 '[Att-Name ~ Att-Value]' Non-mandatory Attribute may be included and 571 has a default value. 573 So, for example, a default value for a non-mandatory IPv4-Address 574 attribute would be denoted by [IPv4-Address ~ 127.0.0.1]. 576 After a FPC Client identifies which additional Attributes have been 577 configured to be included in an instantiated entity, those configured 578 Attributes MUST NOT be deleted by the FPC Agent. Similarly, any 579 statically configured value for an entity Attribute MUST NOT be 580 changed by the FPC Agent. 582 Whenever there is danger of confusion, the fully qualified Attribute 583 name MUST be used when supplying needed Attribute Values for a 584 structured Attribute. 586 4.4. Attribute Value Types 588 For situations in which the type of an attribute value is required, 589 the following syntax is recommended. To declare than an attribute 590 has data type "foo", typecast the attribute name by using the 591 parenthesized data type (foo). So, for instance, [(float) Max- 592 Latency-in-ms:] would indicate that the mandatory Attribute "Max- 593 Latency-in-ms" requires to be configured with a floating point value 594 before the instantiated entity could be used. Similarly, [(float) 595 Max-Latency-in-ms: 9.5] would statically configure a floating point 596 value of 9.5 to the mandatory Attribute "Max-Latency-in-ms". 598 4.5. Namespace and Format 600 The identifiers and names in FPC models which reside in the same 601 Tenant must be unique. That uniqueness must be maintained by all 602 Clients, Agents and DPNs that support the Tenant. The Tenant 603 namespace uniqueness MUST be applied to all elements of the tenant 604 model, i.e. Topology, Policy and Mobility models. 606 When a Policy needs to be applied to Mobility-Contexts in all Tenants 607 on an Agent, the Agent SHOULD define that policy to be visible by all 608 Tenants. In this case, the Agent assigns a unique identifier in the 609 Agent namespace and copies the values to each Tenant. This 610 effectively creates a U-Key although only a G-Key is required within 611 the Tenant. 613 The notation for identifiers can utilize any format with agreement 614 between data-plane agent and client operators. The formats include 615 but are not limited to Globally Unique IDentifiers (GUIDs), 616 Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names 617 (FQDNs), Fully Qualified Path Names (FQPNs) and Uniform Resource 618 Identifiers (URIs). The FPC model does not limit the format, which 619 could dictate the choice of FPC protocol. Nevertheless, the 620 identifiers which are used in a Mobility model should be considered 621 to efficiently handle runtime parameters. 623 4.6. Configuring Attribute Values 625 Attributes of Information Model components such as policy templates 626 are configured with values as part of FPC configuration operations. 627 There may be several such configuration operations before the 628 template instantiation is fully configured. 630 Entity-Status indicates when an Entity is usable within a DPN. This 631 permits DPN design tradeoffs amongst local storage (or other 632 resources), over the wire request size and the speed of request 633 processing. For example, DPN designers with constrained systems MAY 634 only house entities whose status is Active which may result in 635 sending over all policy information with a Mobility-Context request. 636 Storing information elements with an entity status of 637 "PartiallyConfigured" on the DPN requires more resources but can 638 result in smaller over the wire FPC communication and request 639 processing efficiency. 641 When the FPC Client instantiates a Policy from a Template, the 642 Policy-Status is "Initial". When the FPC Client sends the policy to 643 a FPC Agent for installation on a DPN, the Client often will 644 configure appropriate attribute values for the installation, and 645 accordingly changes the Policy-Status to "PartiallyConfigured" or 646 "Configured". The FPC Agent will also configure Domain-specific 647 policies and DPN-specific policies on the DPN. When configured to 648 provide particular services for mobile nodes, the FPC Agent will 649 apply whatever service-specific policies are needed on the DPN. When 650 a mobile node attaches to the network data-plane within the topology 651 under the jurisdiction of a FPC Agent, the Agent may apply policies 652 and settings as appropriate for that mobile node. Finally, when the 653 mobile node launches new flows, or quenches existing flows, the FPC 654 Agent, on behalf of the FPC Client, applies or deactivates whatever 655 policies and attribute values are appropriate for managing the flows 656 of the mobile node. When a "Configured" policy is de-activated, 657 Policy-Status is changed to be "Active". When an "Active" policy is 658 activated, Policy-Status is changed to be "Configured". 660 Attribute values in DPN resident Policies may be configured by the 661 FPC Agent as follows: 663 Domain-Policy-Configuration: Values for Policy attributes that are 664 required for every DPN in the domain. 666 DPN-Policy-Configuration: Values for Policy attributes that are 667 required for every policy configured on this DPN. 669 Service-Group-Policy-Configuration: Values for Policy attributes 670 that are required to carry out the intended Service of the Service 671 Group. 673 MN-Policy-Configuration: Values for Policy attributes that are 674 required for all traffic to/from a particular mobile node. 676 Service-Data-Flow-Policy-Configuration: Values for Policy attributes 677 that are required for traffic belonging to a particular set of 678 flows on the mobile node. 680 Any configuration changes MAY also supply updated values for existing 681 default attribute values that may have been previously configured on 682 the DPN resident policy. 684 Entity blocks describe the format of the policy configurations. 686 4.7. Entity Configuration Blocks 688 As described in Section 4.6, a Policy Template may be configured in 689 several stages by configuring default or missing values for 690 Attributes that do not already have statically configured values. A 691 Policy-Configuration is the combination of a Policy-Key (to identify 692 the Policy Template defining the Attributes) and the currently 693 configured Attribute Values to be applied to the Policy Template. 694 Policy-Configurations MAY add attributes to a Template if Extensible 695 is True. They MAY also refine existing attributes by: 697 assign new values if the Attribute is not static 699 make attributes static if they were not 701 make an attribute mandatory 703 A Policy-Configuration MUST NOT define or refine an attribute twice. 704 More generally, an Entity-Configuration can be defined for any 705 configurable Indexed Set to be the combination of the Entity-Key 706 along with a set of Attribute-Expressions that supply configuration 707 information for the entity's Attributes. Figure 7 shows a schematic 708 representation for such Entity Configuration Blocks. 710 [Entity Configuration Block] 711 | +-[Entity-Key] (M) 712 | +-[Attribute-Expression] (M) 714 Figure 7: Entity Configuration Block 716 This document makes use of the following kinds of Entity 717 Configuration Blocks: 719 Descriptor-Configuration 721 Action-Configuration 723 Rule-Configuration 725 Interface-Configuration 727 Service-Group-Configuration 729 Domain-Policy-Configuration 731 DPN-Policy-Configuration 733 Policy-Configuration 735 MN-Policy-Configuration 737 Service-Data-Flow-Policy-Configuration 739 4.8. Information Model Checkpoint 741 The Information Model Checkpoint permits Clients and Tenants with 742 common scopes, referred to in this specification as Checkpoint 743 BaseNames, to track the state of provisioned information on an Agent. 744 The Agent records the Checkpoint BaseName and Checkpoint value set by 745 a Client. When a Client attaches to the Agent it can query to 746 determine the amount of work that must be executed to configure the 747 Agent to a specific BaseName / checkpoint revision. 749 Checkpoints are defined for the following information model 750 components: 752 Service-Group 754 DPN Information Model 756 Domain Information Model 758 Policy Information Model 760 4.9. Information Model Components 762 4.9.1. Topology Information Model 764 The Topology structure specifies DPNs and the communication paths 765 between them. A network management system can use the Topology to 766 select the most appropriate DPN resources for handling specific 767 session flows. 769 The Topology structure is illustrated in Figure 8 (for definitions 770 see Section 2): 772 | 773 +-[Topology Information Model] 774 | +-[Extensible: FALSE] 775 | +-[Service-Group] 776 | +-[DPN] 777 | +-[Domain] 779 Figure 8: Topology Structure 781 4.9.2. Service-Group 783 Service-Group-Set is collection of DPN interfaces serving some data- 784 plane purpose including but not limited to DPN Interface selection to 785 fulfill a Mobility-Context. Each Group contains a list of DPNs 786 (referenced by DPN-Key) and selected interfaces (referenced by 787 Interface-Key). The Interfaces are listed explicitly (rather than 788 referred implicitly by its specific DPN) so that every Interface of a 789 DPN is not required to be part of a Group. The information provided 790 is sufficient to ensure that the Protocol, Settings (stored in the 791 Service-Group-Configuration) and Features relevant to successful 792 interface selection is present in the model. 794 | 795 +-[Service-Group] , (O) 796 | +-[Extensible: FALSE] 797 | +-[Role] 798 | +-[Protocol] 799 | +-[Feature] (O) 800 | +-[Service-Group-Configuration] (O) 801 | +-[DPN-Key] 802 | | +-[Referenced-Interface] 803 | | | +-[Interface-Key] 804 | | | +-[Peer-Service-Group-Key] (O) 806 Figure 9: Service Group 808 Each Service-Group element contains the following information: 810 Service-Group-Key: A unique ID of the Service-Group. 812 Service-Group-Name: A human-readable display string. 814 Role: The role (MAG, LMA, etc.) of the device hosting the interfaces 815 of the DPN Group. 817 Protocol-Set: The set of protocols supported by this interface 818 (e.g., PMIP, S5-GTP, S5-PMIP etc.). The protocol MAY be only its 819 name, e.g. 'gtp', but many protocols implement specific message 820 sets, e.g. s5-pmip, s8-pmip. When the Service-Group supports 821 specific protocol message sub-subsets the Protocol value MUST 822 include this information. 824 Feature-Set: An optional set of static features which further 825 determine the suitability of the interface to the desired 826 operation. 828 Service-Group-Configuration-Set: An optional set of configurations 829 that further determine the suitability of an interface for the 830 specific request. For example: SequenceNumber=ON/OFF. 832 DPN-Key-Set: A key used to identify the DPN. 834 Referenced-Interface-Set: The DPN Interfaces and peer Service-Groups 835 associated with them. Each entry contains 837 Interface-Key: A key that is used together with the DPN-Key, to 838 create a key that is refers to a specific DPN interface 839 definition. 841 Peer-Service-Group-Key: Enables location of the peer Service- 842 Group for this Interface. 844 4.9.3. Domain Information Model 846 A Domain-Set represents a group of heterogeneous Topology resources 847 typically sharing a common administrative authority. Other models, 848 outside of the scope of this specification, provide the details for 849 the Domain. 851 | 852 +-[Domain] , (O) 853 | +-[Domain-Policy-Configuration] (O) 854 | 856 Figure 10: Domain Information Model 858 Each Domain entry contains the following information: 860 Domain-Key: Identifies and enables reference to the Domain. 862 Domain-Name: A human-readable display string naming the Domain. 864 4.9.4. DPN Information Model 866 A DPN-Set contains some or all of the DPNs in the Tenant's network. 867 Some of the DPNs in the Set may be identical in functionality and 868 only differ by their Key. 870 | 871 +-[DPN] , (O) 872 | +-[Extensible: FALSE] 873 | +-[Interface] 874 | | +-[Role] 875 | | +-[Protocol] 876 | | +-[Interface-Configuration] (O) 877 | +-[Domain-Key] 878 | +-[Service-Group-Key] (O) 879 | +-[DPN-Policy-Configuration] (M) 880 | +-[DPN-Resource-Mapping-Reference] (O) 882 Figure 11: DPN Information Model 884 Each DPN entry contains the following information: 886 DPN-Key: A unique Identifier of the DPN. 888 DPN-Name: A human-readable display string. 890 Domain-Key: A Key providing access to the Domain information about 891 the Domain in which the DPN resides. 893 Interface-Set: The Interface-Set references all interfaces (through 894 which data packets are received and transmitted) available on the 895 DPN. Each Interface makes use of attribute values that are 896 specific to that interface, for example, the MTU size. These do 897 not affect the DPN selection of active or enabled interfaces. 898 Interfaces contain the following information: 900 Role: The role (MAG, LMA, PGW, AMF, etc.) of the DPN. 902 Protocol (Set): The set of protocols supported by this interface 903 (e.g., PMIP, S5-GTP, S5-PMIP etc.). The protocol MAY implement 904 specific message sets, e.g. s5-pmip, s8-pmip. When a protocol 905 implements such message sub-subsets the Protocol value MUST 906 include this information. 908 Interface-Configuration-Set: Configurable settings that further 909 determine the suitability of an interface for the specific 910 request. For example: SequenceNumber=ON/OFF. 912 Service-Group-Set: The Service-Group-Set references all of the 913 Service-Groups which have been configured using Interfaces hosted 914 on this DPN. The purpose of a Service-Group is not to describe 915 each interface of each DPN, but rather to indicate interface types 916 for use during the DPN selection process, when a DPN with specific 917 interface capabilities is required. 919 DPN-Policy-Configuration: A list of Policies that have been 920 configured on this DPN. Some may have values for all attributes, 921 and some may require further configuration. Each Policy- 922 Configuration has a key to enable reference to its Policy- 923 Template. Each Policy-Configuration also has been configured to 924 supply missing and non-default values to the desired Attributes 925 defined within the Policy-Template. 927 DPN-Resource-Mapping-Reference (O): A reference to the underlying 928 implementation, e.g. physical node, software module, etc. that 929 supports this DPN. Further specification of this attribute is out 930 of scope for this document. 932 4.9.5. Policy Information Model 934 The Policy Information Model defines and identifies Rules for 935 enforcement at DPNs. A Policy is basically a set of Rules that are 936 to be applied to each incoming or outgoing packet at a DPN interface. 937 Rules comprise Descriptors and a set of Actions. The Descriptors, 938 when evaluated, determine whether or not a set of Actions will be 939 performed on the packet. The Policy structure is independent of a 940 policy context. 942 In addition to the Policy structure, the Information Model (per 943 Section 4.9.6) defines Mobility-Context. Each Mobility-Context may 944 be configured with appropriate Attribute values, for example 945 depending on the identity of a mobile node. 947 Traffic descriptions are defined in Descriptors, and treatments are 948 defined separately in Actions. A Rule-Set binds Descriptors and 949 associated Actions by reference, using Descriptor-Key and Action-Key. 950 A Rule-Set is bound to a policy in the Policy-Set (using Policy-Key), 951 and the Policy references the Rule definitions (using Rule-Key). 953 | 954 +-[Policy Information Model] 955 | +-[Extensible:] 956 | +-[Policy-Template] (M) 957 | | +-[Policy-Configuration] (O) 958 | | +-[Rule-Template-Key] (M) 959 | | | +-[Precedence] (M) 960 | +-[Rule-Template] (M) 961 | | +-[Descriptor-Match-Type] (M) 962 | | +-[Descriptor-Configuration] (M) 963 | | | +-[Direction] (O) 964 | | +-[Action-Configuration] (M) 965 | | | +-[Action-Order] (M) 966 | | +-[Rule-Configuration] (O) 967 | +-[Descriptor-Template] (M) 968 | | +-[Descriptor-Type] (O) 969 | | +-[Attribute-Expression] (M) 970 | +-[Action-Template] (M) 971 | +-[Action-Type] (O) 972 | | +-[Attribute-Expression] (M) 974 Figure 12: Policy Information Model 976 The Policy structure defines Policy-Set, Rule-Set, Descriptor-Set, 977 and Action-Set, as follows: 979 Policy-Template: A set of Policy structures, indexed by 980 Policy-Key, each of which is determined by a list of Rules 981 referenced by their Rule-Key. Each Policy structure contains the 982 following: 984 Policy-Key: Identifies and enables reference to this Policy 985 definition. 987 Rule-Template-Key: Enables reference to a Rule template 988 definition. 990 Rule-Precedence: For each Rule identified by a Rule-Template-Key 991 in the Policy, specifies the order in which that Rule must be 992 applied. The lower the numerical value of Precedence, the 993 higher the rule precedence. Rules with equal precedence MAY be 994 executed in parallel if supported by the DPN. If this value is 995 absent, the rules SHOULD be applied in the order in which they 996 appear in the Policy. 998 Rule-Template-Set: A set of Rule Template definitions indexed by 999 Rule-Key. Each Rule is defined by a list of Descriptors (located 1000 by Descriptor-Key) and a list of Actions (located by Action-Key) 1001 as follows: 1003 Rule-Template-Key: Identifies and enables reference to this Rule 1004 definition. 1006 Descriptor-Match-Type Indicates whether the evaluation of the 1007 Rule proceeds by using conditional-AND, or conditional-OR, on 1008 the list of Descriptors. 1010 Descriptor-Configuration: References a Descriptor template 1011 definition, along with an expression which names the Attributes 1012 for this instantiation from the Descriptor-Template and also 1013 specifies whether each Attribute of the Descriptor has a 1014 default value or a statically configured value, according to 1015 the syntax specified in Section 4.2. 1017 Direction: Indicates if a rule applies to uplink traffic, to 1018 downlink traffic, or to both uplink and downlink traffic. 1019 Applying a rule to both uplink and downlink traffic, in case of 1020 symmetric rules, eliminates the requirement for a separate 1021 entry for each direction. When not present, the direction is 1022 implied by the Descriptor's values. 1024 Action-Configuration: References an Action Template definition, 1025 along with an expression which names the Attributes for this 1026 instantiation from the Action-Template and also specifies 1027 whether each Attribute of the Action has a default value or a 1028 statically configured value, according to the syntax specified 1029 in Section 4.2. 1031 Action-Order: Defines the order in which actions are executed 1032 when the associated traffic descriptor selects the packet. 1034 Descriptor-Template-Set: A set of traffic Descriptor Templates, each 1035 of which can be evaluated on the incoming or outgoing packet, 1036 returning a TRUE or FALSE value, defined as follows: 1038 Descriptor-Template-Key: Identifies and enables reference to this 1039 descriptor template definition. 1041 Attribute-Expression: An expression which defines an Attribute in 1042 the Descriptor-Template and also specifies whether the Template 1043 also defines a default value or a statically configured value 1044 for the Attribute of the Descriptor has, according to the 1045 syntax specified in Section 4.2. 1047 Descriptor-Type: Identifies the type of descriptor, e.g. an IPv6 1048 traffic selector per [RFC6088]. 1050 Action-Template-Set: A set of Action Templates defined as follows: 1052 Action-Template-Key: Identifies and enables reference to this 1053 action template definition. 1055 Attribute-Expression: An expression which defines an Attribute in 1056 the Action-Template and also specifies whether the Template 1057 also defines a default value or a statically configured value 1058 for the Attribute of the Action has, according to the syntax 1059 specified in Section 4.2. 1061 Action-Type: Identifies the type of an action for unambiguous 1062 interpretation of an Action-Value entry. 1064 4.9.6. Mobility-Context Information Model 1066 The Mobility-Context structure holds entries associated with a mobile 1067 node and its mobility sessions (flows). It is created on a DPN 1068 during the mobile node's registration to manage the mobile node's 1069 flows. Flow information is added or deleted from the Mobility- 1070 Context as needed to support new flows or to deallocate resources for 1071 flows that are deactivated. Descriptors are used to characterize the 1072 nature and resource requirement for each flow. 1074 Termination of a Mobility-Context implies termination of all flows 1075 represented in the Mobility-Context, e.g. after deregistration of a 1076 mobile node. If any Child-Contexts are defined, they are also 1077 terminated. 1079 +-[Mobility-Context] 1080 | +-[Extensible:~ FALSE] 1081 | +-[Delegating-IP-Prefix:] (O) 1082 | +-[Parent-Context] (O) 1083 | +-[Child-Context] (O) 1084 | +-[Service-Group-Key] (O) 1085 | +-[Mobile-Node] 1086 | | +-[IP-Address] (O)) 1087 | | +-[MN-Policy-Configuration] 1088 | +-[Domain-Key] 1089 | | +-[Domain-Policy-Configuration] 1090 | +-[DPN-Key] 1091 | | +-[Role] 1092 | | +-[DPN-Policy-Configuration] 1093 | | +-[ServiceDataFlow] (O) 1094 | | | +-[Service-Group-Key] (O) 1095 | | | +-[Interface-Key] 1096 | | | +-[ServiceDataFlow-Policy- 1097 Configuration] (O) 1098 | | | | +-[Direction] 1100 Figure 13: Mobility-Context Information Model 1102 The Mobility-Context Substructure holds the following entries: 1104 Mobility-Context-Key: Identifies a Mobility-Context 1106 Delegating-IP-Prefix-Set: Delegated IP Prefixes assigned to the 1107 Mobility-Context 1109 Parent-Context: If present, a Mobility Context from which the 1110 Attributes and Attribute Values of this Mobility Context are 1111 inherited. 1113 Child-Context-Set: A set of Mobility Contexts which inherit the 1114 Attributes and Attribute Values of this Mobility Context. 1116 Service-Group-Key: Service-Group(s) used during DPN assignment and 1117 re-assignment. 1119 Mobile-Node: Attributes specific to the Mobile Node. It contains 1120 the following 1121 IP-Address-Set IP addresses assigned to the Mobile Node. 1123 MN-Policy-Configuration-Set For each MN-Policy in the set, a key 1124 and relevant information for the Policy Attributes. 1126 Domain-Key: Enables access to a Domain instance. 1128 Domain-Policy-Configuration-Set: For each Domain-Policy in the set, 1129 a key and relevant information for the Policy Attributes. 1131 DPN-Key-Set: Enables access to a DPN instance assigned to a specific 1132 role, i.e. this is a Set that uses DPN-Key and Role as a compound 1133 key to access specific set instances. 1135 Role: Role this DPN fulfills in the Mobility-Context. 1137 DPN-Policy-Configuration-Set: For each DPN-Policy in the set, a key 1138 and relevant information for the Policy Attributes. 1140 ServiceDataFlow-Key-Set: Characterizes a traffic flow that has been 1141 configured (and provided resources) on the DPN to support data- 1142 plane traffic to and from the mobile device. 1144 Service-Group-Key: Enables access to a Service-Group instance. 1146 Interface-Key-Set: Assigns the selected interface of the DPN. 1148 ServiceDataFlow-Policy-Configuration-Set: For each Policy in the 1149 set, a key and relevant information for the Policy Attributes. 1151 Direction: Indicates if the reference Policy applies to uplink 1152 or downlink traffic, or to both, uplink- and downlink 1153 traffic. Applying a rule to both, uplink- and downlink 1154 traffic, in case of symmetric rules, allows omitting a 1155 separate entry for each direction. When not present the 1156 value is assumed to apply to both directions. 1158 4.9.7. Monitor Information Model 1160 Monitors provide a mechanism to produce reports when events occur. A 1161 Monitor will have a target that specifies what is to be watched. 1163 The attribute/entity to be monitored places certain constraints on 1164 the configuration that can be specified. For example, a Monitor 1165 using a Threshold configuration cannot be applied to a Mobility- 1166 Context, because it does not have a threshold. Such a monitor 1167 configuration could be applied to a numeric threshold property of a 1168 Context. 1170 | 1171 +-[Monitor] 1172 | +-[Extensible:] 1173 | +-[Target:] 1174 | +-[Deferrable] 1175 | +-[Configuration] 1177 Figure 14: Monitor Substructure 1179 Monitor-Key: Identifies the Monitor. 1181 Target: Description of what is to be monitored. This can be a 1182 Service Data Flow, a Policy installed upon a DPN, values of a 1183 Mobility-Context, etc. The target name is the absolute 1184 information model path (separated by '/') to the attribute / 1185 entity to be monitored. 1187 Deferrable: Indicates that a monitoring report can be delayed up to 1188 a defined maximum delay, set in the Agent, for possible bundling 1189 with other reports. 1191 Configuration: Determined by the Monitor subtype. The monitor 1192 report is specified by the Configuration. Four report types are 1193 defined: 1195 * "Periodic" reporting specifies an interval by which a 1196 notification is sent. 1198 * "Event-List" reporting specifies a list of event types that, if 1199 they occur and are related to the monitored attribute, will 1200 result in sending a notification. 1202 * "Scheduled" reporting specifies the time (in seconds since Jan 1203 1, 1970) when a notification for the monitor should be sent. 1204 Once this Monitor's notification is completed the Monitor is 1205 automatically de-registered. 1207 * "Threshold" reporting specifies one or both of a low and high 1208 threshold. When these values are crossed a corresponding 1209 notification is sent. 1211 5. Security Considerations 1213 Detailed protocol implementations for DMM Forwarding Policy 1214 Configuration must ensure integrity of the information exchanged 1215 between a FPC Client and a FPC Agent. Required Security Associations 1216 may be derived from co-located functions, which utilize the FPC 1217 Client and FPC Agent respectively. 1219 General usage of FPC MUST consider the following: 1221 FPC Naming Section 4.5 permits arbitrary string values but a user 1222 MUST avoid placing sensitive or vulnerable information in those 1223 values. 1225 Policies that are very narrow and permit the identification of 1226 specific traffic, e.g. that of a single user, SHOULD be avoided. 1228 6. IANA Considerations 1230 TBD 1232 7. Work Team Participants 1234 Participants in the FPSM work team discussion include Satoru 1235 Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick 1236 Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred 1237 Templin. 1239 8. References 1241 8.1. Normative References 1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, 1245 DOI 10.17487/RFC2119, March 1997, 1246 . 1248 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 1249 "Traffic Selectors for Flow Bindings", RFC 6088, 1250 DOI 10.17487/RFC6088, January 2011, 1251 . 1253 8.2. Informative References 1255 [I-D.bertz-dime-policygroups] 1256 Bertz, L. and M. Bales, "Diameter Policy Groups and Sets", 1257 Work in Progress, Internet-Draft, draft-bertz-dime- 1258 policygroups-06, 18 June 2018, . 1261 [I-D.ietf-dmm-deployment-models] 1262 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1263 Architectural Considerations", Work in Progress, Internet- 1264 Draft, draft-ietf-dmm-deployment-models-04, 15 May 2018, 1265 . 1268 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1269 Korhonen, "Requirements for Distributed Mobility 1270 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1271 . 1273 Appendix A. Implementation Status 1275 Three FPC Agent implementations have been made to date. The first 1276 was based upon Version 03 of the draft and followed Model 1. The 1277 second follows Version 04 of the document. Both implementations were 1278 OpenDaylight plug-ins developed in Java by Sprint. Version 04 is now 1279 primarily enhanced by GS Labs. Version 03 was known as fpcagent and 1280 version 04's implementation is simply referred to as 'fpc'. A third 1281 has been developed on an ONOS Controller for use in MCORD projects. 1283 fpcagent's intent was to provide a proof of concept for FPC Version 1284 03 Model 1 in January 2016 and research various errors, corrections 1285 and optimizations that the Agent could make when supporting multiple 1286 DPNs. 1288 As the code developed to support OpenFlow and a proprietary DPN from 1289 a 3rd party, several of the advantages of a multi-DPN Agent became 1290 obvious including the use of machine learning to reduce the number of 1291 Flows and Policy entities placed on the DPN. This work has driven 1292 new efforts in the DIME WG, namely Diameter Policy Groups 1293 [I-D.bertz-dime-policygroups]. 1295 A throughput performance of tens per second using various NetConf 1296 based solutions in OpenDaylight made fpcagent, based on version 03, 1297 undesirable for call processing. The RPC implementation improved 1298 throughput by an order of magnitude but was not useful based upon 1299 FPC's Version 03 design using two information models. During this 1300 time the features of version 04 and its converged model became 1301 attractive and the fpcagent project was closed in August 2016. 1302 fpcagent will no longer be developed and will remain a proprietary 1303 implementation. 1305 The learnings of fpcagent has influenced the second project, fpc. 1306 Fpc is also an OpenDaylight project but is an open source release as 1307 the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/ 1308 Project_Proposals:FpcAgent). This project is scoped to be a fully 1309 compliant FPC Agent that supports multiple DPNs including those that 1310 communicate via OpenFlow. The following features present in this 1311 draft and others developed by the FPC development team have already 1312 led to an order of magnitude improvement. 1314 Migration of non-realtime provisioning of entities such as 1315 topology and policy allowed the implementation to focus only on 1316 the rpc. 1318 Using only 5 messages and 2 notifications has also reduced 1319 implementation time. 1321 Command Sets, an optional feature in this specification, have 1322 eliminated 80% of the time spent determining what needs to be 1323 done with a Context during a Create or Update operation. 1325 Op Reference is an optional feature modeled after video delivery. 1326 It has reduced unnecessary cache lookups. It also has the 1327 additional benefit of allowing an Agent to become cacheless and 1328 effectively act as a FPC protocol adapter remotely with multi-DPN 1329 support or co-located on the DPN in a single-DPN support model. 1331 Multi-tenant support allows for Cache searches to be partitioned 1332 for clustering and performance improvements. This has not been 1333 capitalized upon by the current implementation but is part of the 1334 development roadmap. 1336 Use of Contexts to pre-provision policy has also eliminated any 1337 processing of Ports for DPNs which permitted the code for 1338 CONFIGURE and CONF_BUNDLE to be implemented as a simple nested 1339 FOR loops (see below). 1341 Initial v04 performance results without code optimizations or tuning 1342 allow reliable provisioning of 1K FPC Mobility-Contexts processed per 1343 second on a 12 core server. This results in 2x the number of 1344 transactions on the southbound interface to a proprietary DPN API on 1345 the same machine. 1347 fpc currently supports the following: 1349 1 proprietary DPN API 1351 Policy and Topology as defined in this 1352 specification using OpenDaylight North Bound 1353 Interfaces such as NetConf and RestConf 1355 CONFIG and CONF_BUNDLE (all operations) 1357 DPN assignment, Tunnel allocations and IPv4 1358 address assignment by the Agent or Client. 1360 Immediate Response is always an 1361 OK_NOTIFY_FOLLOWS. 1363 assignment system (receives rpc call): 1364 perform basic operation integrity check 1365 if CONFIG then 1366 goto assignments 1367 if assignments was ok then 1368 send request to activation system 1369 respond back to client with assignment data 1370 else 1371 send back error 1372 end if 1373 else if CONF_BUNDLE then 1374 for each operation in bundles 1375 goto assignments 1376 if assignments was ok then 1377 hold onto data 1378 else 1379 return error with the assignments that occurred in 1380 prior operations (best effort) 1381 end if 1382 end for 1383 send bundles to activation systems 1384 end if 1386 assignments: 1387 assign DPN, IPv4 Address and/or tunnel info as required 1388 if an error occurs undo all assignments in this operation 1389 return result 1391 activation system: 1392 build cache according to op-ref and operation type 1393 for each operation 1394 for each Context 1395 for each DPN / direction in Context 1396 perform actions on DPN according to Command Set 1397 end for 1398 end for 1399 end for 1400 commit changes to in memory cache 1401 log transaction for tracking and notification 1402 (CONFIG_RESULT_NOTIFY) 1404 Figure 15: fpc pseudo code 1406 For further information please contact Lyle Bertz who is also a co- 1407 author of this document. 1409 NOTE: Tenant support requires binding a Client ID to a Tenant ID (it 1410 is a one to many relation) but that is outside of the scope of this 1411 specification. Otherwise, the specification is complete in terms of 1412 providing sufficient information to implement an Agent. 1414 Authors' Addresses 1416 Satoru Matsushima 1417 SoftBank 1418 1-9-1,Higashi-Shimbashi,Minato-Ku, 1419 Japan 1421 Email: satoru.matsushima@g.softbank.co.jp 1423 Lyle Bertz 1424 6220 Sprint Parkway 1425 Overland Park KS, 66251, 1426 United States of America 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 United States of America 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 United States of America 1457 Phone: +1-408-330-4586 1458 Email: charliep@computer.org