draft-ietf-dmm-fpc-cpdp-09.txt   draft-ietf-dmm-fpc-cpdp-10.txt 
DMM Working Group S. Matsushima DMM Working Group S. Matsushima
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track L. Bertz Intended status: Standards Track L. Bertz
Expires: May 3, 2018 Sprint Expires: September 6, 2018 Sprint
M. Liebsch M. Liebsch
NEC NEC
S. Gundavelli S. Gundavelli
Cisco Cisco
D. Moses D. Moses
Intel Corporation Intel Corporation
C. Perkins C. Perkins
Futurewei Futurewei
October 30, 2017 March 5, 2018
Protocol for Forwarding Policy Configuration (FPC) in DMM Protocol for Forwarding Policy Configuration (FPC) in DMM
draft-ietf-dmm-fpc-cpdp-09 draft-ietf-dmm-fpc-cpdp-10
Abstract Abstract
This document describes a way, called Forwarding Policy Configuration This document describes a way, called Forwarding Policy Configuration
(FPC) to manage the separation of data-plane and control-plane. FPC (FPC) to manage the separation of data-plane and control-plane. FPC
defines a flexible mobility management system using FPC agent and FPC defines a flexible mobility management system using FPC agent and FPC
client functions. An FPC agent provides an abstract interface to the client functions. An FPC agent provides an abstract interface to the
data-plane. The FPC client configures data-plane nodes by using the data-plane. The FPC client configures data-plane nodes by using the
functions and abstractions provided by the FPC agent for that data- functions and abstractions provided by the FPC agent for the data-
plane nodes. The data-plane abstractions presented in this document plane nodes. The data-plane abstractions presented in this document
is extensible, in order to support many different types of mobility are extensible, in order to support many different types of mobility
management systems and data-plane functions. management systems and data-plane functions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. FPC Design Objectives and Deployment . . . . . . . . . . . . 5 3. FPC Design Objectives and Deployment . . . . . . . . . . . . 6
4. FPC Mobility Information Model . . . . . . . . . . . . . . . 8 4. FPC Mobility Information Model . . . . . . . . . . . . . . . 9
4.1. Model Notation and Conventions . . . . . . . . . . . . . 8 4.1. Model Notation and Conventions . . . . . . . . . . . . . 9
4.2. Core Structure - Information Model Components . . . . . . 9 4.2. Templates and Attributes . . . . . . . . . . . . . . . . 12
4.3. Topology . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Attribute-Expressions . . . . . . . . . . . . . . . . . . 13
4.3.1. DPN . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Attribute Value Types . . . . . . . . . . . . . . . . . . 14
4.3.2. DPN-Type . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Namespace and Format . . . . . . . . . . . . . . . . . . 14
4.3.3. DPN-Group . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Configuring Attribute Values . . . . . . . . . . . . . . 14
4.3.4. Domain . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Entity Configuration Blocks . . . . . . . . . . . . . . . 15
4.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. Infomation Model Checkpoint . . . . . . . . . . . . . . . 16
4.5. Configurable Policy . . . . . . . . . . . . . . . . . . . 18 4.9. Information Model Components . . . . . . . . . . . . . . 17
4.6. Mobility-Context . . . . . . . . . . . . . . . . . . . . 19 4.9.1. Service-Group . . . . . . . . . . . . . . . . . . . . 17
4.7. Monitors . . . . . . . . . . . . . . . . . . . . . . . . 22 4.9.2. Service Endpoints . . . . . . . . . . . . . . . . . . 17
4.8. Namespace and Format . . . . . . . . . . . . . . . . . . 23 4.9.3. Topology Information Model . . . . . . . . . . . . . 19
4.9. Attribute Application . . . . . . . . . . . . . . . . . . 24 4.9.4. Domain Information Model . . . . . . . . . . . . . . 19
5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.9.5. DPN Information Model . . . . . . . . . . . . . . . . 19
5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 24 4.9.6. Policy Information Model . . . . . . . . . . . . . . 21
5.1.1. CONFIG and CONF_BUNDLE Messages . . . . . . . . . . . 27 4.9.7. Mobility-Context Information Model . . . . . . . . . 24
5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 29 4.9.8. Monitor Information Model . . . . . . . . . . . . . . 26
5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 30 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 30 5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 27
5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 36 5.1.1. Configure Message . . . . . . . . . . . . . . . . . . 30
5.2.3. Optimization for Current and Subsequent Messages . . 38 5.1.2. Monitor Messages . . . . . . . . . . . . . . . . . . 36
6. Protocol Message Details . . . . . . . . . . . . . . . . . . 41 5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 38
6.1. Data Structures And Type Assignment . . . . . . . . . . . 41 5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 38
6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 41 5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 46
6.1.2. Mobility Structures . . . . . . . . . . . . . . . . . 43 6. Templates And Command Sets . . . . . . . . . . . . . . . . . 48
6.1.3. Message Attributes . . . . . . . . . . . . . . . . . 47 6.1. Monitor Configuration Templates . . . . . . . . . . . . . 49
7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 51 6.2. Descriptor Templates . . . . . . . . . . . . . . . . . . 49
7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 56 6.3. Tunnel Templates . . . . . . . . . . . . . . . . . . . . 52
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 58 6.4. Action Templates . . . . . . . . . . . . . . . . . . . . 53
9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 6.5. Quality of Service Action Templates . . . . . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 6.6. PMIP Command-Set . . . . . . . . . . . . . . . . . . . . 55
11. Work Team Participants . . . . . . . . . . . . . . . . . . . 64 6.7. 3GPP Specific Templates and Command-Set . . . . . . . . . 55
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
12.2. Informative References . . . . . . . . . . . . . . . . . 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Work Team Participants . . . . . . . . . . . . . . . . . . . 64
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
11.1. Normative References . . . . . . . . . . . . . . . . . . 64
11.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 66 Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 66
A.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . . . 67 A.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . . . 67
A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 89 A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 89
A.2.1. FPC YANG Settings and Extensions Model . . . . . . . 89 A.2.1. FPC YANG Settings and Extensions Model . . . . . . . 89
A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 105 A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 101
A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 117 A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 109
A.2.4. RFC 5777 Classifier YANG Model . . . . . . . . . . . 117
A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 125 A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 125
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128 Appendix B. Changes since Version 09 . . . . . . . . . . . . . . 133
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 134
1. Introduction 1. Introduction
This document describes Forwarding Policy Configuration (FPC), a This document describes Forwarding Policy Configuration (FPC), a
system for managing the separation of data-plane and control-plane. system for managing the separation of control-plane and data-plane.
FPC enables flexible mobility management using FPC agent and FPC FPC enables flexible mobility management using FPC client and FPC
client functions. An FPC agent exports an abstract interface to the agent functions. An FPC agent exports an abstract interface
data-plane. To configure data-plane nodes and functions, the FPC representing the data-plane. To configure data-plane nodes and
client uses the interface to the data-plane offered by the FPC agent. functions, the FPC client uses the interface to the data-plane
offered by the FPC agent.
Control planes of mobility management systems, or other applications Control planes of mobility management systems, or related
which require data-plane control, can utilize the FPC client at applications which require data-plane control, can utilize the FPC
various granularities of operation. The operations are capable of client at various levels of abstraction. FPC operations are capable
configuring a single Data-Plane Node (DPN) directly, as well as of directly configuring a single Data-Plane Node (DPN), as well as
multiple DPNs as determined by abstracted data-plane models on the multiple DPNs, as determined by the data-plane models exported by the
FPC agent. FPC agent.
A FPC agent provides data-plane abstraction in the following three A FPC agent represents the data-plane operation according to several
areas: basic information models. An FPC agent also provides access to
Monitors, which produce reports when triggered by events regarding
Topology: DPNs are grouped and abstracted according to well-known Mobility Contexts, DPNs or the Agent.
concepts of mobility management such as access networks, anchors
and domains. A FPC agent provides an interface to the abstract
DPN-groups that enables definition of a topology for the
forwarding plane. For example, access nodes may be assigned to a
DPN-group which peers to a DPN-group of anchor nodes.
Policy: A Policy embodies the mechanisms for processing specific
traffic flows or packets. This is needed for QoS, for packet
processing to rewrite headers, etc. A Policy consists of one or
more rules. Each rule is composed of Descriptors and Actions.
Descriptors in a rule identify traffic flows, and Actions apply
treatments to packets that match the Descriptors in the rule. An
arbitrary set of policies can applied to a particular collection
of flows throgh the use of a Configurable-Policy.
Mobility: A mobility session which is active on a mobile node is To manage mobility sessions, the FPC client assembles applicable sets
abstracted as a Mobility-Context with associated runtime concrete of forwarding policies from the data model, and configures them on
attributes, such as tunnel endpoints, tunnel identifiers, the appropriate FPC Agent. The Agent then renders those policies
delegated prefix(es), routing information, etc. Mobility-Contexts into specific configurations for each DPN at which mobile nodes are
are attached to DPNs via DPN-References. The References assign attached. The specific protocols and configurations to configure a
pre-defined Policies that were requested to be enforced as part of DPN from a FPC Agent are outside the scope of this document.
the mobility signaling request. Policy may also be realized by
Embedded-Rules in the DPN-Reference. Such policies are typically
highly specialized (e.g. negotiated as a part of signaling), were
not pre-provisioned or designed as a template. Hence, they are
not reusable across Mobility-Contexts.
Monitors provide a mechanism to produce reports when events A DPN is a logical entity that performs data-plane operations (packet
regarding Configurable Policies, Mobility Contexts, DPNs or the movement and management). It may represent a physical DPN unit, a
Agent occur. 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.
The Agent assembles applicable sets of forwarding policies for the When a DPN is mapped to physical data-plane equipment, the FPC client
mobility sessions from the data model, and then renders those can have complete knowledge of the DPN architecture, and use that
policies into specific configurations for each DPN to which the information to perform DPN selection for specific sessions. On the
sessions attached. The specific protocols and configurations to other hand, when a virtual DPN is mapped to a collection of physical
configure DPN from a FPC Agent are outside the scope of this DPNs, the FPC client cannot select a specific physical DPN because it
document. is hidden by the abstraction; only the FPC Agent can address the
specific associated physical DPNs. Network architects have the
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 data-plane abstractions may be extended to support many different The abstractions in this document are designed to support many
mobility management systems and data-plane functions. The different mobility management systems and data-plane functions. The
architecture and protocol design of FPC is not tied to specific types architecture and protocol design of FPC is not tied to specific types
of access technologies and mobility protocols. of access technologies and mobility protocols.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Domain: One or more DPNs that form a logical
partition of network resources (e.g., a data-
plane network under common network
administration). An FPC client (e.g., a
mobility management system) may utilize a
single or multiple domains.
DPN: A data-plane node (DPN) is capable of DPN: A data-plane node (DPN) is capable of
deploying data-plane features. DPNs may be performing data-plane features. For example,
switches or routers regardless of their DPNs may be switches or routers, regardless
realiziation, i.e. whether they are hardware of whether they are realized as hardware or
or software based. purely in software.
FPC Agent: A functional entity in FPC that manages DPNs DPN-Set: the set of DPNs in a network configuration
and provides abstracted data-plane networks
to mobility management systems and/or
applications through FPC Clients.
FPC Client: A functional entity in FPC that is integrated Service-Endpoint-Set: a set of Service-Endpoint entities
with mobility management systems and/or
applications to control forwarding policy, FPC Agent: An FPC Agent manages DPNs, thereby providing
mobility sessions and DPNs. abstracted data-plane networks to FPC
Clients.
FPC Client: An FPC Client is integrated with a mobility
management system or related application,
enabling control over forwarding policy,
mobility sessions and DPNs via an FPC Agent.
Service-Group-Set: a set of DPN interfaces that support a
specific data-plane purpose (inbound/
outbound, roaming, subnetwork with common
specific configuration, etc.)
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
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 an
FPC Agent to an 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 an
FPC entity
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.
Tenant: An operational entity that manages mobility Tenant: An operational entity that manages mobility
management systems or applications which management systems or applications which
require data-plane functions. require data-plane functions.
Domain: One or more DPNs that form a data-plane Topology: The DPNs and the links between them. For
network. A mobility management system or an example, access nodes may be assigned to a
application in a tenant may utilize a single Service Group which peers to a Service Group
or multiple domains. of anchor nodes.
Configurable Policy: A set of Rules (forwarding policies)
installed upon a DPN.
Mobility Context: An abstracted endpoint of a mobility session
associated with runtime attributes.
3. FPC Design Objectives and Deployment 3. FPC Design Objectives and Deployment
To fulfill the requirements described in [RFC7333], FPC enables Using FPC, mobility control-planes and applications can configure
mobility control-planes and applications to configure DPNs with DPNs to perform various mobility management roles as described in
various roles of the mobility management as described in [I-D.ietf-dmm-deployment-models]. This fulfills the requirements
[I-D.ietf-dmm-deployment-models]. described in [RFC7333].
FPC defines building blocks of FPC Agent and FPC Client, as well as
data models for the necessary data-plane abstractions. The
attributes defining those data models serve as protocol elements for
the interface between the FPC Agent and the FPC Client.
Mobility control-planes and applications integrate the FPC Client This document defines FPC Agent and FPC Client, as well as the
function. The FPC Client connects to FPC Agent functions. The information models that they use. The attributes defining those
Client and the Agent communicate based on information models for the models serve as the protocol elements for the interface between the
data-plane abstractions described in Section 4. The data models FPC Agent and the FPC Client.
allow the control-plane and the applications to support forwarding
policies on the Agent for their mobility sessions.
The FPC Agent carries out the required configuration and management Mobility control-plane applications integrate features offered by the
of the DPN(s). The Agent determines DPN configurations according to FPC Client. The FPC Client connects to FPC Agent functions. The
the forwarding policies requested by the FPC Client. The DPN Client and the Agent communicate based on information models
configurations could be specific to each DPN implementation such that described in Section 4. The models allow the control-plane to
how FPC Agent determines implementation specific configuration for a configure forwarding policies on the Agent for data-plane
DPN is outside of the scope of this document. Along with the models, communications with mobile nodes.
the control-plane and the applications put Policies to the Agent
prior to creating their mobility sessions.
Once the Topology of DPN(s) and domains are defined for a data plane Once the Topology of DPN(s) and domains are defined on an Agent for a
on an Agent, the data-plane nodes (DPNs) are available for further data plane, the DPNs in the topology are available for further
configuration. The FPC Agent connects those DPNs to manage their configuration. The FPC Agent connects those DPNs to manage their
configurations. configurations.
An FPC Agent configures and manages its DPN(s) according to
forwarding policies requested 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 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. An FPC Agent may be This architecture is illustrated in Figure 1. An FPC Agent may be
implemented in a network controller that handles multiple DPNs, or implemented in a network controller that handles multiple DPNs, or
there is a simple case where another FPC Agent may itself be (more simply) an FPC Agent may itself be integrated into a DPN.
integrated into a DPN.
This document does not adopt a specific protocol for the FPC This document does not specify a protocol for the FPC interface; it
interface protocol and it is out of scope. However it must be is out of scope. However, an implementation must support the FPC
capable of supporting FPC protocol messages and transactions transactions described in Section 5.
described in Section 5.
+-------------------------+ +-------------------------+
| Mobility Control-Plane | | Mobility Control-Plane |
| and | | and |
| Applications | | Applications |
|+-----------------------+| |+-----------------------+|
|| FPC Client || || FPC Client ||
|+----------^------------+| |+----------^------------+|
+-----------|-------------+ +-----------|-------------+
FPC interface protocol | FPC interface protocol |
+---------------+-----------------+ +---------------+-----------------+
| | | |
Network | | Network | |
Controller | DPN | Controller | DPN |
+-----------|-------------+ +----------|---------+ +-----------|-------------+ +----------|---------+
|+----------v------------+| |+---------v--------+| |+----------v------------+| |+---------v--------+|
|| [Data-plane model] || ||[Data-plane model]|| || [Data-plane model] || ||[Data-plane model]||
|| FPC Agent || || FPC Agent || || FPC Agent || || FPC Agent ||
|+-----------------------+| |+------------------+| |+-----------------------+| |+------------------+|
|+------------+----------+| | | |+------------+----------+| | |
||SB Protocols|FPC Client|| | DPN Configuration | ||SB Protocol |FPC Client|| | DPN Configuration |
|| Modules | Module || +--------------------+ || Modules | Module || +--------------------+
|+------^-----+----^-----+| |+------^-----+----^-----+|
+-------|----------|------+ +-------|----------|------+
| | | |
Other | | FPC interface Other | | FPC interface
Southband | | Protocol southband | | protocol
Protocols | | protocols | |
| +-----------------+ | +-----------------+
| | | |
DPN | DPN | DPN | DPN |
+----------|---------+ +----------|---------+ +----------|---------+ +----------|---------+
|+---------v--------+| |+---------v--------+| |+---------v--------+| |+---------v--------+|
|| Configuration || ||[Data-plane model]|| || Configuration || ||[Data-plane model]||
|| Protocol module || || FPC Agent || || Protocol module || || FPC Agent ||
|+------------------+| |+------------------+| |+------------------+| |+------------------+|
| | | | | | | |
| DPN Configuration | | DPN Configuration | | DPN Configuration | | DPN Configuration |
skipping to change at page 8, line 5 skipping to change at page 9, line 5
Figure 1: Reference Forwarding Policy Configuration (FPC) Figure 1: Reference Forwarding Policy Configuration (FPC)
Architecture Architecture
The FPC architecture supports multi-tenancy; an FPC enabled data- The FPC architecture supports multi-tenancy; an FPC enabled data-
plane supports tenants of multiple mobile operator networks and/or plane supports tenants of multiple mobile operator networks and/or
applications. It means that the FPC Client of each tenant connects applications. It means that the FPC Client of each tenant connects
to the FPC Agent and it MUST partition namespace and data for their 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 data-planes. DPNs on the data-plane may fulfill multiple data-plane
roles which are defined per session, domain and tenant. roles which are defined per session, domain and tenant.
Note that all FPC models SHOULD be configurable. The FPC interface FPC information models often configuration to fit the specific needs
protocol in Figure 1 is only required to handle runtime data in the for DPN management of a mobile node's traffic. The FPC interfaces in
Mobility model. The rest of the FPC models, namely Topology and Figure 1 are the only interfaces required to handle runtime data in a
Policy, may be pre-configured, and in that case real-time protocol Mobility Context. The Topology and some Policy FPC models may be
exchanges would not be required for them. Operators that are tenants pre-configured; in that case real-time protocol exchanges are not
in the FPC data-plane could configure Topology and Policy on the required for them.
Agent through other means, such as Restconf
[I-D.ietf-netconf-restconf] or Netconf [RFC6241].
4. FPC Mobility Information Model 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.
:
|
+-[FPC Mobility Information Model]
| |
| +-[DPN Information Model]
| |
| +-[Topology Information Model]
| |
| +-[Policy Information Model]
| |
| +-[Mobility-Context]
| |
| +-[Monitor]
|
Figure 2: FPC Information Model structure
4.1. Model Notation and Conventions 4.1. Model Notation and Conventions
In order to clarify the description of the information model, this The following conventions are used to describe the FPC information
draft uses the convention describe in the below. models.
Information model entities, e.g. DPNs, Rules, etc., are listed in a Information model entities (e.g. DPNs, Rules, etc.) are defined in a
hierarchical notation where all entities with the same hierarchical hierarchical notation where all entities at the same hierarchical
level are located on the same left-justified position one after the level are located on the same left-justified vertical position
other. When entities are composed of sub-entities, they will appear sequentially. When entities are composed of sub-entities, the sub-
shifted to the right. entities appear shifted to the right, as shown in Figure 3.
| |
+-[entity2] +-[entity2]
| +-[entity2.1] | +-[entity2.1]
| +-[entity2.2] | +-[entity2.2]
Figure 2: Model Notation - An Example Figure 3: Model Notation - An Example
Some entities MAY have one or more sub-types placed on the right hand Some entities have one or more qualifiers placed on the right hand
side of the element definition in pointing brackets. Common types side of the element definition in angle-brackets. Common types
include: include:
List: A collection of entities (some could be of the same kind) List: a collection of entities (some could be duplicated)
Set: A collection of entities without duplications Set: a nonempty collection of entities without duplications
Name: a human-readable string Name: a human-readable string
Key: a unique value. There are 3 types of keys: Key: a unique value. We distinguish 3 types of keys:
U-Key: a universally unique key across all tenants. U-Key spaces U-Key: a key unique across all tenants. U-Key spaces typically
are typically involve the use of registries or language involve the use of registries or language specific mechanisms
specific mechanisms that guarantee universal uniqueness of that guarantee universal uniqueness of values.
values.
G-Key: a globally unique key - unique within a tenant G-Key: a key unique within a tenant
L-Key: a unique key within the set of values in local namespace.
For example, there exist interfaces with teh same name, e.g.
"interface0", in two different DPNs within the same tenant but
there can only be one "interface0" within each DPN, i.e. its
local Interface-Id L-Key space.
The Settings pattern, i.e. attributes whose names contain the word L-Key: a key unique within a local namespace. For example, there
'Settings', is a genera set that holds unique properties. If may exist interfaces with the same name, e.g. "if0", in two
multiple values of a property are present they are held in a List for different DPNs but there can only be one "if0" within each DPN
the property within the settings container. The container acts as an (i.e. its local Interface-Key L-Key space).
extensible placeholder for properties (attribute/value pairs).
Each entity or its subtype may be optional (O) or mandatory (M). Each entity or attribute may be optional (O) or mandatory (M).
Entities that are not marked as optional are mandatory. Entities that are not marked as optional are mandatory.
Example: The following example shows 3 entities: The following example shows 3 entities:
- Entity1 is a globally unique key and has an -- Entity1 is a globally unique key, and optionally can have
optional, associated Name an associated Name
- Entity2 is a list -- Entity2 is a list
- Entity3 is a set and is optional -- Entity3 is a set and is optional
+ +
| |
+-[entity1] <G-Key> (M), <Name> (O) +-[entity1] <G-Key> (M), <Name> (O)
+-[entity2] <List> +-[entity2] <List>
+-[entity3] <Set> (O) +-[entity3] <Set> (O)
| |
+ +
Figure 3 Figure 4
When expanding entity1 into an information model such as YANG it When expanding entity1 into a modeling language such as YANG it would
would result in two values: entity1-GKey and entity1-Name. result in two values: entity1-GKey and entity1-Name.
4.2. Core Structure - Information Model Components 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:
The substructures that comprise the information model are: EntityA definition references an entityB model element.
Topology: defines the different DPNs and links between them. EntityB model elements are indexed by entityB-Key.
Policy-Definitions: describes how to handle flows: how to identify Each EntityB model element has an entityB-Key which allows it to be
traffic and what actions are performed on data packets 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.
Configurable-Policy: policies that are relatively static. These .
policies are usually pre-provisioned and are modified only when .
the network configuration is updated or when new policy rules are |
configured +-[entityA]
| +-[entityB-Key]
| +-[entityB-Values]
.
.
|
+-[entityB] <L-Key> (M) <Set>
| +-[entityB-Type]
.
.
Mobility-Context: policies that are created or modified during the Figure 5: Indexed sets of entities
network's operation. In most cases, on a per-flow or per session
basis
Monitor: a list of events that trigger notification messages from Indexed sets are specified for each of the following kinds of
FPC Agents to FPC Clients entities:
: Domain (See Section 4.9.4)
| DPN (See Section 4.9.5)
+-[Mobility] Policy (See Section 4.9.6)
| + Descriptor (See Figure 13)
| | Action (See Figure 13)
: +-[Topology] Service Group (See Section 4.9.1, and
| Mobility-Context (See Section 4.9.7)
+-[Policy]
|
+-[Configurable-Policy] <Set>
|
+-[Mobility-Context] <Set>
|
+-[Monitor] <Set>
Figure 4: Mobility Information Model - Core Structure 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.3. Topology 4.2. Templates and Attributes
The Topology sub-structure specifies virtual DPNs and the relations In order to simplify development and maintenance of the needed
between them. It is used by the network management entity to select policies and other objects used by FPC, the Information Models which
the most appropriate DPN resources for handling specific session are presented often have attributes that are not initialized with
flows. 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 an 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.
A virtual DPN is a logical entity that performs DPN functionality +-[Template] <U-Key, Name> (M) <Set>
(packet movement and management). It may represent a physical DPN | +-[Attributes] <Set> (M)
unit, a sub-function of a physical DPN or a collection of physical | +-[Extensible ~ FALSE]
DPNs. The motivation to refer to virtual DPNs in the information | +-[Entity-State ~ Initial]
model rather than physical DPNs is to provide flexibility for network | +-[Version]
architects to define which DPN-selection capabilities are performed
by the FPC Agent (distributed) and which by the FPC client
(centralized).
When a virtual DPN is mapped to a physical DPN, the FPC client has Figure 6: Template entities
maximum knowledge of the DPN architecture and uses it to perform DPN
selection for specific sessions. 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 and only the FPC
Agent can address the specific associated physical DPNs.
The Topology sub-structure is comprised of the following sub- Attributes: A set of Attribute names MAY be included when defining a
structures: Template for instantiating FPC entities. Any instantiation from a
Template MUST have at least one Attribute in order to be a useful
entity.
DPN-Set: the set of virtual DPNs in a network configuration 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.
DPN-Type-Set: a set of DPN-Type entities 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.
DPN-Group-Set: a set of virtual DPNs that supports a specific Version: Provides a version tag for the template.
administrative purpose (in/out bound, roaming, subnetwork with
common specific configuration etc.)
Domain: a set of Domains tha represent a logical partition of The Attributes in an Entity Template may be either mandatory or non-
network resources 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
+-[Topology] Attributes, so that no additional values are needed before the entity
| +-[DPN] <Set> can made Active. Any instantiation from a Template MUST have at
| +-[DPN-Type] <Set> least one Attribute in order to be a useful entity.
| +-[DPN-Group] <Set>
| +-[Domain] <Set>
Figure 5: Topology Substructure 4.3. Attribute-Expressions
4.3.1. DPN The syntax of the Attribute definition is formatted to make it clear,
for every Attribute in the Entity Template, which of the six
possibilities is specified, as follows:
The DPN set sub-structure specifies a subset of virtual DPNs in the '[Att-Name: ]' Mandatory Attribute is defined, but template does not
network . Some of the DPNs may be identical in functionality and only provide any configured value.
differ by their key.
| '[Att-Name: Att-Value]' Mandatory Attribute is defined, and has a
+-[DPN] <Set> statically configured value.
| +-[DPN-Id] <G-Key>, <Name> (O)
| +-[DPN-Resource-Mapping-Reference] (O)
| +-[Interface] <Set>
| +-[Interface-Reference]
| | +-[Access-Technology] <U-Key>
| | +-[Role] <U-Key>
| | +-[Interface-Id] <L-Key>
| +-[Interface-Settings] <Set> (O)
Figure 6: DPN Substructure '[Att-Name: ~ Att-Value]' Mandatory Attribute is defined, and has a
default value.
Each DPN entry contains the following information: '[Att-Name]' Non-mandatory Attribute may be included but template
does not provide any configured value.
DPN-Id (Key): A unique Identifier of the virtual DPN '[Att-Name = Att-Value]' Non-mandatory Attribute may be included and
has a statically configured value.
DPN-Id (Name): the human-readable display string '[Att-Name ~ Att-Value]' Non-mandatory Attribute may be included and
DPN-Resource-Mapping-Reference (O): A reference to the underlying has a default value.
implementation, e.g. physical node, virtual element, etc. that
supports this DPN. This value MUST be non-empty prior to Dynamic-
Policies being installed upon the DPN.
Interface-Set: the set of interfaces (through which data packets are So, for example, a default value for a non-mandatory IPv4-Address
received and transmitted) of that Virtual DPN. The virtual DPN attribute would be denoted by [IPv4-Address ~ 127.0.0.1].
abstracts one or multiple physical DPNs each having one or more
interfaces. The Interface-set sub-structure is a collection of
all interface types available by this virtual DPN. The purpose of
this information is not to describe each interface of each DPN,
but rather, to indicate the entire set of interface types for the
sake of the DPN selection process, when a DPN with specific
interface capabilities is required. Each interface entry has a
reference to a defined DPN-Type entry in the DPN-Type-Set sub-
structure defined below and additional information that is
specific to that interface:
Interface-Reference - a 3-tuple key that uniquely references an After an FPC Client identifies which additional Attributes have been
entry in the DPN-Type-Set sub-structure: Access-Technology, configured to be included in an instantiated entity, those configured
Role and Interface-Id. 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.
Interface-Settings - An optional set of settings of this Whenever there is danger of confusion, the fully qualified Attribute
interface (that do not affect the DPN selection of active or name MUST be used when supplying needed Attribute Values for a
enabled interfaces). Examples: MTU size, display name, etc. structured Attribute.
4.3.2. DPN-Type 4.4. Attribute Value Types
DPN-Type is the collection of all possible types of interfaces For situations in which the type of an attribute value is required,
defined for DPNs in the network. The interfaces are grouped the following syntax is recommended. To declare than an attribute
according to their access technology, e.g. 3GPP, WiMAX, 802.x and has data type "foo", typecast the attribute name by using the
Role, e.g. LMA, MAG, PGW, AMF etc. Within a group, interfaces may parenthesized data type (foo). So, for instance, [(float) Max-
have additional properties that are more specific, a list of features Latency-in-ms:] would indicate that the mandatory Attribute "Max-
and optionally settings relevant to DPN selection. This information Latency-in-ms" requires to be configured with a floating point value
is used when searching for resources in a network to carry out before the instantiated entity could be used. Similarly, [(float)
required operations on data traffic. 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
+-[DPN-Type] <Set>
| +-[Access-Technology] <U-Key>,<Name> (O)
| +-[Role] <U-Key>, <Name> (O)
| +-[Interface] <Set>
| +-[Interface-Id] <L-Key>, <Name> (O)
| +-[Interface-Protocol] <Set>
| +-[Features] <Set> (O)
| +-[Interface-Settings] <Set> (O)
Figure 7: DPN Type The identifiers and names in FPC models which reside in the same
namespace 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.
Each DPN-Type entry contains the following information: When a Policy needs to be applied to Contexts in all tenants on an
Agent, the Agent SHOULD define that policy to be visible from all the
tenants. In this case, the Agent assigns an unique identifier in the
agent namespace and effectively creates a U-Key although only a G-Key
is required.
Access-technology: the technology used in the access network that The notation for identifiers can utilize any format with agreement
originated the signaling (WiMAX, 3GPP, 802.x etc.) 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.
Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing the There are identifiers reserved for Protocol Operation. See
interfaces specified below. Section 5.1.1.5 for details.
Interface: A set of interfaces possible for the group above. Each 4.6. Configuring Attribute Values
interface carries the following information:
Interface-Id: a key that is used together with the 2-tuple Attributes of Information Model components such as policy templates
Access-Technology and Role, to create a 3-tuple key that is are configured with values as part of FPC configuration operations.
referred to be the interface definition of virtual DPNs There may be several such configuration operations before the
template instantiation is fully configured.
Interface-Protocols: rotocols supported by this interface - When the FPC Client instantiates a Policy from a Template, the
PMIP, S5-GTP, S5-PMIP etc. Policy-Status is "Initial". When the FPC Client sends the policy to
an 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 (if any) 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 an 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 DPN 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".
Features: an optional set of supported features which further Attribute values in DPN-resident Policies may be configured by the
determine the suitability of the interface to the desired FPC Agent as follows:
operation
Interface-Settings: an optional set of settings that MUST be Domain-Settings: Values for Policy attributes that are required for
known when determining the suitability of an interface for the every DPN in the domain.
specific request. The difference between 'Features' and
'Settings' is that 'Features' are static while 'Settings' may
be configured. Examples: SequenceNumber=ON/OFF
The entries Access-Technology and Role represent a tuple key that DPN-Settings: Values for Policy attributes that are required for
uniquely identifies the set of interfaces that may be available for every policy configured on this DPN.
DPNs of the specific type.
4.3.3. DPN-Group Service-Settings: Values for Policy attributes that are required to
carry out the intended Service of the Service Group.
A DPN-Group is a list of a group of DPNs serving some administrative MN-Settings: Values for Policy attributes that are required for all
purpose. Each group contains a list of DPNs (referenced by DPN-Id) traffic to/from a particular mobile node.
and selected interfaces (referenced by the interface's 3-tuple key).
The interfaces are listed rather than referred implicitly by each
specific DPN to enable to define a subset of a DPN interfaces to be
part of the group.
| Flow-Settings: Values for Policy attributes that are required for
+-[DPN-Group] <Set> traffic belonging to a particular set of flows on the mobile node.
| +-[DPN-Group-Id] <G-Key>, <Name> (O)
+-[Referenced-Interface] <Set>
| +-[Interface-Id] <L-Key>
| +-[Role] <U-Key>
| +-[Access-Technology] <U-Key>
| +-[Supporting-DPN-Id] <Set>
| +-[DPN-Group-Peer-Reference] <Set> (O)
+-[DPN-Peer-Group] <Set>
| +-[Remote-DPN-Group-Id] <L-key>
| +-[Interface-Settings] <Set> (O)
+-[Domain-Id-Reference]
Figure 8: DPN Group Any of these configuration steps may also supply updated values for
existing default attribute values that may have been previously
configured on the DPN-resident policy.
Each DPN-Group entry contains the following information: 4.7. Entity Configuration Blocks
DPN-Group (Key): A unique Identifer of the DPN-Group 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.
DPN-Group (Name): the human-readable display string 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.
Referenced-Interfaces: A set of interfaces and the DPNs / associated [Entity Configuration Block]
DPN-Peer-Groups that support them. Each entry contains | +-[Entity-Key] (M)
| +-[Attribute-Expression] <Set> (M)
Interface-Id: a key that is used together with the 2-tuple Figure 7: Entity Configuration Block
Access-Technology and Role, to create a 3-tuple key that is
referred to be the interface definition of virtual DPNs
Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing This document makes use of the following kinds of Entity
the interfaces specified below. Configuration Blocks:
Access-technology: the technology used in the access network Domain-Policy-Configuration
that originated the signaling (WiMAX, 3GPP, 802.x etc.)
Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing DPN-Policy-Configuration
the interfaces specified below.
Supporting-DPN-Id (Set): A set of DPN-Id-References that support Descriptor-Configuration
the specific interface for this DPN-Group.
Interface-Settings: an optional set of settings that MUST be Action-Configuration
known when determining the suitability of an interface for the
specific request.F
DPN-Peer-Group: A set of Remote (from the DPN-Group's point of view) MN-Policy-Configuration
DPN-Groups. When communication occurs between the DPN-Group and
DPN-Peer-Group the Interface-Settings MUST be used. Each entry
contains the following information: entry contains
Remote-DPN-Group-Id: A unique Identifier of the DPN-Peer-Group Flow-Policy-Configuration
Interface-Settings: an optional set of settings that MUST be 4.8. Infomation Model Checkpoint
known when determining the suitability of an interface for the
specific request.
4.3.4. Domain 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. If a new 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.
A Domain represents a logica abstraction of a group of heterogeneous Checkpoints are defined for the following information model
Topology resources. Other models, outside of the scope of this components:
specificaiton, provide the details for the Domain.
| Service-Group
+-[Domain] <Set>
| +-[Domain-Id] <G-Key>, <Name> (O)
+-[Domain-Reference]
Figure 9: Domainn DPN Information Model
Each Domain entry contains the following information: Topology Information Model
Domain (Key): A unique Identifier of the Domain Policy Information Model
Domain (Name): the human-readable display string 4.9. Information Model Components
Domain-Reference: A link to the underlying resource / informaiton 4.9.1. Service-Group
that provides further details regarding the domain.
4.4. Policy A Service-Group is collection of DPN interfaces serving some data-
plane purpose. 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 the Group.
The Policy substructure defines and identifies grouped Rules for |
enforcement on the data plane. Rules comprise traffic descriptors +-[Service-Group] <G-Key>, <Name> (O) <Set>
and actions on how to treat traffic in case the traffic descriptor | +-[Extensible: FALSE]
matches a data packet. The Policy substructure is independent of a | +-[DPN-Key]
policy context, whether it's an administratively configurable policy | +-[Role] <U-Key>
which applies to all or a defined aggregate of data flows, or a | +-[Referenced-Interface] <Set>
mobility context-related policy, which is associated with a mobility | | +-[Interface-Key] <L-Key>
session and may apply only to data traffic of an associated mobile | | +-[Peer-Service-Group-Key] <Set> (O)
node while being registered.
In addition to the Policy substructure, the Core Structure per Figure 8: Service Group
Section 4.2 holds accordingly separate entries for the Configurable-
Policy as well as for Mobility-Context, which do not only define
their own policies by embedded rules, but comprise references to
policy definitions in the Policy substructure, to which additional
settings can be applies on a per-Configurable-Policy basis and on a
per-Mobility-Context bases respectively.
Traffic descriptions and traffic treatment actions are defined Each Service-Group contains the following information:
separately in Descriptor-Definition and Action-Definition
respectively. Binding between traffic descriptors and associated
traffic treatment action is defined in a set of rule definition
entries (Rule-Definition) which comprise references to entries in the
set of traffic descriptors (Descriptor-Reference) and traffic
treatment actions (Action-Reference). Accordingly, a single rule or
a group of rules are bound to a policy in the set of policy
definitions (Policy-Definition) by reference to entries in the set of
rule definitions (Rule-Id).
| Service-Group (Key): A unique ID of the Service-Group
+-[Policy]
| +-[Policy-Definition] <Set>
| | +-[Policy-Id] <G-Key> (M)
| | +-[Rule-Reference] Set (M)
| | +-[Precedence] <L-Key> (M)
| | +-[Rule-Id-Reference] (M)
| +-[Rule-Definition] <Set>
| | +-[Rule-Id] <L-Key> (M)
| | +-[Descriptor-Match-Type] (M)
| | +-[Descriptor-Reference] <Set>
| | | +-[Descriptor-Id-Reference]
| | | +-[Direction] (O)
| | +-[Action-Reference] <Set>
| | +-[Action-Id-Reference]
| | +-[Action-Order]
| +-[Descriptor-Definition] <Set>
| | +-[Descriptor -Id] <L-Key> (M)
| | +-[Descriptor-Type]
| | +-[Descriptor-Value]
| +-[Action-Definition] <Set>
| +-[Action-Id] <L-Key> (M)
| +-[Action-Type]
| +-[Action-Value]
|
Figure 10: Policy Substructure Service-Group (Name): a human-readable display string
The Policy Substructure contains the following entries: Role: the role (MAG, LMA, PGW, AMF etc.) of the device hosting the
interfaces of the DPN Group.
Policy-Definition: A set of policy definitions which bind a single Referenced-Interface: <Set> The Interfaces and peer Service-Groups
or multiple rules to a policy. associated with them. Each entry contains
Policy-Id: Identifies a policy definition. Interface-Key: a key that is used together with the Role, to
create a key that is referred to be the interface definition of
DPNs
Rule-Reference: Assigns a set of rule definitions, which are Peer-Service-Group-Key: Enables location of the peer Service
bound to a policy definition, by reference to the associated Group for this Interface.
Rule in the Rule-Definition Substructure.
Precedence: Defines the order with which the rules must be 4.9.2. Service Endpoints
applied.
Rule-Id-Reference: Identifies a rule. Service Endpoint is the collection of all services provided by DPN
interfaces in the network. The interfaces are grouped according to
their Role (e.g. LMA, MAG, PGW, AMF, etc.) Within a group, DPN
interfaces may have additional properties that are more specific, as
determined by a list of features and (optionally) settings relevant
to DPN selection. This information is used when searching for
resources in a network to carry out required operations on data-plane
traffic.
Rule-Definition: A set of rule definitions which bind a single or |
multiple traffic descriptors (by reference to Descriptor- +-[Service-Endpoint] <Set>
Definition) to a single or multiple traffic treatment actions (by | +-[Extensible: FALSE]
reference to Action-Definition). | +-[Role] <U-Key>, <Name> (O)
| +-[Service-Group-Key] <Set>
| +-[Interface] <Set>
| | +-[Interface-Key] <L-Key>, <Name> (O)
| | +-[DPN-Key]
| | +-[Protocol] <Set>
| | +-[Features] <Set> (O)
| | +-[Settings] <Set> (O)
Rule-Id: Identifies a rule definition. Figure 9: DPN Type
Descriptor-Match-Type: Conjuction of Descriptor-Values to apply Each Service-Endpoint entry contains the following information:
as match to DPN traffic, which can be either OR or AND. The
identified conjunction applies to all Descriptor-Definitions in
the given Rule-Definition.
Descriptor-Reference: Assigns a set of descriptors to the rule Service-Group-Key: Keys enabling reference to the Service-Groups
by reference to the associated Descriptor-Definition. that are to be supported by this Service-Endpoint.
Descriptor-Id-Reference: Identifies the referred Descriptor- Interface: A set of interfaces possible for the group defined by
Definition the Role. Each interface carries the following information:
Direction: Indicates if a rule applies to uplink traffic, to Interface-Key: a key that is used to locate the interface
downlink traffic, or to both, uplink- and downlink traffic. definition.
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 direction is implied by the
Descriptor's values.
Action-Reference: Assigns a set of actions to the rule by Role: the roles (MAG, LMA, PGW, AMF, etc.) of the interface.
reference to the associated Action-Definition.
Action-Id-Reference: Identifies the referred Action-Definition. DPN-Key: The DPN key of the associated interface.
Action-Order: Defines the order how actions are executed in case Protocol: set of protocols supported by this interface (e.g.,
the rule applies per match of the associated traffic PMIP, S5-GTP, S5-PMIP etc.).
descriptor.
Descriptor-Definition: A set of descriptor definitions, each being Features (optional): a set of static features which further
identified by a key (Descriptor-Id) determine the suitability of the interface to the desired
operation for which selection is underway.
Descriptor-Id: Identifies a descriptor definition. Settings (optional): configurable settings that further
determine the suitability of an interface for the specific
request. For example: SequenceNumber=ON/OFF.
Descriptor-Type: Identifies the type of descriptor, e.g. an IPv6 The Role uniquely identifies the kind of interfaces that may be
traffic selector per [RFC 6088], for unambiguous 2 available for DPNs of the specific type.
interpretation of a Descriptor-Value.
Descriptor-Value: Defines all required attribute-value pairs per 4.9.3. Topology Information Model
the traffic descriptor type identified in Descriptor-Type.
Action-Definition: A set of action definitions. 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.
Action-Id: Identifies an action definition. The Topology structure is illustrated in Figure 10 (for definitions
see Section 2):
Action-Type: Identifies the type of an action for unambiguous |
interpretation of an Action-Value entry. +-[Topology Information Model]
| +-[Extensible: FALSE]
| +-[DPN] <Set>
| +-[Domain] <Set>
Action-Value: Defines all required attribute-value pairs per the Figure 10: Topology Structure
action type identified in Action-Type.
4.5. Configurable Policy 4.9.4. Domain Information Model
| A Domain represents a group of heterogeneous Topology resources
+-[Configurable-Policy] <Set> typically sharing a common administrative authority. Other models,
| +-[DPN-Id-Reference] <U-Key> outside of the scope of this specification, provide the details for
| +-[Installed-Policy] <List> the Domain.
| | +-[Installed-Policy-Id] <G-Key>
| | +-[Policy-Id-Reference]
| | +-[Policy-Settings] <Set> (O)
| +-[Settings] <Set> (O)
|
Figure 11: Configurable Policy |
+-[Domain] <G-Key>, <Name> (O) <Set>
| +-[Domain-Policy-Configuration] (O) <Set>
|
The Configurable-Policy Substructure contains the following entries: Figure 11: Domain Information Model
DPN-Id-Reference: Refers to the DPN to which the policy applies. Each Domain entry contains the following information:
Installed-Policy: A list of policies that apply to an identified Domain (Key): Identifies and enables reference to the Domain
DPN.
Installed-Policy-Id: Holds the identifier of the DPN at which Domain (Name): A human-readable display string naming the Domain
the policy has been installed.
Policy-Id-Reference: Assigns a policy by reference to the 4.9.5. DPN Information Model
associated Policy-Definition.
Policy-Settings: Settings that apply to the previously A DPN-Set contains some or all of the DPNs in the tenant's network.
referenced policy to complement rules or make them concrete, Some of the DPNs in the Set may be identical in functionality and
e.g. in case the descriptor representing a packet match has not only differ by their Key.
or unambiguously been defined in the poliicy sub-structure.
Settings: Settings that apply to multiple policies at the |
identified DPN. +-[DPN] <G-Key>, <Name> (O) <Set>
| +-[Extensible: FALSE]
| +-[Interface] <L-Key> <Set>
| | +-[Role] <U-Key>
| | +-[Protocol] <Set>
| | +-[Settings] (O)
| +-[Domain-Key]
| +-[Service-Group-Key] <Set> (O)
| +-[DPN-Policy-Configuration] <List> (M)
| +-[DPN-Resource-Mapping-Reference] (O)
4.6. Mobility-Context Figure 12: DPN Information Model
The Mobility-Context Substructure holds entries associated with a Each DPN entry contains the following information:
mobile node's mobility sessions. At least one instance is created at
the mobile node's registration to serve as parent context.
Additional instances holding child context with reference to parent
context can be created. Child context holds, for example,
descriptors of mobile node data traffic which needs to be treated
different from traffic that matches descriptor of the parent context,
e.g. in terms of QoS. Child context can inherit some attributes/
values from parent context, such as traffic encapsulation and
forwarding information, but can hold different or additional
attributes/values that apply to traffic that matches the descriptor
of the child context.
Termination a parent context implies termination of all dependent DPN-Key: A unique Identifier of the DPN
child context, e.g. at deregistration of a mobile node.
| DPN-Name: A human-readable display string
+-[Mobility-Context] <Set>
| +-[Mobility-Context-Id] <G-Key>
| +-[DPN-Group-Id-Reference] (O)
| +-[Parent-Mobility-Context-Id-Reference] (O)
| +-[DPN-References] <List>
| | +-[DPN-Id-Reference]
| | +-[Direction] (O)
| | +-[DPN-Settings-Complementary]
| | +-[Interface-Id-Reference]
| | +-[Embedded-Rule] <Set> (O)
| | +-[Assigned-Policy-Reference] <Set> (O)
| +-[Requested-Policy-Reference] <Set> (O)
| +-[Context-Settings-Complementary] <Set> (O)
Figure 12: Mobility Context Domain-Key: A Key providing access to the Domain information about
the Domain in which the DPN resides.
The Mobility-Context Substructure holds the following entries: 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 informaiton:
Mobility-Context-Id: Identifies a Mobility-Context Role: the role (MAG, LMA, PGW, AMF, etc.) of the DPN.
DPN-Group-Id-Reference: Assigns a DPN-Group, which groups DPN that Settings (optional): configurable settings that further
are used during the DPN selection procedure, by reference. determine the suitability of an interface for the specific
request. For example: SequenceNumber=ON/OFF.
Parent-Mobility-Context-Id-Reference: Assigns a parent Mobility- Service-Group-Set: The Service-Group-Set references all of the
Context to aquire settings as required. 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-References: Holds a list of DPNs with the associated concrete DPN-Policy-Configuration: A list of Policies that have been
policies that apply to the DPN. An entry MUST have at least one configured on this DPN. Some may have values for all attributes,
value present in its Assigned-Policy-Refence or Embedded-Rule sets and some may require further configuration. Each Policy-
in order to be valid. 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-Id-Reference: Assigns a DPN, to which the policy applies, by DPN-Resident-Policy.Policy-Configuration: A Policy Key providing
reference. access to Template from which the DPN-Resident-Policy was
instantiated, as well as an Attribute-Expression for this
instantiation from the Policy-Template, which supplies default
values and statically configured values for the Attributes,
according to the syntax specified in Section 4.2.
Direction: Indicates if a rule applies to uplink or downlink DPN-Resource-Mapping-Reference (O): A reference to the underlying
traffic, or to both, uplink- and downlink traffic. Applying a implementation, e.g. physical node, software module, etc. that
rule to both, uplink- and downlink traffic, in case of supports this DPN. This value MUST be non-empty prior to Dynamic-
symmetric rules, allows omitting a separate entry for each Policies being installed upon the DPN. Further specification of
direction. When not present the value is assumed to apply to this attribute is out of scope for this document.
both directions.
DPN-Settings-Complementary: Complementary seeings that apply to 4.9.6. Policy Information Model
the DPN for the given Mobility-Context.
Interface-Id-Reference: Assigns the selected interface of the The Policy Information Model defines and identifies Rules for
DPN my reference. 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, whether it's an administratively configurable policy
which applies to all data flows, or a defined aggregate of flows, or
to a mobility context-related policy, which is associated with a
mobility session and may apply only to data traffic of an associated
mobile node when that node is being registered.
Embedded-Rule: Rule that applies to the DPN for this Mobility- In addition to the Policy structure, the Information Model (per
Context. This rule is embedded and not refereced in the Policy Section 4.9.7) defines Mobility-Context. Each Mobility-Context may
substructure. be configured with appropriate Attribute values, for example
depending on the identity of a mobile node.
Assigned-Policy-Reference: A set of references to the list of Traffic descriptions are defined in Descriptors, and treatments are
Requested-Policy-References per this Mobility-Context. 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).
Requested-Policy-Reference: Assigns a list of policies in Policy- |
Definitions that can apply to any DPN per this Mobility-Context. +-[Policy Information Model]
DPN-Reference entries can select from this list of policy | +-[Extensible:]
references to apply to the associated DPN. | +-[Policy-Template] <G-Key> (M) <Set>
| | +-[Policy-Status]
| | +-[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)
| +-[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)
Context-Settings-Complementary: Complementary settings that apply Figure 13: Policy Information Model
to the referenced policies per this Mobility-Context.
The Rules Template format is aligned with the Rule Substructure. It The Policy structure defines Policy-Set, Rule-Set, Descriptor-Set,
can represent an Embedded-Rule per the Mobility-Context Substructure. and Action-Set, as follows:
| Policy-Template: <Set> A set of Policy structures, indexed by
+-[Embedded-Rule] <List> Policy-Key, each of which is determined by a list of Rules
| +-[Rule-Id] (M) referenced by their Rule-Key. Each Policy structure contains the
| +-[Precedence] <L-Key> following:
| +-[Descriptor-Match-Type] (M)
| +-[Descriptor-Definition] <Set>
| | +-[Descriptor-Id] <L-Key> (M)
| | +-[Descriptor-Type]
| | +-[Descriptor-Value]
| +-[Action-Definition] <Set>
| +-[Action-Order] <L-Key> (M)
| +-[Action-Id] (O)
| +-[Action-Type]
| +-[Action-Value]
Figure 13: Rule Template Policy-Key: Identifies and enables reference to this Policy
definition.
The Embedded-Rule template holds the following entries: Policy-Status: Either Initial, PartiallyConfigured, Configured,
or Active. Default value is Initial.
Rule-Id: Identifies a rule definition. It is provided for Rule-Template-Key: Enables reference to a Rule template
convenience. definition.
Precedence: Defines the order with which the rules must be applied Rule-Precedence: For each Rule identified by a Rule-Template-Key
and is used as the 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 Resource Management
Function. If this value is absent, the rules SHOULD be applied
in the order in which they appear in the Policy.
Descriptor-Match-Type: Conjuction of Descriptor-Values to apply as Rule-Template-Set: A set of Rule template definitions indexed by
match to DPN traffic, which can be either OR or AND. The Rule-Key. Each Rule is defined by a list of Descriptors (located
identified conjunction applies to all Descriptor-Definitions in by Descriptor-Key) and a list of Actions (located by Action-Key)
the given Rule-Definition as follows:
Descriptor-Definition: A set of descriptor definitions, each being Rule-Template-Key: Identifies and enables reference to this Rule
identified by a key (Descriptor-Id) definition.
Descriptor-Id: Identifies a Descriptor-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-Type: Identifies the type of descriptor, e.g. an IPv6 Descriptor-Configuration: References a Descriptor template
traffic selector per [RFC 6088], for unambiguous 2 definition, along with an expression which names the Attributes
interpretation of a Descriptor-Value 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.
Descriptor-Value: Defines all required attribute-value pairs per Direction: Indicates if a rule applies to uplink traffic, to
the traffic descriptor type identified in Descriptor-Type. 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-Definition: A set of action definitions. Action-Configuration: References an Action template definition,
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 how actions are executed in case Action-Order: Defines the order in which actions are executed
the rule applies per match of the associated traffic when the associated traffic descriptor selects the packet.
descriptor.
Action-Id: Identifies an action definition. Descriptor-Template-Set: A set of traffic Descriptors, 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 actions 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 Action-Type: Identifies the type of an action for unambiguous
interpretation of an Action-Value entry. interpretation of an Action-Value entry.
Action-Value: Defines all required attribute-value pairs per the 4.9.7. Mobility-Context Information Model
action type identified in Action-Type.
4.7. Monitors 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.
Monitors provide a mechanism to produce reports when events occur. A Termination of a Mobility-Context implies termination of all flows
Monitor will have a target that specifies what is to be watched. represented in the Mobility-Context, e.g. after deregistration of a
mobile node. If any Child-Contexts are defined, they are also
terminated.
When a Monitor is specified, the configuration MUST be applicable to +-[Mobility-Context] <G-Key> <Set>
the attribute/entity monitored. For example, a Monitor using a | +-[Extensible ~ FALSE]
Threshold configuration cannot be applied to a Context, because | +-[Delegating-IP-Prefix:] <Set>
Contexts do not have thresholds. But such a monitor could be applied | +-[Parent-Context]
to a numeric threshold property of a Context. | +-[Child-Context] <Set>
| +-[Mobile-Node]
| | +-[IP-Address] <Set>
| | +-[MN-Policy-Configuration] <Set>
| +-[Domain-Key]
| | +-[Domain-Policy-Configuration] <Set>
| +-[DPN-Key] <Set>
| | +-[Role]
| | +-[DPN-Policy-Configuration] <Set>
| | +-[ServiceDataFlow]
| | | +-[Service-Group-Key]
| | | +-[Interface-Key] <Set>
| | | +-[Flow-Policy-Configuration] <Set>
| | | | +-[Direction]
| Figure 14: Mobility-Context Information Model
+-[Monitor] <List>
| +-[Monitor-Id] <U-Key>
| +-[Target]
| +-[Binding-Information] (O)
| +-[Deterrable] (O)
| +-[Configuration]
Figure 14: Monitor Substructure The Mobility-Context Substructure holds the following entries:
Monitor-Id: Name of the Monitor. The Id format MUST conform to Mobility-Context-Key: Identifies a Mobility-Context
Section 4.8.
Target: Description of what is to be monitored. This can be an Extensible: Determines whether or not entities instantiated from
Event, a Dynamic Policy, an installed DPN Policy, or values of a this Template can be extended with new non-mandatory Attributes
Dynamic-Policy attribute. When the type is an attribute of not defined here. Default value is FALSE.
Mobility-Context, the target name is a concatenation of the
Context-Id and the relative path (separated by '/') to the
attribute(s) to be monitored. Target must provide unambiguously
identify the monitored attribute and the location (DPN).
Binding-Information: Complements (ambigous) Target information to Parent-Context: If present, a Mobility Context from which the
define the Monitor in an unambigous way. Attributes and Attribute Values of this Mobility Context are
inherited.
Deterrable: Indicates that a monitoring report can be delayed in a Child-Context: A set of Mobility Contexts which inherit the
defined delay budget for possible bundling with other reports Attributes and Attribute Values of this Mobility Context.
Configuration: Determined by the Monitor subtype. The recipient of Mobile-Node: Attributes specific to the Mobile Node.
a notification as monitor report is specified in the
Configuration. Four reporting types are defined:
* Periodic reporting specifies an interval by which a Domain-Key: Enables access to a Domain instance.
notification is sent.
* Event reporting specifies a list of event types that, if they Domain-Policy-Configuration: For each Domain-Policy in the set, a
occur and are related to the monitored attribute, will result key and relevant information for the Policy Attributes.
in sending a notification.
* Scheduled reporting specifies the time (in seconds since Jan 1, DPN-Key: Enables access to a DPN instance.
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 Role: Role this DPN fulfills in the Mobility-Context.
threshold. When these values are crossed a corresponding
notification is sent.
4.8. Namespace and Format DPN-Policy-Configuration: For each DPN-Policy in the set, a key and
relevant information for the Policy Attributes.
The identifiers and names in FPC models which reside in the same ServiceDataFlow: Characterizes a traffic flow that has been
namespace must be unique. That uniqueness must be kept in agent or configured (and provided resources) on the DPN to support data-
data-plane tenant namespace on an Agent. The tenant namespace plane traffic to and from the mobile device.
uniqueness MUST be applied to all elements of the tenant model, i.e.
Topology, Policy and Mobility models.
When a Policy needs to be applied to Contexts in all tenants on an Service-Group-Key: Enables access to a Service-Group instance.
Agent, the Agent SHOULD define that policy to be visible from all the
tenants. In this case, the Agent assigns an unique identifier in the
agent namespace and effectively creates a U-Key although only a G-Key
is required.
The format of identifiers can utilize any format with agreement Interface-Key: Assigns the selected interface of the DPN.
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 types of format that dictate the Flow-Policy-Configuration: For each Flow-Policy in the set, a
choice of FPC protocol. However the choice of identifiers which are key and relevant information for the Policy Attributes.
used in Mobility model need to be considered to handle runtime
parameters in real-time.
4.9. Attribute Application Direction: Indicates if a rule 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.
When search for attributes in Settings to apply for Embeded Rules or 4.9.8. Monitor Information Model
Assigned-Policy-References the following search order is applied by
the Agent / DPN for Mobilty-Contexts:
1. DPN-Settings-Complementary of the DPN-Reference entry Monitors provide a mechanism to produce reports when events occur. A
Monitor will have a target that specifies what is to be watched.
2. Context-Settings-Complementary of the Mobility-Context 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.
3. If Parent-Mobility-Context-Id-Reference is not empty the |
following are also searched: +-[Monitor] <List>
| +-[Extensible:]
| +-[Monitor-Key:] <U-Key>
| +-[Target:]
| +-[Deferrable]
| +-[Configuration]
1. DPN-Settings-Complementary of the DPN-Reference entry for the Figure 15: Monitor Substructure
same interface, if present.
2. Context-Settings-Complementary of this parent Mobility- Monitor-Key: Name of the Monitor. The format MUST conform to
Context Section 4.5.
3. Optionally, if this Mobility-Context has a non-empty Parent- Target: Description of what is to be monitored. This can be a
Mobility-Context-Id-Reference this step MAY be repeated but Service Data Flow, a Policy installed upon a DPN, values of a
it is NOT reccommended as it could slow system performance. Mobility-Context, etc. The target name is the absolute
information model path (separated by '/') to the attribute /
entity to be monitored.
4. Interface-Settings of the DPN interface Deferrable: Indicates that a monitoring report can be delayed up to
a defined maximum delay for possible bundling with other reports.
Only looking at settings of the first Parent-Mobility-Context-Id- Configuration: Determined by the Monitor subtype. The monitor
Reference is recommended for performance reasons. If further depth report is specified by the Configuration. Four report types are
of search is supported the Agent MUST make this known to the Client. defined:
For Configurable Policy the following search order is applied: * "Periodic" reporting specifies an interval by which a
notification is sent.
1. Policy-Settings of the Installed-Policy * "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.
2. Settings of the Configurable-Policy * "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.
5. Protocol * "Threshold" reporting specifies one or both of a low and high
threshold. When these values are crossed a corresponding
notification is sent.
NOTE - The terms Context and Mobility-Context are used 5. Protocol
interchangeable throughout the rest of this document.
5.1. Protocol Messages and Semantics 5.1. Protocol Messages and Semantics
Five message types are supported: Four Client to Agent messages are supported.
+---------------+----------------+----------------------------------+ +---------------------+---------------------------------------------+
| Message | Type | Description | | Message | Description |
+---------------+----------------+----------------------------------+ +---------------------+---------------------------------------------+
| CONF | HEADER OP_TYPE | Configure processes a single | | Configure | A Configure message includes multiple edits |
| | BODY | operation. | | | to one or more information model entities. |
| | | | | | Edits are executed according to their Edit- |
| CONF_BUNDLE | HEADER OP_TYPE | A Conf-bundle takes multiple | | | Id in ascending order. The global status |
| | REF_SCOPE | operations that are to be | | | of the operation and the status of |
| | TRANS_STRATEGY | executed as a group with partial | | | individual edits are returned. Partial |
| | 1*[OP_ID BODY] | failures allowed. They are | | | failures, i.e. individual edit failures, |
| | | executed according to the OP_ID | | | are allowed. |
| | | value coupled with the BODY in | | Register-Monitors | Register monitors at an Agent. The message |
| | | ascending order. If a | | | includes the Monitor information as |
| | | CONF_BUNDLE fails, any entities | | | specified in Section 4.9.8. |
| | | provisioned in the CURRENT | | Deregister-Monitors | Deregister monitors from an Agent. An |
| | | operation are removed. However, | | | optional boolean, Send-Data, indicates if a |
| | | any successful operations | | | successful deregistration triggers a Notify |
| | | completed prior to the current | | | with final data from the Agent for the |
| | | operation are preserved in order | | | corresponding Monitor. |
| | | to reduce system load. | | Probe | Probe the status of registered monitors. |
| | | | | | This triggers a Notify with current data |
| REG_MONITOR | HEADER *[ | Register a monitor at an Agent. | | | from the Agent for the corresponding |
| | MONITOR ] | The message includes information | | | Monitors. |
| | | about the attribute to monitor | +---------------------+---------------------------------------------+
| | | and the reporting method. Note |
| | | that a MONITOR_CONFIG is |
| | | required for this operation. |
| | | |
| DEREG_MONITOR | HEADER 1*[ | Deregister monitors from an |
| | MONITOR_ID ] [ | Agent. Monitor IDs are provided. |
| | SEND_DATA ] | SEND_DATA is an optional boolen |
| | | that indicates if a successful |
| | | DEREG triggers a NOTIFY with |
| | | final data. |
| | | |
| PROBE | HEADER | Probe the status of a registered |
| | MONITOR_ID | monitor. |
+---------------+----------------+----------------------------------+
Table 1: Client to Agent Messages Table 1: Client to Agent Messages
Each message contains a header with the Client Identifier, an Each message contains a header with the following information:
execution delay timer and an operation identifier. The delay, in ms,
is processed as the delay for operation execution from the time the
operation is received by the Agent.
The Client Identifier is used by the Agent to associate specific Client Identifier: An Identifier used by the Agent to associate
configuration characteristics, e.g. options used by the Client when specific configuration characteristics, e.g. options used by the
communicating with the Agent, as well as the association of the Client when communicating with the Agent, the association of the
Client and tenant in the information model. Client and tenant in the information model as well as tracking
operations and notifications.
CONF_BUNDLE also has the Transaction Strategy (TRANS_STRATEGY) Delay: An optional time (in ms) to delay the execution of the
attribute. This value specifies the behavior of the Agent when an operation on the DPN once it is received by the Agent.
operation fails while processing a CONF_BUNDLE message. The value of
'default' uses the default strategy defined for the message. The
value 'all_or_nothing' will roll back all successfully executed
operations within the bundle as well as the operation that failed.
An FPC interface protocol used to support this specification may not Operation Identifier: A unique identifier created by the Client to
need to support CONF_BUNDLE messages or specific TRANS_STRATEGY types correlate responses and notifications
beyond 'default' when the protocol provides similar semantics.
However, this MUST be clearly defined in the specification that
defines the interface protocol.
An Agent will respond with an ERROR, OK, or an OK WITH INDICATION An Agent will respond with an ERROR, indicating one or more Errors
that remaining data will be sent via a notify from the Agent to the have occured, or an OK.
Client Section 5.1.1.4.2 for CONFIG and CONF_BUNDLE requests. When
returning an 'ok' of any kind, optional data MAY be present.
Two Agent notifications are supported: For Configure messages, an OK status for an edit MAY include
subsquent edits in the response that were required to properly
execute the edit. It MAY also indicate that the final status and any
final edits required to fulfill the request will be sent via a
Configure result notification from the Agent to the Client, see
Section 5.1.1.4.2.
+----------------------+----------+---------------------------------+ If errors occur, they MUST be returned as a list in responses and
| Message | Type | Description | each Error contains the following information:
+----------------------+----------+---------------------------------+
| CONFIG_RESULT_NOTIFY | See | An asynchronous notification |
| | Table 13 | from Agent to Client based upon |
| | | a previous CONFIG or |
| | | CONF_BUNDLE request. |
| | | |
| NOTIFY | See | An asynchronous notification |
| | Table 14 | from Agent to Client based upon |
| | | a registered MONITOR. |
+----------------------+----------+---------------------------------+
Table 2: Agent to Client Messages (notifications) Error-type: The specific error type. Values are TRANSPORT (0), RPC
(1), PROTOCOL(2) or APPLICATION (3).
The HEADER is a part of all messages and is comprised of the Error-Tag: An error tag.
following information:
CLT_ID: The Client Identifier Error-App-Tag: Application specific error tag.
DELAY (OPTIONAL): The time (in ms) to delay the execution of ther Error-Message: A message describing the error.
operaiton on the DPN once it is received by the Agent.
OP_ID: Operation Identifier Error-Info: Any data required for the response.
Results will be supplied per operation input. Each result contains
the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS
values are:
OK - Success |
+-[Errors] <List>
| +-[(Enumeration) Error-Type ]
| +-[(String) Error-Tag ]
| +-[(String) Error-App-Tag ] (O)
| +-[(String) Error-Message ] (O)
| +-[Error-Info] (O)
ERR - An Error has occurred Figure 16: Error Information Model
If an error occurs, information MUST be returned in the response. Two Agent to Client notifications are supported.
Error informaiton is comprised of the following:
ERROR_TYPE_ID (Unsigned 32, REQUIRED) - The identifier of a +-------------------------------+-----------------------------------+
specific error type The values are TRANSPORT (0), RPC (1), | Message | Description |
PROTOCOL(2) or APPLICATION (3). +-------------------------------+-----------------------------------+
| Configure-Result-Notification | An asynchronous notification from |
| | Agent to Client based upon a |
| | previous Configure request. |
| Notify | An asynchronous notification from |
| | Agent to Client based upon a |
| | registered Monitor's |
| | configuration, a Monitor |
| | deregistration or Probe. |
+-------------------------------+-----------------------------------+
ERROR_TAG - (String, REQUIRED) - enumerated error tag. Table 2: Agent to Client Messages (notifications)
ERROR_APP_TAG - (String, OPTIONAL) - Application specific error 5.1.1. Configure Message
tag.
ERROR_MESSAGE - (String, OPTIONAL) - A message describing the The Configure message follows edit formats proposed by [RFC8072] with
error. more fields in each edit, an extra operation (clone) and a different
response format.
ERROR_INFO - (Any Data, OPTIONAL) - Any data required for the 5.1.1.1. Edit Operation Types
response.
5.1.1. CONFIG and CONF_BUNDLE Messages +-----------+-------------------------------------------------------+
| Operation | Description |
+-----------+-------------------------------------------------------+
| create | Creates a new data resource or Entity. If the |
| | resource exists an error is returned. |
| delete | Deletes a resource. If it does not exist an error is |
| | returned. |
| insert | Inserts data in a list or user ordered list. |
| merge | Merges the edit value with the target data resource; |
| | the resource is created if it does not exist. |
| move | Moves the target data resource. |
| replace | Replace the target data resource with the edit value. |
| remove | Removes a data resource if it already exists. |
| clone | Clones a data resource and places the copy at the new |
| | location. If the resource does not exist an error is |
| | returned. |
+-----------+-------------------------------------------------------+
CONFIG and CONF_BUNDLE include OP_TYPE as part of the header Table 3: Configure Edit Operations
information:
OP_TYPE: specifies the type of operation. Valid values are 'create' 5.1.1.2. Edit Operation
(0), 'update' (1), 'query' (2) or 'delete' (3).
The BODY is comprised of the following information: Each Configure includes one or more edits. These edits include the
following information:
COMMAND_SET: Specifies the Command Set (see Section 5.1.1.2). Edit-Id: uniquely specifies the identifier of the edit within the
operation.
REF_SCOPE: If supported, specifies the Reference Scope (see Edit-Type: specifies the type of operation (see Section 5.1.1.1).
Command-Set: The Command-Set is a technology-specific bitset that
allows for a single entity to be sent in an edit with multiple
requested, technology specific sub-transactions to be completed.
It can also provide clarity for a request. For example, a
Mobility-Context could have the Home Network Prefix absent but it
is unclear if the Client would like the address to be assigned by
the Agent or if this is an error. Rather than creating a
specific command for assigning the IP a bit position in a
Command-Set can be used to indicate Agent based IP assignment
requests.
Reference-Scope: If supported, specifies the Reference Scope (see
Section 5.1.1.3) Section 5.1.1.3)
BODY INTERNALS: A list of entities under Policy, e.g. Policy- Target: Specifies the Target node (Data node path or FPC Identity)
Definitions, Action-Definitions, etc. as well as Installed for the edit operation. This MAY be a resource, e.g. Mobility-
Policies and Contexts when the OP_TYPE is 'create' or 'update'. Context, Descriptor-Template, etc., or a data node within a
Otherwise it is a list of Targets for 'query' or 'deletion'. See resource as specified by its path.
Section 6.1.3.2 for details.
CONF_BUNDLES includes an OP_ID with each body for tracking of the Point: The absolute URL path for the data node that is being used as
bundle's subtransactions. the insertion point, clone point or move point for the target of
this 'edit' entry.
5.1.1.1. Agent Operation Processing Where: Identifies where a data resource will be inserted, cloned to
or moved. Only allowed these for lists and lists of data nodes
that are 'ordered-by user'. The values are 'before', 'after',
'first', 'last' (default value).
The Agent will process entities provided in an operation in the Value The value used for this edit operation.
following order:
1. Action-Definitions |
+-[Configure]
| +-[Client-Id:]
| +-[(Unsigned 32) Execution-Delay]
| +-[Operation-Id:]
| +-[Edits:] <List>
| | +-[Edit-Id:] <L-Key>
| | +-[(Enumeration) Edit-Type:]
| | +-[(BitSet) Command-Set]
| | +-[(Enumeration) Reference-Scope]
| | +-[Target:]
| | +-[Point]
| | +-[(Enumeration) Where]
| | +-[Value]
2. Descriptor Defintions Figure 17: Configure Request
3. Rule Definitions Edits sent to the Agent provided in an operation SHOULD be sent in
the following order to avoid errors:
4. Policy Definitions 1. Action Templates
5. Installed Policies 2. Descriptor Templates
6. Mobility Contexts according to COMMAND_SET 3. Rule Templates
5.1.1.2. Command Bitsets 4. Policy Templates
The COMMAND_SET is a technology specific bitset that allows for a 5. DPN Templates
single entity to be sent in an operation with multiple requested sub- 6. Mobility Contexts
transactions to be completed. It can also provide clarity for a
request. For example, a Mobility-Context could have the Home Network
Prefix absent but it is unclear if the Client would like the address
to be assigned by the Agent or if this is an error. Rather than
creating a specific command for assigning the IP a bit position in a
COMMAND_SET is reserved for Agent based IP assignment.
5.1.1.3. Reference Scope 5.1.1.3. Reference Scope
The Reference Scope is an optional feature that provides the scope of The Reference Scope is an optional feature that provides the scope of
references used in a configuration command, i.e. CONFIG or references used in a configuration command. These scopes are defined
CONF_BUNDLE. These scopes are defined as as:
o none - All entities have no references to other entities. o none - All entities have no references to other entities.
o op - All references are contained in the operation body, i.e. only o edit - All references are contained in the edit body, i.e. only
intra-operation references exist. intra-operation references exist.
o bundle - All references exist in bundle (inter-operation/intra- o operation - All references exist in the operation (inter-edit/
bundle). NOTE - If this value is present in a CONFIG message it intra-operation).
is equivalent to 'op'.
o storage - One or more references exist outside of the operation o storage - One or more references exist outside of the operation.
and bundle. A lookup to cache / storage is required. A lookup to cache / storage is required.
o unknown - the location of the references are unknown. This is o unknown - the location of the references are unknown. This is
treated as a 'storage' type. treated as a 'storage' type.
An agent that only accepts 'op' or 'bundle' reference scope messages An Agent that only accepts 'edit' or 'operation' reference scope
is referred to as 'stateless' as it has no direct memory of messages is referred to as 'stateless' as it has no direct memory of
references outside messages themselves. This permits low memory references outside messages themselves. This permits low memory
footprint Agents. Even when an Agent supports all message types an footprint Agents/DPNs. Even when an Agent supports all message types
'op' or 'bundle' scoped message can be processed quickly by the Agent an 'edit' or 'operation' scoped message can be processed quickly by
as it does not require storage access. the Agent/DPN as it does not require storage access.
Figure 18 shows an example containment hierarchy provided for all
caches.
+---------------+
| Global Cache |
| (storage) |
+------+--------+
|
+----------------+
| |
+------+-----------+ +------+-----------+
| Operation Cache | | Operation Cache |
| (operation) | .... | (operation) |
+------+-----------+ +--------+---------+
| |
+---+-----------+ |
| | |
+------+------+ +------+------+ +------+------+
| Edit Cache | | Edit Cache | | Edit Cache |
| (edit) | | (edit) | | (edit) |
+-------------+ +-------------+ +-------------+
(no cache)
Figure 18: Exemple Hierarchical Cache
5.1.1.4. Operation Response 5.1.1.4. Operation Response
5.1.1.4.1. Immediate Response 5.1.1.4.1. Immediate Response
For CONF and CONF_BUNDLE the Response MAY include the the following: The Response MUST include the following:
NOTIFY_FOLLOWS - A boolean indicator that the Operation has been Operation Identifier of the corresponding request.
accepted by the Agent but further processing is required. A
CONFIG_RESULT_NOTIFY will be sent once the processing has
succeeded or failed.
ENTITIES - Optionally, entities created or partially fulfilled as Global Status for the operation (see Table 1).
part of the operation as specified in Table 12 For Clients that
need attributes back quickly for call processing, the AGENT MUST A list of Edit results (described below).
respond back with an OK_NOTIFY_FOLLOWS and minimally the
attributes assigned by the Agent in the response. These An edit response, Edit-Status, is comprised of the following:
situations MUST be determined through the use of Command Sets (see
Section 5.1.1.2). Edit-Id: Edit Indentifier.
Edit-Status: OK.
When the Edit-Status is OK the following values MAY be present
Notify-Follows - A boolean indicator that the edit has been
accepted by the Agent but further processing is required. A
Configure-Result-Notification will be sent once the processing
has succeeded or failed.
Subsequent-Edits: This is a list of Edits that were required to
fulfill the request. It follows the edit request semantics
(see Section 5.1.1.2).
Errors: When the Edit-Status is ERROR the following values are
present. See Table 1 for details.
The response will minimally contain an Edit-Status implying 'OK' or a
list of errors.
|
+-[Operation-Id:]
+-[Result-Status:]
+-[Errors] <List>
| +-[(Enumeration) Error-Type:]
| +-[(String) Error-Tag:]
| +-[(String) Error-App-Tag]
| +-[(String) Error-Message]
| +-[Error-Info]
+-[Edit-Status]
| +-[Edit-Id:]
| +-[Edit-Status: ~ OK]
| +-[Notify-Follows]
| +-[Subsequent-Edits] <List>
| | +-[Edit-Id:] <L-Key>
| | +-[(Enumeration) Edit-Type:]
| | +-[Target:]
| | +-[Point]
| | +-[(Enumeration) Where]
| | +-[Value]
| +-[Errors] <List>
| | +-[(Enumeration) Error-Type:]
| | +-[(String) Error-Tag:]
| | +-[(String) Error-App-Tag]
| | +-[(String) Error-Message]
| | +-[Error-Info]
|
Figure 19: Configure Operation Response
5.1.1.4.2. Asynchronous Notification 5.1.1.4.2. Asynchronous Notification
A CONFIG_RESULT_NOTIFY occurs after the Agent has completed A Configure-Result-Notification occurs after the Agent has completed
processing related to a CONFIG or CONF_BUNDLE request. It is an processing related to a Configure request. It is an asynchronous
asynchronous communication from the Agent to the Client. communication from the Agent to the Client.
The values of the CONFIG_RESULT_NOTIFY are detailed in Table 13. It is identical to the immediate response with the exception that the
Notify-Follows, if present, MUST be false. As this value is
unnecessary it SHOULD be ommitted.
5.1.2. Monitors 5.1.1.5. Reserved Identities
Several identities are reserved in the Policy Information Model and
Mobility-Context to faciliate specfic uses cases.
Agents and tenants express their support for descriptors and actions
using the following Key patterns
supported-<descriptor template name> indicates a support for the
descriptor template as defined in its original specification. For
example "base-rfc5777classifier" is a Descriptor Template that
conforms to the rfc5777-classifier (Figure 28) as defined in this
document.
supported-<action template name> indicates a support for the
action template as defined in its original specification.
"base-rule" is comprised of all base descriptors using an 'or'
Descriptor-Match-Type and all Actions in no specific order.
"base-template" is comprised of the base rule.
"base-template" can be used to determine supported Action and
Descriptor Templates. It can also be used to support an open
template where any specific Descriptors and Actions can be applied,
however, depending upon the Order of Actions it is likely to produce
undesirable results.
One use case is supported via reservation of specific DPN-Keys:
Requested policies are those that the Client would like to be
assigned to a DPN. The naming convention is similar to those used
for DPN Assignment via an Agent.
"Requested" is a Key that represents requested policies which
have not been assigned to a specific DPN. No Role is assigned
to the DPN.
"Requested-<Role>" represents requested policies that have not
been assigned to a DPN and can only be assigned to DPNs that
fulfill the specified Role.
It is possible to have policies in the "Requested" DPN that do not
appear in other entries which reflects the inability to
successfully assign the policy.
5.1.2. Monitor Messages
An Agent may reject a registration if it or the DPN has insufficient An Agent may reject a registration if it or the DPN has insufficient
resources. resources.
An Agent or DPN may temporarily suspend monitoring if insufficient An Agent or DPN MAY temporarily suspend monitoring if insufficient
resources exist. In such a case the Agent MUST notify the Client. resources exist. In such a case the Agent MUST notify the Client.
When a monitor has a reporting configuration of SCHEDULED it is When a monitor has a reporting configuration of SCHEDULED it is
automatically de-registered after the last NOTIFY occurs. automatically de-registered after the last Notify occurs.
If a SCHEDULED or PERIODIC configuration is provided during If a SCHEDULED or PERIODIC configuration is provided during
registration with the time related value (time or period registration with the time related value (time or period
respectively) of 0 a NOTIFY is sent and the monitor is immediately respectively) of 0 a Notify is sent and the monitor is immediately
de-registered. This method should, when a MONITOR has not been de-registered. This method should, when a Monitor has not been
installed, result in an immediate NOTIFY sufficient for the Client's installed, result in an immediate Notify sufficient for the Client's
needs and lets the Agent realize the Client has no further need for needs and lets the Agent realize the Client has no further need for
the monitor to be registered. the monitor to be registered.
PROBE messages are also used by a Client to retrieve information Probe messages are used by a Client to retrieve information about a
about a previously installed monitor. The PROBE message SHOULD previously installed monitor. The Probe message SHOULD identify one
identify one or more monitors by means of including the associated or more monitors by means of including the associated monitor
monitor identifier. An Agent receiving a PROBE message sends the identifier. An Agent receiving a Probe message sends the requested
requested information in a single or multiple NOTIFY messages. information in a single or multiple Notify messages.
If the Monitor configuration associated with a NOTIFY is deterrable If the Monitor configuration associated with a Notify can be
then the NOTIFY MAY be bundled with other messages back to the Agent deferred, then the Notify MAY be bundled with other messages back to
even if this results in a delay of the NOTIFY. the Agent even if this results in a delay of the Notify.
The Monitor messages use the following data:
Monitor-Key: Monitor Key.
Monitor: A Monitor configuration (see Section 4.9.8).
Send-Data: An indicator that specifies that the final value MUST be
sent as a notification from the Agent.
|
+-[Register-Monitors]
| +-[Client-Id:]
| +-[(Unsigned 32) Execution-Delay]
| +-[Operation-Id:]
| +-[Monitors] <List>
| | +-[Extensible:]
| | +-[Monitor-Key:] <U-Key>
| | +-[Target:]
| | +-[Binding-Information]
| | +-[Deferrable]
| | +-[Configuration:]
|
+-[Deregister-Monitors]
| +-[Client-Id:]
| +-[(Unsigned 32) Execution-Delay]
| +-[Operation-Id:]
| +-[Monitors:] <List>
| | +-[Monitor-Key:] <U-Key>
| | +-[(Boolean) Send-Data ~ False]
|
+-[Deregister-Monitors]
| +-[Client-Id:]
| +-[(Unsigned 32) Execution-Delay]
| +-[Operation-Id:]
| +-[Monitor-Key:] <List>
Figure 20: Monitor Messages
5.1.2.1. Asynchronous Notification 5.1.2.1. Asynchronous Notification
A NOTIFY can be sent as part of de-registraiton, a trigger based upon A Monitor Report can be sent as part of de-registration, a trigger
a Monitor Configuration or a PROBE. A NOTIFY is comprised of unique based upon a Monitor Configuration or a Probe. A Report is comprised
Notification Identifier from the Agent, the Monitor ID the of the Monitor Key the report applies to, the Trigger for the report,
notification applies to, the Trigger for the notification, a a timestamp of when the report's' associated event occurs and data
timestamp of when the notification's associated event occurs and data
that is specific to the monitored value's type. that is specific to the monitored value's type.
Triggers include but are not limited to
o Subscribed Event occurred
o Low Threshold Crossed
o High Threshold Crossed
o Periodic Report
o Scheduled Report
o Probe
o Deregistration Final Value
o Monitoring Suspended
o Monitoring Resumed
o DPN Availabile
o DPN Unavailable
Multiple Reports are sent in a Notify message. Each Notify is
comprised of unique Notification Identifier from the Agent and
timestamp indicating when the notification was created.
|
+-[ Notify ]
| +-[(Unsigned 32) Notification-Identifier:]
| +-[Timestamp:]
| +-[Report:] <List>
| | +-[Trigger:]
| | +-[Monitor-Key:]
| | +-[Value]
Figure 21: Monitor Messages
5.2. Protocol Operation 5.2. Protocol Operation
Please note that JSON is used to represent the information in Figures
in this section but any over the wire representation that accurately
reflects the information model MAY be used.
5.2.1. Simple RPC Operation 5.2.1. Simple RPC Operation
An FPC Client and Agent MUST identify themselves using the CLI_ID and An FPC Client and Agent MUST identify themselves using the Client
AGT_ID respectively to ensure that for all transactions a recipient Identifier and Agent Identifier respectively to ensure that for all
of an FPC message can unambiguously identify the sender of the FPC transactions a recipient of an FPC message can unambiguously identify
message. A Client MAY direct the Agent to enforce a rule in a the sender of the FPC message.
particular DPN by including a DPN_ID value in a Context. Otherwise
the Agent selects a suitable DPN to enforce a Context and notifies A Client MAY direct the Agent to enforce a rule in a particular DPN
the Client about the selected DPN using the DPN_ID. by including a DPN Key value in a Mobility Context. Otherwise the
Agent selects a suitable DPN to enforce one or more portions of a
Mobility Context and notifies the Client about the selected DPN(s)
using the DPN Identifier(s).
All messages sent from a Client to an Agent MUST be acknowledged by All messages sent from a Client to an Agent MUST be acknowledged by
the Agent. The response must include all entities as well as status the Agent. The response must include all edit status as well as
information, which indicates the result of processing the message, subsequent edits, which indicates the result of processing the
using the RESPONSE_BODY property. In case the processing of the message, as part of the Configure response. In case the processing
message results in a failure, the Agent sets the ERROR_TYPE and of the message results in a failure, the Agent sets the global status
ERROR_TAG accordingly and MAY clear the entity, e.g. Context or Error-Type and Error-Tag accordingly and MAY clear the entity, e.g.
Configurable-Policy, which caused the failure, in the response. Context or Configurable-Policy, which caused the failure, in the
response.
If based upon Agent configuration or the processing of the request If based upon Agent configuration or the processing of the request
possibly taking a significant amount of time the Agent MAY respond possibly taking a significant amount of time the Agent MAY respond
with a NOTIFY_FOLLOWS indicaiton with an optional RESPONSE_BODY with a Notify-Follows indication with optional Subsequent-Edit(s)
containing the partially completed entities. When a NOTIFY_FOLLOWS containing the partially completed entity modifications. When a
indication is indicated, the Agent will, upon completion or failure Notify-Follows indication is indicated, the Agent will, upon
of the operation, respond with an asynchronous CONFIG_RESULT_NOTIFY completion or failure of the operation, respond with an asynchronous
to the Client. Configuration-Result-Notification to the Client.
A Client MAY add a property to a Context without providing all A Client MAY add a property to a Mobilty-Context without providing
required details of the attribute's value. In such case the Agent all required details of the attribute's value. In such case the
SHOULD determine the missing details and provide the completed Agent SHOULD determine the missing details and provide the completed
property description back to the Client. If the processing will take property description, via Subsequent-Edit(s) back to the Client. If
too long or based upon Agent configuration, the Agent MAY respond the processing will take too long or based upon Agent configuration,
with an OK that indicates a NOTIFY_FOLLOWS and also includes a the Agent MAY respond with an OK for the Edit that indicates a
RESPONSE_BODY containing the partially completed entities. Notify-Follows and also includes Subsequent-Edit(s) containing the
partially completed entity edits.
In case the Agent cannot determine the missing value of an In case the Agent cannot determine the missing value of an
attribute's value per the Client's request, it leaves the attribute's attribute's value per the Client's request, it leaves the attribute's
value cleared in the RESPONSE_BODY and sets the RESULT to Error, value cleared ]and sets the Edit Result to Error and provides an
ERROR_TYPE and ERROR_TAG. As example, the Control-Plane needs to Error-Type and Error-Tag. As example, the Control-Plane needs to
setup a tunnel configuration in the Data-Plane but has to rely on the setup a tunnel configuration in the Data-Plane but has to rely on the
Agent to determine the tunnel endpoint which is associated with the Agent to determine the tunnel endpoint which is associated with the
DPN that supports the Context. The Client adds the tunnel property DPN that supports the Mobility-Context. The Client adds the tunnel
attribute to the FPC message and clears the value of the attribute property attribute to the FPC message and clears the value of the
(e.g. IP address of the local tunnel endpoint). The Agent attribute (e.g. IP address of the local tunnel endpoint). The Agent
determines the tunnel endpoint and includes the completed tunnel determines the tunnel endpoint and includes the completed tunnel
property in its response to the Client. property in its response to the Client in a Subsequent-Edit entry.
Figure 15 illustrates an exemplary session life-cycle based on Proxy Figure 22 illustrates an exemplary session life-cycle based on Proxy
Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1) Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1)
and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1 and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1
represents the Proxy CoA after attachment, whereas Edge DPN2 serves represents the Proxy CoA after attachment, whereas Edge DPN2 serves
as Proxy CoA after handover. As exemplary architecture, the FPC as Proxy CoA after handover. As exemplary architecture, the FPC
Agent and the network control function are assumed to be co-located Agent and the network control function are assumed to be co-located
with the Anchor-DPN, e.g. a Router. with the Anchor-DPN, e.g. a Router.
The Target of the second request uses the Mobility-Context by name.
Alternatively, the Target could have included the DPN-Key and Policy-
Key to further reduce the amount of information exchnanged. Setting
the Target's value to the most specific node SHOULD be followed
whenever practicle.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(CREATE)--->| | | | |---(1)--Configure-------->| |
| | | [ MOBILTY_CONTEXT_ID, |--tun1 up->| | | "configure" : { | |
| | | DPNREFLIST:[[DPN1, BOTH | | | | "client-id" : 0, | |
| | | DPN_SETTINGS_COMPL:[ | | | | "operation-id" : 0, | |
| | | DOWNLINK(QOS/TUN), | | | | "edit" : [ | |
| | | UPLINK(QOS/TUN)] ]] |--tc qos-->| | | "edit-id" : 0, | |
| | | CTXT_SETTINGS_COMPL:[ | | | | "edit-type" : "create", | |
| | | IP_PREFIX(HNP) ] ] | | | | "target" : "/mobility-context", |
| | |<---(2)- OK --------------|-route add>| | | "value" : { |
| | "mobility-context-key" : "ctxt1", |
| | "delegating-ip-prefix" : [ <HNP> ], |
| | "dpn" : "[ { |
| | "dpn-key" : "DPN1", |
| | "service-data-flow" : [
| | "identifier" : 0,
| | "flow-settings" : [
| | ...
| | {"policy-key" : "dl-tunnel-with-qos",
| | "qos-template" : <QOS Settings...>,
| | ...
| | "tunnel" : <DL tunnel info...> },
| | {"policy-key" : "ul-tunnel",
| | ...
| | "tunnel" : <UL tunnel info...> } ]
| | ] } ] } ] } | |
| | | |--tun1 up->|
| | | | |
| | | |--tc qos-->|
| | | | |
| | |<---(2)- Response --------|-route add>|
| | | { | |
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 0, | |
| | | "result-status" : "ok", | |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | | | | | | | | |
|<------------PBA------| | | |<------------PBA------| | |
| | | | | | | | | |
| +----+ | | | | | +----+ | | | |
| |Edge| | | | | | |Edge| | | | |
| |DPN1| | | | | | |DPN1| | | | |
| +----+ | | | | | +----+ | | | |
| | | | | |
| |-=======================================================-| | |-=======================================================-|
| | | | | | | |
| [MN handover] | | | | [MN handover] | | |
| |---PBU ---->| | | | |---PBU ---->| | |
| | |--(3)- CONFIG(MODIFY)---->| | | | |--(3)- CONFIG(MODIFY)---->| |
| |<--PBA------| [ MOBILTY_CONTEXT_ID |-tun1 mod->| | | "configure" : { |-tun1 mod->|
| | | DPNREFLIST:[[DPN1, BOTH | | | | "client-id" : 0, | |
| | | DPN_SETTINGS_COMPL:[ | | | | "operation-id" : 1, | |
| | | DOWNLINK(TUN), | | | | "edit" : [ | |
| | +----+ | UPLINK(TUN)] ]] ] | | | | "edit-id" : 0, | |
| | |Edge| |<---(4)- OK --------------| | | | "edit-type" : "merge", | |
| | "target" : "/mobility-context/ctxt1", |
| | "value" : { | |
| | "dpn-set" : "[ { |
| | "dpn-key" : "DPN1", |
| | "service-data-flow" : [
| | "identifier" : 0,
| | "flow-settings" : [
| | ...
| | {"policy-key" : "dl-tunnel-with-qos",
| | "tunnel" : <NEW tunnel info...> } ]
| | } ] } ] } | |
| |<--PBA------| | |
| | | |-tun1 mod->|
| | |<---(4)- OK --------------| |
| | | { | |
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 1, | |
| | | "result-status" : "ok", | |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | +----+ | | |
| | |Edge| | | |
| | |DPN2| | | | | | |DPN2| | | |
| | +----+ | | | | | +----+ | | |
| | | | | | | | | | | |
| | |-============================================-| | | |-============================================-|
| | | | | | | | | |
Figure 15: Exemplary Message Sequence (focus on FPC reference point) Figure 22: Example Message Sequence (focus on FPC reference point)
After reception of the Proxy Binding Update (PBU) at the LMA Control- After reception of the Proxy Binding Update (PBU) at the LMA Control-
Plane function (LMA-C), the LMA-C selects a suitable DPN, which Plane function (LMA-C), the LMA-C selects a suitable DPN, which
serves as Data-Plane anchor to the mobile node's (MN) traffic. The serves as Data-Plane anchor to the mobile node's (MN) traffic. The
LMA-C adds a new logical Context to the DPN to treat the MN's traffic LMA-C adds a new logical Context to the DPN to treat the MN's traffic
(1) and includes a Context Identifier (CONTEXT_ID) to the CONFIG (1) and includes a Context Identifier (ctxt1) in the Configure
command. The LMA-C identifies the selected Anchor DPN by including command. The LMA-C identifies the selected Anchor DPN by including
the associated DPN identifier and the Direction the entry applies to, the associated DPN identifier.
BOTH.
The LMA-C adds properties during the creation of the new Context. The LMA-C adds policy template properties during the creation of the
One property is added to the DPN Settings Complimentary, to specify new Mobility-Context. One policy, "dl-tunnel-with-qos", is an
the forwarding tunnel type and endpoints (Anchor DPN, Edge DPN1) in example template that permits tunnel forwarding of traffic destined
each direction (as required). Another property is added to specify to the MN's HNP, i.e. downlink traffic, with optional QoS parameters.
the QoS differentiation, which the MN's traffic should experience. Another policy, "ul-tunnel", provides a simple uplink anchor
At reception of the Context, the FPC Agent utilizes local termination template where the uplink tunnel information is provided.
The downlink tunnel information specifies the destination endpoint
(Edge DPN1).
At reception of the Mobility-Context, the FPC Agent utilizes local
configuration commands to create the tunnel (tun1) as well as the configuration commands to create the tunnel (tun1) as well as the
traffic control (tc) to enable QoS differentiation. After traffic control (tc) to enable QoS differentiation. After
configuration has been completed, the Agent applies a new route to configuration has been completed, the Agent applies a new route to
forward all traffic destined to the MN's HNP specified as a property forward all traffic destined to the MN's HNP specified as a property
in the Context's Complementary Settings and applied the configured in the Mobility-Context and applied the configured tunnel interface
tunnel interface (tun1). (tun1).
During handover, the LMA-C receives an updating PBU from the handover During handover, the LMA-C receives an updating PBU from the handover
target MAG-C2. The PBU refers to a new Data-Plane node (Edge DPN2) target MAG-C2. The PBU refers to a new Data-Plane node (Edge DPN2)
to represent the new tunnel endpoints in the downlink and uplink, as to represent the new tunnel endpoint in the downlink as required.
required. The LMA-C sends a CONFIG message (3) to the Agent to The LMA-C sends a Configure message (3) to the Agent to modify the
modify the existing tunnel property of the existing Context and to existing tunnel property of the existing Mobility-Context and to
update the tunnel endpoint from Edge DPN1 to Edge DPN2. Upon update the downlink tunnel endpoint from Edge DPN1 to Edge DPN2.
reception of the CONFIG message, the Agent applies updated tunnel Upon reception of the Configure message, the Agent applies updated
property to the local configuration and responds to the Client (4). tunnel property to the local configuration and responds to the Client
(4).
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(MODIFY)--->| | | | |---(1)--Configure-------->| |
|<------------PBA------| [ CONTEXT_ID, |--tun1 ->| | | "configure" : { | |
| | | DPNREFLIST:[[DPN1, BOTH | | | | "client-identifier" : 0, | |
| | | DPN_SETTINGS_COMPL:[ | | | | "operation-id" : 3, | |
| | | DOWNLINK(TUN delete), | down | | | "edits" : [ | |
| | | UPLINK(TUN delete)] ]] ] | | | | "edit-id" : 0, | |
| | "edit-type" : "merge", | |
| | "target" : "/mobility-context/ctxt1 |
| | /dpn/DPN1/service-data-flow/0 |
| | /flow-settings/dl-tunnel-with-qos |
| | /0" |
| | "value" : { | |
| | "tunnel" : null | |
| | } ] } | |
|<------------PBA------| |--tun1 ->|
| | | | down |
| | | | | | | | | |
| | |<-(2)- OK ----------------| | | | |<---(2)- Response --------| |
| | | { | |
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 3, | |
| | | "result-status" : "ok", | |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | | | | | | | | |
| | [ MinDelayBeforeBCEDelete expires ] | | | | [ MinDelayBeforeBCEDelete expires ] | |
| | | | | | | | | |
| | |---(3)--CONFIG(DELETE)--->|-- tun1 -->| | | |---(3)--Configure-------->|-- tun1 -->|
| | | | delete | | | "configure" : { | delete |
| | |<-(4)- OK ----------------| | | | "client-identifier" : 0, | |
| | "operation-id" : 4, | |
| | "edits" : [ | |
| | "edit-id" : 0, | |
| | "edit-type" : "delete", | |
| | "target" : "/mobility-context/ctxt1" |
| | ] } | |
| | | | |
| | |<---(4)- Response --------| |
| | | { | |
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 4, | |
| | | "result-status" : "ok", | |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | | |-- route ->| | | | |-- route ->|
| | | | remove | | | | | remove |
| | | | | | | | | |
Figure 16: Exemplary Message Sequence (focus on FPC reference point) Figure 23: Exemplary Message Sequence (focus on FPC reference point)
When a teardown of the session occurs, MAG-C1 will send a PBU with a When a teardown of the session occurs, MAG-C1 will send a PBU with a
lifetime value of zero. The LMA-C sends a CONFIG message (1) to the lifetime value of zero. The LMA-C sends a Configure message (1) to
Agent to modify the existing tunnel property of the existing Context the Agent to modify the existing tunnel property of the existing
to delete the tunnel information.) Upon reception of the CONFIG Mobility-Context to delete the tunnel information. Upon reception of
message, the Agent removes the tunnel configuration and responds to the Configure message, the Agent removes the tunnel configuration and
the Client (2). Per [RFC5213], the PBA is sent back immediately responds to the Client (2). Per [RFC5213], the PBA is sent back
after the PBA is received. immediately after the PBA is received.
If no valid PBA is received after the expiration of the If no valid PBA is received after the expiration of the
MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a
CONFIG (3) message with a deletion request for the Context. Upon Configure (3) message with a deletion request for the Context. Upon
reception of the message, the Agent deletes the tunnel and route on reception of the message, the Agent deletes the tunnel and route on
the DPN and responds to the Client (4). the DPN and responds to the Client (4).
When a multi-DPN Agent is used the DPN list permits several DPNs to When a multi-DPN Agent is used the DPN list permits several DPNs to
be provisioned in a single message for the single Conext. be provisioned in a single message for the single Mobility-Conext.
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN1 | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN1 |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(CREATE)--->| | | | |---(1)--Configure-------->| |
| | | [ MOBILTY_CONTEXT_ID, |--tun1 up->| | | "configure" : { |--tun1 up->|
| | | DPNREFLIST:[[DPN1, BOTH | | | | "client-identifier" : 0, | |
| | | DPN_SETTINGS_COMPL:[ | | | | "operation-id" : 0, | |
| | | DOWNLINK(QOS/TUN), | | | | "edit" : [ |--tc qos-->|
| | | UPLINK(QOS/TUN) ] ], |--tc qos-->| | | "edit-id" : 0, | |
| | | [DPN2, BOTH | | | | "edit-type" : "create", | |
| | | DPN_SETTINGS_COMPL:[ | | | | "target" : "mobility-context", |
| | | DOWNLINK(QOS/TUN), | | | | "value" : { |
| | | UPLINK(QOS/TUN) ] ] ], | | | | "mobility-context-key" : "ctxt1", |
| | | CTXT_SETTINGS_COMPL [ | | | | "delegating-ip-prefix" : [ <HNP> ], |
| | | IP_PREFIX(HNP) ] ] | | | | "dpn" : "[ { |
| | |<-(2)- OK_NOTIFY_FOLLOWS -|-route add>| | | "dpn-key" : "DPN1", |
| | "service-data-flow" : [
| | "identifier" : 0,
| | "flow-settings" : [
| | ...
| | {"policy-key" : "dl-tunnel-with-qos",
| | "qos-template" : <QOS Settings...>,
| | ...
| | "tunnel" : <DL tunnel info...> },
| | {"policy-key" : "ul-tunnel",
| | ...
| | "tunnel" : <UL tunnel info...> } ]
| | "dpn-key" : "DPN2", |
| | "service-data-flow" : [
| | "identifier" : 0,
| | "flow-settings" : [
| | ...
| | {"policy-key" : "dl-tunnel-with-qos",
| | "qos-template" : <QOS Settings...>,
| | ...
| | "tunnel" : <DL tunnel info...> },
| | {"policy-key" : "ul-tunnel",
| | ...
| | "tunnel" : <UL tunnel info...> } ]
| | } ] } ] } | |
| | | | |
| | |<---(2)- Response --------| |
| | | { |-route add>|
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 3, | |
| | | "result-status" : "ok", | |
| | | "notify-follows" : "true", |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | | | | | | | | |
|<------------PBA------| | | |<------------PBA------| | |
| | | | | | | | | |
| +----+ | | | | +----+ | | |
| |Edge| | | | | |Edge| | | |
| |DPN2| | | | | |DPN2| | | |
| +----+ | | | | +----+ | | |
| |<---------------------- tun1 up -------------| | | |<---------------------- tun1 up -------------| |
| |<---------------------- tc qos --------------| | | |<---------------------- tc qos --------------| |
| |<---------------------- route add -----------| | | |<---------------------- route add -----------| |
| | | | | | | | | |
| | |<(3) CONFIG_RESULT_NOTIFY | | | | |<(3) Configure-Result- | |
| | | [ Response Data ] | | | | | Notification | |
| | | { |-route add>|
| | | "agent-id" : "agent1"," | |
| | | "operation-id" : 3, | |
| | | "result-status" : "ok", | |
| | | "notify-follows" : "true", |
| | | "edit-status" : [ | |
| | | "edit-id" : 0, | |
| | | "edit-status" : "ok" | |
| | | ] } | |
| | | | |
| | | | | | | | | |
Figure 17: Exemplary Message Sequence for Multi-DPN Agent Figure 24: Exemplary Message Sequence for Multi-DPN Agent
Figure 17 shows how the first 2 messages in Figure 15 are supported Figure 24 shows how the first 2 messages in Figure 22 are supported
when a multi-DPN Agent communicates with both Anchor DPN1 and Edge when a multi-DPN Agent communicates with both Anchor DPN1 and Edge
DPN2. In such a case, the FPC Client sends the downlink and uplink DPN2. In such a case, the FPC Client sends the downlink and uplink
for both DPNs in the DPN Reference List of the same Context. Message for both DPNs in the DPN Reference List of the same Mobility-Context.
1 shows the DPN Reference List with all entries. Each entry Message 1 shows the DPN Set with all entries. Each entry identifies
identifies the DPN and direction (one of 'uplink', 'downlink' or the DPN.
'both').
The Agent responds with an OK and NOTIFY_FOLLOWS indication while it The Agent responds with an OK and Notify-Follows indication while it
simultaneoulsy provisions both DPNs. Upon successful completion, the simultaneoulsy provisions both DPNs. Upon successful completion, the
Agent responds to the Client with a CONFIG_RESULT_NOTIFY indicating Agent responds to the Client with a Configuration-Result-Notification
the operation status. indicating the operation status.
5.2.2. Policy And Mobility on the Agent 5.2.2. Policy And Mobility on the Agent
A Client may build Policy and Topology using any mechanism on the A Client may build Policy and Topology using Configure messages.
Agent. Such entities are not always required to be constructed in
realtime and, therefore, there are no specific messages defined for
them in this specification.
The Client may add, modify or delete many Installed Policies and The Client may add, modify or delete many DPN Policies as DPN Policy
Contexts in a single FPC message. This includes linking Contexts to Expressions and Mobility-Contexts in a single FPC message. This
Actions and Descriptors, i.e. a Rule. As example, a Rule which includes linking Mobility-Contexts to DPN Policies as well as
performs re-writing of an arriving packet's destination IP address creating the Policy, Rules Actions and Descriptors. As example, a
from IP_A to IP_B matching an associated Descriptor, can be enforced Rule which performs re-writing of an arriving packet's destination IP
in the Data-Plane via an Agent to implicitly consider matching address from IP_A to IP_B matching an associated Descriptor, can be
arriving packet's source IP address against IP_B and re- write the enforced in the Data-Plane via an Agent to implicitly consider
source IP address to IP_A. matching arriving packet's source IP address against IP_B and re-
write the source IP address to IP_A.
Figure 18 illustrates the generic policy configuration model as used Figure 25 illustrates the generic policy configuration model as used
between a FPC Client and a FPC Agent. between a FPC Client and a FPC Agent.
Descriptor_1 -+ +- Action_1 Descriptor_1 -+ +- Action_1
| | | |
Descriptor_2 -+--<Rule>--+- Action_2 Descriptor_2 -+--<Rule>--+- Action_2
+------+ +-----------+
/Order#/-------------+ /Precendent#/--------+
+------+ | +----------+ |
| |
Descriptor_3 -+ +- Action_3 +-<Policy> Descriptor_3 -+ +- Action_3 +-<Policy>
| | | ^ | | | ^
Descriptor_4 -+--<Rule>--+- Action_4 | | Descriptor_4 -+--<Rule>--+- Action_4 | |
+------+ | | +-----------+ | |
/Order#/-------------+ | /Precendent#/--------+ |
+------+ | +----------+ |
<Intsalled-Policy> <DPN-Settings>
+---------------------+ +----------------------+ +---------------------+ +----------------------+
| Bind 1..M traffic | | Bind 1..N traffic | | Bind 1..M traffic | | Bind 1..N traffic |
| Descriptors to | --> | treatment actions | | Descriptors to | --> | treatment actions |
| to a Policy and | | to a Policy and | | to a Policy and | | to a Policy and |
| Configurable-Policy | | Configurable-Policy | | Configurable-Policy | | Configurable-Policy |
+---------------------+ +----------------------+ +---------------------+ +----------------------+
| | | |
+-------------- Data-Plane Rule ------------------+ +-------------- Data-Plane Rule ------------------+
Figure 18: Structure of Configurable Policies Figure 25: Structure of Configurable Policies
As depicted in Figure 18, the Configurable-Policy represents the As depicted in Figure 25, the DPN Settings represents the anchor of
anchor of Rules through the Policy / Rule hierarchy. A Client and Rules through the Policy / Rule hierarchy. A Client and Agent use
Agent use the identifier of the associated Policy to directly access the identifier of the associated Policy to directly access the Rule
the Rule and perform modifications of traffic Descriptors or Action and perform modifications of traffic Descriptors or Action
references. A Client and Agent use the identifiers to access the references. Arriving packets are matched against traffic according
Descriptors or Actions to perform modifications. From the viewpoint to Rule precedence and Descriptors. If a Rule is applicable the
of packet processing, arriving packets are matched against traffic packet is treated according to the ordered Action values.
Descriptors and processed according to the treatment Actions
specified in the list of properties associated with the Configurable-
Policy.
A Client complements a rule's Descriptors with a Rule's Order A Client associates a Precedence value for the Rule's Descriptors, to
(priority) value to allow unambiguous traffic matching on the Data- allow unambiguous traffic matching on the Data-Plane.
Plane.
Figure 19 illustrates the generic context configuration model as used Figure 26 illustrates the generic context configuration model as used
between a FPC Client and a FPC Agent. between a Client and a Agent.
TrafficSelector_1 <Policy 1>
| ^
profile-parameters |
| <Service-Data-Flow 0> <--- <Mobility-Context-ID2>
mobility-profile-- dl ------+ ^
^ | |
| qos-profile <Policy 1> |
<ContextID1> | ^ |
^ per-mn-agg-max-dl_2 | |
| <Service-Data-Flow 0> <--- <Mobility-Context-ID1>
<ContextID2>
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| Bind 1..M traffic | | Bind 1..N traffic | | Bind 1..M traffic | | Bind 1..N traffic |
| selectors to | --> | treatment / qos | | selectors to | --> | treatment / qos |
| a Context | | actions to a | | a Context | | actions to a |
| | | Context | | | | Context |
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| | | |
+-------------- Data-Plane Rule ------------------+ +-------------- Data-Plane Rule ------------------+
Figure 19: Structure of Contexts Figure 26: Mobility Context Heirarchy
As depicted in Figure 19, the Context represents a mobility session The figure Figure 26 represents a mobility session hierarchy. A
hierarchy. A Client and Agent directly assigns values such as Client and Agent directly assigns values such as downlink traffic
downlink traffic descriptors, QoS information, etc. A Client and descriptors, QoS information, etc. A Client and Agent use the
Agent use the context identifiers to access the descriptors, qos context identifiers to access the descriptors, qos information, etc.
information, etc. to perform modifications. From the viewpoint of to perform modifications. From the viewpoint of packet processing,
packet processing, arriving packets are matched against traffic arriving packets are matched against traffic Descriptors and
Descriptors and processed according to the qos or other mobility processed according to the qos or other mobility profile related
profile related Actions specified in the Context's properties. If Actions specified in the Mobilty-Context's and Service-Data-Flow's'
present, the final action is to use a Context's tunnel information to properties. If present, a Policy could contain tunnel information to
encapsulate and forward the packet. encapsulate and forward the packet.
A second Context also references context1 in the figure. Based upon A second Mobility-Context also references Mobility-Context-ID1 in the
the technology a property in a parent context (parent mobility- figure. Based upon the technology a property in a parent context
context-id reference) MAY be inherited by its descendants. This (parent mobility-context-id reference) MAY be inherited by its
permits concise over the wire representation. When a Client deletes descendants. This permits concise over the wire representation.
a parent Context all children are also deleted. When a Client deletes a parent Context all children are also deleted.
5.2.3. Optimization for Current and Subsequent Messages
5.2.3.1. Configuration Bundles
Bundles provide transaction boundaries around work in a single
message. Operations in a bundle MUST be successfully executed in the
order specified. This allows references created in one operation to
be used in a subsequent operation in the bundle.
The example bundle shows in Operation 1 (OP 1) the creation of a
Context 1 which is then referenced in Operation 2 (OP 2) by
CONTEXT_ID 2. If OP 1 fails then OP 2 will not be executed. The
advantage of the CONF_BUNDLE is preservation of dependency orders in
a single message as opposed to sending multiple CONFIG messages and
awaiting results from the Agent.
When a CONF_BUNDLE fails, any entities provisioned in the CURRENT
operation are removed, however, any successful operations completed
prior to the current operation are preserved in order to reduce
system load.
+-------Router--------+
+-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor |
| Client | | Agent | | DPN |
+-----------+ +-------+ +---------+
| | |
|--CONF_BUNDLE(CREATE)---->| |
| [ OP 1, | |
| [ MOBILTY_CONTEXT_ID 1, |--tun1 up->|
| DPNREFLIST:[[DPN1, BOTH | |
| DPN_SETTINGS_COMPL:[ | |
| DOWNLINK(QOS/TUN), | |
| UPLINK(QOS/TUN)] ]] |--tc qos-->|
| CTXT_SETTINGS_COMPL:[ | |
| IP_PREFIX(HNP) ] ] ],| |
| [ OP 2, | |
| [ MOBILTY_CONTEXT_ID, |--tun1 up->|
| DPNREFLIST:[[DPN1, BOTH | |
| DPN_SETTINGS_COMPL:[ | |
| DOWNLINK(QOS/TUN), | |
| UPLINK(QOS/TUN)] ]] |--tc qos-->|
| PARENT_CONTEXT_ID_REF=1 | |
| ] ] | |
| | |
Figure 20: Exemplary Bundle Message (focus on FPC reference point)
5.2.3.2. Command Bitsets (Optional)
Command Sets permit the ability to provide a single, unified data
structure, e.g. Mobility-Context, and specify which activities are
expected to be performed on the DPN. This has some advantages
o Rather than sending N messages with a single operation performed
on the DPN a single message can be used with a Command Set that
specifies the N DPN operations to be executed.
o Errors become more obvious. For example, if the HNP is NOT
provided but the Client did not specify that the HNP should be
assigned by the Agent this error is easily detected. Without the
Command Set the default behavior of the Agent would be to assign
the HNP and then respond back to the Client where the error would
be detected and subsequent messaging would be required to remedy
the error. Such situations can increase the time to error
detection and overall system load without the Command Set present.
o Unambiguous provisioning specification. The Agent is exactly in
sync with the expectations of the Client as opposed to guessing
what DPN work could be done based upon data present at the Agent.
This greatly increases the speed by which the Agent can complete
work.
o Permits different technologies with different instructions to be
supported in FPC.
As Command Bitsets are technology specific, e.g. PMIP or 3GPP
Mobility, the type of work varies on the DPN and the amount of data
present in a Context or Port will vary. Using the technology
specific instructions allows the Client to serve multiple
technologies and MAY result in a more stateless Client as the
instructions are transferred the Agent which will match the desired,
technology specific instructions with the capabilities and over the
wire protocol of the DPN more efficiently.
5.2.3.3. Reference Scope(Optional)
Although entities MAY refer to any other entity of an appropriate
type, e.g. Contexts can refer to Policies or other Contexts, the
Reference Scope gives the Agent an idea of where those references
reside. They may be in the same operation, an operation in the same
CONF_BUNDLE message or in storage. There may also be no references.
This permits the Agent to understand when it can stop searching for
reference it cannot find. For example, if a CONF_BUNDLE message uses
a Reference Scope of type 'op' then it merely needs to keep an
operation level cache and consume no memory or resources searching
across the many operations in the CONF_BUNDLE message or the data
store.
Agents can also be stateless by only supporting the 'none', 'op' and
'bundle' reference scopes. This does not imply they lack storage but
merely the search space they use when looking up references for an
entity. The figure below shows the caching hierarchy provided by the
Reference Scope
Caches are temporarily created at each level and as the scope
includes more caches the amount of entities that are searched
increases. Figure 21 shows an example containment hierarchy provided
for all caches.
+---------------+
| Global Cache |
| (storage) |
+------+--------+
|
+----------------------+
| |
+------+--------+ +------+--------+
| Bundle Cache | | Bundle Cache |
| (bundle) | .... | (bundle) |
+------+--------+ +------+--------+
|
+--------------------+--------------------+
| | |
+--------+---------+ +--------+---------+ +--------+---------+
| Operation Cache | | Operation Cache | | Operation Cache |
| (op) | | (op) | | (op) |
+------------------+ +------------------+ +------------------+
(no cache)
Figure 21: Exemplary Hierarchical Cache
5.2.3.4. Basename Registry Feature (Optional)
The Optional BaseName Registry support feature is provided to permit
Clients and tenants with common scopes, referred to in this
specification as BaseNames, to track the state of provisioned policy
information on an Agent. The registry records the BaseName and
Checkpoint set by a Client. If a new Client attaches to the Agent it
can query the Registry to determine the amount of work that must be
executed to configure the Agent to a BaseName / checkpoint revision.
A State value is also provided in the registry to help Clients
coordinate work on common BaseNames.
6. Protocol Message Details
6.1. Data Structures And Type Assignment
This section provides a type mapping for FPC structures. When being
mapped to a specific information such as YANG the data type MAY
change.
6.1.1. Policy Structures
+------------+------------------+-----------------------------------+
| Structure | Field | Type |
+------------+------------------+-----------------------------------+
| ACTION | ACTION_ID | FPC-Identity (Section 4.8) |
| | | |
| ACTION | ACTION_TYPE | [32, unsigned integer] |
| | | |
| ACTION | ACTION_VALUE | Type specific |
| | | |
| DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 4.8) |
| | | |
| DESCRIPTOR | DESCRIPTOR_TYPE | [32, unsigned integer] |
| | | |
| DESCRIPTOR | DESCRIPTOR_VALUE | Type specific |
| | | |
| POLICY | POLICY_ID | FPC-Identity (Section 4.8) |
| | | |
| POLICY | RULES | *[ PRECEDENCE RULE_ID ] |
| | | PRECENDENCE is [32, unsigned |
| | | integer]. For Rule see Table 4 |
+------------+------------------+-----------------------------------+
Table 3: Action Fields
Policies contain a list of Rules by their order value. Each Rule
contains Descriptors with optional directionality and Actions with
order values that specifies action execution ordering if the Rule has
multiple actions.
Rules consist of the following fields.
+------------------+-------------------+----------------------------+
| Field | Type | Sub-Fields |
+------------------+-------------------+----------------------------+
| RULE_ID | FPC-Identity | |
| | (Section 4.8) | |
| | | |
| MATCH_TYPE | ENUMERATION [2, | |
| | unsigned bits] | |
| | ('AND' or 'OR') | |
| | | |
| RULE_DESCRIPTORS | *[ DESCRIPTOR_ID | DIRECTION [2, unsigned |
| | DIRECTION ] | bits] is an ENUMERATION |
| | | (uplink, downlink or |
| | | both). |
| | | |
| RULE_ACTIONS | *[ ACTION_ID | ACTION-ORDER [8, unsigned |
| | ACTION_ORDER ] | integer] specifies action |
| | | execution order. |
+------------------+-------------------+----------------------------+
Table 4: Rule Fields
6.1.2. Mobility Structures
+---------------------------------+---------------------------------+
| Field | Type |
+---------------------------------+---------------------------------+
| DPN_ID | FPC-Identity (Section 4.8) |
| | |
| 1*[ INSTALLED_POLICY_ID | |
| POLICY_ID_REFERENCE | |
| POLICY_SETTINGS ] | |
| DPN_POLICY_SETTINGS | |
| | |
| INSTALLED_POLICY_ID | FPC-Identity (Section 4.8) |
| | |
| POLICY_ID_REFERENCE | POLICY_ID |
| | |
| POLICY_SETTINGS | A collection of policy specific |
| | setings (properties) |
| | |
| DPN_POLICY_SETTINGS | A collection of setings |
| | (properties) that affect |
| | multiple installed policies. |
+---------------------------------+---------------------------------+
Table 5: Configurable-Policy Fields
+-------------------------------------+-----------------------------+
| Field | Type |
+-------------------------------------+-----------------------------+
| MOBILITY_CONTEXT_ID | FPC-Identity (Section 4.8) |
| | |
| DPN_GROUP_ID_REFERENCE | FPC-Identity (Section 4.8) |
| | |
| PARENT_MOBILITY_CONTEXT_ID_REFERNCE | FPC-Identity (Section 4.8) |
| | |
| DPNS [NOTE 2] | *[ DPN_REFERENCE ] |
| | |
| REQUEST_POLICY_REFERENCES | * [ POLICY_ID ] |
| | |
| CONTEXT_SETTINGS_COMPLEMENTARY | A Collection of Settings |
| | (properties). |
+-------------------------------------+-----------------------------+
Table 6: Mobility Context Fields
+----------------------------+--------------------------------------+
| Field | Type |
+----------------------------+--------------------------------------+
| DPN_ID | FPC-Identity (Section 4.8) |
| | |
| DIRECTION | See Table 4 |
| | |
| INTERFACE_ID_REF | FPC-Identity (Section 4.8) |
| | |
| EMBEDDED_RULES | *[ EMBEDDED_RULE ] |
| | |
| DPN_SETTINGS_COMPLEMENTARY | A Collection of Settings |
| | (properties). |
| | |
| ASSIGNED_POLICY_REFERENCES | * [ POLICY_ID ] |
+----------------------------+--------------------------------------+
Table 7: DPN_REFERENCE Fields
+---------------------------+---------------------------------------+
| Field | Type |
+---------------------------+---------------------------------------+
| RULE_ID | FPC-Identity (Section 4.8) |
| | |
| MATCH_TYPE | See Table 4 |
| | |
| PRECEDENCE | See Table 3 |
| | |
| ACTION_DEFINITION_SET | *[ ACTION_ORDER ACTION_ID ACTION_TYPE |
| | ACTION_VALUE ] |
| | |
| DESCRIPTOR_DEFINITION_SET | *[ DESCRIPTOR_ID DESCRIPTOR_TYPE |
| | DESCRIPTOR_VALUE ] |
+---------------------------+---------------------------------------+
Table 8: EMBEDDED_RULE Fields
6.1.2.1. Monitors
+---------------------+-------------------------+-------------------+
| Field | Type | Description |
+---------------------+-------------------------+-------------------+
| MONITOR | MONITOR_ID DETERRABLE | |
| | TARGET | |
| | BINDING_INFORMATION | |
| | [REPORT_CONFIG] | |
| | | |
| DETERRABLE | boolean | Deterrability |
| | | indicator. |
| | | |
| BINDING_INFORMATION | String | |
| | | |
| MONITOR_ID | FPC-Identity. See | |
| | Section 4.8 | |
| | | |
| EVENT_TYPE_ID | [8, Event Type ID] | Event Type |
| | | (unsigned |
| | | integer). |
| | | |
| TARGET | OCTET STRING (See | |
| | Section 4.7) | |
| | | |
| REPORT_CONFIG | [8, REPORT-TYPE] | |
| | [TYPE_SPECIFIC_INFO] | |
| | | |
| PERIODIC_CONFIG | [32, period] | report interval |
| | | (ms). |
| | | |
| THRESHOLD_CONFIG | [32, low] [32, hi] | thresholds (at |
| | | least one value |
| | | must be present) |
| | | |
| SCHEDULED_CONFIG | [32, time] | |
| | | |
| EVENTS_CONFIG | *[EVENT_TYPE_ID] | |
+---------------------+-------------------------+-------------------+
Table 9: Monitor Structures and Attributes 6. Templates And Command Sets
TRIGGERS include but are not limited to the following values: Configurations templates are shown below.
o Events specified in the Event List of an EVENTS CONFIG 6.1. Monitor Configuration Templates
o LOW_THRESHOLD_CROSSED A periodic configuration specifies a time interval (ms) for
reporting.
o HIGH_THRESHOLD_CROSSED A scheduled configuration specifies a time for reporting.
o PERIODIC_REPORT
o SCHEDULED_REPORT A threshold configuration MUST have at least one hi or low threshold
and MAY have both.
o PROBED A Target-Events-Configuration is a list of Events that, when
generated by the Target, results in a Monitor notification.
o DEREG_FINAL_VALUE |
+-[Monitor] <List>
...
| +-[Configuration]
| | +-[Periodic-Configuration]
| | | +-[(Unsigned32) Period:]
...
| +-[Configuration]
| | +-[Schedule-Configuration]
| | | +-[(Unsigned32) Schedule:]
...
| +-[Configuration]
| | +-[Threshold-Configuration]
| | | +-[(Unsigned32) Low]
| | | +-[(Unsigned32) Hi]
...
| +-[Configuration]
| | +-[Target-Events-Configuration]
| | | +-[(Unsigned32) Event-Key:] <List>
6.1.3. Message Attributes Figure 27: Monitor Configuration Templates
6.1.3.1. Header 6.2. Descriptor Templates
Each operation contains a header with the following fields: A IP-Prefix-Template MUST have at least the To or From IP Prefix /
Length populated. The IP Prefix specifies and Address and Length.
+--------------+----------------+-----------------------------------+ The PMIP Traffic Selector template is mapped according to [RFC6088]
| Field | Type | Messages |
+--------------+----------------+-----------------------------------+
| CLIENT_ID | FPC-Identity | All |
| | (Section 4.8) | |
| | | |
| DELAY | [32, unsigned | All |
| | integer] | |
| | | |
| OP_ID | [64, unsigned | All |
| | integer] | |
| | | |
| OP_REF_SCOPE | [4, | Values are none(0), op(1), |
| | ENUMERATION] | bundle(2), storage(3) or |
| | | unknown(4) |
+--------------+----------------+-----------------------------------+
Table 10: Message Header Fields The RFC 5777 Classifier is a structured version of common filter
rules and follows the format specified in [RFC5777]. The Flow-Label,
Flow-Label range and ECN-IP-Codepoint specified in [RFC7660] are
added to the Descriptor as well.
6.1.3.2. CONFIG and CONF_BUNDLE Attributes and Notifications |
+--------------------+--------------------+-------------------------+ +-[ip-prefix-template]
| Field | Type | Operation Types | | +-[(IP Prefix / Length) To-IP-Prefix]
| | | Create(C), Update(U), | | +-[(IP Prefix / Length) From-IP-Prefix]
| | | Query(Q) and Delete(D) | ...
+--------------------+--------------------+-------------------------+ +-[pmip-traffic-selector]
| OP_TYPE | [8, op type] | CONFIG and CONF_BUNDLE | | +-[(Enumerated - IPv4 or IPv6) ts-format]
| | | | | +-[ipsec-spi-range]
| COMMAND_SET | FPC Command | C,U | | | +-[ (ipsec-spi) start-spi: ]
| | Bitset. See | | | | +-[ (ipsec-spi) end-spi ]
| | Section 5.1.1.2. | | | +-[source-port-range]
| | | | | | +-[ (port-number) start-port: ]
| INSTALLED_POLICIES | *[ | C,U | | | +-[ (port-number) end-port ]
| | INSTALLED_POLICY ] | | | +-[destination-port-range]
| | | | | | +-[ (port-number) start-port: ]
| MOBILITY-CONTEXTS | *[ MOBILITY- | C,U | | | +-[ (port-number) end-port ]
| | CONTEXT [ | | | +-[source-address-range-v4]
| | COMMAND_SET [NOTE | | | | +-[ (ipv4-address) start-address: ]
| | 1] ] ] | | | | +-[ (ipv4-address) end-address ]
| | | | | +-[destination-address-range-v4]
| TARGETS | FPC-Identity | Q,D | | | +-[ (ipv4-address) start-address: ]
| | (Section 4.8) | | | | +-[ (ipv4-address) end-address ]
| | *[DPN_ID] | | | +-[ds-range]
| | | | | | +-[ (dscp) start-ds: ]
| POLICIES | *[ POLICY ] | C,U | | | +-[ (dscp) end-ds ]
| | | | | +-[protocol-range]
| RULES | *[ RULE ] | C,U | | | +-[ (uint8) start-protocol: ]
| | | | | | +-[ (uint8) end-protocol ]
| DESCRIPTORS | *[ DESCRIPTOR ] | C,U | | +-[source-address-range-v6]
| | | | | | +-[(ipv6-address) start-address: ]
| ACTIONS | *[ ACTION ] | C,U | | | +-[(ipv6-address) end-address ]
+--------------------+--------------------+-------------------------+ | +-[destination-address-range-v6]
| | +-[(ipv6-address) start-address: ]
| | +-[(ipv6-address) end-address ]
| +-[flow-label-range]
| | +-[(ipv6-flow-label) start-flow-label ]
| | +-[(ipv6-flow-label) end-flow-label ]
| +-[traffic-class-range]
| | +-[ (dscp) start-traffic-class ]
| | +-[ (dscp) end-traffic-class ]
| +-[next-header-range]
| | +-[ (uint8) start-next-header ]
| | +-[ (uint8) end-next-header ]
...
+-[rfc5777-classifier]
| +-[Extensible: True]
| +-[(uint8) protocol]
| +-[(Enumerated - In/Out/Both) Direction]
| +-[From-Spec] <List>
| | +-[(ip-address) IP-Address] <List>
| | +-[IP-Address-Range] <List>
| | | +-[(ip-address) IP-Address-Start]
| | | +-[(ip-address) IP-Address-End]
| | +-[IP-Address-Mask] <List>
| | | +-[(ip-address) IP-Address:]
| | | +-[(Unsigned 32) IP-Bit-Mask-Width:]
| | +-[(mac-address) MAC-Address] <List>
| | +-[MAC-Address-Mask] <List>
| | | +-[(mac-address) MAC-Address:]
| | | +-[(mac-address) MAC-Address-Mask-Pattern:]
| | +-[(eui64-address) EUI64-Address] <List>
| | +-[EUI64-Address-Mask] <List>
| | | +-[(eui64-address) EUI64-Address:]
| | | +-[(eui64-address) EUI64-Address-Mask-Pattern:]
| | +-[(Integer 32) Port] <List>
| | +-[Port-Range] <List>
| | | +-[(Integer 32) Port-Start]
| | | +-[(Integer 32) Port-End]
| | +-[(Boolean) Negated]
| | +-[(Boolean) Use-Assigned-Address]
| +-[To-Spec] <List> (O)
| | +-[(ip-address) IP-Address] <List>
| | +-[IP-Address-Range] <List>
| | | +-[(ip-address) IP-Address-Start]
| | | +-[(ip-address) IP-Address-End]
| | +-[IP-Address-Mask] <List>
| | | +-[(ip-address) IP-Address:]
| | | +-[(Unsigned 32) IP-Bit-Mask-Width:]
| | +-[(mac-address) MAC-Address] <List>
| | +-[MAC-Address-Mask] <List>
| | | +-[(mac-address) MAC-Address:]
| | | +-[(mac-address) MAC-Address-Mask-Pattern:]
| | +-[(eui64-address) EUI64-Address] <List>
| | +-[EUI64-Address-Mask] <List>
| | | +-[(eui64-address) EUI64-Address:]
| | | +-[(eui64-address) EUI64-Address-Mask-Pattern:]
| | +-[(Integer 32) Port] <List>
| | +-[Port-Range] <List>
| | | +-[(Integer 32) Port-Start]
| | | +-[(Integer 32) Port-End]
| | +-[(Boolean) Negated]
| | +-[(Boolean) Use-Assigned-Address]
| +-[(dscp) Diffserv-Code-Point] <List>
| +-[(Boolean) Fragmentation-Flag ~ False]
| +-[IP-Option] <List>
| +-[TCP-Option] <List>
| +-[TCP-Flags]
| +-[ICMP-Type] <List>
| +-[ETH-Option] <List>
| +-[ecn-ip-codepoint] <List>
| +-[(flowlabel) flow-label] <List>
| +-[flow-label-range] <List>
| | +-[(flowlabel) flow-label-start]
| | +-[(flowlabel) flow-label-end]
Table 11: CONFIG and CONF_BUNDLE OP_BODY Fields Figure 28: Descriptor Templates
+--------------------+------------------+---------------------------+ 6.3. Tunnel Templates
| Field | Type | Operation Types |
| | | Create(C), Update(U), |
| | | Query(Q) and Delete(D) |
+--------------------+------------------+---------------------------+
| OP_ID | [64, unsigned | All |
| | integer] | |
| | | |
| STATUS | [1, Enumerated] | OK(0) or Error(1) |
| | | |
| NOTIFY_FOLLOWS | boolean | |
| | | |
| POLICIES | *[ POLICY ] | C,U |
| | | |
| RULES | *[ RULE ] | C,U |
| | | |
| DESCRIPTORS | *[ DESCRIPTOR ] | C,U |
| | | |
| ACTIONS | *[ ACTION ] | C,U |
| | | |
| INSTALLED_POLICIES | *[ | C,U [NOTE 1] |
| | INSTALLED_POLICY | |
| | ] | |
| | | |
| CONTEXTS | *[ CONTEXT [ | C,U [NOTE 1] |
| | COMMAND_SET | |
| | [NOTE 1] ] ] | |
| | | |
| TARGETS | *[ FPC-Identity | Q,D [NOTE 1] |
| | (Section 4.8) ] | |
| | | |
| ERROR_TYPE_ID | [32, unsigned | All [NOTE 2] |
| | integer] | |
| | | |
| ERROR_TAG | [1024, octet | All [NOTE 2, 3] |
| | string] | |
+--------------------+------------------+---------------------------+
Table 12: Immediate Response RESPONSE_BODY Fields The Network Service Header is specified in [RFC8300].
Notes: The MPLS SR Stack is specified in
[I-D.ietf-spring-segment-routing-mpls].
NOTE 1 - Present in OK and OK with NOTIFY_FOLLOWS for both CONFIG The IPv6 SR Stack is specified in
and CONF_BUNDLE. MAY also be present in an CONF_BUNDLE Error [I-D.ietf-6man-segment-routing-header].
response (ERR) if one of the operations completed successfully.
NOTE 2 - Present only for Error (ERR) responses. A tunnel MUST have the local-address or remote-address (or both)
populated.
NOTE 3 - Other Error Info (Strings) MAY also be present. For GRE, the gre-key MUST be present.
+-----------------+----------------------+--------------------------+ For GTP (GPRS Tunneling Protocol), the following attributes MAY be
| Field | Type | Description | present
+-----------------+----------------------+--------------------------+
| AGENT_ID | FPC-Identity | |
| | (Section 4.8) | |
| | | |
| OP_ID | [64, unsigned | All |
| | integer] | |
| | | |
| STATUS | [1, Enumerated] | OK(0) or Error(1) |
| | | |
| NOTIFICATION_ID | [32, unsigned | A Notification |
| | integer] | Identifier used to |
| | | determine notification |
| | | order. |
| | | |
| TIMESTAMP | [32, unsigned | The time that the |
| | integer] | notification occurred. |
| | | |
| DATA | *[ [OP_ID (if | |
| | CONF_BUNDLE) ] | |
| | RESPONSE_BODY (Table | |
| | 12) ] | |
+-----------------+----------------------+--------------------------+
Table 13: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields local tunnel endpoint identifier (teid) - MUST be present if
local-address is nonempty
6.1.3.3. Monitors remote tunnel endpoint identifier (teid) - MUST be present if
+-----------------+---------------------+---------------------------+ remote-address is nonempty
| Field | Type | Description |
+-----------------+---------------------+---------------------------+
| NOTIFICATION_ID | [32, unsiged | |
| | integer] | |
| | | |
| TIMESTAMP | [32, unsigned | |
| | integer] | |
| | | |
| CAUSE | [32, unsigned | |
| | integer] | |
| | | |
| NOTIFY | MONITOR | NOTIFICATION_DATA is the |
| | [NOTIFICATION_DATA] | value of the monitored |
| | | target if this is not ean |
| | | error. |
+-----------------+---------------------+---------------------------+
Table 14: Monitor Notifications sequence-numbers-on - Indicates that sequence numbers will be used
7. Derived and Subtyped Attributes Tunnels can be used as Next Hop and Descriptor values.
This section notes settings and derived attributes. |
+-[next-hop-template]
| +-[Extensible: True]
| +-[(ip-address) address]
| +-[(mac-address) mac-address]
| +-[(service-path-id) service-path]
| +-[(mpls-label) mpls-path]
| +-[(network service header) nsh]
| +-[(Unsigned Integer) interface]
| +-[(Unsigned 128) segment-identifier]
| +-[(MPLS Stack) mpls-label-stack]
| +-[(MPLS SR Stack) mpls-sr-stack]
| +-[(IPv6 SR Stack) srv6-stack]
| +-[tunnel-template]
...
|
+-[tunnel-template]
| +-[Extensible: True]
| +-[(address) local-address]
| +-[(address) remote-address]
| +-[mtu]
| +-[(Enumeration - ipv4(0), ipv6(1), dual(2) payload_type:]
| +-[(Enumeration - ip-in-ip(0),
udp(1), gre(2), gtpv1(3), gtpv2(4)) type:]
| +-[interface]
| +-[next-hop]
| +-[gre-key:] (type == gre)
| +-[gtp-info] (type == gtpv1 or type == gtpv2 )
| | +-[(Unsigned 32) local-teid]
| | +-[(Unsigned 32) remote-teid]
| | +-[(Boolean) sequence-numbers-on] (type == gtpv1)
+---------------------------+---------------------+-----------------+ Figure 29: Tunnel Templates
| Field | Type | Detail |
+---------------------------+---------------------+-----------------+
| TUN_LOCAL_ADDRESS | IP Address | [NOTE 1] |
| | | |
| TUN_REMOTE_ADDRESS | IP Address | [NOTE 1] |
| | | |
| TUN_MTU | [32, unsigned | |
| | integer] | |
| | | |
| TUN_PAYLOAD_TYPE | [2, bits] | Enumeration: pa |
| | | yload_ipv4(0), |
| | | payload_ipv6(1) |
| | | or payload_dual |
| | | (2). |
| | | |
| TUN_TYPE | [8, unsigned | Enumeration: |
| | integer] | IP-in-IP(0), |
| | | UDP(1), GRE(2) |
| | | and GTP(3). |
| | | |
| TUN_IF | [16, unsigned | Input interface |
| | integer] | index. |
| | | |
| MOBILITY_SPECIFIC_TUN_PAR | [ IETF_PMIP_MOB_PRO | [NOTE 1] |
| AMS | FILE | | |
| | 3GPP_MOB_PROFILE ] | |
| | | |
| NEXTHOP | Varies | [NOTE 1] See |
| | | Table 18. |
| | | |
| QOS_PROFILE_PARAMS | [ 3GPP_QOS | | [NOTE 1] |
| | PMIP_QOS ] | |
+---------------------------+---------------------+-----------------+
NOTE 1 - These parameters are extensible. The Types may be extended 6.4. Action Templates
for Field value by future specifications or in the case of Vendor
Specific Attributes by enterprises.
Table 15: Context Tunnel And QoS Settings The following figure shows common next-hop (set next-hop) and tunnel
templates for Actions.
+-----------+------------------+--------------------+---------------+ Drop action has no values.
| Field | Type Value | Type | Description |
| (Type | | | |
| Value) | | | |
+-----------+------------------+--------------------+---------------+
| TO_PREFIX | [IP Address] [ | Aggregated or per- | FROM_PREFIX |
| (0) | Prefix Len ] | host destination | (1) |
| | | IP address/prefix | |
| | | descriptor. | |
| | | | |
| [IP | Aggregated or | TRAFFIC_SELECTOR | Format per |
| Address] | per-host source | (2) | specification |
| [ Prefix | IP | | [RFC6088]. |
| Len ] | address/prefix | | |
| | descriptor. | | |
| | | | |
| Traffic |
| Selector. |
+-----------+------------------+--------------------+---------------+
Table 16: Descriptor Subtypes Rewrite uses a Descriptor to set the values of the packet. Exactly
one Descriptor MUST be present. Only the Destination and Source port
fields, if present, are used from the Descriptor.
+--------------+-------------------------+--------------------------+ Copy-Forward creates a copy of the packet and then forwards it in
| Field (Type | Type | Description | accordance to the nexthop value.
| Value) | | |
+--------------+-------------------------+--------------------------+
| DROP (0) | Empty | Drop the associated |
| | | packets. |
| | | |
| REWRITE (1) | [in_src_ip] | Rewrite IP Address (NAT) |
| | [out_src_ip] | or IP Address / Port |
| | [in_dst_ip] | (NAPT). |
| | [out_dst_ip] | |
| | [in_src_port] | |
| | [out_src_port] | |
| | [in_dst_port] | |
| | [out_dst_port] | |
| | | |
| COPY_FORWARD | FPC-Identity. See | Copy all packets and |
| (2) | Section 4.8. | forward them to the |
| | | provided identity. The |
| | | value of the identity |
| | | MUST be a port or |
| | | context. |
+--------------+-------------------------+--------------------------+
Table 17: Action Subtypes |
+-[drop-template]
...
|
+-[rewrite-template]
| +-[Extensible: True]
| +-[ip-prefix-template]
| +-[pmip-traffic-selector]
| +-[rfc5777-classifier]
...
|
+-[copy-forward-template]
| +-[Extensible: True]
| +-[next-hop:]
+--------------------------------+----------------+-----------------+ Figure 30: Action Templates
| Field (Type Value) | Type | Description |
+--------------------------------+----------------+-----------------+
| IP_ADDR (0) | IP Address | An IP Address. |
| | | |
| MAC_ADDR (1) | MAC Address | A MAC Address. |
| | | |
| SERVICE_PATH_ID (2) | [24, unsigned | Service Path |
| | integer] | Identifier |
| | | (SPI) |
| | | |
| MPLS_LABEL (3) | [20, unsigned | MPLS Label |
| | integer] | |
| | | |
| NSH (4) | [SERVICE_PATH_ | See [I-D.ietf-s |
| | ID] [8, | fc-nsh] |
| | unsigned | |
| | integer] | |
| | | |
| INTERFACE_INDEX (5) | [16, unsigned | Interface Index |
| | integer] | (an unsigned |
| | | integer). |
| | | |
| SEGMENT_ID (6) | [128, unsigned | Segement |
| | integer] | Identifier. |
| | | |
| MPLS_LABEL_STACK (7) | 7 | 1*[20 bit |
| | | labels] |
| | | |
| MPLS SR Stack. See [I-D.ietf-s | SRV6_STACK (8) | 32+ Bytes |
| pring-segment-routing-mpls]. | | |
| | | |
| See [I-D.ietf-6man-segment-rou |
| ting-header]. |
+--------------------------------+----------------+-----------------+
Table 18: Next Hop Subtypes 6.5. Quality of Service Action Templates
+----------+-------+------------------+-----------------------------+ PMIP QoS is specified in [RFC7222].
| Field | Type | Type | Description |
| | Value | | |
+----------+-------+------------------+-----------------------------+
| QOS | 0 | [qos index type] | Refers to a single index |
| | | [index] [DSCP] | and DSCP to write to the |
| | | | packet. |
| | | | |
| GBR | 1 | [32, unsigned | Guaranteed bit rate. |
| | | integer] | |
| | | | |
| MBR | 2 | [32, unsigned | Maximum bit rate. |
| | | integer] | |
| | | | |
| PMIP_QOS | 3 | Varies by Type | A non-traffic selector PMIP |
| | | | QoS Attribute per [RFC7222] |
+----------+-------+------------------+-----------------------------+
Table 19: QoS Subtypes |
+-[qos-template]
| +-[Extensible: True]
| +-[(dscp) trafficclass]
| +-[pmip-qos]
| | +-[(Unsigned 32) per-mn-agg-max-dl]
| | +-[(Unsigned 32) per-mn-agg-max-ul]
| | +-[per-session-agg-max-dl]
| | | +-[(Unsigned 32) max-rate:]
| | | +-[(Boolean) service-flag:]
| | | +-[(Boolean) exclude-flag:]
| | +-[per-session-agg-max-ul]
| | | +-[(Unsigned 32) max-rate:]
| | | +-[(Boolean) service-flag:]
| | | +-[(Boolean) exclude-flag:]
| | +-[allocation-retention-priority]
| | | +-[(Unsigned 8) prioirty-level:]
| | | +-[(Enumeration) premption-capability:]
| | | +-[(Enumeration) premption-vulnerability:]
| | +-[(Unsigned 32) agg-max-dl]
| | +-[(Unsigned 32) agg-max-ul]
| | +-[(Unsigned 32) gbr-dl]
| | +-[(Unsigned 32) gbr-ul]
+----------+---------+----------------+-----------------------------+ Figure 31: QoS Templates
| Field | Type | Type | Description |
| | Value | | |
+----------+---------+----------------+-----------------------------+
| IPIP_TUN | 0 | | IP in IP Configuration |
| | | | |
| UDP_TUN | 1 | [src_port] | UDP Tunnel - source and/or |
| | | [dst_port] | destination port |
| | | | |
| GRE_TUN | 2 | [32, GRE Key] | GRE Tunnel. |
+----------+---------+----------------+-----------------------------+
Table 20: Tunnel Subtypes 6.6. PMIP Command-Set
The following COMMAND_SET values are supported for IETF_PMIP. The following Command Set values are supported for IETF PMIP.
o assign-ip - Assign the IP Address for the mobile session. o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node. o assign-dpn - Assign the Dataplane Node.
o session - Assign values for the Session Level. o session - Assign values for the Session Level.
o uplink - Command applies to uplink. o uplink - Command applies to uplink.
o downlink - Command applies to downlink. o downlink - Command applies to downlink.
7.1. 3GPP Specific Extenstions 6.7. 3GPP Specific Templates and Command-Set
3GPP support is optional and detailed in this section. The following 3GPP support is optional and detailed in this section. The following
acronyms are used: acronyms are used:
APN-AMBR: Access Point Name Aggregate Maximum Bit Rate APN-AMBR: Access Point Name Aggregate Maximum Bit Rate
ARP: Allocation of Retention Priority UE-AMBR: User Equipment Aggregate Maximum Bit Rate
EBI: EPS Bearer Identity QCI: QoS Class Identifier
GBR: Guaranteed Bit Rate EBI: EPS Bearer Identity
GTP: GPRS (General Packet Radio Service) Tunneling Protocol LBI: Linked Bearer Identity
IMSI: International Mobile Subscriber Identity IMSI: International Mobile Subscriber Identity
MBR: Maximum Bit Rate
QCI: QoS Class Identifier
TEID: Tunnel Endpoint Identifier.
TFT: Traffic Flow Template (TFT) TFT: Traffic Flow Template (TFT)
UE-AMBR: User Equipment Aggregate Maximum Bit Rate Generally, 3GPP QoS values should use the qos-template. Note: User
Equipment Aggregate Maximum Bit Rate (UE-AMBR) maps to the per-mn-
agg-max-dl and per-mn-agg-max-ul.
NOTE: GTP Sequence Number (SEQ_NUMBER) is used in failover and |
handover. +-[ MN-Policy-Template ]
| +-[(Unsigned 64) imsi:]
...
+-[tunnel-template]
| +-[Extensible: True]
| +-[(unsigned 4) ebi:]
| +-[(unsigned 4) lbi]
...
+-[qos-template]
| +-[Extensible: True]
| +-[(unsigned 4) qos-class-identifier]
| +-[(Unsigned 32) ue-agg-max-bitrate]
| +-[(Unsigned 32) apn-agg-max-bitrate]
...
+-------------+-------+-------------+-------------------------------+ Figure 32: 3GPP Mobility Templates
| Field | Type | Namespace / | Type |
| | Value | Entity | |
| | | Extended | |
+-------------+-------+-------------+-------------------------------+
| GTPV1 | 3 | Tunnel | LOCAL_TEID REMOTE_TEID |
| | | Subtypes | SEQ_NUMBER |
| | | namespace. | |
| | | | |
| GTPV2 | 4 | Tunnel | LOCAL_TEID REMOTE_TEID |
| | | Subtypes | SEQ_NUMBER |
| | | namespace. | |
| | | | |
| LOCAL_TEID | N/A | N/A | [32, unisgned integer] |
| | | | |
| REMOTE_TEID | N/A | N/A | [32, unisgned integer] |
| | | | |
| SEQ_NUMBER | N/A | N/A | [32, unisgned integer] |
| | | | |
| TFT | 3 | Descriptors | Format per TS 24.008 Section |
| | | Subtypes | 10.5.6.12. |
| | | namespace. | |
| | | | |
| IMSI | N/A | Context | [64, unsigned integer] |
| | | (new | |
| | | attribute) | |
| | | | |
| EBI | N/A | Context | [4, unsigned integer] |
| | | (new | |
| | | attribute) | |
| | | | |
| 3GPP_QOS | 4 | QoS | [8, qci] [32, gbr] [32, mbr] |
| | | Subtypes | [32, apn_ambr] [32, ue_ambr] |
| | | namespace. | ARP |
| | | | |
| ARP | N/A | N/A | See Allocation-Retention- |
| | | | Priority from [RFC7222] |
+-------------+-------+-------------+-------------------------------+
Table 21: 3GPP Attributes and Structures |
+-[ packet-filter ]
| +-[Extensible: True]
| +-[(Unsigned 8) identifier:]
| +-[Contents:] <List>
| | +-[(ip-address) ipv4-ipv6-local]
| | +-[(ipv6-prefix) ipv6-prefix-local]
| | +-[(ip-address) ipv4-ipv6-remote]
| | +-[(ipv6-prefix) ipv6-prefix-remote]
| | +-[(Unsigned 8) protocol-next-header]
| | +-[(Unsigned 16) local-port]
| | +-[local-port-range]
| | | +-[(Unsigned 16) local-port-lo]
| | | +-[(Unsigned 16) local-port-hi]
| | +-[(Unsigned 16) remote-port]
| | +-[remote-port-range]
| | | +-[(Unsigned 16) remote-port-lo]
| | | +-[(Unsigned 16) remote-port-hi]
| | +-[(Unsigned 32) sec-parameter-index]
| | +-[(dscp) traffic-class]
| | +-[traffic-class-range]
| | | +-[(dscp) traffic-class-lo]
| | | +-[(dscp) traffic-class-hi]
| | +-[(dscp) flow-label]
...
The following COMMAND_SET values are supported for 3GPP. Figure 33: 3GPP Packet Filter Template (Descriptor)
o assign-ip - Assign the IP Address for the mobile session. The following Command Set values are supported for 3GPP.
o assign-dpn - Assign the Dataplane Node. o assign-ip - Assign the IP Address for the mobile session.
o assign-fteid-ip - Assign the Fully Qualified TEID (F-TEID) LOCAL o assign-fteid-ip - Assign the Fully Qualified TEID (F-TEID) LOCAL
IP address. IP address.
o assign-fteid-teid - Assign the Fully Qualified TEID (F-TEID) LOCAL o assign-fteid-teid - Assign the Fully Qualified TEID (F-TEID) LOCAL
TEID. TEID.
o session - Assign values for the Session Level. When this involves o session - Assign values for the Session Level. When this involves
'assign-fteid-ip' and 'assign-fteid-teid' this implies the values 'assign-fteid-ip' and 'assign-fteid-teid', the values are part of
are part of the default bearer. the default bearer.
o uplink - Command applies to uplink. o uplink - Command applies to uplink.
o downlink - Command applies to downlink. o downlink - Command applies to downlink.
8. Implementation Status o assign-dpn - Assign the Dataplane Node.
7. Implementation Status
Three FPC Agent implementations have been made to date. The first Three FPC Agent implementations have been made to date. The first
was based upon Version 03 of the draft and followed Model 1. The was based upon Version 03 of the draft and followed Model 1. The
second follows Version 04 of the document. Both implementations were second follows Version 04 of the document. Both implementations were
OpenDaylight plug-ins developed in Java by Sprint. Version 03 was OpenDaylight plug-ins developed in Java by Sprint. Version 03 was
known as fpcagent and version 04's implementation is simply referred known as fpcagent and version 04's implementation is simply referred
to as 'fpc'. A third has been devloped on an ONOS Controller for use to as 'fpc'. A third has been devloped on an ONOS Controller for use
in MCORD projects. in MCORD projects.
fpcagent's intent was to provide a proof of concept for FPC Version fpcagent's intent was to provide a proof of concept for FPC Version
skipping to change at page 59, line 8 skipping to change at page 58, line 12
project was closed in August 2016. fpcagent will no longer be project was closed in August 2016. fpcagent will no longer be
developed and will remain a proprietary implementation. developed and will remain a proprietary implementation.
The learnings of fpcagent has influenced the second project, fpc. The learnings of fpcagent has influenced the second project, fpc.
Fpc is also an OpenDaylight project but is an open source release as Fpc is also an OpenDaylight project but is an open source release as
the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/ the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/
Project_Proposals:FpcAgent). This project is scoped to be a fully Project_Proposals:FpcAgent). This project is scoped to be a fully
compliant FPC Agent that supports multiple DPNs including those that compliant FPC Agent that supports multiple DPNs including those that
communicate via OpenFlow. The following features present in this communicate via OpenFlow. The following features present in this
draft and others developed by the FPC development team have already draft and others developed by the FPC development team have already
lead to an order of magnitude improvement. led to an order of magnitude improvement.
Migration of non-realtime provisioning of entities such as Migration of non-realtime provisioning of entities such as
topology and policy allowed the implementation to focus only on topology and policy allowed the implementation to focus only on
the rpc. the rpc.
Using only 5 messages and 2 notifications has also reduced Using only 5 messages and 2 notifications has also reduced
implementation time. implementation time.
Command Sets, an optional feature in this specification, have Command Sets, an optional feature in this specification, have
eliminated 80% of the time spent determining what needs to be eliminated 80% of the time spent determining what needs to be
skipping to change at page 61, line 46 skipping to change at page 60, line 46
for each Context for each Context
for each DPN / direction in Context for each DPN / direction in Context
perform actions on DPN according to Command Set perform actions on DPN according to Command Set
end for end for
end for end for
end for end for
commit changes to in memory cache commit changes to in memory cache
log transaction for tracking and notification log transaction for tracking and notification
(CONFIG_RESULT_NOTIFY) (CONFIG_RESULT_NOTIFY)
Figure 22: fpc pseudo code Figure 34: fpc pseudo code
For further information please contact Lyle Bertz who is also a co- For further information please contact Lyle Bertz who is also a co-
author of this document. author of this document.
NOTE: Tenant support requires binding a Client ID to a Tenant ID (it 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 is a one to many relation) but that is outside of the scope of this
specification. Otherwise, the specification is complete in terms of specification. Otherwise, the specification is complete in terms of
providing sufficient information to implement an Agent. providing sufficient information to implement an Agent.
9. Security Considerations 8. Security Considerations
Detailed protocol implementations for DMM Forwarding Policy Detailed protocol implementations for DMM Forwarding Policy
Configuration must ensure integrity of the information exchanged Configuration must ensure integrity of the information exchanged
between an FPC Client and an FPC Agent. Required Security between an FPC Client and an FPC Agent. Required Security
Associations may be derived from co-located functions, which utilize Associations may be derived from co-located functions, which utilize
the FPC Client and FPC Agent respectively. the FPC Client and FPC Agent respectively.
The YANG modules defined in this memo is designed to be accessed via The YANG modules defined in this memo is designed to be accessed via
the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest
NETCONF layer is the secure transport layer and the mandatory-to- NETCONF layer is the secure transport layer and the mandatory-to-
skipping to change at page 62, line 38 skipping to change at page 61, line 38
proper protection can have a negative effect on network operations. proper protection can have a negative effect on network operations.
These are the subtrees and data nodes and their sensitivity/ These are the subtrees and data nodes and their sensitivity/
vulnerability: vulnerability:
Nodes under the Policy tree provide generic policy enforcement and Nodes under the Policy tree provide generic policy enforcement and
traffic classification. They can be used to block or permit traffic classification. They can be used to block or permit
traffic. If this portion of the model was to be compromised it traffic. If this portion of the model was to be compromised it
may be used to block, identify or permit traffic that was not may be used to block, identify or permit traffic that was not
intended by the Tenant or FPC CLient. intended by the Tenant or FPC CLient.
Nodes under the Topology tree provide defintion of the Tenant's Nodes under the Topology tree provide definition of the Tenant's
forwarding topology. Any compromise of this information will forwarding topology. Any compromise of this information will
provide topology information that could be used for subsequent provide topology information that could be used for subsequent
attack vectors. Removal of topology can limit services. attack vectors. Removal of topology can limit services.
Nodes under the Mobility Tree are runtime only and manipulated by Mobility-Context provides runtime only and manipulated by remote
remote procedure calls. The unwanted deletion or removal of such procedure calls. The unwanted deletion or removal of such
information would deny users service or provide services to information would deny users service or provide services to
unauthorized parties. unauthorized parties.
Some of the readable data nodes defined may be considered sensitive Some of the readable data nodes defined may be considered sensitive
or vulnerable in some network environments. It is thus important to or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to control read access (e.g., via get, get-config, or notification) to
these data nodes. These are the subtrees and data nodes and their these data nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability: sensitivity/vulnerability:
IP address assignments in the Context along with their associated IP address assignments in the Mobility-Context along with their
tunnel configurations/identifiers (from the FPC base module) associated tunnel configurations/identifiers (from the FPC base
module)
Internaional Mobile Subscriber Identity (IMSI) and bearer Internaional Mobile Subscriber Identity (IMSI) and bearer
identifiers in the Context when using the optional 3GPP module identifiers in the Context when using the FPC base model
Some of the RPC operations defined may be considered sensitive or Some of the RPC operations defined may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control access to these operations. These are the operations and control access to these operations. These are the operations and
their sensitivity/vulnerability: their sensitivity/vulnerability:
CONFIG and CONF_BUNDLE send Context information which can include Configure sends Mobility-Context information which can include
information of a sensitive or vulnerable nature in some network information of a sensitive or vulnerable nature in some network
environments as described above. environments as described above.
Monitor related RPC operations do not specicially provide Monitor related RPC operations do not specicially provide
sensitive or vulnerable informaiton but care must be taken by sensitive or vulnerable information but care must be taken by
users to avoid identifier values that expose sensitive or users to avoid identifier values that expose sensitive or
vulnerable information. vulnerable information.
Notications MUST be treated with same level of protection and Notications MUST be treated with same level of protection and
scrutiny as the operations they correspond to. For example, a scrutiny as the operations they correspond to. For example, a
CONFIG_RESULT_NOTIFY notification provides the same information Configure-Result notification provides the same information that
that is sent as part of the input and output of the CONFIG and is sent as part of the input and output of the Configure RPC
CONF_BUNDLE RPC operations. operations.
General usage of FPC MUST consider the following: General usage of FPC MUST consider the following:
FPC Naming Section 4.8 permits arbirtrary string values but a FPC Naming Section 4.5 permits arbirtrary string values but a
users MUST avoid placing sensitive or vulnerable information in users MUST avoid placing sensitive or vulnerable information in
those values. those values.
Policies that are very narrow and permit the identification of Policies that are very narrow and permit the identification of
specific traffic, e.g. that of a single user, SHOULD be avoided. specific traffic, e.g. that of a single user, SHOULD be avoided.
10. IANA Considerations 9. IANA Considerations
This document registers six URIs in the "IETF XML Registry" This document registers six URIs in the "IETF XML Registry"
[RFC3688]. Following the format in RFC 3688, the following [RFC3688]. Following the format in RFC 3688, the following
registrations have been made. registrations have been made.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos URI: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-traffic-selector-types URI: urn:ietf:params:xml:ns:yang:ietf-dmm-traffic-selector-types
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext
Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-diam-trafficclassifier
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]. Module Names" registry [RFC6020].
name: ietf-dmm-fpc name: ietf-dmm-fpc
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc
prefix: fpc prefix: fpc
reference: TBD1 reference: TBD1
name: ietf-dmm-pmip-qos name: ietf-dmm-pmip-qos
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos
prefix: qos-pmip prefix: qos-pmip
reference: TBD2 reference: TBD2
name: ietf-dmm-traffic-selector-types name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang: namespace: urn:ietf:params:xml:ns:yang:
ietf-dmm-traffic-selector-types ietf-dmm-traffic-selector-types
prefix: traffic-selectors prefix: traffic-selectors
reference: TBD3 reference: TBD3
name: ietf-dmm-fpc-settingsext name: ietf-dmm-fpc-settingsext
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext namespace: urn:ietf:params:xml:ns:yang:
prefix: fpcbase ietf-dmm-fpc-settingsext
reference: TBD4 prefix: fpcbase
reference: TBD4
11. Work Team Participants name: ietf-diam-trafficclassifier
namespace: urn:ietf:params:xml:ns:yang:
ietf-diam-trafficclassifier
prefix: diamclassifier
reference: TBD5
10. Work Team Participants
Participants in the FPSM work team discussion include Satoru Participants in the FPSM work team discussion include Satoru
Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick
Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred
Templin. Templin.
12. References 11. References
12.1. Normative References
[I-D.ietf-6man-segment-routing-header] 11.1. Normative References
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017.
[I-D.ietf-sfc-nsh] [I-D.ietf-6man-segment-routing-header]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress), Field, B., daniel.voyer@bell.ca, d.,
October 2017. daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10 data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), June 2017. (work in progress), February 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
Ed., and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777,
DOI 10.17487/RFC5777, February 2010,
<https://www.rfc-editor.org/info/rfc5777>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088, "Traffic Selectors for Flow Bindings", RFC 6088,
DOI 10.17487/RFC6088, January 2011, DOI 10.17487/RFC6088, January 2011,
<https://www.rfc-editor.org/info/rfc6088>. <https://www.rfc-editor.org/info/rfc6088>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
Korhonen, "Requirements for Distributed Mobility "Network Service Header (NSH)", RFC 8300,
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc7333>. <https://www.rfc-editor.org/info/rfc8300>.
12.2. Informative References 11.2. Informative References
[I-D.bertz-dime-policygroups] [I-D.bertz-dime-policygroups]
Bertz, L. and M. Bales, "Diameter Policy Groups and Sets", Bertz, L. and M. Bales, "Diameter Policy Groups and Sets",
draft-bertz-dime-policygroups-04 (work in progress), June draft-bertz-dime-policygroups-05 (work in progress),
2017. December 2017.
[I-D.ietf-dmm-deployment-models] [I-D.ietf-dmm-deployment-models]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-02 (work in progress), August 2017. models-03 (work in progress), November 2017.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>. <https://www.rfc-editor.org/info/rfc5213>.
skipping to change at page 66, line 38 skipping to change at page 65, line 49
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
Gundavelli, "Quality-of-Service Option for Proxy Mobile Gundavelli, "Quality-of-Service Option for Proxy Mobile
IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014,
<https://www.rfc-editor.org/info/rfc7222>. <https://www.rfc-editor.org/info/rfc7222>.
[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>.
[RFC7660] Bertz, L., Manning, S., and B. Hirschman, "Diameter
Congestion and Filter Attributes", RFC 7660,
DOI 10.17487/RFC7660, October 2015,
<https://www.rfc-editor.org/info/rfc7660>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch
Media Type", RFC 8072, DOI 10.17487/RFC8072, February
2017, <https://www.rfc-editor.org/info/rfc8072>.
Appendix A. YANG Data Model for the FPC protocol Appendix A. YANG Data Model for the FPC protocol
These modules define YANG definitions. When mapping from the FPC This section provides a type mapping for FPC structures in YANG.
model was performed U-Key values, ACTION_TYPES and DESCRIPTOR_TYPES When being mapped to a specific information such as YANG the data
as well as many enumerations were mapped to identity types. type MAY change.
ACTION_TYPES and DESCRIPTOR_TYPES are also optional as the type can
be inferred from the value. Four modules are defined: L-Keys for Actions, Descriptors, Rules, Policies, DPNs, Domains and
Mobility-Contexts are specified as FPC-Identity which follows rules
according to Section 4.5.
Action and Descriptor Templates are mapped as choices. This was done
to ensure no duplication of Types and avoid use of identityref for
typing.
Policy Expressions are provided as default values. NOTE that a
static value CANNOT be supported in YANG.
Five modules are defined:
o ietf-dmm-fpc (fpc) - Defines the base model and messages for FPC o ietf-dmm-fpc (fpc) - Defines the base model and messages for FPC
that are meant to be static in FPC. that are meant to be static in FPC.
o ietf-dmm-fpc-settingsext An FPC module that defines the o ietf-dmm-fpc-settingsext An FPC module that defines the
information model elements that are likely to be extended in FPC. information model elements that are likely to be extended in FPC.
o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS
parameters per RFC 7222 parameters per RFC 7222
o ietf-trafficselectors-types (traffic-selectors) - Defines Traffic o ietf-trafficselectors-types (traffic-selectors) - Defines Traffic
Selectors per RFC 6088 Selectors per [RFC6088]
o ietf-diam-trafficclassifier (diamclassifier) - Defines the
Classifier per [RFC5777]
A.1. FPC YANG Model A.1. FPC YANG Model
This module defines the information model and protocol elements This module defines the information model and protocol elements
specified in this document. specified in this document.
This module references [RFC6991], [RFC8040] and the fpc-settingsext This module references [RFC6991], [RFC8040] and the fpc-settingsext
module defined in this document. module defined in this document.
<CODE BEGINS> file "ietf-dmm-fpc@2017-09-27.yang" <CODE BEGINS> file "ietf-dmm-fpc@2018-02-28.yang"
module ietf-dmm-fpc { module ietf-dmm-fpc {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc"; namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc";
prefix fpc; prefix fpc;
import ietf-inet-types { prefix inet; import ietf-inet-types { prefix inet;
revision-date 2013-07-15; } revision-date 2013-07-15; }
import ietf-restconf { prefix restconf;
revision-date 2017-01-26; }
import ietf-dmm-fpc-settingsext { prefix fpcbase; import ietf-dmm-fpc-settingsext { prefix fpcbase;
revision-date 2017-09-27; revision-date 2018-02-28; }
} import ietf-diam-trafficclassifier { prefix rfc5777;
revision-date 2018-02-28; }
import ietf-restconf { prefix rc;
revision-date 2017-01-26; }
import ietf-yang-patch { prefix ypatch;
revision-date 2017-02-22; }
organization "IETF Distributed Mobility Management (DMM) organization "IETF Distributed Mobility Management (DMM)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Dapeng Liu WG Chair: Dapeng Liu
<mailto:maxpassion@gmail.com> <mailto:maxpassion@gmail.com>
WG Chair: Jouni Korhonen WG Chair: Sri Gundavelli
<mailto:jouni.nospam@gmail.com> <mailto:sgundave@cisco.com>
Editor: Satoru Matsushima Editor: Satoru Matsushima
<mailto:satoru.matsushima@g.softbank.co.jp> <mailto:satoru.matsushima@g.softbank.co.jp>
Editor: Lyle Bertz Editor: Lyle Bertz
<mailto:lylebe551144@gmail.com>"; <mailto:lylebe551144@gmail.com>";
description description
"This module contains YANG definition for "This module contains YANG definition for
Forwarding Policy Configuration Protocol (FPCP). Forwarding Policy Configuration Protocol (FPCP).
skipping to change at page 68, line 23 skipping to change at page 68, line 18
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License."; without warranty as described in the Simplified BSD License.";
revision 2017-09-27 { revision 2018-02-28 {
description "Version 10 updates."; description "Version 10 updates.";
reference "draft-ietf-dmm-fpc-cpdp-10"; reference "draft-ietf-dmm-fpc-cpdp-10";
} }
revision 2017-09-27 {
description "Version 10 updates.";
reference "draft-ietf-dmm-fpc-cpdp-09";
}
revision 2017-07-22 { revision 2017-07-22 {
description "Version 08 updates."; description "Version 08 updates.";
reference "draft-ietf-dmm-fpc-cpdp-08"; reference "draft-ietf-dmm-fpc-cpdp-08";
} }
revision 2017-03-08 { revision 2017-03-08 {
description "Version 06 updates."; description "Version 06 updates.";
reference "draft-ietf-dmm-fpc-cpdp-06"; reference "draft-ietf-dmm-fpc-cpdp-06";
} }
revision 2016-08-03 { revision 2016-08-03 {
description "Initial Revision."; description "Initial Revision.";
reference "draft-ietf-dmm-fpc-cpdp-05"; reference "draft-ietf-dmm-fpc-cpdp-05";
} }
feature fpc-basename-registry {
description "Ability to track Base Names already provisioned
on the Agent";
}
feature fpc-bundles {
description "Ability for Client to send multiple bundles of
actions to an Agent";
}
feature fpc-auto-binding {
description "Allows a FPC Agent to advertise Topology Objects
that could be DPNs";
}
feature operation-ref-scope {
description "Provides the scope of refeneces in an operation.
Used to optmize the Agent processing.";
}
//General Structures //General Structures
grouping templatedef {
leaf extensible {
type boolean;
description "Indicates if the template is
extensible";
}
leaf-list mandatory-static-attributes {
type string;
description "Attribute (Name) that cannot change.
If it has not been defined in the template it
MUST NOT be present at all for the template
to be valid.";
}
leaf entity-state {
type enumeration {
enum initial {
description "Inital Configuration";
}
enum partially-configured {
description "Partial Configuration";
}
enum configured {
description "Confgured";
}
enum active {
description "Active";
}
}
default initial;
description "Entity State";
}
description "Teamplate Definition";
}
typedef fpc-identity { typedef fpc-identity {
type union { type union {
type uint32; type uint32;
type string; type string;
type instance-identifier; type instance-identifier;
} }
description "FPC Identity"; description "FPC Identity";
} }
grouping target-value { grouping index {
leaf target { leaf index {
type fpc-identity; type uint16;
mandatory true; description "Index";
description "Target Identity";
}
description "FPC Target Value";
}
// Topology
typedef fpc-interface-id {
type fpc:fpc-identity;
description "DPN interface Identifier";
}
identity interface-protocols {
description "Protocol supported by the interface";
}
identity features {
description "Protocol features";
}
// Settings
grouping settings {
container settings-set {
uses fpcbase:fpc-settings;
description "Settings";
}
description "Settings container";
}
//Topology - Groupings
grouping interface-settings {
container interface-settings-set {
description "Interface settings";
}
description "Generic interface settings container";
}
grouping access-technology-key {
leaf access-technology {
type identityref {
base "fpcbase:access-technology";
}
mandatory true;
description "Access Technology";
}
description "Access Technology key";
}
grouping role-key {
leaf role {
type identityref {
base "fpcbase:role";
}
mandatory true;
description "Access Technology Role";
}
description "Access Technology Role key";
}
grouping interface-id-key {
leaf interface-id {
type fpc:fpc-interface-id;
mandatory true;
description "interface identifier";
}
description "Interface Identifier key";
}
grouping dpn-identifier-key {
leaf dpn-id {
type fpc:fpc-identity;
mandatory true;
description "DPN Identifier Type";
}
description "DPN Identifier key";
}
grouping dpn-interface-reference {
uses fpc:access-technology-key;
uses fpc:role-key;
uses fpc:interface-id-key;
description "A reference to a DPN interface";
}
// Topology Grouping
grouping fpc-topology {
list dpn-set {
key dpn-id;
uses fpc:dpn-identifier-key;
leaf dpn-name {
type string;
description "DPN name";
}
leaf dpn-resource-mapping-reference {
type string;
description "Reference to underlying DPN resource(s)";
}
list interface-set {
key "access-technology role interface-id";
uses fpc:dpn-interface-reference;
uses fpc:interface-settings;
description "DPN interfaces";
}
description "Set of DPNs";
}
list dpn-type-set {
key "access-technology role";
uses fpc:access-technology-key;
leaf access-technology-name {
type string;
description "Access Technology Name";
}
uses fpc:role-key;
leaf role-name {
type string;
description "Access Technology Role Name";
}
list interface-set {
key interface-id;
uses fpc:interface-id-key;
leaf interface-name {
type string;
description "DPN-Type Interface Name";
}
leaf-list interface-protocol-set {
type identityref {
base "interface-protocols";
}
description "Supported protocols";
}
leaf-list feature-set {
type identityref {
base "interface-protocols";
}
description "Supported features";
} }
uses fpc:interface-settings; description "Index Value";
description "A DPN interface types";
}
description "Set of DPN types";
} }
list dpn-group-set {
key "dpn-group-id"; // Policy Structures
leaf dpn-group-id { grouping descriptor-template-key {
type fpc:fpc-identity; leaf descriptor-template-key {
mandatory true; type fpc:fpc-identity;
description "DPN Group Identifier"; mandatory true;
} description "Descriptor Key";
list referenced-dpns-set {
key "access-technology role interface-id";
uses fpc:dpn-interface-reference;
leaf-list supporting-dpn-id-set {
type fpc:fpc-identity;
description "DPNs that suppport this group";
}
leaf-list dpn-group-peer-id-set {
type fpc:fpc-identity;
description "DPN Peer Groups reference";
}
description "A list of DPNs supporting a group
by DPN Type";
}
list dpn-group-peer-set {
key remote-dpn-group-id;
leaf remote-dpn-group-id {
type fpc:fpc-identity;
mandatory true;
description "Remote DPN Group identifier";
} }
uses fpc:interface-settings; description "Descriptor-Template Key";
description "Locally applied settings used for
the referenced DPN-Group (peer group).";
}
leaf domain-id {
type fpc:fpc-identity;
description "Domain Identiifer";
}
description "List of DPN groups";
}
list domain-set {
key domain-id;
leaf domain-id {
type fpc:fpc-identity;
mandatory true;
description "Domain Identifier";
}
leaf domain-name {
type string;
description "Domain displayname";
}
leaf domain-reference {
type string;
description "Reference to domain resources";
}
description "List of Domains";
}
description "FPC Topology grouping";
}
// Policy Structures
// Descriptor Structure
identity fpc-descriptor-type {
description "A traffic descriptor";
} }
grouping descriptor-definition { grouping action-template-key {
leaf descriptor-id { leaf action-template-key {
type fpc:fpc-identity; type fpc:fpc-identity;
mandatory true; mandatory true;
description "Descriptor Id"; description "Action Key";
}
leaf descriptor-type {
type identityref {
base "fpc-descriptor-type";
}
description "Descriptor Type Value";
} }
uses fpcbase:fpc-descriptor-value; description "Action-Template Key";
description "FPC Descriptor Definition";
}
// Action Structure
identity fpc-action-type {
description "Action Type";
} }
grouping action-definition { grouping rule-template-key {
leaf action-id { leaf rule-template-key {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Action Identifier"; mandatory true;
} description "Rule Identifier";
leaf action-type {
type identityref {
base "fpc-action-type";
}
description "Action Type";
} }
uses fpcbase:fpc-action-value; description "Rule Key";
description "FPC Action Definition";
} }
// Rule Structure grouping policy-template-key {
typedef fpc-direction-type { leaf policy-template-key {
type enumeration { type fpc:fpc-identity;
enum uplink { mandatory true;
description "uplink"; description "Rule Identifier";
}
enum downlink {
description "Downlink";
}
enum both {
description "Both";
} }
} description "Rule Key";
description "FPC Direction";
}
grouping fpc-rule-id {
leaf rule-id {
type fpc:fpc-identity;
mandatory true;
description "Rule Identifier";
}
description "FPC Rule-Id key";
} }
grouping match-type {
leaf descriptor-match-type { // Settings
type enumeration { grouping policy-configuration {
enum or { list policy-configuration {
value 0; key index;
description "OR logic"; leaf index {
type uint16;
description "Index used for reference";
} }
enum and { choice policy-setting {
value 1; case descriptor-value {
description "AND logic"; uses fpcbase:fpc-descriptor-value;
description "Descriptor Value";
}
case action-value {
uses fpcbase:fpc-action-value;
description "Action Value";
}
description "Policy Attributes";
} }
} description "Policy Configuration";
mandatory true;
description "Type of Match (OR or AND) applied to the
descriptor-reference-set.";
}
description "Map Type Grouping";
}
grouping fpc-action-order {
leaf action-order {
type uint32;
mandatory true;
description "Action Execution Order";
} }
description "Action Order Leaf"; description "Policy Configuration Value";
} }
grouping rule-definition {
uses fpc:fpc-rule-id; // FPC Policy
uses fpc:match-type; grouping policy-information-model {
list descriptor-reference-set { list action-template {
key "descriptor-id-reference"; key action-template-key;
leaf descriptor-id-reference { uses fpc:action-template-key;
type fpc:fpc-identity; uses fpcbase:fpc-action-value;
mandatory true; uses fpc:templatedef;
description "Descriptor Id Reference"; description "Action Template";
} }
leaf direction { list descriptor-template {
type fpc:fpc-direction-type; key descriptor-template-key;
description "Direction"; uses fpc:descriptor-template-key;
} uses fpcbase:fpc-descriptor-value;
description "A set of Descriptor references"; uses fpc:templatedef;
description "Descriptor Template";
}
list rule-template {
key rule-template-key;
uses fpc:rule-template-key;
leaf descriptor-match-type {
type enumeration {
enum or {
value 0;
description "OR logic";
}
enum and {
value 1;
description "AND logic";
}
}
default "and";
description "Type of Match (OR or AND)
applied to the descriptor-configurations";
} }
list action-reference-set { list descriptor-configuration {
key "action-order"; key "descriptor-template-key";
uses fpc:fpc-action-order; uses fpc:descriptor-template-key;
leaf action-id-reference { leaf direction {
type fpc:fpc-identity; type rfc5777:direction-type;
mandatory true; description "Direction";
description "Action Identifier Reference"; }
} list attribute-expression {
description "A set of Action references"; key index;
uses fpc:index;
uses fpcbase:fpc-descriptor-value;
description "Descriptor Attributes";
}
description "A set of Descriptor references";
} }
description list action-configuration {
"Rule.Definition"; key "action-order";
} leaf action-order {
// Policy Structures type uint32;
grouping fpc-precedence { mandatory true;
leaf precedence { description "Action Execution Order";
type uint32; }
mandatory true; uses fpc:action-template-key;
description "Rule Precedence"; list attribute-expression {
} key index;
description "FPC Rule Precedence"; uses fpc:index;
} uses fpcbase:fpc-action-value;
grouping policy { description "Action Attributes";
leaf policy-id { }
type fpc:fpc-identity; description "A set of Action references";
description "Policy Identifier";
} }
list rule-set { uses fpc:templatedef;
uses fpc:policy-configuration;
description "Rule Template";
}
list policy-template {
key policy-template-key;
uses fpc:policy-template-key;
list rule-template {
key "precedence"; key "precedence";
unique "rule-id-reference"; unique "rule-template-key";
uses fpc:fpc-precedence; leaf precedence {
leaf rule-id-reference { type uint32;
type fpc:fpc-identity;
mandatory true; mandatory true;
description "Rule Identifier"; description "Rule Precedence";
} }
uses fpc:rule-template-key;
description "Rule Entry"; description "Rule Entry";
} }
description "FPC Policy"; uses fpc:templatedef;
} uses fpc:policy-configuration;
// FPC Policy description "Policy Template";
grouping fpc-policy { }
list action-definition-set { description "FPC Policy Structures";
key action-id;
uses fpc:action-definition;
description "List of Actions";
}
list descriptor-definition-set {
key descriptor-id;
uses fpc:descriptor-definition;
description "List of Descriptors";
}
list rule-definition-set {
key rule-id;
uses fpc:rule-definition;
description "List of Rules";
} }
list policy-definition-set {
key policy-id; // Topology Information Model
uses fpc:policy; identity role {
description "List of Policies"; description "Role";
} }
description "FPC Policy Structures"; grouping dpn-key {
} leaf dpn-key {
// Mobility Structures type fpc:fpc-identity;
grouping configurable-policy-set { description "DPN Key";
list installed-policy-list {
key dpn-id-reference;
leaf dpn-id-reference {
type fpc:fpc-identity;
description "Installed Policy identifier";
}
list installed-policy-set {
key installed-policy-id;
leaf installed-policy-id {
type fpc:fpc-identity;
description "Installed Policy Identifier";
} }
leaf policy-id-reference { description "DPN Key";
type fpc:fpc-identity; }
description "Installed Policy Identifier"; grouping role-key {
leaf role-key {
type identityref {
base "fpc:role";
}
mandatory true;
description "Access Technology Role";
} }
container policy-settings { description "Access Technology Role key";
uses fpcbase:fpc-settings; }
description "Policy Settings"; grouping interface-key {
leaf interface-key{
type fpc:fpc-identity;
mandatory true;
description "interface identifier";
} }
description "Policy installed upon a DPN"; description "Interface Identifier key";
}
description "Configurable Policy";
uses fpc:settings;
} }
description "List of installed DPN policies and settings"; identity interface-protocols {
description "Protocol supported by the interface";
}
identity features {
description "Protocol features";
}
// Settings
grouping interface-settings {
list interface-settings {
key policy-template-key;
uses fpc:policy-template-key;
uses fpc:policy-configuration;
description "Interface settings";
}
description "Generic interface settings container";
} }
// Dynamic Policy
grouping mobility-context { // Mobility Context
leaf mobility-context-id { grouping mobility-context {
leaf mobility-context-key {
type fpc:fpc-identity; type fpc:fpc-identity;
mandatory true; mandatory true;
description "Mobility Context Identifier"; description "Mobility Context Key";
} }
leaf dpn-group-id-reference { leaf-list delegating-ip-prefix {
type fpc:fpc-identity; type inet:ip-prefix;
description "Group ID used when DPN selecitons were description "IP Prefix";
made";
} }
leaf parent-mobility-context-id-reference { leaf parent-context {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Parent Mobility Context"; description "Parent Mobility Context";
} }
list dpn-reference-list { leaf-list child-context {
key "dpn-id-reference direction";
leaf dpn-id-reference {
type fpc:fpc-identity; type fpc:fpc-identity;
mandatory true; description "Child Mobility Context";
description "DPN Id reference"; }
} container mobile-node {
leaf direction { leaf-list ip-address {
type fpc:fpc-direction-type; type inet:ip-address;
mandatory true; description "IP Address";
description "Direction of DPN assignment";
}
container dpn-settings-complementary {
uses fpcbase:fpc-settings;
description "Complentary Settings";
}
leaf interface-id-reference {
type fpc:fpc-interface-id;
mandatory true;
description "referenced interface";
}
list embedded-rule-set {
key "precedence";
unique "rule-id";
uses fpc:fpc-rule-id;
uses fpc:match-type;
uses fpc:fpc-precedence;
list action-definition-set {
key "action-order";
uses fpc:fpc-action-order;
uses fpc:action-definition;
description "List of Actions";
} }
list descriptor-definition-set { leaf imsi {
key descriptor-id; type fpcbase:imsi-type;
uses fpc:descriptor-definition; description "IMSI";
description "List of Descriptors";
} }
description "List of FPC Embedded Rule Definitions"; list mn-settings {
} key policy-template-key;
leaf-list assigned-policy-reference-set { uses fpc:policy-template-key;
type fpc:fpc-identity; uses fpc:policy-configuration;
description "List of Policies request to be enforced for description "MN Policy Cofiguration";
this Mobility Context"; }
} description "Mobile Node";
description "DPN List";
} }
container domain {
leaf-list requested-policy-reference-set { leaf domain-key {
type fpc:fpc-identity; type fpc:fpc-identity;
description "List of Policies request to be enforced for description "Domain Key";
this Mobility Context"; }
list domain-settings {
key policy-template-key;
uses fpc:policy-template-key;
uses fpc:policy-configuration;
description "MN Policy Cofiguration";
}
description "Domain";
} }
container context-settings-complementary { list dpn {
uses fpcbase:fpc-settings; key dpn-key;
description "Context Settings"; uses fpc:dpn-key;
list dpn-settings {
key policy-template-key;
uses fpc:policy-template-key;
uses fpc:policy-configuration;
description "DPN Policy Cofiguration";
}
leaf role {
type identityref {
base "fpc:role";
}
description "Role";
}
list service-data-flow {
key identifier;
leaf identifier {
type uint32;
description "Generic Identifier";
}
leaf service-group-key {
type fpc:fpc-identity;
description "Service Group Key";
}
list interface {
key interface-key;
uses fpc:interface-key;
description "interface assigned";
}
list flow-settings {
key policy-template-key;
uses fpc:policy-template-key;
uses fpc:policy-configuration;
description "Flow Policy Cofiguration";
}
description "Service Dataflow";
}
description "DPN";
} }
description "Mobility Context"; description "Mobility Context";
} }
// Events, Probes & Notifications
// Events, Probes & Notifications
identity event-type { identity event-type {
description "Base Event Type"; description "Base Event Type";
} }
typedef event-type-id { typedef event-type-id {
type uint32; type uint32;
description "Event ID Type"; description "Event ID Type";
} }
grouping monitor-id { grouping monitor-key {
leaf monitor-id { leaf monitor-key {
type fpc:fpc-identity; type fpc:fpc-identity;
mandatory true; mandatory true;
description "Monitor Identifier"; description "Monitor Key";
} }
description "Monitor Id"; description "Monitor Id";
} }
grouping monitor-config { grouping target-value {
uses fpc:monitor-id; leaf target {
type string;
description "target";
}
description "Target Value";
}
grouping monitor-config {
uses fpc:templatedef;
uses fpc:monitor-key;
uses fpc:target-value;
container binding-information {
description "Placeholder for information helpful
to binding the monitor ot the correct target";
}
leaf deterrable { leaf deterrable {
type boolean; type boolean;
description "Indicates reports related to this description "Indicates reports related to this
config can be delayed."; config can be delayed.";
} }
container binding-information {
description "Placeholder for information helpful
to binding the monitor ot the correct target";
}
uses fpc:target-value;
choice configuration { choice configuration {
mandatory true; mandatory true;
case periodic-config { leaf period {
leaf period {
type uint32; type uint32;
description "Period"; description "Period";
}
description "Periodic Config Case";
} }
case threshold-config { case threshold-config {
leaf lo-thresh { leaf low {
type uint32; type uint32;
description "lo threshold"; description "low threshold";
} }
leaf hi-thresh { leaf hi {
type uint32; type uint32;
description "hi threshold"; description "high threshold";
} }
description "Threshold Config Case"; description "Threshold Config Case";
} }
case scheduled-config { leaf schedule {
leaf report-time {
type uint32; type uint32;
description "Reporting Time"; description "Reporting Time";
}
description "Scheduled Config Case";
} }
case events-config-ident { leaf-list event-identities {
leaf-list event-identities {
type identityref { type identityref {
base "fpc:event-type"; base "fpc:event-type";
} }
description "Event Identities"; description "Event Identities";
}
description "Events Config Identities Case";
} }
case events-config { leaf-list event-ids {
leaf-list event-ids {
type uint32; type uint32;
description "Event IDs"; description "Event IDs";
}
description "Events Config Case";
} }
description "Event Config Value"; description "Event Config Value";
} }
description "Monitor Configuration"; description "Monitor Configuration";
} }
grouping report {
uses fpc:monitor-config; // Top Level Structures
choice report-value { list tenant {
leaf trigger { key "tenant-key";
type fpc:event-type-id; leaf tenant-key {
description "Trigger Identifier"; type fpc:fpc-identity;
description "Tenant Key";
}
container mobility-information-model {
list dpn {
key dpn-key;
uses fpc:dpn-key;
leaf dpn-name {
type string;
description "DPN name";
}
leaf dpn-resource-mapping-reference {
type string;
description "Reference to underlying
DPN resource(s)";
}
leaf-list domain-key {
type fpc:fpc-identity;
description "Domains";
}
leaf-list service-group-key {
type fpc:fpc-identity;
description "Service Group";
}
list interface {
key "interface-key";
uses fpc:interface-key;
leaf interface-name {
type string;
description "Interface Name";
} }
case simple-empty { leaf-list roles {
leaf nothing { type identityref {
type empty; base "fpc:role";
description "Empty Value"; }
description "Roles supported";
}
leaf-list protocol {
type identityref {
base "interface-protocols";
}
description "Supported protocols";
}
uses fpc:interface-settings;
description "DPN interfaces";
}
list dpn-settings {
key policy-template-key;
uses fpc:policy-template-key;
uses fpc:policy-configuration;
description "DPN Policy Configuration";
}
description "Set of DPNs";
}
description "Mobility Information Model";
}
container dpn-checkpoint {
uses fpc:basename-info;
description "DPN Checkpoint information";
}
list service-group {
key service-group-key;
leaf service-group-key {
type fpc:fpc-identity;
mandatory true;
description "Service Group Key";
}
leaf service-group-name {
type string;
description "Service Group Name";
}