Internet DRAFT - draft-ietf-dmm-fpc-cpdp

draft-ietf-dmm-fpc-cpdp







DMM Working Group                                          S. Matsushima
Internet-Draft                                                  SoftBank
Intended status: Standards Track                                L. Bertz
Expires: 27 March 2021                                            Sprint
                                                              M. Liebsch
                                                                     NEC
                                                           S. Gundavelli
                                                                   Cisco
                                                                D. Moses
                                                       Intel Corporation
                                                            C.E. Perkins
                                                               Futurewei
                                                       23 September 2020


       Protocol for Forwarding Policy Configuration (FPC) in DMM
                       draft-ietf-dmm-fpc-cpdp-14

Abstract

   This document describes a way, called Forwarding Policy Configuration
   (FPC) to manage the separation of data-plane and control-plane.  FPC
   defines a flexible mobility management system using FPC agent and FPC
   client functions.  A FPC agent provides an abstract interface to the
   data-plane.  The FPC client configures data-plane nodes by using the
   functions and abstractions provided by the FPC agent for the data-
   plane nodes.  The data-plane abstractions presented in this document
   are extensible in order to support many different types of mobility
   management systems and data-plane functions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 March 2021.





Matsushima, et al.        Expires 27 March 2021                 [Page 1]

Internet-Draft              DMM FPC Protocol              September 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  FPC Design Objectives and Deployment  . . . . . . . . . . . .   6
   4.  FPC Mobility Information Model  . . . . . . . . . . . . . . .   9
     4.1.  Model Notation and Conventions  . . . . . . . . . . . . .  10
     4.2.  Templates and Attributes  . . . . . . . . . . . . . . . .  12
     4.3.  Attribute-Expressions . . . . . . . . . . . . . . . . . .  13
     4.4.  Attribute Value Types . . . . . . . . . . . . . . . . . .  14
     4.5.  Namespace and Format  . . . . . . . . . . . . . . . . . .  14
     4.6.  Configuring Attribute Values  . . . . . . . . . . . . . .  15
     4.7.  Entity Configuration Blocks . . . . . . . . . . . . . . .  16
     4.8.  Information Model Checkpoint  . . . . . . . . . . . . . .  17
     4.9.  Information Model Components  . . . . . . . . . . . . . .  18
       4.9.1.  Topology Information Model  . . . . . . . . . . . . .  18
       4.9.2.  Service-Group . . . . . . . . . . . . . . . . . . . .  18
       4.9.3.  Domain Information Model  . . . . . . . . . . . . . .  20
       4.9.4.  DPN Information Model . . . . . . . . . . . . . . . .  20
       4.9.5.  Policy Information Model  . . . . . . . . . . . . . .  22
       4.9.6.  Mobility-Context Information Model  . . . . . . . . .  24
       4.9.7.  Monitor Information Model . . . . . . . . . . . . . .  26
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   7.  Work Team Participants  . . . . . . . . . . . . . . . . . . .  28
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  28
   Appendix A.  Implementation Status  . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33







Matsushima, et al.        Expires 27 March 2021                 [Page 2]

Internet-Draft              DMM FPC Protocol              September 2020


1.  Introduction

   This document describes Forwarding Policy Configuration (FPC), a
   system for managing the separation of control-plane and data-plane.
   FPC enables flexible mobility management using FPC client and FPC
   agent functions.  A FPC agent exports an abstract interface
   representing the data-plane.  To configure data-plane nodes and
   functions, the FPC client uses the interface to the data-plane
   offered by the FPC agent.

   Control planes of mobility management systems, or related
   applications which require data-plane control, can utilize the FPC
   client at various levels of abstraction.  FPC operations are capable
   of directly configuring a single Data-Plane Node (DPN), as well as
   multiple DPNs, as determined by the data-plane models exported by the
   FPC agent.

   A FPC agent represents the data-plane operation according to several
   basic information models.  A FPC agent also provides access to
   Monitors, which produce reports when triggered by events or FPC
   Client requests regarding Mobility Contexts, DPNs or the Agent.

   To manage mobility sessions, the FPC client assembles applicable sets
   of forwarding policies from the data model, and configures them on
   the appropriate FPC Agent.  The Agent then renders those policies
   into specific configurations for each DPN at which mobile nodes are
   attached.  The specific protocols and configurations to configure a
   DPN from a FPC Agent are outside the scope of this document.

   A DPN is a logical entity that performs data-plane operations (packet
   movement and management).  It may represent a physical DPN unit, a
   sub-function of a physical DPN or a collection of physical DPNs
   (i.e., a "virtual DPN").  A DPN may be virtual -- it may export the
   FPC DPN Agent interface, but be implemented as software that controls
   other data-plane hardware or modules that may or may not be FPC-
   compliant.  In this document, DPNs are specified without regard for
   whether the implementation is virtual or physical.  DPNs are
   connected to provide mobility management systems such as access
   networks, anchors and domains.  The FPC agent interface enables
   establishment of a topology for the forwarding plane.

   When a DPN is mapped to physical data-plane equipment, the FPC client
   can have complete knowledge of the DPN architecture, and use that
   information to perform DPN selection for specific sessions.  On the
   other hand, when a virtual DPN is mapped to a collection of physical
   DPNs, the FPC client cannot select a specific physical DPN because it
   is hidden by the abstraction; only the FPC Agent can address the
   specific associated physical DPNs.  Network architects have the



Matsushima, et al.        Expires 27 March 2021                 [Page 3]

Internet-Draft              DMM FPC Protocol              September 2020


   flexibility to determine which DPN-selection capabilities are
   performed by the FPC Agent (distributed) and which by the FPC client
   (centralized).  In this way, overlay networks can be configured
   without disclosing detailed knowledge of the underlying hardware to
   the FPC client and applications.

   The abstractions in this document are designed to support many
   different mobility management systems and data-plane functions.  The
   architecture and protocol design of FPC is not tied to specific types
   of access technologies and mobility protocols.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Attribute Expression:   The definition of a template Property.  This
                           includes setting the type, current value,
                           default value and if the attribute is static,
                           i.e. can no longer be changed.

   Domain:                 One or more DPNs that form a logical
                           partition of network resources (e.g., a data-
                           plane network under common network
                           administration).  A FPC client (e.g., a
                           mobility management system) may utilize a
                           single or multiple domains.

   DPN:                    A data-plane node (DPN) is capable of
                           performing data-plane features.  For example,
                           DPNs may be switches or routers, regardless
                           of whether they are realized as hardware or
                           purely in software.

   FPC Client:             A FPC Client is integrated with a mobility
                           management system or related application,
                           enabling control over forwarding policy,
                           mobility sessions and DPNs via a FPC Agent.

   Mobility Context:       A Mobility Context contains the data-plane
                           information necessary to efficiently send and
                           receive traffic from a mobile node.  This
                           includes policies that are created or
                           modified during the network's operation - in
                           most cases, on a per-flow or per session
                           basis.  A Mobility-Context represents the
                           mobility sessions (or flows) which are active



Matsushima, et al.        Expires 27 March 2021                 [Page 4]

Internet-Draft              DMM FPC Protocol              September 2020


                           on a mobile node.  This includes associated
                           runtime attributes, such as tunnel endpoints,
                           tunnel identifiers, delegated prefix(es),
                           routing information, etc.  Mobility-Contexts
                           are associated to specific DPNs.  Some pre-
                           defined Policies may apply during mobility
                           signaling requests.  The Mobility Context
                           supplies information about the policy
                           settings specific to a mobile node and its
                           flows; this information is often quite
                           dynamic.

   Mobility Session:       Traffic to/from a mobile node that is
                           expected to survive reconnection events.

   Monitor:                A reporting mechanism for a list of events
                           that trigger notification messages from a FPC
                           Agent to a FPC Client.

   Policy:                 A Policy determines the mechanisms for
                           managing specific traffic flows or packets.
                           Policies specify QoS, rewriting rules for
                           packet processing, etc.  A Policy consists of
                           one or more rules.  Each rule is composed of
                           a Descriptor and Actions.  The Descriptor in
                           a rule identifies packets (e.g., traffic
                           flows), and the Actions apply treatments to
                           packets that match the Descriptor in the
                           rule.  Policies can apply to Domains, DPNs,
                           Mobile Nodes, Service-Groups, or particular
                           Flows on a Mobile Node.

   Property:               An attribute-value pair for an instance of a
                           FPC entity.

   Service-Group:          A set of DPN interfaces that support a
                           specific data-plane purpose, e.g. inbound/
                           outbound, roaming, subnetwork with common
                           specific configuration, etc.

   Template:               A recipe for instantiating FPC entities.
                           Template definitions are accessible (by name
                           or by a key) in an indexed set.  A Template
                           is used to create specific instances (e.g.,
                           specific policies) by assigning appropriate
                           values into the Template definition via
                           Attribute Expression.




Matsushima, et al.        Expires 27 March 2021                 [Page 5]

Internet-Draft              DMM FPC Protocol              September 2020


   Template Configuration  The process by which a Template is referenced
                           (by name or by key) and Attribute Expressions
                           are created that change the value, default
                           value or static nature of the Attribute, if
                           permitted.  If the Template is Extensible,
                           new attributes MAY be added.

   Tenant:                 An operational entity that manages mobility
                           management systems or applications which
                           require data-plane functions.  A Tenant
                           defines a global namespace for all entities
                           owned by the Tenant enabling its entities to
                           be used by multiple FPC Clients across
                           multiple FPC Agents.

   Topology:               The DPNs and the links between them.  For
                           example, access nodes may be assigned to a
                           Service-Group which peers to a Service-Group
                           of anchor nodes.

3.  FPC Design Objectives and Deployment

   Using FPC, mobility control-planes and applications can configure
   DPNs to perform various mobility management roles as described in
   [I-D.ietf-dmm-deployment-models].  This fulfills the requirements
   described in [RFC7333].

   This document defines FPC Agent and FPC Client, as well as the
   information models that they use.  The attributes defining those
   models serve as the protocol elements for the interface between the
   FPC Agent and the FPC Client.

   Mobility control-plane applications integrate features offered by the
   FPC Client.  The FPC Client connects to FPC Agent functions.  The
   Client and the Agent communicate based on information models
   described in Section 4.  The models allow the control-plane to
   configure forwarding policies on the Agent for data-plane
   communications with mobile nodes.

   Once the Topology of DPN(s) and domains are defined on an Agent for a
   data plane, the DPNs in the topology are available for further
   configuration.  The FPC Agent connects those DPNs to manage their
   configurations.

   A FPC Agent configures and manages its DPN(s) according to forwarding
   policies requested and Attributes provided by the FPC Client.
   Configuration commands used by the FPC agent to configure its DPN
   node(s) may be specific to the DPN implementation; consequently the



Matsushima, et al.        Expires 27 March 2021                 [Page 6]

Internet-Draft              DMM FPC Protocol              September 2020


   method by which the FPC Agent carries out the specific configuration
   for its DPN(s) is out of scope for this document.  Along with the
   data models, the FPC Client (on behalf of control-plane and
   applications) requests that the Agent configures Policies prior to
   the time when the DPNs start forwarding data for their mobility
   sessions.

   This architecture is illustrated in Figure 1.  A FPC Agent may be
   implemented in a network controller that handles multiple DPNs, or
   (more simply) an FPC Agent may itself be integrated into a DPN.

   This document does not specify a protocol for the FPC interface; it
   is out of scope.






































Matsushima, et al.        Expires 27 March 2021                 [Page 7]

Internet-Draft              DMM FPC Protocol              September 2020


                           +-------------------------+
                           | Mobility Control-Plane  |
                           |          and            |
                           |      Applications       |
                           |+-----------------------+|
                           ||      FPC Client       ||
                           |+----------^------------+|
                           +-----------|-------------+
               FPC interface protocol  |
                       +---------------+-----------------+
                       |                                 |
         Network       |                                 |
         Controller    |                      DPN        |
           +-----------|-------------+        +----------|---------+
           |+----------v------------+|        |+---------v--------+|
           ||   [Data-plane model]  ||        ||[Data-plane model]||
           ||       FPC Agent       ||        ||    FPC Agent     ||
           |+-----------------------+|        |+------------------+|
           |+------------+----------+|        |                    |
           ||SB Protocol |FPC Client||        |  DPN Configuration |
           ||   Modules  |  Module  ||        +--------------------+
           |+------^-----+----^-----+|
           +-------|----------|------+
                   |          |
         Other     |          | FPC interface
        southbound |          | protocol
         protocols |          |
                   |          +-----------------+
                   |                            |
       DPN         |                 DPN        |
        +----------|---------+       +----------|---------+
        |+---------v--------+|       |+---------v--------+|
        ||  Configuration   ||       ||[Data-plane model]||
        || Protocol module  ||       ||     FPC Agent    ||
        |+------------------+|       |+------------------+|
        |                    |       |                    |
        | DPN Configuration  |       |  DPN Configuration |
        +--------------------+       +--------------------+













Matsushima, et al.        Expires 27 March 2021                 [Page 8]

Internet-Draft              DMM FPC Protocol              September 2020


         Figure 1: Reference Forwarding Policy Configuration (FPC)
                                Architecture


   The FPC architecture supports multi-tenancy; a FPC enabled data-plane
   supports tenants of multiple mobile operator networks and/or
   applications.  It means that the FPC Client of each tenant connects
   to the FPC Agent and it MUST partition namespace and data for their
   data-planes.  DPNs on the data-plane may fulfill multiple data-plane
   roles which are defined per session, domain and tenant.

   Multi-tenancy permits the paritioning of data-plane entities as well
   as a common namespace requirement upon FPC Agents and Clients when
   they use the same Tenant for a common data-plane entity.

   FPC information models often configuration to fit the specific needs
   for DPN management of a mobile node's traffic.  The FPC interfaces in
   Figure 1 are the only interfaces required to handle runtime data in a
   Mobility Context.  The Topology and some Policy FPC models MAY be
   pre-configured; in that case real-time protocol exchanges are not
   required for them.

   The information model provides an extensibility mechanism through
   Templates that permits specialization for the needs of a particular
   vendor's equipment or future extension of the model presented in this
   specification.

4.  FPC Mobility Information Model

   The FPC information model includes the following components:

      DPN Information Model,
      Topology Information Model,
      Policy Information Model,
      Mobility-Context, and
      Monitor, as illustrated in Figure 2.















Matsushima, et al.        Expires 27 March 2021                 [Page 9]

Internet-Draft              DMM FPC Protocol              September 2020


                   :
                   |
                   +-[FPC Mobility Information Model]
                   |          |
                   |          +-[Topology Information Model]
                   |          |
                   |          +-[Policy Information Model]
                   |          |
                   |          +-[Mobility-Context]
                   |          |
                   |          +-[Monitor]
                   |

                 Figure 2: FPC Information Model structure


4.1.  Model Notation and Conventions

   The following conventions are used to describe the FPC information
   models.

   Information model entities (e.g.  DPNs, Rules, etc.) are defined in a
   hierarchical notation where all entities at the same hierarchical
   level are located on the same left-justified vertical position
   sequentially.  When entities are composed of sub-entities, the sub-
   entities appear shifted to the right, as shown in Figure 3.

                              |
                              +-[entity2]
                              |         +-[entity2.1]
                              |         +-[entity2.2]

                   Figure 3: Model Notation - An Example


   Some entities have one or more qualifiers placed on the right hand
   side of the element definition in angle-brackets.  Common types
   include:

   List:  A collection of entities (some could be duplicated)

   Set:  A nonempty collection of entities without duplications

   Name:  A human-readable string

   Key:  A unique value.  We distinguish 3 types of keys:

      U-Key:  A key unique across all Tenants.  U-Key spaces typically



Matsushima, et al.        Expires 27 March 2021                [Page 10]

Internet-Draft              DMM FPC Protocol              September 2020


         involve the use of registries or language specific mechanisms
         that guarantee universal uniqueness of values.

      G-Key:  A key unique within a Tenant

      L-Key:  A key unique within a local namespace.  For example, there
         may exist interfaces with the same name, e.g. "if0", in two
         different DPNs but there can only be one "if0" within each DPN
         (i.e. its local Interface-Key L-Key space).

   Each entity or attribute may be optional (O) or mandatory (M).
   Entities that are not marked as optional are mandatory.

       The following example shows 3 entities:
           -- Entity1 is a globally unique key, and optionally can have
                      an associated Name
           -- Entity2 is a list
           -- Entity3 is a set and is optional
                      +
                      |
                      +-[entity1] <G-Key> (M), <Name> (O)
                      +-[entity2] <List>
                      +-[entity3] <Set> (O)
                      |
                      +

                                  Figure 4


   When expanding entity1 into a modeling language such as YANG it would
   result in two values: entity1-Key and entity1-Name.

   To encourage re-use, FPC defines indexed sets of various entity
   Templates.  Other model elements that need access to an indexed model
   entity contain an attribute which is always denoted as "entity-Key".
   When a Key attribute is encountered, the referencing model element
   may supply attribute values for use when the referenced entity model
   is instantiated.  For example: Figure 5 shows 2 entities:

      EntityA definition references an entityB model element.

      EntityB model elements are indexed by entityB-Key.

   Each EntityB model element has an entityB-Key which allows it to be
   uniquely identified, and a list of Attributes (or, alternatively, a
   Type) which specifies its form.  This allows a referencing entity to
   create an instance by supplying entityB-Values to be inserted, in a
   Settings container.



Matsushima, et al.        Expires 27 March 2021                [Page 11]

Internet-Draft              DMM FPC Protocol              September 2020


                           .
                           .
                           |
                           +-[entityA]
                           |      +-[entityB-Key]
                           |      +-[entityB-Values]
                           .
                           .
                           |
                           +-[entityB] <L-Key> (M) <Set>
                           |      +-[entityB-Type]
                           .
                           .

                     Figure 5: Indexed sets of entities

   Indexed sets are specified for each of the following kinds of
   entities:



      Domain (See Section 4.9.3)
      DPN (See Section 4.9.4)
      Policy (See Section 4.9.5)
      Rule (See Section 4.9.5)
      Descriptor (See Figure 12)
      Action (See Figure 12)
      Service-Group (See Section 4.9.2, and
      Mobility-Context (See Section 4.9.6)

   As an example, for a Domain entity, there is a corresponding
   attribute denoted as "Domain-Key" whose value can be used to
   determine a reference to the Domain.

4.2.  Templates and Attributes

   In order to simplify development and maintenance of the needed
   policies and other objects used by FPC, the Information Models which
   are presented often have attributes that are not initialized with
   their final values.  When an FPC entity is instantiated according to
   a template definition, specific values need to be configured for each
   such attribute.  For instance, suppose an entity Template has an
   Attribute named "IPv4-Address", and also suppose that a FPC Client
   instantiates the entity and requests that it be installed on a DPN.
   An IPv4 address will be needed for the value of that Attribute before
   the entity can be used.





Matsushima, et al.        Expires 27 March 2021                [Page 12]

Internet-Draft              DMM FPC Protocol              September 2020


                        +-[Template] <U-Key, Name> (M) <Set>
                        |      +-[Attributes] <Set> (M)
                        |      +-[Extensible ~ FALSE]
                        |      +-[Entity-State ~ Initial]
                        |      +-[Version]

                        Figure 6: Template entities


   Attributes:  A set of Attribute names MAY be included when defining a
      Template for instantiating FPC entities.

   Extensible:  Determines whether or not entities instantiated from the
      Template can be extended with new non-mandatory Attributes not
      originally defined for the Template.  Default value is FALSE.  If
      a Template does not explicitly specify this attribute, the default
      value is considered to be in effect.

   Entity-State:  Either Initial, PartiallyConfigured, Configured, or
      Active.  Default value is Initial.  See Section 4.6 for more
      information about how the Entity-Status changes during the
      configuration steps of the Entity.

   Version:  Provides a version tag for the Template.

   The Attributes in an Entity Template may be either mandatory or non-
   mandatory.  Attribute values may also be associated with the
   attributes in the Entity Template.  If supplied, the value may be
   either assigned with a default value that can be reconfigured later,
   or the value can be assigned with a static value that cannot be
   reconfigured later (see Section 4.3).

   It is possible for a Template to provide values for all of its
   Attributes, so that no additional values are needed before the entity
   can made Active.  Any instantiation from a Template MUST have at
   least one Attribute in order to be a useful entity unless the
   Template has none.

4.3.  Attribute-Expressions

   The syntax of the Attribute definition is formatted to make it clear.
   For every Attribute in the Entity Template, six possibilities are
   specified as follows:

   '[Att-Name: ]'  Mandatory Attribute is defined, but template does not
      provide any configured value.

   '[Att-Name: Att-Value]'  Mandatory Attribute is defined, and has a



Matsushima, et al.        Expires 27 March 2021                [Page 13]

Internet-Draft              DMM FPC Protocol              September 2020


      statically configured value.

   '[Att-Name: ~ Att-Value]'  Mandatory Attribute is defined, and has a
      default value.

   '[Att-Name]'  Non-mandatory Attribute may be included but template
      does not provide any configured value.

   '[Att-Name = Att-Value]'  Non-mandatory Attribute may be included and
      has a statically configured value.

   '[Att-Name ~ Att-Value]'  Non-mandatory Attribute may be included and
      has a default value.

   So, for example, a default value for a non-mandatory IPv4-Address
   attribute would be denoted by [IPv4-Address ~ 127.0.0.1].

   After a FPC Client identifies which additional Attributes have been
   configured to be included in an instantiated entity, those configured
   Attributes MUST NOT be deleted by the FPC Agent.  Similarly, any
   statically configured value for an entity Attribute MUST NOT be
   changed by the FPC Agent.

   Whenever there is danger of confusion, the fully qualified Attribute
   name MUST be used when supplying needed Attribute Values for a
   structured Attribute.

4.4.  Attribute Value Types

   For situations in which the type of an attribute value is required,
   the following syntax is recommended.  To declare than an attribute
   has data type "foo", typecast the attribute name by using the
   parenthesized data type (foo).  So, for instance, [(float) Max-
   Latency-in-ms:] would indicate that the mandatory Attribute "Max-
   Latency-in-ms" requires to be configured with a floating point value
   before the instantiated entity could be used.  Similarly, [(float)
   Max-Latency-in-ms: 9.5] would statically configure a floating point
   value of 9.5 to the mandatory Attribute "Max-Latency-in-ms".

4.5.  Namespace and Format

   The identifiers and names in FPC models which reside in the same
   Tenant must be unique.  That uniqueness must be maintained by all
   Clients, Agents and DPNs that support the Tenant.  The Tenant
   namespace uniqueness MUST be applied to all elements of the tenant
   model, i.e.  Topology, Policy and Mobility models.





Matsushima, et al.        Expires 27 March 2021                [Page 14]

Internet-Draft              DMM FPC Protocol              September 2020


   When a Policy needs to be applied to Mobility-Contexts in all Tenants
   on an Agent, the Agent SHOULD define that policy to be visible by all
   Tenants.  In this case, the Agent assigns a unique identifier in the
   Agent namespace and copies the values to each Tenant.  This
   effectively creates a U-Key although only a G-Key is required within
   the Tenant.

   The notation for identifiers can utilize any format with agreement
   between data-plane agent and client operators.  The formats include
   but are not limited to Globally Unique IDentifiers (GUIDs),
   Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names
   (FQDNs), Fully Qualified Path Names (FQPNs) and Uniform Resource
   Identifiers (URIs).  The FPC model does not limit the format, which
   could dictate the choice of FPC protocol.  Nevertheless, the
   identifiers which are used in a Mobility model should be considered
   to efficiently handle runtime parameters.

4.6.  Configuring Attribute Values

   Attributes of Information Model components such as policy templates
   are configured with values as part of FPC configuration operations.
   There may be several such configuration operations before the
   template instantiation is fully configured.

   Entity-Status indicates when an Entity is usable within a DPN.  This
   permits DPN design tradeoffs amongst local storage (or other
   resources), over the wire request size and the speed of request
   processing.  For example, DPN designers with constrained systems MAY
   only house entities whose status is Active which may result in
   sending over all policy information with a Mobility-Context request.
   Storing information elements with an entity status of
   "PartiallyConfigured" on the DPN requires more resources but can
   result in smaller over the wire FPC communication and request
   processing efficiency.

   When the FPC Client instantiates a Policy from a Template, the
   Policy-Status is "Initial".  When the FPC Client sends the policy to
   a FPC Agent for installation on a DPN, the Client often will
   configure appropriate attribute values for the installation, and
   accordingly changes the Policy-Status to "PartiallyConfigured" or
   "Configured".  The FPC Agent will also configure Domain-specific
   policies and DPN-specific policies on the DPN.  When configured to
   provide particular services for mobile nodes, the FPC Agent will
   apply whatever service-specific policies are needed on the DPN.  When
   a mobile node attaches to the network data-plane within the topology
   under the jurisdiction of a FPC Agent, the Agent may apply policies
   and settings as appropriate for that mobile node.  Finally, when the
   mobile node launches new flows, or quenches existing flows, the FPC



Matsushima, et al.        Expires 27 March 2021                [Page 15]

Internet-Draft              DMM FPC Protocol              September 2020


   Agent, on behalf of the FPC Client, applies or deactivates whatever
   policies and attribute values are appropriate for managing the flows
   of the mobile node.  When a "Configured" policy is de-activated,
   Policy-Status is changed to be "Active".  When an "Active" policy is
   activated, Policy-Status is changed to be "Configured".

   Attribute values in DPN resident Policies may be configured by the
   FPC Agent as follows:

   Domain-Policy-Configuration:  Values for Policy attributes that are
      required for every DPN in the domain.

   DPN-Policy-Configuration:  Values for Policy attributes that are
      required for every policy configured on this DPN.

   Service-Group-Policy-Configuration:  Values for Policy attributes
      that are required to carry out the intended Service of the Service
      Group.

   MN-Policy-Configuration:  Values for Policy attributes that are
      required for all traffic to/from a particular mobile node.

   Service-Data-Flow-Policy-Configuration:  Values for Policy attributes
      that are required for traffic belonging to a particular set of
      flows on the mobile node.

   Any configuration changes MAY also supply updated values for existing
   default attribute values that may have been previously configured on
   the DPN resident policy.

   Entity blocks describe the format of the policy configurations.

4.7.  Entity Configuration Blocks

   As described in Section 4.6, a Policy Template may be configured in
   several stages by configuring default or missing values for
   Attributes that do not already have statically configured values.  A
   Policy-Configuration is the combination of a Policy-Key (to identify
   the Policy Template defining the Attributes) and the currently
   configured Attribute Values to be applied to the Policy Template.
   Policy-Configurations MAY add attributes to a Template if Extensible
   is True.  They MAY also refine existing attributes by:

      assign new values if the Attribute is not static

      make attributes static if they were not

      make an attribute mandatory



Matsushima, et al.        Expires 27 March 2021                [Page 16]

Internet-Draft              DMM FPC Protocol              September 2020


   A Policy-Configuration MUST NOT define or refine an attribute twice.
   More generally, an Entity-Configuration can be defined for any
   configurable Indexed Set to be the combination of the Entity-Key
   along with a set of Attribute-Expressions that supply configuration
   information for the entity's Attributes.  Figure 7 shows a schematic
   representation for such Entity Configuration Blocks.

                   [Entity Configuration Block]
                   |       +-[Entity-Key] (M)
                   |       +-[Attribute-Expression] <Set> (M)

                    Figure 7: Entity Configuration Block


   This document makes use of the following kinds of Entity
   Configuration Blocks:

      Descriptor-Configuration

      Action-Configuration

      Rule-Configuration

      Interface-Configuration

      Service-Group-Configuration

      Domain-Policy-Configuration

      DPN-Policy-Configuration

      Policy-Configuration

      MN-Policy-Configuration

      Service-Data-Flow-Policy-Configuration

4.8.  Information Model Checkpoint

   The Information Model Checkpoint permits Clients and Tenants with
   common scopes, referred to in this specification as Checkpoint
   BaseNames, to track the state of provisioned information on an Agent.
   The Agent records the Checkpoint BaseName and Checkpoint value set by
   a Client.  When a Client attaches to the Agent it can query to
   determine the amount of work that must be executed to configure the
   Agent to a specific BaseName / checkpoint revision.





Matsushima, et al.        Expires 27 March 2021                [Page 17]

Internet-Draft              DMM FPC Protocol              September 2020


   Checkpoints are defined for the following information model
   components:

      Service-Group

      DPN Information Model

      Domain Information Model

      Policy Information Model

4.9.  Information Model Components

4.9.1.  Topology Information Model

   The Topology structure specifies DPNs and the communication paths
   between them.  A network management system can use the Topology to
   select the most appropriate DPN resources for handling specific
   session flows.

   The Topology structure is illustrated in Figure 8 (for definitions
   see Section 2):

                         |
                         +-[Topology Information Model]
                         |          +-[Extensible: FALSE]
                         |          +-[Service-Group]
                         |          +-[DPN] <Set>
                         |          +-[Domain] <Set>

                        Figure 8: Topology Structure


4.9.2.  Service-Group

   Service-Group-Set is collection of DPN interfaces serving some data-
   plane purpose including but not limited to DPN Interface selection to
   fulfill a Mobility-Context.  Each Group contains a list of DPNs
   (referenced by DPN-Key) and selected interfaces (referenced by
   Interface-Key).  The Interfaces are listed explicitly (rather than
   referred implicitly by its specific DPN) so that every Interface of a
   DPN is not required to be part of a Group.  The information provided
   is sufficient to ensure that the Protocol, Settings (stored in the
   Service-Group-Configuration) and Features relevant to successful
   interface selection is present in the model.






Matsushima, et al.        Expires 27 March 2021                [Page 18]

Internet-Draft              DMM FPC Protocol              September 2020


   |
   +-[Service-Group] <G-Key>, <Name> (O) <Set>
   |           +-[Extensible: FALSE]
   |           +-[Role] <U-Key>
   |           +-[Protocol] <Set>
   |           +-[Feature] <Set> (O)
   |           +-[Service-Group-Configuration] <Set> (O)
   |           +-[DPN-Key] <Set>
   |           |           +-[Referenced-Interface] <Set>
   |           |           |       +-[Interface-Key] <L-Key>
   |           |           |       +-[Peer-Service-Group-Key] <Set> (O)

                          Figure 9: Service Group


   Each Service-Group element contains the following information:

   Service-Group-Key:  A unique ID of the Service-Group.

   Service-Group-Name:  A human-readable display string.

   Role:  The role (MAG, LMA, etc.) of the device hosting the interfaces
      of the DPN Group.

   Protocol-Set:  The set of protocols supported by this interface
      (e.g., PMIP, S5-GTP, S5-PMIP etc.).  The protocol MAY be only its
      name, e.g. 'gtp', but many protocols implement specific message
      sets, e.g. s5-pmip, s8-pmip.  When the Service-Group supports
      specific protocol message sub-subsets the Protocol value MUST
      include this information.

   Feature-Set:  An optional set of static features which further
      determine the suitability of the interface to the desired
      operation.

   Service-Group-Configuration-Set:  An optional set of configurations
      that further determine the suitability of an interface for the
      specific request.  For example: SequenceNumber=ON/OFF.

   DPN-Key-Set:  A key used to identify the DPN.

   Referenced-Interface-Set:  The DPN Interfaces and peer Service-Groups
      associated with them.  Each entry contains

      Interface-Key:  A key that is used together with the DPN-Key, to
         create a key that is refers to a specific DPN interface
         definition.




Matsushima, et al.        Expires 27 March 2021                [Page 19]

Internet-Draft              DMM FPC Protocol              September 2020


      Peer-Service-Group-Key:  Enables location of the peer Service-
         Group for this Interface.

4.9.3.  Domain Information Model

   A Domain-Set represents a group of heterogeneous Topology resources
   typically sharing a common administrative authority.  Other models,
   outside of the scope of this specification, provide the details for
   the Domain.

             |
             +-[Domain] <G-Key>, <Name> (O) <Set>
             |       +-[Domain-Policy-Configuration] (O) <Set>
             |

                    Figure 10: Domain Information Model

   Each Domain entry contains the following information:

   Domain-Key:  Identifies and enables reference to the Domain.

   Domain-Name:  A human-readable display string naming the Domain.

4.9.4.  DPN Information Model

   A DPN-Set contains some or all of the DPNs in the Tenant's network.
   Some of the DPNs in the Set may be identical in functionality and
   only differ by their Key.

               |
               +-[DPN] <G-Key>, <Name> (O) <Set>
               |     +-[Extensible: FALSE]
               |     +-[Interface] <L-Key> <Set>
               |     |      +-[Role] <U-Key>
               |     |      +-[Protocol] <Set>
               |     |      +-[Interface-Configuration] <Set> (O)
               |     +-[Domain-Key]
               |     +-[Service-Group-Key] <Set> (O)
               |     +-[DPN-Policy-Configuration] <List> (M)
               |     +-[DPN-Resource-Mapping-Reference] (O)

                      Figure 11: DPN Information Model


   Each DPN entry contains the following information:

   DPN-Key:  A unique Identifier of the DPN.




Matsushima, et al.        Expires 27 March 2021                [Page 20]

Internet-Draft              DMM FPC Protocol              September 2020


   DPN-Name:  A human-readable display string.

   Domain-Key:  A Key providing access to the Domain information about
      the Domain in which the DPN resides.

   Interface-Set:  The Interface-Set references all interfaces (through
      which data packets are received and transmitted) available on the
      DPN.  Each Interface makes use of attribute values that are
      specific to that interface, for example, the MTU size.  These do
      not affect the DPN selection of active or enabled interfaces.
      Interfaces contain the following information:

      Role:  The role (MAG, LMA, PGW, AMF, etc.) of the DPN.

      Protocol (Set):  The set of protocols supported by this interface
         (e.g., PMIP, S5-GTP, S5-PMIP etc.).  The protocol MAY implement
         specific message sets, e.g. s5-pmip, s8-pmip.  When a protocol
         implements such message sub-subsets the Protocol value MUST
         include this information.

      Interface-Configuration-Set:  Configurable settings that further
         determine the suitability of an interface for the specific
         request.  For example: SequenceNumber=ON/OFF.

   Service-Group-Set:  The Service-Group-Set references all of the
      Service-Groups which have been configured using Interfaces hosted
      on this DPN.  The purpose of a Service-Group is not to describe
      each interface of each DPN, but rather to indicate interface types
      for use during the DPN selection process, when a DPN with specific
      interface capabilities is required.

   DPN-Policy-Configuration:  A list of Policies that have been
      configured on this DPN.  Some may have values for all attributes,
      and some may require further configuration.  Each Policy-
      Configuration has a key to enable reference to its Policy-
      Template.  Each Policy-Configuration also has been configured to
      supply missing and non-default values to the desired Attributes
      defined within the Policy-Template.

   DPN-Resource-Mapping-Reference (O):  A reference to the underlying
      implementation, e.g. physical node, software module, etc. that
      supports this DPN.  Further specification of this attribute is out
      of scope for this document.








Matsushima, et al.        Expires 27 March 2021                [Page 21]

Internet-Draft              DMM FPC Protocol              September 2020


4.9.5.  Policy Information Model

   The Policy Information Model defines and identifies Rules for
   enforcement at DPNs.  A Policy is basically a set of Rules that are
   to be applied to each incoming or outgoing packet at a DPN interface.
   Rules comprise Descriptors and a set of Actions.  The Descriptors,
   when evaluated, determine whether or not a set of Actions will be
   performed on the packet.  The Policy structure is independent of a
   policy context.

   In addition to the Policy structure, the Information Model (per
   Section 4.9.6) defines Mobility-Context.  Each Mobility-Context may
   be configured with appropriate Attribute values, for example
   depending on the identity of a mobile node.

   Traffic descriptions are defined in Descriptors, and treatments are
   defined separately in Actions.  A Rule-Set binds Descriptors and
   associated Actions by reference, using Descriptor-Key and Action-Key.
   A Rule-Set is bound to a policy in the Policy-Set (using Policy-Key),
   and the Policy references the Rule definitions (using Rule-Key).

              |
              +-[Policy Information Model]
              |      +-[Extensible:]
              |      +-[Policy-Template] <G-Key> (M) <Set>
              |      |       +-[Policy-Configuration] <Set> (O)
              |      |       +-[Rule-Template-Key] <List> (M)
              |      |       |       +-[Precedence] (M)
              |      +-[Rule-Template] <L-Key> (M) <Set>
              |      |       +-[Descriptor-Match-Type] (M)
              |      |       +-[Descriptor-Configuration] <Set> (M)
              |      |       |       +-[Direction] (O)
              |      |       +-[Action-Configuration] <Set> (M)
              |      |       |       +-[Action-Order] (M)
              |      |       +-[Rule-Configuration] (O)
              |      +-[Descriptor-Template] <L-Key> (M) <Set>
              |      |       +-[Descriptor-Type] (O)
              |      |       +-[Attribute-Expression] <Set> (M)
              |      +-[Action-Template] <L-Key> (M) <Set>
              |              +-[Action-Type] (O)
              |      |       +-[Attribute-Expression] <Set> (M)

                    Figure 12: Policy Information Model


   The Policy structure defines Policy-Set, Rule-Set, Descriptor-Set,
   and Action-Set, as follows:




Matsushima, et al.        Expires 27 March 2021                [Page 22]

Internet-Draft              DMM FPC Protocol              September 2020


   Policy-Template: <Set>  A set of Policy structures, indexed by
      Policy-Key, each of which is determined by a list of Rules
      referenced by their Rule-Key.  Each Policy structure contains the
      following:

      Policy-Key:  Identifies and enables reference to this Policy
         definition.

      Rule-Template-Key:  Enables reference to a Rule template
         definition.

      Rule-Precedence:  For each Rule identified by a Rule-Template-Key
         in the Policy, specifies the order in which that Rule must be
         applied.  The lower the numerical value of Precedence, the
         higher the rule precedence.  Rules with equal precedence MAY be
         executed in parallel if supported by the DPN.  If this value is
         absent, the rules SHOULD be applied in the order in which they
         appear in the Policy.

   Rule-Template-Set:  A set of Rule Template definitions indexed by
      Rule-Key.  Each Rule is defined by a list of Descriptors (located
      by Descriptor-Key) and a list of Actions (located by Action-Key)
      as follows:

      Rule-Template-Key:  Identifies and enables reference to this Rule
         definition.

      Descriptor-Match-Type  Indicates whether the evaluation of the
         Rule proceeds by using conditional-AND, or conditional-OR, on
         the list of Descriptors.

      Descriptor-Configuration:  References a Descriptor template
         definition, along with an expression which names the Attributes
         for this instantiation from the Descriptor-Template and also
         specifies whether each Attribute of the Descriptor has a
         default value or a statically configured value, according to
         the syntax specified in Section 4.2.

      Direction:  Indicates if a rule applies to uplink traffic, to
         downlink traffic, or to both uplink and downlink traffic.
         Applying a rule to both uplink and downlink traffic, in case of
         symmetric rules, eliminates the requirement for a separate
         entry for each direction.  When not present, the direction is
         implied by the Descriptor's values.

      Action-Configuration:  References an Action Template definition,





Matsushima, et al.        Expires 27 March 2021                [Page 23]

Internet-Draft              DMM FPC Protocol              September 2020


         along with an expression which names the Attributes for this
         instantiation from the Action-Template and also specifies
         whether each Attribute of the Action has a default value or a
         statically configured value, according to the syntax specified
         in Section 4.2.

      Action-Order:  Defines the order in which actions are executed
         when the associated traffic descriptor selects the packet.

   Descriptor-Template-Set:  A set of traffic Descriptor Templates, each
      of which can be evaluated on the incoming or outgoing packet,
      returning a TRUE or FALSE value, defined as follows:

      Descriptor-Template-Key:  Identifies and enables reference to this
         descriptor template definition.

      Attribute-Expression:  An expression which defines an Attribute in
         the Descriptor-Template and also specifies whether the Template
         also defines a default value or a statically configured value
         for the Attribute of the Descriptor has, according to the
         syntax specified in Section 4.2.

      Descriptor-Type:  Identifies the type of descriptor, e.g. an IPv6
         traffic selector per [RFC6088].

   Action-Template-Set:  A set of Action Templates defined as follows:

      Action-Template-Key:  Identifies and enables reference to this
         action template definition.

      Attribute-Expression:  An expression which defines an Attribute in
         the Action-Template and also specifies whether the Template
         also defines a default value or a statically configured value
         for the Attribute of the Action has, according to the syntax
         specified in Section 4.2.

      Action-Type:  Identifies the type of an action for unambiguous
         interpretation of an Action-Value entry.

4.9.6.  Mobility-Context Information Model

   The Mobility-Context structure holds entries associated with a mobile
   node and its mobility sessions (flows).  It is created on a DPN
   during the mobile node's registration to manage the mobile node's
   flows.  Flow information is added or deleted from the Mobility-
   Context as needed to support new flows or to deallocate resources for
   flows that are deactivated.  Descriptors are used to characterize the
   nature and resource requirement for each flow.



Matsushima, et al.        Expires 27 March 2021                [Page 24]

Internet-Draft              DMM FPC Protocol              September 2020


   Termination of a Mobility-Context implies termination of all flows
   represented in the Mobility-Context, e.g. after deregistration of a
   mobile node.  If any Child-Contexts are defined, they are also
   terminated.

        +-[Mobility-Context] <G-Key> <Set>
        |            +-[Extensible:~ FALSE]
        |            +-[Delegating-IP-Prefix:] <Set> (O)
        |            +-[Parent-Context] (O)
        |            +-[Child-Context] <Set> (O)
        |            +-[Service-Group-Key] <Set> (O)
        |            +-[Mobile-Node]
        |            |       +-[IP-Address] <Set> (O))
        |            |       +-[MN-Policy-Configuration] <Set>
        |            +-[Domain-Key]
        |            |       +-[Domain-Policy-Configuration] <Set>
        |            +-[DPN-Key] <Set>
        |            |       +-[Role]
        |            |       +-[DPN-Policy-Configuration] <Set>
        |            |       +-[ServiceDataFlow] <L-Key> <Set> (O)
        |            |       |       +-[Service-Group-Key] (O)
        |            |       |       +-[Interface-Key] <Set>
        |            |       |       +-[ServiceDataFlow-Policy-
                                           Configuration] <Set> (O)
        |            |       |       |       +-[Direction]

               Figure 13: Mobility-Context Information Model


   The Mobility-Context Substructure holds the following entries:

   Mobility-Context-Key:  Identifies a Mobility-Context

   Delegating-IP-Prefix-Set:  Delegated IP Prefixes assigned to the
      Mobility-Context

   Parent-Context:  If present, a Mobility Context from which the
      Attributes and Attribute Values of this Mobility Context are
      inherited.

   Child-Context-Set:  A set of Mobility Contexts which inherit the
      Attributes and Attribute Values of this Mobility Context.

   Service-Group-Key:  Service-Group(s) used during DPN assignment and
      re-assignment.

   Mobile-Node:  Attributes specific to the Mobile Node.  It contains
      the following



Matsushima, et al.        Expires 27 March 2021                [Page 25]

Internet-Draft              DMM FPC Protocol              September 2020


      IP-Address-Set  IP addresses assigned to the Mobile Node.

      MN-Policy-Configuration-Set  For each MN-Policy in the set, a key
         and relevant information for the Policy Attributes.

   Domain-Key:  Enables access to a Domain instance.

   Domain-Policy-Configuration-Set:  For each Domain-Policy in the set,
      a key and relevant information for the Policy Attributes.

   DPN-Key-Set:  Enables access to a DPN instance assigned to a specific
      role, i.e. this is a Set that uses DPN-Key and Role as a compound
      key to access specific set instances.

   Role:  Role this DPN fulfills in the Mobility-Context.

   DPN-Policy-Configuration-Set:  For each DPN-Policy in the set, a key
      and relevant information for the Policy Attributes.

   ServiceDataFlow-Key-Set:  Characterizes a traffic flow that has been
      configured (and provided resources) on the DPN to support data-
      plane traffic to and from the mobile device.

      Service-Group-Key:  Enables access to a Service-Group instance.

      Interface-Key-Set:  Assigns the selected interface of the DPN.

      ServiceDataFlow-Policy-Configuration-Set:  For each Policy in the
         set, a key and relevant information for the Policy Attributes.

         Direction:  Indicates if the reference Policy applies to uplink
            or downlink traffic, or to both, uplink- and downlink
            traffic.  Applying a rule to both, uplink- and downlink
            traffic, in case of symmetric rules, allows omitting a
            separate entry for each direction.  When not present the
            value is assumed to apply to both directions.

4.9.7.  Monitor Information Model

   Monitors provide a mechanism to produce reports when events occur.  A
   Monitor will have a target that specifies what is to be watched.

   The attribute/entity to be monitored places certain constraints on
   the configuration that can be specified.  For example, a Monitor
   using a Threshold configuration cannot be applied to a Mobility-
   Context, because it does not have a threshold.  Such a monitor
   configuration could be applied to a numeric threshold property of a
   Context.



Matsushima, et al.        Expires 27 March 2021                [Page 26]

Internet-Draft              DMM FPC Protocol              September 2020


                           |
                           +-[Monitor] <G-Key> <List>
                           |         +-[Extensible:]
                           |         +-[Target:]
                           |         +-[Deferrable]
                           |         +-[Configuration]

                      Figure 14: Monitor Substructure


   Monitor-Key:  Identifies the Monitor.

   Target:  Description of what is to be monitored.  This can be a
      Service Data Flow, a Policy installed upon a DPN, values of a
      Mobility-Context, etc.  The target name is the absolute
      information model path (separated by '/') to the attribute /
      entity to be monitored.

   Deferrable:  Indicates that a monitoring report can be delayed up to
      a defined maximum delay, set in the Agent, for possible bundling
      with other reports.

   Configuration:  Determined by the Monitor subtype.  The monitor
      report is specified by the Configuration.  Four report types are
      defined:

      *  "Periodic" reporting specifies an interval by which a
         notification is sent.

      *  "Event-List" reporting specifies a list of event types that, if
         they occur and are related to the monitored attribute, will
         result in sending a notification.

      *  "Scheduled" reporting specifies the time (in seconds since Jan
         1, 1970) when a notification for the monitor should be sent.
         Once this Monitor's notification is completed the Monitor is
         automatically de-registered.

      *  "Threshold" reporting specifies one or both of a low and high
         threshold.  When these values are crossed a corresponding
         notification is sent.










Matsushima, et al.        Expires 27 March 2021                [Page 27]

Internet-Draft              DMM FPC Protocol              September 2020


5.  Security Considerations

   Detailed protocol implementations for DMM Forwarding Policy
   Configuration must ensure integrity of the information exchanged
   between a FPC Client and a FPC Agent.  Required Security Associations
   may be derived from co-located functions, which utilize the FPC
   Client and FPC Agent respectively.

   General usage of FPC MUST consider the following:

      FPC Naming Section 4.5 permits arbitrary string values but a user
      MUST avoid placing sensitive or vulnerable information in those
      values.

      Policies that are very narrow and permit the identification of
      specific traffic, e.g. that of a single user, SHOULD be avoided.

6.  IANA Considerations

   TBD

7.  Work Team Participants

   Participants in the FPSM work team discussion include Satoru
   Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick
   Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred
   Templin.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              DOI 10.17487/RFC6088, January 2011,
              <https://www.rfc-editor.org/info/rfc6088>.

8.2.  Informative References








Matsushima, et al.        Expires 27 March 2021                [Page 28]

Internet-Draft              DMM FPC Protocol              September 2020


   [I-D.bertz-dime-policygroups]
              Bertz, L. and M. Bales, "Diameter Policy Groups and Sets",
              Work in Progress, Internet-Draft, draft-bertz-dime-
              policygroups-06, 18 June 2018, <http://www.ietf.org/
              internet-drafts/draft-bertz-dime-policygroups-06.txt>.

   [I-D.ietf-dmm-deployment-models]
              Gundavelli, S. and S. Jeon, "DMM Deployment Models and
              Architectural Considerations", Work in Progress, Internet-
              Draft, draft-ietf-dmm-deployment-models-04, 15 May 2018,
              <http://www.ietf.org/internet-drafts/draft-ietf-dmm-
              deployment-models-04.txt>.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

Appendix A.  Implementation Status

   Three FPC Agent implementations have been made to date.  The first
   was based upon Version 03 of the draft and followed Model 1.  The
   second follows Version 04 of the document.  Both implementations were
   OpenDaylight plug-ins developed in Java by Sprint.  Version 04 is now
   primarily enhanced by GS Labs.  Version 03 was known as fpcagent and
   version 04's implementation is simply referred to as 'fpc'.  A third
   has been developed on an ONOS Controller for use in MCORD projects.

   fpcagent's intent was to provide a proof of concept for FPC Version
   03 Model 1 in January 2016 and research various errors, corrections
   and optimizations that the Agent could make when supporting multiple
   DPNs.

   As the code developed to support OpenFlow and a proprietary DPN from
   a 3rd party, several of the advantages of a multi-DPN Agent became
   obvious including the use of machine learning to reduce the number of
   Flows and Policy entities placed on the DPN.  This work has driven
   new efforts in the DIME WG, namely Diameter Policy Groups
   [I-D.bertz-dime-policygroups].












Matsushima, et al.        Expires 27 March 2021                [Page 29]

Internet-Draft              DMM FPC Protocol              September 2020


   A throughput performance of tens per second using various NetConf
   based solutions in OpenDaylight made fpcagent, based on version 03,
   undesirable for call processing.  The RPC implementation improved
   throughput by an order of magnitude but was not useful based upon
   FPC's Version 03 design using two information models.  During this
   time the features of version 04 and its converged model became
   attractive and the fpcagent project was closed in August 2016.
   fpcagent will no longer be developed and will remain a proprietary
   implementation.

   The learnings of fpcagent has influenced the second project, fpc.
   Fpc is also an OpenDaylight project but is an open source release as
   the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/
   Project_Proposals:FpcAgent).  This project is scoped to be a fully
   compliant FPC Agent that supports multiple DPNs including those that
   communicate via OpenFlow.  The following features present in this
   draft and others developed by the FPC development team have already
   led to an order of magnitude improvement.

       Migration of non-realtime provisioning of entities such as
       topology and policy allowed the implementation to focus only on
       the rpc.

       Using only 5 messages and 2 notifications has also reduced
       implementation time.

       Command Sets, an optional feature in this specification, have
       eliminated 80% of the time spent determining what needs to be
       done with a Context during a Create or Update operation.

       Op Reference is an optional feature modeled after video delivery.
       It has reduced unnecessary cache lookups.  It also has the
       additional benefit of allowing an Agent to become cacheless and
       effectively act as a FPC protocol adapter remotely with multi-DPN
       support or co-located on the DPN in a single-DPN support model.

       Multi-tenant support allows for Cache searches to be partitioned
       for clustering and performance improvements.  This has not been
       capitalized upon by the current implementation but is part of the
       development roadmap.

       Use of Contexts to pre-provision policy has also eliminated any
       processing of Ports for DPNs which permitted the code for
       CONFIGURE and CONF_BUNDLE to be implemented as a simple nested
       FOR loops (see below).






Matsushima, et al.        Expires 27 March 2021                [Page 30]

Internet-Draft              DMM FPC Protocol              September 2020


   Initial v04 performance results without code optimizations or tuning
   allow reliable provisioning of 1K FPC Mobility-Contexts processed per
   second on a 12 core server.  This results in 2x the number of
   transactions on the southbound interface to a proprietary DPN API on
   the same machine.

   fpc currently supports the following:

                           1 proprietary DPN API

                           Policy and Topology as defined in this
                           specification using OpenDaylight North Bound
                           Interfaces such as NetConf and RestConf

                           CONFIG and CONF_BUNDLE (all operations)

                           DPN assignment, Tunnel allocations and IPv4
                           address assignment by the Agent or Client.

                           Immediate Response is always an
                           OK_NOTIFY_FOLLOWS.






























Matsushima, et al.        Expires 27 March 2021                [Page 31]

Internet-Draft              DMM FPC Protocol              September 2020


        assignment system (receives rpc call):
          perform basic operation integrity check
          if CONFIG then
            goto assignments
            if assignments was ok then
              send request to activation system
              respond back to client with assignment data
            else
              send back error
            end if
          else if CONF_BUNDLE then
            for each operation in bundles
            goto assignments
            if assignments was ok then
              hold onto data
            else
              return error with the assignments that occurred in
                prior operations (best effort)
            end if
            end for
            send bundles to activation systems
          end if

        assignments:
          assign DPN, IPv4 Address and/or tunnel info as required
          if an error occurs undo all assignments in this operation
          return result

        activation system:
          build cache according to op-ref and operation type
          for each operation
            for each Context
              for each DPN / direction in Context
                perform actions on DPN according to Command Set
              end for
            end for
          end for
          commit changes to in memory cache
          log transaction for tracking and notification
                                        (CONFIG_RESULT_NOTIFY)

                         Figure 15: fpc pseudo code

   For further information please contact Lyle Bertz who is also a co-
   author of this document.






Matsushima, et al.        Expires 27 March 2021                [Page 32]

Internet-Draft              DMM FPC Protocol              September 2020


   NOTE: Tenant support requires binding a Client ID to a Tenant ID (it
   is a one to many relation) but that is outside of the scope of this
   specification.  Otherwise, the specification is complete in terms of
   providing sufficient information to implement an Agent.

Authors' Addresses

   Satoru Matsushima
   SoftBank
   1-9-1,Higashi-Shimbashi,Minato-Ku,
   Japan

   Email: satoru.matsushima@g.softbank.co.jp


   Lyle Bertz
   6220 Sprint Parkway
   Overland Park  KS, 66251,
   United States of America

   Email: lylebe551144@gmail.com


   Marco Liebsch
   NEC Laboratories Europe
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   D-69115 Heidelberg
   Germany

   Phone: +49 6221 4342146
   Email: liebsch@neclab.eu


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA 95134
   United States of America

   Email: sgundave@cisco.com


   Danny Moses

   Email: danny.moses@intel.com





Matsushima, et al.        Expires 27 March 2021                [Page 33]

Internet-Draft              DMM FPC Protocol              September 2020


   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA 95050
   United States of America

   Phone: +1-408-330-4586
   Email: charliep@computer.org











































Matsushima, et al.        Expires 27 March 2021                [Page 34]