draft-ietf-dmm-fpc-cpdp-03.txt   draft-ietf-dmm-fpc-cpdp-04.txt 
DMM Working Group M. Liebsch DMM Working Group S. Matsushima
Internet-Draft NEC Internet-Draft SoftBank
Intended status: Standards Track S. Matsushima Intended status: Standards Track L. Bertz
Expires: September 22, 2016 SoftBank Expires: April 2, 2017 Sprint
M. Liebsch
NEC
S. Gundavelli S. Gundavelli
Cisco Cisco
D. Moses D. Moses
Intel Corporation Intel Corporation
L. Bertz September 29, 2016
Sprint
March 21, 2016
Protocol for Forwarding Policy Configuration (FPC) in DMM Protocol for Forwarding Policy Configuration (FPC) in DMM
draft-ietf-dmm-fpc-cpdp-03.txt draft-ietf-dmm-fpc-cpdp-04.txt
Abstract Abstract
This specification supports the separation of the Control-Plane for This document describes the solution of data-plane separation from
mobility- and session management from the Data-Plane. The protocol control-plane which enables a flexible mobility management system
semantics abstract the configuration of Data-Plane nodes and applies using agent and client functions. To configure data-plane nodes and
it between a Client function, which is used by an application of the functions, the data-plane is abstracted by an agent interface to the
mobility Control-Plane, and an Agent function, which is associated client. The data-plane abstraction model is extensible in order to
with the configuration of Data-Plane nodes, according to the Data- support many different type of mobility management systems and data-
Plane rules issued by the mobility Control-Plane. The scope of the plane functions.
rules comprises traffic description and treatment of packets in terms
of encapsulation, IP address re-writing and QoS. Additional protocol
semantics are described to support the maintenance of the Data-Plane
path.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 22, 2016. This Internet-Draft will expire on April 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(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 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Reference Architecture and Deployment Options . . . . . . . . 4 3. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Architecture for DMM Forwarding Policy Configuration . . 4 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Role of the FPC Client Function . . . . . . . . . . . 7 4.1.1. Domains . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Role of the FPC Agent Function . . . . . . . . . . . 7 4.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 8
3.3. Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Role of the DMM FPC Client Function . . . . . . . . . 8 4.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Role of the DMM FPC Agent Function . . . . . . . . . 8 4.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 11
4. Protocol to support Model I . . . . . . . . . . . . . . . . . 9 4.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Protocol Attributes . . . . . . . . . . . . . . . . . . . 12 4.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 15
4.3. Protocol Messages and Semantics . . . . . . . . . . . . . 19 4.3. FPC-Mobility . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 20 4.3.1. Port . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol to support Model II . . . . . . . . . . . . . . . . 29 4.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Protocol Attributes . . . . . . . . . . . . . . . . . . . 29 4.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Protocol Messages and Semantics . . . . . . . . . . . . . 31 4.4. Namespace and Format . . . . . . . . . . . . . . . . . . 22
5.3. Protocol Operation . . . . . . . . . . . . . . . . . . . 33 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 5.1.1. CONF and CONF_BUNDLES Messages . . . . . . . . . . . 25
8. Work Team Participants . . . . . . . . . . . . . . . . . . . 34 5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 35 5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 33
Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 35 5.2.3. Optimization for Current and Subsequent Messages . . 35
A.1. FPC Base . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 40
A.1.1. FPC Base YANG Model . . . . . . . . . . . . . . . . . 36 6. Protocol Message Details . . . . . . . . . . . . . . . . . . 41
A.1.2. FPC Base tree . . . . . . . . . . . . . . . . . . . . 52 6.1. Data Structures And Type Assignment . . . . . . . . . . . 41
A.2. FPC PMIP . . . . . . . . . . . . . . . . . . . . . . . . 58 6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 41
A.2.1. FPC PMIP YANG Model . . . . . . . . . . . . . . . . . 58 6.1.2. Mobilty Structures . . . . . . . . . . . . . . . . . 43
A.2.2. FPC PMIP tree . . . . . . . . . . . . . . . . . . . . 61 6.1.3. Topology Structures . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 6.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 46
6.2. Message Attributes . . . . . . . . . . . . . . . . . . . 48
6.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2. CONF and CONF_BUNDLES Attributes and Notifications . 48
6.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 50
7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 51
7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 54
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 56
9. Security Considerations . . . . . . . . . . . . . . . . . . . 60
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
11. Work Team Participants . . . . . . . . . . . . . . . . . . . 60
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 62
A.1. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 62
A.1.1. FPC Base YANG Model . . . . . . . . . . . . . . . . . 62
A.1.2. FPC Agent YANG Model . . . . . . . . . . . . . . . . 73
A.1.3. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 85
A.1.4. Traffic Selectors YANG Model . . . . . . . . . . . . 97
A.1.5. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 107
A.1.6. FPC / PMIP Integration YANG Model . . . . . . . . . . 118
A.1.7. FPC Policy Extension YANG Model . . . . . . . . . . . 124
A.2. FPC Agent Information Model YANG Tree . . . . . . . . . . 126
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 130
1. Introduction 1. Introduction
One objective of the Distributed Mobility Management (DMM) WG is the This document describes Forwarding Policy Configuration (FPC), the
separation of the mobility management Control- and Data-Plane to solution of data-plane separation from control-plane which enables
enable flexible deployment, such as decentralized provisioning of flexible mobility management systems using agent and client
Data-Plane nodes (DPN). Data-Plane nodes can be configured to functions. To configure data-plane nodes and functions, the data-
function as an anchor for a registered Mobile Node's (MN) traffic, plane is abstracted in the agent which provides an interface to the
others can be configured to function as a Mobile Access Gateway (MAG) client.
per the Proxy Mobile IPv6 protocol [RFC5213] or a Foreign Agent (FA)
per the Mobile IPv4 protocol [RFC3344]. Requirements for DMM have
been described in [RFC7333], whereas best current practices for DMM
are documented in [RFC7429].
The Data-Plane must provide a set of functions to the Mobility Control planes of mobility management systems, and/or any
Control-Plane, such as support for encapsulation, IP address re- applications which require data-plane control, can utilize the FPC
writing, QoS differentiation and traffic shaping. In addition, means Client in flexible granularities of operation. The configuration
for traffic description must be provided to complement traffic operations are capable of configuring not only single Data-Plane Node
treatment actions and build unambiguous Data-plane rules. These (DPN) directly, but also multiple DPNs from abstracted data-plane
requirements are met by various transport network components, such as models on the FPC agent.
IP switches and routers, though configuration semantics differ
between them.
Forwarding Policy Configuration (FPC) per this document enables the FPC agent provides the data-plane abstraction models in the following
configuration of any Data-Plane node and type by the abstraction of three areas:
configuration details and the use of common configuration semantics.
The protocol using the FPC semantics is deployed between a Client
function, which is associated with the Mobility Management Control-
Plane, and an Agent function. The Agent function enforces the Data-
Plane configuration and can be present on a transport network
controller or co-located with a Data-Plane node. The Agent applies
the generalized configuration semantics to configuration, which is
specific to the Data-Plane node and type.
This specification follows a common functional architecture, which Topology: DPNs are grouped and abstracted in terms of roles of
utilizes the FPC protocol between the Client and Agent functions, and mobility management such as access, anchors and domains. FPC
supports two operational models, Model I and Model II. Agent abstracts DPN-groups and consists of forwarding plane
topology, such as access nodes assigned to a DPN-group which peers
to a DPN-group of anchor nodes.
A Client supporting Model I interacts with the Agent to build Policy: Policy abstracts policies which handle specific traffic
unambiguous rules which are to be enforced in the Data-Plane. An flows or packets such as QoS, packet processing to rewrite
Agent supporting Model I translates a rule, which follows the data headers, etc. A policy consists of one or multiple rules which
model herein, into one or multiple configuration actions to enforce are composed of Descriptors and Actions. Descriptors in a rule
the rule in the Data-Plane. identify traffic flows and Actions apply treatments to packets
matched to the Descriptors in the rule. An arbitrary set of
policies is abstracted as a Policy-group which is applied to
Ports.
A Client supporting Model II utilizes a sequence of control messages Mobility: An endpoint of a mobility session is abstracted as a
to interact with the Agent, where each control message has an Context with its associated runtime concrete attributes, such as
unambiguous semantic, e.g. to set up a tunnel interface or to tunnel endpoints, tunnel identifiers, delegated prefix(es),
configure a policy route in a Data-Plane node. An Agent supporting routing information, etc. Contexts are attached to DPN-groups
Model II performs a configuration action per the semantics of the along with consequence of the control plane. One or multiple
received control message. Contexts which have same sets of policies are assigned Ports which
abstract those policiy sets. A Context can belong to multiple
Ports which serve different kinds of purpose and policy. Monitors
aprovide a mechanism to produce reports when events regarding
Ports, Sessions, DPNs or the Agent occurs.
The availability of both operational models enables tailored The Agent collects applicable sets of forwarding policies for the
implementation and deployment of Control-/Data-Plane separation in mobility sessions from the data model, and then renders those
mobile communication gateways, e.g. by having the Mobility Control- policies into specific configurations for each DPN to which the
Plane directly communicating to a Data-Plane node as per Model II, or sessions attached. Specific protocols and configurations to
per Model I by the deployment of a Network Controller in between the configure DPN from FPC Agent are out of scope of this document.
Mobility Control-Plane and Data-Plane nodes, which are under control
of the Network Controller. Support for both the models enables an
operator to transition their network in incremental phases.
The architecture and reference interface specified in this document The data-plane abstraction model is extensible in order to support
is not tied to any specific Control-Plane protocol that is in use in many different types of mobility management systems and data-plane
the mobility network, or to any type of access technology. The functions. The architecture and protocol design of FPC intends not
mobility protocols in use can be Proxy Mobile IPv6, GTP, IPSec or to tie to specific types of access technologies and mobility
other protocols; and the access network can be 4G LTE, WiFi, or 5G. protocols.
These aspects have no direct implication on the FPC interface that is
between Control- and Data-Plane nodes.
2. Conventions and Terminology 2. Conventions and 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].
3. Reference Architecture and Deployment Options 3. FPC Architecture
3.1. Architecture for DMM Forwarding Policy Configuration In accordance with the requirements of flexible data-plane functions
deployment described in [RFC7333], FPC provides a means for mobility
control-plane and applications to handle DPNs that must be configured
with various roles of the mobility management aspect described in
[I-D.ietf-dmm-deployment-models].
The DMM Forwarding Policy Configuration (FPC) protocol enables the FPC uses building blocks of Agent, Client and data-plane abstraction
separation of the mobility management Control-Plane from the Data- models as the interface between the agent and the client.
Plane and provides the required control and semantics in between
these two planes. Figure 1 depicts an exemplary use case where IP
traffic between a Correspondent Node (CN) and a Mobile Node (MN)
traverses multiple DPNs, each applying policies as per the Control-
Plane's request. Policies in the one or multiple DPNs can result in
traffic steering according to a host-route, packet scheduling and
marking according to a subscriber's QoS profile, or forwarding rules
(e.g. encapsulation within GRE or GTP-U tunnel).
+--------------------------+ Mobility control-plane and applications integrate the FPC Client
| Mobility Control | function and connect to FPC Agent functions. The Client and the
+--------------------------+ Agent communicate based on data-plane abstraction models described in
| | | Section 4. Along with models, the control-plane and the applications
| | | put forwarding policies for their mobility sessions on the Agent.
| | |
\ / V V V
+--+ -o- +---+ +---+ +---+ +--+
|MN| ---- |---|DPN|<========|DPN|<----|DPN|<--|CN|
+--+ | +---+ +---+ +---+ +--+
Rules: Rules: Rules:
Encap,Decap, Encap,Decap Policy-Route,
Forward,QoS Forward,QoS Forward
Figure 1: Exemplary illustration of DMM traffic steering and policy The Agent connects to DPN(s) to manage their configuration. These
enforcement at Data Plane Nodes (DPN) configurations are rendered from the forwarding policies by the
Agent. FPC Agent may be implemented in a network controller that
handles multiple DPNs or it also may be integrated into a DPN.
Mobility Control-Plane functions have the following roles in common: The FPC architecture supports multi-tenancy where the FPC enabled
data-plane supports multiple tenants of mobile operator networks and/
or applications. DPNs on the data-plane run in multiple data-plane
roles which are defined per session, domain and tenant.
o Tracking a mobile node's attachment, detachment from the access This architecture is illustrated in Figure 1. This document does not
network adopt a specific protocol for the FPC envelope protocol and it is out
of scope. However it must be capable of supporting FPC protocol
messages and transactions described in Section 5.
o Accept requests to set up and maintain mobility-related Data-Plane +-------------------------+
paths between DPNs, enforcing QoS and forwarding policies. Such | Mobility Control-Plane |
requests are a result of mobility signaling between different | and |
Mobility Control-Plane functions. | Applications |
|+-----------------------+|
|| FPC Client ||
|+----------^------------+|
+-----------|-------------+
FPC envelope protocol |
+---------------+-----------------+
| |
Network | |
Controller | DPN |
+-----------|-------------+ +----------|---------+
|+----------v------------+| |+---------v--------+|
|| [Data-plane model] || ||[Data-plane model]||
|| FPC Agent || || FPC Agent ||
|+-----------------------+| |+------------------+|
|+------------+----------+| | |
||SB Protocols|FPC Client|| | DPN Configuration |
|| Modules | Module || +--------------------+
|+------^-----+----^-----+|
+-------|----------|------+
| |
Other | | FPC envelope
Southband | | Protocol
Protocols | |
| +-----------------+
| |
DPN | DPN |
+----------|---------+ +----------|---------+
|+---------v--------+| |+---------v--------+|
|| Configuration || ||[Data-plane model]||
|| Protocol module || || FPC Agent ||
|+------------------+| |+------------------+|
| | | |
| DPN Configuration | | DPN Configuration |
+--------------------+ +--------------------+
o Ensure that required rules to establish and maintain connectivity Figure 1: Reference Forwarding Policy Configuration (FPC)
of an MN with its correspondent nodes are enforced in the Data- Architecture
Plane.
o Participate in monitoring the DPNs' operation and support the Note that the FPC envelope protocol is only required to handle
handling of exceptions, e.g. the detection of a partial DPN runtime data in the Mobility model. The rest of the FPC models,
failure and the diversion of traffic through a different DPN. namely Topology and Policy, are pre-configured, therefore real-time
data handling capabilities are not required for them. Operators that
are tenants in the FPC data-plane can configure Toplogy and Policy on
the Agent through other means, such as Restconf
[I-D.ietf-netconf-restconf] or Netconf [RFC6241].
o Maintain consistency between multiple DPNs which enforce policy 4. Information Model
rules to ensure connectivity between a MN and its correspondent
services.
Mobility Data-Plane functions have the following roles in common: This section describes information model that represents the concept
of FPC which is language and protocol neutral. Figure 2 is an
overview of FPC data-plane abstraction model.
o Forward and treat traffic according to the policies and directives (Mobile operator tenant that abstracted data-plane is used)
sent by the Mobility Control-Plane |
+---FPC-Topology
| |
| +---Domains
| |
| +---DPN-groups
| |
| +---DPNs
|
+---FPC-Policy
| |
| +---Descriptors
| |
| +---Actions
| |
| +---Policies
| |
| +---Policy-groups
|
+---FPC-Mobility
|
+---Ports
|
+---Contexts
o Provide status information (e.g. load, health, statistics and Figure 2: FPC Data-plane Abstraction Model
traffic volume) and events related to service failure upon request
o Participate in the process of topology acquisition, e.g. by 4.1. FPC-Topology
exposing relevant topological and capability information, such as
support for QoS differentiation and supported encapsulation
protocols
The protocol for DMM FPC applies to the interface between a FPC Topology abstraction enables an actual data-plane network to support
Client function and a FPC Agent function, as depicted in Figure 2. multiple mobile operator's topologies of their data-plane. The FPC-
The FPC Client function is associated with an application function of Topology consists of DPNs, DPN-groups and Domains which abstract
the mobility management Control-Plane, e.g. a Local Mobility Anchor data-plane topologies for the Client's mobility control-planes and
Control-Plane function per the Proxy Mobile IPv6 protocol. The FPC applications.
Agent function processes the FPC protocol semantics and translates
them into configuration commands per the DPN's technology. In one
example, an FPC Agent can be co-located with a Network Controller,
which enforces forwarding rules on a set of Data-plane nodes. In
another example, the Agent can be co-located with a Data-Plane node
to directly interact with interface management and the router's RIB
Manager. The mapping of the common FPC semantics and policy
description to the configuration commands of a particular DPN is
specific to the DPN's technology and the Agent's implementation.
+-------------------------+ A mobile operator who utilizes a FPC enabled data-plane network can
| Mobility Control-Plane | virtually create their DPNs along with their data-plane design on the
| | Agent. The operator also creates a DPN-group of which the DPNs are
|+--------[API]----------+| attributed roles of mobility management such as access, anchors and
|| FPC Client Function || domains.
|+----------^------------+|
+-----------|-------------+
|
| DMM FPC protocol
|
+-----------|-------------+
|+----------v------------+|
|| FPC Agent Function ||
|+-----------------------+|
| |
| DPN Configuration API |
+-------------------------+
Figure 2: Functional reference architecture for DMM Forwarding Policy 4.1.1. Domains
Configuration (FPC)
3.2. Model 1 A domain is defined by the operators to attribute DPN-groups to the
3.2.1. Role of the FPC Client Function domain. Domains may represent services or applications within the
operator.
The FPC Client function, which follows Model I operation, includes (FPC-Topology)
the following tasks: |
+---Domains
|
+---Domain-id
|
+---Domain-name
|
+---Domain-type
o Build one or multiple FPC Control messages/attributes to Figure 3: Domain Model Structure
establish, update or delete rules on one or multiple DPN(s)
according to the Mobility Control-Plane's directives
o Apply a DPN's policy rules (encapsulation, address re-write, QoS, Domain-id: Identifier of Domain. The ID format SHOULD refer to
traffic monitoring) on the basis of properties bound to logical Section 4.4.
ports (similar to the bearer concept in cellular networks)
o Build, modify or delete logical ports as needed Domain-name: Defines Domain name.
o Bind associated policy rules as one or multiple properties to a Domain-type: Specifies which type of communication allowed within
logical port the domain, such as ipv4, ipv6, ipv4v6 or ieee802.
o Apply traffic forwarding rules (e.g. per-IP flow, per-MN, per-IP, 4.1.2. DPN-groups
per-prefix) on the basis traffic descriptions bound to logical
ports
o Send each generated FPC control message to the FPC Agent A DPN-group defines a set of DPNs which share common data-plane
attributes. DPN-groups consist data-plane topology that consists of
a DPN-group of access nodes connecting to an anchor nodes DPN-group.
o Keep record of the configured policy rules and interact with the DPN Group has attributes such as the data-plane role, supported
FPC Agent to ensure proper synchronization between Mobility access technologies, mobility profiles, connected peer groups and
Control-Plane states and rules configured on the FPC Agent domain.
o Process received Response, Notification and Query messages issued (FPC-Topology)
by a FPC Agent and interact with the Control-Plane to act |
accordingly +---DPN-groups
|
+---DPN-group-id
|
+---Data-plane-role
|
+---Domains
|
+---Access-type
|
+---Mobility-profile
|
+---DPN-group-peers
3.2.2. Role of the FPC Agent Function Figure 4: DPN-groups Model Structure
The FPC Agent function, which follows Model I operation, includes the DPN-group-id: Defines identifier of DPN-group. The ID format SHOULD
following tasks: refer to Section 4.4.
o Process received Control messages issued by a FPC Client Function Data-plane-role: Defines data-plane role of the DPN-group, such as
access-dpn, L2/L3 or anchor-dpn.
o Apply received rules to local configuration (e.g. encapsulation, Domains: Specifies domains which the DPN-group belongs to.
NA(P)T, traffic prioritization and scheduling) in the Data-Plane
o Maintain administrative data as well as operational data, which Access-type: Defines access type which the DPN-group supports such
describes the status of the rules in the Data-Plane as ethernet(802.3/11), 3gpp cellular(S1, RAB), if any.
o Monitor events (e.g. failure, incomplete rule) and issue an Mobility-profile: Defines supported mobility profile, such as ietf-
associated message to the FPC Client Function (NOTIFICATION, pmip, 3gpp, or new profiles defined as extensions of this
QUERY) specification. When those profiles are correctly defined, some
or all data-plane parameters of contexts can be automatically
derived from this profile by FPC Agent.
3.3. Model 2 DPN-group-peers: Defines remote peers of DPN-group with parameters
described in Section 4.1.2.1.
3.3.1. Role of the DMM FPC Client Function 4.1.2.1. DPN-group Peers
The FPC Client function, which follows Model II operation, includes DPN-group-peers defines parameters of remote peer DPNs as illustrated
the following tasks: in Figure 5.
o The FPC Client offers a set of services to the mobility control (DPN-groups)
plane entities. These services are for activating/deactivating |
specific configuration on a Data-Plane node supported by a FPC +---DPN-group-peers
Agent. These services for example are creation/deletion of a |
layer-3 tunnel; adding/deleting an IP route; +---Remote-DPN-group-id
|
+---Remote-mobility-profile
|
+---Remote-data-plane-role
|
+---Remote-endpoint-address
|
+---Local-endpoint-address
|
+---Tunnel-MTU-size
o The FPC Client translates the request from the mobile control Figure 5: DPN-groups Peer Model Structure
plane as a FPC message. The message identifies the service name
and includes a set of information elements. This message is sent
to the FPC Agent over the FPC interface.
3.3.2. Role of the DMM FPC Agent Function Remote-DPN-group-id: Indicates peering DPN-Group.
The FPC Agent function, which follows Model II operation, includes Remote-mobility-profile: Defines mobility-profile used for this
the following tasks: peer, currently defined profiles are ietf-pmip, 3gpp, or new
profiles defined as extensions of this specification.
o FPC Agent offers a set of services to the FPC client. Each of Remote-data-plane-role: Defines forwarding-plane role of peering
these services have a well-defined meaning and can be invoked by DPN-group.
the FPC Client passing a set of parameters. These services for
example are creation/deletion of a layer-3 tunnel; adding/deleting
an IP route.
o Any FPC Client can invoke a specific service on the FPC Agent Remote-endpoint-address: Defines Endpoint address of the peering
through the use of FPC messaging interface. The interface DPN-group.
semantics allow the identification of the service request and for
inclusion of the parameters relevant for that service request.
o FPC Agent processes a FPC message and identifies the service Local-endpoint-address: Defines Endpoint address of its own DPN-
request. The FPC Agent maps the service request to a local group to peer the remote DPN-group.
configuration and enables that configuration in the forwarding
plane. For example, if there is a service request for Tunnel
creation including the relevant parameters such as source IP
address, destination IP address and encapsulation type, this
request will result in the FPC Agent configuring such tunnel
configuration on the Data-Plane node.
o The FPC Agent provides a resulting status code on how the request Tunnel-MTU-size: Defines MTU size of tunnel.
was executed by the agent.
4. Protocol to support Model I 4.1.3. DPNs
4.1. Data Structure List of DPNs which defines all available nodes for a tenant of the
FPC data-plane network. Role of a DPN in the data-plane is not
determined until the DPN is attributed to a DPN-group.
To abstract from configuration details of an IP switch or IP router A DPN may have multiple DPN-groups which are in different data-plane
on the FPC protocol interface, Model I adopts the construct of roles or domains. Mobility sessions of that DPN-groups are installed
logical ports to describe rules for D-Plane processing. A port binds into actual data-plane nodes. The Agent defines DPN binding to
one or multiple properties, which describe traffic treatment actions, actual nodes.
such as a QoS policy, IP address re-write or packet encapsulation.
Which traffic is treated is determined by one or multiple traffic
descriptors, which also bind to that port. A group of one or
multiple traffic descriptors, one or multiple properties defining
traffic treatment actions and the port identifier make a rule. The
port identifier serves as key to access the rule.
All traffic arriving at a Data-Plane node and matching a traffic (FPC-Topology)
descriptor will be treated per the properties bound to the port the |
traffic descriptor is also bound to. For example, Traffic Selectors +---DPNs
[RFC6088], which can be bound to a port, can identify single or |
multiple IP flows. Aggregated IP traffic destined toward a given IP +---DPN-id
address prefix or originated from an address matching a particular IP |
address range can be described using the Traffic Selector or an IP +---DPN-name
prefix traffic descriptor per this specification. |
+---DPN-groups
|
+---Node-reference
In addition to traffic descriptors and traffic treatment actions, Figure 6: DPNs Model Structure
which build a Data-Plane processing rule, a port has associated
operational data, which tracks the status of rule enforcement in a
selected Data-Plane node. A rule can also have administrative data
such as its directionality (uni- or bi-directional) and
administrative status such as enabled, disabled or virtual.
Furthermore, an identifier of the Data-Plane node to which the rule
applies is kept in the operational data associated with a port.
When the Client desires specific operational state for the port, it DPN-id: Defines identifier of DPN. The ID format SHOULD refer to
may apply administrative state properties to the port. This, Section 4.4.
however, may not take immediate effect on the Data-Plane Node. Thus,
Client implementations must support situations where differences
exist between configured and operational state of a port. A Client
can request operational data associated with a particular port from
an Agent.
A Client adds, modifies or deletes a rule on an Agent using the FPC DPN-name: Defines name of DPN.
protocol messages. The protocol enables a Client to provide
additional administrative information about a particular port or a
group of ports to the Agent. This includes control of the operation
of a rule, e.g. whether a rule associated with a particular port
applies only uni-directionally or bi-directionally. In case of bi-
directionality, an Agent can apply a rule associated with a single
port in the Data-Plane to both directions. As example, a rule which
performs re-writing of an arriving packet's destination IP address
from IP_A to IP_B matching an associated Traffic Selector, can be
enforced in the Data-Plane via an Agent to implicitly consider
matching arriving packet's source IP address against IP_B and re-
write the source IP address to IP_A.
Figure 3 illustrates the generic policy configuration model as used DPN-groups: List of DPN-group which the DPN belongs to.
between a FPC Client and a FPC Agent.
TrafficDescriptor_1-+ +--Property_1 Node-reference: Indicates an actual node to which the Agent binds
| | the DPN. The Agent SHOULD maintain that nodes information
TrafficDescriptor_2-+---<PORT#>---+--Property_2 including IP address of management and control protocol to
: | +--------+| connect them.
: : /Adm Data/ +--Property_3
: | +--------+ : :
TrafficDescriptor_M-+ +-------+ +--Property_N
/OP Data/
+-------+
+-------------------+ +---------------------+
| Bind 1..M traffic | | Bind 1..N traffic |
| templates to | --------> | treatment actions |
| a port | | to a port |
+-------------------+ +---------------------+
| | 4.2. FPC-Policy
+------------------ Data-Plane Rule --------------------+
Figure 3: Structure of rules on Client/Agent defining Data-Plane The FPC-Policy consists of Descriptors, Actions, Policies and Policy-
traffic treatment groups, which can be viewed as configuration data while Contexts and
Ports are akin to structures that are instantiated on the Agent. The
Descriptors and Actions in a Policy referenced by a Port are active
when the Port is in a active Context, i.e. they can be applied to
traffic on a DPN.
As depicted in Figure 3, the port represents the anchor of a rule. A 4.2.1. Descriptors
Client and Agent use the identifier of a port to access the rule and
perform modifications of traffic descriptors or properties. From the
viewpoint of packet processing, arriving packets are matched against
traffic descriptors and processed according to the treatment actions
specified in the list of properties associated with the port.
A Client can assign an existing or new port to a group of ports using List of Descriptors which defines classifiers of specific traffic
a port group identifier. The logic behind grouping multiple ports is flow, such as those based on source and destination addresses,
up to the Control-Plane. As example, multiple rules associated with protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet. Note
a single mobile node can be grouped and identified by the port group that Descriptors are extensibly defined by specific profiles which
identifier. In case the Control-Plane needs to delete all rules 3gpp, ietf or other SDOs produce. Many specifications also use the
associated with the mobile node, the Client can issue a message to terms Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A
delete a port one and identify the group group identifier instead of packet that meets the criteria of a Descriptor is said to satisfy,
deleting each port individually. A Client can also apply pass or is consumed by the Descriptor. Descriptors are assigned an
administrative properties to a group of ports by adding the port identifier and contain a type and value.
group ID to the FPC message.
A Client can complement a traffic descriptor with a match priority (FPC-Policy)
value to allow unambiguous traffic matching on the Data-Plane. If |
the Client does not provide a match priority value with a traffic +---Descriptors
descriptor or a group of traffic descriptors have the same priority |
value, an Agent enforces the rule in the Data-Plane node to enable +---Descriptor-id
traffic detection by longest prefix match. |
+---Descriptor-type
|
+---Descriptor-value
Operational information of a port includes the data listed in the Figure 7: Descriptor Model Structure
following table:
+---------------------------------------------------------------------+ Descriptor-id: Identifier of Descriptor. The ID format SHOULD refer
| Admin Data | Format Clarification | Description | to Section 4.4.
+=====================================================================+
| DPN_ID | Sect. 4.2 | Identifies a Data-Plane node|
| | | to which the rule applies |
+---------------------------------------------------------------------+
| PRT_BIDIR | BOOLEAN | Bidirectionality of a port |
| | | (cleared = unidirectional) |
+----------------+----------------------+-----------------------------+
| ADMIN_STATUS | [8, admin status] | Requested status for a rule |
| | | in a Data-Plane node |
| | | (enabled, disabled, virtual)|
+---------------------------------------------------------------------+
| SESSION_STATUS | [8, session status] | Status of a session in the |
| | | Control-Plane (complete, |
| | | incomplete, outdated) |
+---------------------------------------------------------------------+
| PRT_GROUP_ID | [32, group id] | Identifies a group of ports |
| | | to which this port belongs |
+---------------------------------------------------------------------+
| CLI_ID | Sect. 4.2 | Identifies the Client which |
| | | created this port |
+---------------------------------------------------------------------+
| AGT_ID | Sect. 4.2 | Identifies the Agent which |
| | | enforces the rule as per |
| | | this port |
+---------------------------------------------------------------------+
Figure 4: Administrative Data associated with a port Descriptor-type: Defines descriptor type, which classifies specific
traffic flow, such as source and destination addresses,
protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet.
+---------------------------------------------------------------------+ Descriptor-value: Specifies the value of Descriptor such as IP
|Operational Data| Format Clarification | Description | prefix/address, protocol number, port number, etc.
+=====================================================================+
| OPER_STATUS | [8, oper status] | Status of a rule in a |
| | | Data-Plane node (enabled, |
| | | disabled, virtual) |
+---------------------------------------------------------------------+
| SERVICE_STATUS | [8, service status] | Ability of an enabled rule |
| | | to serve traffic (complete, |
| | | incomplete, outdated) |
+---------------------------------------------------------------------+
Figure 5: Operational Data associated with a port 4.2.2. Actions
A Client MAY apply an administrative state property to a port List of Actions which defines treatment/actions to apply to
indicating the desired operational status of a port, e.g. enabled, classified traffic meeting the criteria defined by Descriptors.
disabled or virtual (not intended to serve traffic but used as a Actions include traffic management related activity such as shaping,
template for other ports). Rules specified by an enabled port are policing based on given bandwidth, and connectivity management
enforced in the Data-Plane node. A disabled port on an Agent can be actions such as pass, drop, forward to given nexthop. Note that
useful for pre-configuration, e.g. other operations can be performed Actions are extensibly defined by specific profiles which 3gpp, ietf
on the port prior to its enablement. Ultimately, a disabled port is or other SDOs produce.
intended to be enabled. Virtual ports can serve as a reference to
clone new ports, which can then be enabled. When creating a cloned
port, the Client can update or add properties to suit the rule that
should be enforced in the Data-Plane.
A Client MAY set a Session state for a particular port or group of (FPC-Policy)
ports on the Agent to guide the Agent on how to treat local events. |
As example, an Agent SHOULD refrain from sending an FPC message to +---Actions
the Client as result of a local event, which indicates a missing |
rule, in case the session state is 'incomplete', as the Agent can +---Action-id
expect the Control-Plane to provide the missing rule unsolicited. In |
case the session state is 'outdated', the Agent MAY notify the Client +---Action-type
to update the associated rule on the Agent. |
+---Action-value
4.2. Protocol Attributes Figure 8: Action Model Structure
Protocol messages as per Section 4.3 identify an FPC Client or Agent Action-id: Identifier of Action. The ID format SHOULD refer to
function, as well as a DPN, and carry traffic descriptor attributes, Section 4.4.
logical port identification and properties specifying traffic
treatment actions. Traffic can be described per-host, in aggregate
or per-IP flow. A Client MAY append administrative properties to a
message to indicate the desired status of a port to the Agent.
This document specifies attributes from the following categories: Action-type: Defines action type, i.e. how to treat the specified
traffic flow, e.g. pass, drop, forward to given nexthop value and
shape, police based on given bandwidth value, etc.
o Identifier attributes Action-value: Specifies value of Action, such as bandwidth, nexthop
o Traffic Descriptors address or drop explicitly, etc.
o Properties specifying traffic treatment actions 4.2.3. Policies
o Protocol-specific Properties Policies are collections of Rules. Each Policy has a Policy
Identifier and a list of Rule/Order pairs. The Order and Rule values
MUST be unique in the Policy. Unlike the AND filter matching of each
Rule the Policy uses an OR matching to find the first Rule whose
Descriptors are satisfied by the packet. The search for a Rule to
apply to packet is executed according to the unique Order values of
the Rules. This is an ascending order search, i.e. the Rule with the
lowest Order value is tested first and if its Descriptors are not
satisfied by the packet the Rule with the next lowest Order value is
tested. If a Rule is not found then the Policy does not apply.
Policies contain Rules as opposed to references to Rules.
o Administrative properties (FPC-Policy)
|
+---Policies
|
+---Policy-id
|
+---Rules
|
+---Order
|
+---Descriptors
| |
| +---Descriptor-id
| |
| +---Direction
|
+---Actions
|
+---Action-id
|
+---Order
+---------------------------------------------------------------------+ Figure 9: Policies Model Structure
| Attribute | Format Clarification | Description |
+=====================================================================+
| Identifiers |
+---------------------------------------------------------------------+
| PRT_ID | [32,PRT_ID] | Identifies a logical Port |
+---------------------------------------------------------------------+
| PRT_GROUP_ID | [32,PRT_GROUP_ID] | Identifies a group of |
| | | logical Ports |
+---------------------------------------------------------------------+
| PRT_PROP_ID | [32,PRT_ID] | Identifies a logical Port |
| | [8,PROP_ID] | and one of its properties |
+---------------------------------------------------------------------+
| PRT_TD_ID | [32,PRT_ID] | Identifies a logical Port |
| | [8,TD_ID] | and a traffic descriptor |
| | | that applies to the port |
+----------------+----------------------+-----------------------------+
| CLI_ID | [16, Carrier ID] | Identifies an |
| | [16, Network ID] | FPC Client function |
| | [32, Client ID] | |
+---------------------------------------------------------------------+
| AGT_ID | [16, Carrier ID] | Identifies an |
| | [16, Network ID] | FPC Agent function |
| | [32, Agent ID] | |
+---------------------------------------------------------------------+
| DPN_ID | [16, Carrier ID] | Identifies a Data Plane |
| | [16, Network ID] | Node (DPN) |
| | [32, DPN ID] | |
+---------------------------------------------------------------------+
| MONITOR_ID | [32, Monitor ID] | Identifies a registered |
| | | monitor |
+---------------------------------------------------------------------+
| EVENT_TYPE_ID | [8, Event Type ID] | Identifies an event type |
+---------------------------------------------------------------------+
| Optional Identifiers |
+---------------------------------------------------------------------+
| SERVICE_PATH_ID| [24-bit identifier] | Service Path Identifier |
+---------------------------------------------------------------------+
Figure 6: Model I Protocol Attributes: Identifiers Policy-id: Identifier of Policy. The ID format SHOULD refer to
Section 4.4.
+----------------------------------------------------------------------+ Rules: List of Rules which are a collection of Descriptors and
| Attribute | Format Clarification | Description | Actions. All Descriptors MUST be satisfied before the Actions
+======================================================================+ are taken. This is known as an AND Descriptor list, i.e.
| Properties | Descriptor 1 AND Descriptor 2 AND ... Descriptor X MUST be
+----------------------------------------------------------------------+ satisfied for the Rule to apply. These are internal structure to
| PROP_TUN | [type][src][dst] | Property Encapsulation, | the Policy, i.e. it is not a first class, visible object at the
| | | indicates type GRE, IP, | top level of an Agent.
| | | GTP |
+----------------------------------------------------------------------+
| PROP_REWR | [in_src_ip][out_src_ip] | Property NAT defines |
| | [in_dst_ip][out_dst_ip] | IP address and port |
| | [in_src_port][out_src_port]| re-write rules |
| | [in_dst_port][out_dst_port]| |
+----------------------------------------------------------------------+
| PROP_QOS | [QoS index type][index] | Property QoS refers to |
| | [DSCP] | single index and DS Code|
| | | Point to write |
+----------------------------------------------------------------------+
| PROP_QOS_GBR | [GBR] *[PRT_ID] | Guaranteed Bit Rate and |
| | | single or multiple |
| | | PRT_IDs to which the |
| | | GBR applies when being |
| | | aggregated |
+---------------+----------------------------+-------------------------+
| PROP_QOS_MBR | [MBR] *[PRT_ID] | Maximum Bit Rate and |
| | | single or multiple |
| | | PRT_IDs to which the |
| | | MBR applies when being |
| | | aggregated |
+---------------+----------------------------+-------------------------+
| PROP_GW | [ip address next hop] | IP address of the Next |
| | | Hop to which IP packets |
| | | should be forwarded |
+----------------------------------------------------------------------+
| PROP_CPY_FORW | [PRT_ID] | Copy IP packets, treat |
| | | the duplicates per the |
| | | properties of the |
| | | referred port |
+----------------------------------------------------------------------+
| PROP_DROP | | Drop IP packet |
+----------------------------------------------------------------------+
| PROP_CONCAT | [PRT_ID] | Include treatment per |
| | | the referred port into |
| | | the rule |
+----------------------------------------------------------------------+
| Optional Properties |
+----------------------------------------------------------------------+
| PROP_NSH | [SERVICE_PATH_ID] | Include NSH |
| | [Service Index] | |
+----------------------------------------------------------------------+
Figure 7: Model I Protocol Attributes: Traffic Treatment Properties Order: Specifies ordering if the Rule has multiple Descriptors and
Action sets.
+---------------------------------------------------------------------+ Descriptors: List of Descriptors.
| Attribute | Format Clarification | Description |
+=====================================================================+
| Protocol-specific |
+---------------------------------------------------------------------+
| IPIP_CONF | | IP-encapsulation |
| | | configuration attribute |
+---------------------------------------------------------------------+
| GRE_CONF | [prototype][seq-#] | GRE_encapsulation |
| | [key] | configuration attribute |
+---------------------------------------------------------------------+
| GTP_CONF | [TEID_local] | GTP-U encapsulation |
| | [TEID_remote] | configuration attribute |
| | [seq-#] | |
+---------------------------------------------------------------------+
Figure 8: Model I Protocol Attributes: Protocol-specific Descriptor-id: Indicates each Descriptor in the Rule.
+---------------------------------------------------------------------+ Direction: Specifies which direction applies, such as upstream,
| Attribute | Format Clarification | Description | downstream or both.
+=====================================================================+
| Traffic Descriptor Container |
+---------------------------------------------------------------------+
| TD_CONTAINER | [PRT_TD_ID] | Traffic handling priority, |
| | [8, PRIO] | One or multiple traffic |
| |*[traffic descriptor] | descriptors |
+---------------------------------------------------------------------+
Figure 9: Protocol Attributes: Traffic Description Container Actions: List of Actions.
+---------------------------------------------------------------------+ Action-id: Indicates each Action in the rule.
| Attribute | Format Clarification | Description |
+=====================================================================+
| Traffic Descriptors |
+---------------------------------------------------------------------+
| TD_DST_IP | [IP address] | Aggregated or per-host dst |
| | [Prefix Len] | IP address/prefix rule |
+---------------------------------------------------------------------+
| TD_SRC_IP | [IP address] | Aggregated or per-host src |
| | [Prefix Len] | IP address/prefix rule |
+---------------------------------------------------------------------+
| TD_TS | [Traffic Selector] | Traffic Selector, |
| | | Format as per RFC6088 |
+----------------+----------------------+-----------------------------+
Figure 10: Protocol Attributes: Traffic Descriptors Order: Specifies Action ordering if the Rule has multiple actions.
+----------------------------------------------------------------------+ 4.2.4. Policy-groups
| Attribute | Format Clarification | Description |
+======================================================================+
| Properties |
+----------------------------------------------------------------------+
| ADMIN_STATE | [state] | Administrative state: |
| | | enabled, disabled, |
| | | virtual |
+----------------------------------------------------------------------+
| SESSION_STATE | [state] | Session state: complete,|
| | | incomplete, outdated |
+----------------------------------------------------------------------+
| CLONE_REF | [PRT_ID] | Cloning of a rule based |
| | | on referred port ID |
+----------------------------------------------------------------------+
| ACT_DELAY | [delay] | Delay in ms before an |
| | | updated rule takes |
| | | effect at the Agent |
+----------------------------------------------------------------------+
| PRT_BIDIR | [boolean] | When set, the rule per |
| | | this port is applied |
| | | bi-directionally |
+----------------------------------------------------------------------+
| RESULT | [result] | Result of processing |
| | | a message: |
| | | success, failure |
+----------------------------------------------------------------------+
Figure 11: Protocol Attributes: Administrative Properties List of Policy-groups which are an aggregation of Policies. Common
applications include aggregating Policies that are defined by
different functions, e.g. Network Address Translation, Security,
etc. The structure has an Identifier and references the Policies via
their Identifiers.
+----------------------------------------------------------------------+ (FPC-Policy)
| Attribute | Format Clarification | Description | |
+======================================================================+ +---Policy-groups
| Monitors and Notification | |
+----------------------------------------------------------------------+ +---Policy-group-id
| MONITOR | Monitor-ID Attribute | A Monitor | |
| | [REPORT CONFIG] | | +---Policies
+----------------------------------------------------------------------+
| REPORT_CONFIG | [8, REPORT-TYPE] | The type of report and |
| | [TYPE_SPECIFIC_INFO] | type-specific |
| | | configurations |
+----------------------------------------------------------------------+
| PERIODIC_CONFIG | [32, period] | REPORT-TYPE is PERIODIC, |
| | | period specifies the |
| | | report interval (ms) |
+----------------------------------------------------------------------+
| THRESHOLD_CONFIG | [32, low] | REPORT-TYPE is THRESHOLD, |
| | [32, hi] | Low Threshold, |
| | | High Threshold (at least |
| | | one value required) |
+----------------------------------------------------------------------+
| SCHEDULED_CONFIG | [32, time] | REPORT-TYPE is SCHEDULED, |
| | | Time when NOTIFY is sent |
| | | |
+----------------------------------------------------------------------+
| EVENTS_CONFIG | *[EVENT_TYPE_ID] | List of Events that |
| | | trigger the Monitor |
+----------------------------------------------------------------------+
| DEREG_INFO | *[MONITOR_ID] | Monitors to deregister, |
| | [boolean] | Boolean (optional) |
| | | indicates if a successful |
| | | DEREG triggers a NOTIFY |
| | | with final data |
+----------------------------------------------------------------------+
| NOTIFY_INFO | [32, Notification-Id] |ID used for Client ordering|
| | [MONITOR-ID] |Monitor-ID of the NOTIFY, |
| | [32, TRIGGER] |TRIGGER for the NOTIFY, |
| | [32, timestamp] |Timestamp of when the |
| | |attributes were recorded |
+----------------------------------------------------------------------+
Figure 12: Protocol Attributes: Monitor and Notify Attributes Figure 10: Policy-group Model Structure
TRIGGERS include but are not limited to the following values: Policy-group-id: Identifier of Policy-group. The ID format SHOULD
refer to Section 4.4.
o Events specified in the Event List of an EVENTS CONFIG Policies: List of Policies in the Policy-group.
o LOW_THRESHOLD_CROSSED 4.3. FPC-Mobility
o HIGH_THRESHOLD_CROSSED
o PERIODIC_REPORT The FPC-Mobility consists of Port and Context. A mobility session is
abstracted as a Context with its associated runtime concrete
attributes, such as tunnel endpoints, tunnel identifiers, delegated
prefix(es) and routing information, etc. A Port abstracts a set of
policies applied to the Context.
o SCHEDULED_REPORT 4.3.1. Port
o PROBED A port represents a collection of policy groups, a group of rules
that can exist independent of the mobility/session lifecycle.
Mobility control-plane or applications create, modify and delete
Ports on FPC Agent through the FPC Client.
o DEREG_FINAL_VALUE When a Port is indicated in a Context, the set of Descriptors and
Actions in the Policies of the Port are collected and applied to the
Context. They must be instantiated on the DPN as forwarding related
actions such as QoS differentiations, packet processing of encap/
decap, header rewrite, route selection, etc.
4.3. Protocol Messages and Semantics (FPC-Mobility)
|
+---Ports
|
+---Port-id
|
+---Policy-groups
The following table specifies all protocol messages to create and Figure 11: Port Model Structure
modify a rule by creating and deleting logical Ports, adding and
modifying properties and binding traffic descriptors to a port.
Furthermore, messages can schedule tasks, such as monitoring, at an
Agent or probe the status of the scheduled task from a Client.
Additional messages enable the Data-Plane to notify or query the
Control-Plane through the Agent and Client functions.
+---------------------------------------------------------------------+ Port-id: Identifier of Port. The ID format SHOULD refer to
| Message | Description | Section 4.4.
+=====================================================================+
| Messages issued by the FPC Client |
+---------------------------------------------------------------------+
| PRT_ADD | Add a logical port |
+---------------------------------------------------------------------+
| PRT_DEL | Delete a logical port |
+---------------------------------------------------------------------+
| PROP_ADD | Add a property to a logical port |
+---------------------------------------------------------------------+
| PROP_MOD | Modify a property of a logical port |
+---------------------------------------------------------------------+
| PROP_DEL | Delete a property from a logical port |
+---------------------------------------------------------------------+
| TD_ADD | Add traffic descriptor to a logical port |
+---------------------------------------------------------------------+
| TD_MOD | Modify an existing traffic descriptor |
+---------------------------------------------------------------------+
| TD_DEL | Delete an existing traffic descriptor |
+---------------------------------------------------------------------+
| MONITOR_REG | Install a monitor at an Agent. The message |
| | includes information about the attribute to |
| | monitor and the reporting method. |
+---------------------------------------------------------------------+
| MONITOR_DEREG | Remove a monitor at an Agent. |
+---------------------------------------------------------------------+
| PROBE | Probe the status of a registered event |
+---------------------------------------------------------------------+
| Messages issued by the FPC Agent |
+---------------------------------------------------------------------+
| | Notify the Client about the status of a |
| NOTIFY | monitored attribute per the reporting method |
| | (periodic / event trigger / probed) |
+---------------------------------------------------------------------+
| QUERY | Query the Client about missing rules/states |
+---------------------------------------------------------------------+
Figure 13: Protocol Messages Policy-groups: List of references to Policy-groups which apply to
the Port.
4.4. Protocol Operation 4.3.2. Context
The following list comprises a more detailed description of each An endpoint of a mobility session or the instantiation of policy-
message's semantic. groups is abstracted as a Context with its associated runtime
concrete attributes, such as tunnel endpoints, tunnel identifiers,
delegated prefix(es) and routing information, etc. Mobility control-
plane or applications create, modify and delete contexts on FPC Agent
through the FPC Client.
An FPC Client and Agent MUST identify themself using the CLI_ID and A Context directly describes traffic treatment policies in QoS
AGT_ID respectively to ensure that for all transactions a recipient profile and Mobility profiles or indirectly via Ports. Parameters in
of an FPC message can unambiguously identify the sender of the FPC these profiles may be set by the FPC Client directly or indirectly
message. A Client MAY direct the Agent to enforce a rule in a derived from the set of Descriptors and Actions when the Ports
particular DPN by including a DPN_ID value. Otherwise the Agent indicate Policies which specify those descriptors and actions. If a
selects a suitable DPN to enforce a rule and notifies the Client Context doesn't have any Port, all parameters of the Context must be
about the selected DPN using the DPN_ID. set by the Client.
o PRT_ADD - Issued by a Client to add a new logical port at an (FPC-Mobility)
Agent. An Agent receiving the PRT_ADD message identifies the new |
port according to the included port identifier (PRT_ID). The +---Contexts
Agent adds a new port into its conceptual data structures using |
the port identifier as key. Optionally, the PRT_ADD message MAY +---Context-id
include properties as well as traffic descriptors, which are bound |
and refer to the new port. This enables a Client to issue a new +---Ports
configuration in a single transaction with an Agent. A Client MAY |
assign a port to a group of ports and indicate the associated port +---DPN-group
group identifier (PRT_GROUP_ID) in the PRT_ADD message. |
+---Delegating-ip-prefixes
|
+---Parent-context
o PRT_DEL - Used by a Client to delete a port. An Agent receiving Figure 12: Common Context Model Structure
such message MUST delete all properties associated with the
identified port.
o PROP_ADD - Used by the Client to add a new property to an existing Context-id: Identifier of Context. The ID format SHOULD refer to
port. The property is unambiguously identified through a property Section 4.4.
identifier (PRT_PROP_ID). All traffic, which is directed to this
port is treated according to the existing and newly added
property. Optionally, the PROP_ADD message can include traffic
descriptors, which refer to the port to which the properties are
bound. This enables a Client to add new rules to the existing
port to which the new properties have been bound in a single
transaction.
o PROP_MOD - Used by a Client to modify an existing property. For Ports: List of Ports. When a Context is applied to Port(s), the
example, a tunnel property can be changed to direct traffic to a context is configured by policies of those Port(s). Port-id
different tunnel endpoint in case of a mobile node's handover. references indicate Ports which apply to the Context. Context
Optionally, the PROP_MOD message can include rules descriptions, can be a part of multiple Ports which have different policies.
which refer to the port whose properties are modified. This
enables a Client to add new rules to the existing port whose
properties have been modified in a single transaction.
o PROP_DEL - Used by a Client to delete one or multiple properties, DPN-group: The DPN-group assigned to the Context.
each being identified by a property identifier.
o TD_ADD - Used by a Client to add a traffic descriptor to a port. Delegating-ip-prefixes: List of IP prefixes to be delegated to the
The traffic descriptor SHOULD unambiguously identify aggregated mobile node of the context.
traffic (longest prefix), per host IP traffic or per-flow traffic
in the TD_ADD command and bind the identified traffic to a port.
Traffic descriptors are carried in a TD_CONTAINER, which allows
the identification of a traffic description as well as the
indication if a traffic handling priority in case the sole traffic
description does not suffice unambiguous traffic matching. An
Agent receiving a TD_ADD command MUST add the traffic descriptor
to its local conceptual data structures and apply commands for
local configuration to add the new traffic descriptor to the rule
on the DPN. Multiple traffic descriptors can bind to the same
port. All traffic captured by the traffic descriptor will
experience the same treatment per the properties which bind to
that port.
o TD_MOD - Used by a Client to modify an existing traffic Parent-context: Indicates context which the context inherits.
descriptor. An Agent receiving such messages MUST apply commands
to the local configuration and update the rule on the DPN
accordingly.
o TD_DEL - Used to remove an existing traffic descriptor from a 4.3.2.1. Single DPN Agent Case
port. The Agent receiving such messages MUST delete the
identified traffic descriptor from the local configuration and
update the rule on the DPN accordingly.
o MONITOR_REG - Used by a Client to install a monitor at an Agent. In the case where a FPC Agent supports only one DPN, the Agent MUST
A monitor contains the monitor id, attribute to monitor, and maintain context data just for the DPN. The Agent does not need to
optional reporting configuration. The attribute may be any ID maintain a Topology model. The Context in single DPN case consists
with the exception of MONITOR_ID and EVENT_TYPE_ID. When a of following parameters for both direction of uplink and downlink.
Monitor registration is applied, the reporting configuration MUST
be applicable to the attribute monitored, e.g. a Monitor using a
Threshold configuration cannot be applied to a Port but it can be
applied to a numeric Port Property. Four report types are
defined: (1) Periodic reporting specifies an interval by which a
NOTIFY is sent to the Client, (2) Event reporting specifies a list
of EVENT_TYPE_IDs that, if they occur and are related to the
monitored attribute, will result in sending a NOTIFY to the
Client, (3) Scheduled reporting specifies the time (in seconds
since Jan 1, 1970) when a NOTIFY for the monitor should be sent to
the Client. Once this Monitor's NOTIFY is completed the Monitor
is automatically de-registered, (4) Threshold reporting specifies
one or both of a low and high threshold. When these values are
crossed a corresponding NOTIFY is sent to the Client. All
monitored data can be requested by the Client at any time using
the PROBE message. Thus, reporting configuration is optional and
when not present only PROBE messages may be used for monitoring.
If a SCHEDULED or PERIODIC configuration is provided during
registration with the time related value (time or period
respectively) of 0 a NOTIFY is immediately sent and the monitor is
immediately de-registered. This method should when a MONITOR has
not been installed, an immediate NOTIFY is sufficient for the
Client's needs and the Client has no further need for the monitor
to be registered. An Agent may reject a registration if it or the
DPN has insufficient resources.
o MONITOR_DEREG - Used by a Client to remove a monitor from an (Contexts)
Agent. The message identifies one or multiple monitors by |
including the MONITOR_ID. The message also includes an optional +---UL-Tunnel-local-address
Boolean value that, when true, will result in NOTIFY messages |
being sent for the MONITOR_ID to the Client. When a monitor has a +---UL-Tunnel-remote-address
reporting configuration of SCHEDULED it is automatically de- |
registered after the NOTIFY occurs. An Agent or DPN may +---UL-Tunnel-mtu-size
temporarily suspend monitoring if insufficient resources exist. |
In such a case the Agent MUST notify the Client. +---UL-Mobility-specific-tunnel-parameters
|
+---UL-Nexthop
|
+---UL-QoS-profile-specific-parameters
|
+---UL-DPN-specific-parameters
|
+---UL-Vendor-specific-parameters
o PROBE - Used by a Client to retrieve information about a Figure 13: Uplink Context Model of Single DPN Structure
previously installed monitor. The PROBE message SHOULD identify
one or more monitors by means of including the associated monitor
identifier. An Agent receiving a PROBE message SHOULD send the
requested information in a single or multiple NOTIFY messages.
o NOTIFY - Used by an Agent to report the status of a monitor to a UL-Tunnel-local-address: Specifies uplink endpoint address of the
Client. This message contains the MONITOR_ID, a NOTIFICATION_ID DPN.
to permit the Client to distinguish amongst many monitoring
related requests, a TRIGGER that caused the NOTIFY message, the
timestamp of when the monitored information was record for the
message along with the value of the monitored attribute.
o QUERY - Used by an Agent to request an update of port properties UL-Tunnel-remote-address: Specifies uplink endpoint address of the
via a Client. The Agent adds one or multiple port identifiers to remote DPN.
the QUERY message to request all properties associated with the
identified port(s). The Agent MAY request the update of
particular properties associated with a port by including the
property and its identifier. As result of processing a QUERY
message, the Client sends one or multiple PROP_MOD messages with
the requested properties to the Agent.
All messages sent from a Client to an Agent MUST be acknowledged by UL-Tunnel-Mtu-size: Specifies uplink MTU size of tunnel.
the Agent. The response must include all attributes as well as
status information, which indicates the result of processing the
message, using the RESULT property. In case the processing of the
message results in a failure, the Agent sets the RESULT accordingly
and MAY clear the property or traffic descriptor, which caused the
failure, in the response.
A Client MAY add a property to a port without providing all required UL-Mobility-specific-tunnel-parameters: Specifies profile specific
details of the attribute's value. In such case the Agent SHOULD uplink tunnel parameters to the DPN which the agent exists. The
determine the missing details and provide the completed property profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf-
description back to the Client. In case the Agent cannot determine pmip profile, or new profiles defined by extensions of this
the missing value of an attribute's value per the Client's request, specification.
it leaves the attribute's value cleared in the response and sets the
RESULT to failure. As example, the Control-Plane needs to 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 DPN
that enforces the rule. The Client adds the tunnel property
attribute to the FPC message and clears the value of the attribute
(e.g. IP address of the local tunnel endpoint). The Agent
determines the tunnel endpoint and includes the completed tunnel
property in its response to the Client.
The following list provides information on the use and semantics of UL-Nexthop: Indicates nexthop information of uplink in external
attributes for traffic treatment: network such as IP address, MAC address, SPI of service function
chain, SID of segment routing, etc.
o PROP_TUN - Defines the properties for encapsulation into different UL-QoS-profile-specific-parameters: Specifies profile specific QoS
tunnel headers. The property includes IP address information of parameter of uplink, such as QCI/TFT for 3gpp profile,
tunnel endpoints as well as a type identifier specifying the [RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by
encapsulation type. Further attributes may be included to provide extensions of this specification.
information which is relevant for the configuration and
initialization of the tunnel.
o PROP_REWR - Defines the properties for IP address and port re- UL-DPN-specific-parameters: Specifies optional node specific
write. parameters of uplink in need, such as if-index, tunnel-if-number
that must be unique in the DPN.
o PROP_QOS - Defines the QoS properties in terms of a known index UL-Vendor-specific-parameters: Specifies a vendor specific parameter
type, e.g. LTE's Quality Class Index (QCI), and its value (QCI space for uplink.
1..9), as well as a Differentiated Services Code Point (DSCP) to
classify and mark packets. Additional QoS attributes may follow,
to define Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR)
bounds. PROP_QOS_GBR and PROP_QOS_MBR attributes can apply to a
single port or multiple ports. The latter is required to
configure aggregate bounds, such as Aggregate Maximum Bit Rate
(AMBR), taking traffic, which is forwarded through different ports
(hence experiencing different treatment), into account. In such
case the GBR/MBR attributes append multiple PRT_ID attributes to
identify the ports which are to be monitored to determine the
aggregated view of the bit rate. As alternative to binding a
PROP_QOS_MBR property to each port whose traffic is to be taken
into account for Aggregate Maximum Bitrate (AMBR) metering, a
Client can create a separate port with a single PROP_QOS_MBR
property. Other ports, whose traffic is to be metered per the
AMBR, can refer to the port with the PROP_QOS_MBR property using
the PROP_CONCAT property. The scope of attributes for QoS is
aligned to [RFC7222]. The Allocation and Retention Priority (ARP)
as per [RFC7222] is not present in the list of QoS-specific
attributes, since ARP is treated and kept in the Control-Plane for
granting requests for new resources and QoS, as well as for
preempting other QoS configuration, if needed.
o PROP_QOS_GBR - Defines the GBR bound for traffic associated with a (Contexts)
port. |
+---DL-Tunnel-local-address
|
+---DL-Tunnel-remote-address
|
+---DL-Tunnel-Mtu-size
|
+---DL-Mobility-specific-tunnel-parameters
|
+---DL-Nexthop
|
+---DL-QoS-profile-specific-parameters
|
+---DL-DPN-specific-parameters
|
+---DL-Vendor-specific-parameters
o PROP_QOS_MBR - Defines the MBR bound for traffic associated with a Figure 14: Downlink Context Model of Single DPN Structure
port.
o PROP_GW - Defines a Next Hop IP address, to which packets are DL-Tunnel-local-address: Specifies downlink endpoint address of the
forwarded. Using this attribute, the Control-Plane can configure DPN.
a host-route in the Data-Plane to deviate from default routes.
o PROP_CPY_FORW - Refers to a different port and results in DL-Tunnel-remote-address: Specifies downlink endpoint address of the
treatment of a copy of packets per the properties bound to the remote DPN.
referred port.
o PROP_DROP - Defines a treatment action to drop packets of traffic DL-Tunnel-Mtu-size: Specifies downlink MTU size of tunnel.
associated with a port. As example, this treatment action can be
used to enforce gating rules and filter traffic which does not
match any traffic descriptor.
o PROP_CONCAT - Traffic can be treated per properties bound to DL-Mobility-specific-tunnel-parameters: Specifies profile specific
concatenated ports. After treatment of traffic according to the downlink tunnel parameters to the DPN which the agent exists.
properties of a port, additional treatment actions per the The profiles includes GTP/TEID for 3gpp profile, GRE/Key for
properties bound to a separate port, which is referred to in the ietf-pmip profile, or new profiles defined by extensions of this
PROP_CONCAT property, apply to the traffic. As example, port specification.
concatenation can be used to enable AMBR metering to traffic which
is associated with multiple other ports.
o PROP_NSH - Defines the properties for a Network Service Header DL-Nexthop: Indicates nexthop information of downlink in external
(NSH). The header is included to the classified IP flows. network such as IP address, MAC address, SPI of service function
chain, SID of segment routing, etc.
Unlike descriptors, overlapping or contradictory properties cannot be DL-QoS-profile-specific-parameters: Specifies profile specific QoS
resolved by the Agent. For example, adding address translation parameter of downlink, such as QCI/TFT for 3gpp profile,
related properties and a Drop property to a single port may result in [RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by
needless activity in the DPN or it may reflect a temporary extensions of this specification.
administrative activity where the port must Drop traffic. Other
properties may be intentionally set, e.g. a property that invokes and
accounting activity and a Drop property present on the same port.
The FPC Client MUST avoid situations where contradictory properties
or those that result in unnecessary activity are added to ports.
Rather, in such situations, multiple ports MUST be used. In some
obvious cases the Agent MAY raise a warning but a contradictory
action.
The following list provides information on the use and semantics of DL-DPN-specific-parameters: Specifies optional node specific
administrative properties: parameters of downlink in need such as if-index, tunnel-if-number
that must be unique in the DPN.
o ADMIN_STATE - A Client can apply an administrative state to a port DL-Vendor-specific-parameters: Specifies a vendor specific parameter
indicating the desired operational status of a port (enabled, space for downlink.
disabled, virtual). An Agent, which receives a message without
ADMIN_STATE property, SHOULD consider the port to be 'enabled'.
o SESSION_STATE - A Client can indicate to the Agent the status of a 4.3.2.2. Multiple DPN Agent Case
rule to serve Data-Plane traffic. A session state 'complete'
confirms that a rule is valid and ready to serve Data-Plane
traffic. A session state 'incomplete' hints to the Agent that
more FPC message will arrive from the Client to complete a rule,
whereas session state 'outdated' requires the Agent to solicit an
update of the rule from the Client in case a rule with session
state 'complete' is desired. An Agent, which receives a message
without SESSION_STATE property, SHOULD assume the session state is
'complete'.
o CLONE_REF - Instead of repeatedly sending all properties and Another case is when a FPC Agent connects to multiple DPNs. This
traffic descriptors for similar rules, a Client can take a clone Agent MUST maintain a set of Context data for each DPN. The Context
of a previously configured rule as base for a new one by using the contains a DPNs list where each entry of the list consists of the
CLONE_REF property with a PRT_ADD message and refer to an existing parameters in Figure 15. A Context data for one DPN has two entries
port. The cloned port will be a copy of the referred port and for each direction of uplink and downlink.
serve as base for the new port. The cloned port will have its own
port identifier, which will also be present in the port identifier
portion of the property identifiers. After a cloned port has been
created, it represents its own rule without any further dependency
on the reference port which served as source to create the clone.
A Client MAY apply updates to existing properties of the new port,
as well as delete or add properties. Updates to the port in terms
of new or changed properties and traffic descriptors MAY already
come with the PRT_ADD message or subsequently using messages to
handle properties and traffic descriptors. A Client can use the
CLONE_REF property with messages to handle properties and traffic
descriptors to achieve a different result. In such case these
messages identify an existing port already and processing the
CLONE_REF property on the receiving Agent will result in a reset
of the identified port to match the properties of the port
referred to in the CLONE_REF property.
o ACT_DELAY - A Client can use this property to define a delay in ms (Contexts)
before an updated rule takes effect at an Agent, e.g. an |
administrative state 'enabled' will be enforced by the Agent after +---DPNs
the delay per the Client's request. |
+---DPN-id
|
+---Direction
|
+---Tunnel-local-address
|
+---Tunnel-remote-address
|
+---Tunnel-mtu-size
|
+---Mobility-specific-tunnel-parameters
|
+---Nexthop
|
+---QoS-profile-specific-parameters
|
+---DPN-specific-parameters
|
+---Vendor-specific-parameters
o PRT_BIDIR - A Client uses this property to indicate to an Agent to Figure 15: Multiple-DPN Supported Context Model Structure
apply a rule associated with a port bi-directionally. In case the
PRT_BIDIR property is absent in a message, the Agent assumes a
rule applies uni-directionally.
o RESULT - An Agent uses this property to signal to the Client in a DPN-id: Indicates DPN of which the runtime context data installed.
response the result of processing a message.
Figure 14 illustrates an exemplary session life-cycle based on Proxy Direction: Specifies which side of connection at the DPN indicated,
"uplink" or "downlink".
Tunnel-local-address: Specifies endpoint address of the DPN at the
uplink or downlink.
Tunnel-remote-address: Specifies endpoint address of remote DPN at
the uplink or downlink.
Tunnel-mtu-size: Specifies the MTU size of tunnel on uplink or
downlink.
Mobility-specific-tunnel-parameters: Specifies profile specific
tunnel parameters for uplink or downlink of the DPN. The
profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf-
pmip profile, or new profiles defined by extensions of this
specification.
Nexthop: Indicates nexthop information for uplink or downlink in
external network of the DPN such as IP address, MAC address, SPI
of service function chain, SID of segment routing, etc.
QoS-profile-specific-parameters: Specifies profile specific QoS
parameter for uplink or downlink of the DPN, such as QCI/TFT for
3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or new profiles
defined by extensions of this specification.
DPN-specific-parameters: Specifies optional node specific parameters
for uplink or downlink of the DPN in need, such like if-index,
tunnel-if-number that must be unique in the DPN.
Vendor-specific-parameters: Specifies a vendor specific parameter
space for the DPN.
4.3.3. Monitors
Monitors provide a mechanism to produce reports when events occur. A
Monitor will have a target that specifies what is to be watched.
When a Monitor is specified, the configuration MUST be applicable to
the attribute/entity monitored, e.g. a Monitor using a Threshold
configuration cannot be applied to a context but it can be applied to
a numeric property.
(FPC-Mobility)
|
+---Monitors
|
+---Monitor-id
|
+---Target
|
+---Configuration
Figure 16: Common Monitor Model Structure
Monitor-id: Name of the Monitor. The ID format SHOULD refer to
Section 4.4.
Target: Target to be monitored. This may be an event, a Context, a
Port or attribute(s) of Contexts. When the type is an
attribute(s) of a Context, the target name is a concatenation of
the Context-Id and the relative path (separated by '/') to the
attribute(s)to be monitored.
Configuration: Determined by the Monitor subtype. Four report types
are defined:
* Periodic reporting specifies an interval by which a
notification is sent to the Client.
* Event reporting specifies a list of even types that, if they
occur and are related to the monitored attribute, will result
in sending a notfication to the Client
* Scheduled reporting specifies the time (in seconds since Jan
1, 1970) when a notificaiton for the monitor should be sent to
the Client. Once this Monitor's notification is completed the
Monitor is automatically de-registered.
* Threshold reporting specifies one or both of a low and high
threshold. When these values are crossed a corresponding
notification is sent to the Client.
4.4. Namespace and Format
The identifiers and names in FPC models which reside in the same
namespace must be unique. That uniqueness must be kept in agent or
data-plane tenant namespace on an Agent. The tenant namespace
uniquenes 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
Agent, the Agent SHOULD define that policy to be visible from all the
tenants. In this case, the Agent assign an unique identifier in the
agent namespace.
The format of identifiers can utilize any format with agreement
between data-plane agent and client operators. The formats include
but are not limited to Globally Unique IDentifiers (GUIDs),
Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names
(FQDNs), Fully Qualified Path Names ( FQPNs) and Uniform Resource
Identifiers (URIs).
The FPC model MUST NOT limit the types of format that dictate the
choice of FPC protocol. It is noted that the choice of identifiers
which are used in Mobility model should be suitable to handle runtime
parameters in real-time. The Topology and Policy models are not
restricted to meet that requirement as described in Section 3.
5. Protocol
5.1. Protocol Messages and Semantics
Five message types are supported:
+---------------+---------------+-----------------------------------+
| Message | Type | Description |
+---------------+---------------+-----------------------------------+
| CONF | HEADER | Configure processes a single |
| | ADMIN_STATE | operation. |
| | SESSION_STATE | |
| | OP_TYPE BODY | |
| | | |
| CONF_BUNDLES | 1*[HEADER | Configure-bundles takes multiple |
| | ADMIN_STATE | operations that are to be |
| | SESSION_STATE | executed as a group with partial |
| | OP_TYPE BODY] | failures allowed. They are |
| | | executed according to the OP_ID |
| | | value in the OP_BODY in ascendig |
| | | order. If a CONFIGURE_BUNDLES |
| | | 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. |
| | | |
| REG_MONITOR | HEADER | Install a monitor at an Agent. |
| | ADMIN_STATE | The message includes information |
| | *[ MONITOR ] | about the attribute to monitor |
| | | and the reporting method. Note |
| | | that a MONITOR_CONFIG is required |
| | | for this opeation. |
| | | |
| DEREG_MONITOR | HEADER *[ | Remove monitors from an Agent. |
| | MONITOR_ID ] | Monitor IDs are provided. Boolean |
| | [ boolean ] | (optional) 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
Each message contains a header with the Client Identifier, an
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.
Messages that create or update Monitors and Entities, i.e. CONF,
CONF_BUNDLES and REG_MONITOR, specify an Administrative State which
specifies the Administrative state of the message subject(s) after
the successful completion of the operation. If the status is set to
virtual, any existing data on the DPN is removed. If the value is
set to disabled, then an operation will occur on the DPN IF the
entity exists on the DPN. If set to 'active' the DPN will be
provisioned. Values are 'enabled', 'disabled' or 'virtual'.
An Agent will respond with an error, ok, or an ok with indication
that remaining data will be sent via a notify from the Agent to the
Client Section 5.1.1.5.2. When returning an 'ok' of any kind,
optional data may be present.
Two Agent notifications are supported:
+----------------------+----------+---------------------------------+
| Message | Type | Description |
+----------------------+----------+---------------------------------+
| CONFIG_RESULT_NOTIFY | See | An asynchronous notification |
| | Table 15 | from Agent to Client based upon |
| | | a previous CONFIG or |
| | | CONFIG_BUNDLES request. |
| | | |
| NOTIFY | See | An asynchronous notification |
| | Table 16 | from Agent to Client based upon |
| | | a registered MONITOR. |
+----------------------+----------+---------------------------------+
Table 2: Agent to Client Messages (Notfications)
5.1.1. CONF and CONF_BUNDLES Messages
CONF and CONF_BUNDLES specify the following information for each
operation in addition to the header information:
SESSION_STATE: sets the expected state of the entities embedded in
the operation body after successful completion of the operation.
Values can be 'complete', 'incomplete' or 'outdated'. Any
operation that is 'incomplete' MAY NOT result in communication
between the Agent and DPN. If the result is 'outdated' any new
operations on these entities or new references to these entities
have unpredictable results.
OP_TYPE: specifies the type of operation. Valid values are 'create'
(0), 'update' (1), 'query' (2) or 'delete' (3).
COMMAND_SET: specifies the Command Set IF the feature is supported
(see Section 5.1.1.3).
BODY A list of Clones, if supported, Ports and Contexts when the
OP_TYPE is 'create' or 'update'. Otherwise it is a list of
Targets for 'query' or 'deletion'. See Section 6.2.2 for
details.
5.1.1.1. Agent Operation Processing
The Agent will process entities provided in an operation in the
following order:
1. Clone Instructions, if the feature is supported
2. Ports
3. Contexts according to COMMAND_SET order processing
The following Order Processing occurs when COMMAND Sets are present
1. The Entity specific COMMAND_SET is processed according to its bit
order unless otherwise specified by the technology specific
COMMAND_SET definition.
2. Operation specific COMMAND_SET is processed upon all applicable
entities (even if they had Entity specific COMMAND_SET values
present) according to its bit order unless otherwise specified by
the technology specific COMMAND_SET definition.
3. Operation OP_TYPE is processed for all entities.
When deleting objects only their name needs to be provided. However,
attributes MAY be provided if the Client wishes to avoid requiring
the Agent cache lookups.
When deleting an attribute, a leaf reference should be provided.
This is a path to the attibutes.
5.1.1.2. Cloning
Cloning is an optional feature that allows a Client to copy one
structure to another in an operation. Cloning is always done first
within the operation (see Operation Order of Execution for more
detail). If a Client wants to build an object then Clone it, use
CONFIG_BUNDLES with the first operation being the entities to be
copied and a second operation with the Cloning instructions. A CLONE
operation takes two arguments, the first is the name of the target to
clone and the second is the name of the newly created entity.
Individual attributes are not clonable; only Ports and Contexts can
be cloned.
5.1.1.3. Command Bitsets
The COMMAND_SET is a technology specific bitset that allows for a
single entity to be sent in an operation with requested sub-
transactions to be completed. For example, a 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.
Alternatively, an entity could be sent in an update operation that
would be considered incomplete, e.g. missing some required data in
for the entity, but has sufficient data to complete the instructions
provided in the COMMAND_SET.
5.1.1.4. Reference Scope
The Reference Scope is an optional feature that provides the scope of
references used in a configuration command, i.e. CONFIG or
CONFIG_BUNDLES. These scopes are defined as
o none - all entities have no references to other entities. This
implies only Contexts are present Ports MUST have references to
Policy-Groups.
o op - All references are contained in the operation body, i.e. only
intra-operaion references exist.
o bundle - All references in exist in bundle (inter-operation/intra-
bundle). NOTE - If this value comes in CONFIG call it is
equivalent to 'op'.
o storage - One or more references exist outside of the operation
and bundle. A lookup to a cache / storage is required.
o unknown - the location of the references are unknown. This is
treated as a 'storage' type.
If supported by the Agent, when cloning instructions are present, the
scope MUST NOT be 'none'. When Ports are present the scope MUST be
'storage' or 'uknown'.
An agent that only accepts 'op' or 'bundle' reference scope messages
is referred to as 'stateless' as it has no direct memory of
references outside messages themselves. This permits low memory
footprint Agents. Even when an Agent supports all message types an
'op' or 'bundle' scoped message can be processed quickly by the Agent
as it does not require storage access.
5.1.1.5. Operation Response
5.1.1.5.1. Immediate 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
ERR - An Error has occurred
OK_NOTIFY_FOLLOWS - The Operation has been accepted by the Agent
but further processing is required. A CONFIG_RESULT_NOTIFY will
be sent once the processing has succeeded or failed.
Any result MAY contain nothing or a entities created or partially
fulfilled as part of the operation as specified in Table 14. For
Clients that need attributes back quickly for call processing, the
AGENT MUST respond back with an OK_NOTIFY_FOLLOWS and minimally the
attributes assigned by the Agent in the response. These situations
MUST be determined through the use of Command Sets (see
Section 5.1.1.3).
If an error occurs the following information is returned.
ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error
type
ERROR_INFORMATION - An OPTIONAL string of no more than 1024
characters.
5.1.1.5.2. Asynchronous Notification
A CONFIG_RESULT_NOTIFY occurs after the Agent has completed
processing related to a CONFIG or CONFIG_BUNDLES request. It is an
asynchronous communication from the Agent to the Client.
The values of the CONFIG_RESULT_NOTIFY are detailed in Table 15.
5.1.2. Monitors
When a monitor has a reporting configuration of SCHEDULED it is
automatically de-registered after the NOTIFY occurs. An Agent or DPN
may temporarily suspend monitoring if insufficient resources exist.
In such a case the Agent MUST notify the Client.
All monitored data can be requested by the Client at any time using
the PROBE message. Thus, reporting configuration is optional and
when not present only PROBE messages may be used for monitoring. If
a SCHEDULED or PERIODIC configuration is provided during registration
with the time related value (time or period respectively) of 0 a
NOTIFY is immediately sent and the monitor is immediately de-
registered. This method should, when a MONITOR has not been
installed, result in an immediate NOTIFY sufficient for the Client's
needs and lets the Agent realize the Client has no further need for
the monitor to be registered. An Agent may reject a registration if
it or the DPN has insufficient resources.
PROBE messages are also used by a Client to retrieve information
about a previously installed monitor. The PROBE message SHOULD
identify one or more monitors by means of including the associated
monitor identifier. An Agent receiving a PROBE message sends the
requested information in a single or multiple NOTIFY messages.
5.2. Protocol Operation
5.2.1. Simple RPC Operation
An FPC Client and Agent MUST identify themself using the CLI_ID and
AGT_ID respectively to ensure that for all transactions a recipient
of an FPC message can unambiguously identify the sender of the FPC
message. A Client MAY direct the Agent to enforce a rule in a
particular DPN by including a DPN_ID value in a Context. Otherwise
the Agent selects a suitable DPN to enforce a Context and notifies
the Client about the selected DPN using the DPN_ID.
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
information, which indicates the result of processing the message,
using the RESPONSE_BODY property. In case the processing of the
message results in a failure, the Agent sets the ERROR_TYPE_ID and
ERROR_INFORMATION accordingly and MAY clear the Context or Port,
which caused the failure, in the response.
If based upon Agent configuration or the processing of the request
possibly taking a significant amount of time the Agent MAY respond
with an OK_NOTIFY_FOLLOWS with an optional RESPONSE_BODY containing
the paritially completed entities. When an OK_NOTIFY_FOLLOWS is
sent, the Agent will, upon completion or failure of the operation,
respond with an asynchronous CONFIG_RESULT_NOTIFY to the Client.
A Client MAY add a property to a Context without providing all
required details of the attribute's value. In such case the Agent
SHOULD determine the missing details and provide the completed
property description back to the Client. If the processing will take
too long or based upon Agent configuration, the Agent MAY respond
with an OK_NOTIFY_FOLLOWS with a RESPONSE_BODY containing the
paritially completed entities.
In case the Agent cannot determine the missing value of an
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,
ERROR_TYPE_ID and ERROR_INFORMATION. As example, the Control-Plane
needs to 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 DPN that supports the Context. The Client adds
the tunnel property attribute to the FPC message and clears the value
of the attribute (e.g. IP address of the local tunnel endpoint).
The Agent determines the tunnel endpoint and includes the completed
tunnel property in its response to the Client.
Figure 17 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.
+-------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)-PRT_ADD---------->| | | | |---(1)--CONFIG(CREATE)--->| |
| | | [PRT_ID] | | | | | [ CONTEXT_ID, |--tun1 up->|
| | | DOWNLINK(QOS/TUN), | |
| | | UPLINK(QOS/TUN), |--tc qos-->|
| | | IP_PREFIX(HNP) ] | |
| | |<---(2)- OK --------------|-route add>|
| | | | | | | | | |
| | |--(2)---PROP_ADD--------->| | |<------------PBA------| | |
| | | [PRT_ID,PROP_TUN] |--tun1 up->|
| | | | | | | | | |
| | |--(3)---PROP_ADD--------->| | | +----+ | | | |
| | | [PRT_ID,PROP_QOS] |--tc qos-->| | |Edge| | | | |
|<------------PBA------|--(4)----TS_ADD---------->| |
| +----+ | | [PRT_ID, |-route add>|
| |Edge| | | TD_CONTAINER(HNP)] | |
| |DPN1| | | | | | |DPN1| | | | |
| +----+ | | | | | +----+ | | | |
| | | | | |
| |-=======================================================-| | |-=======================================================-|
| | | | | | | |
| [MN handover] | | | | [MN handover] | | |
| |---PBU ---->| | | | |---PBU ---->| | |
| | |--(5)---PROP_MOD--------->| | | | |--(3)- CONFIG(MODIFY)---->| |
| |<--PBA------| [PRT_ID,PROP_TUN] |-tun1 mod->| | |<--PBA------| [ CONTEXT_ID |-tun1 mod->|
| | | | | | | | DOWNLINK(TUN), | |
| | +----+ | | | | | +----+ | UPLINK(TUN) ] | |
| | |Edge| | | | | | |Edge| |<---(4)- OK --------------| |
| | |DPN2| | | | | | |DPN2| | | |
| | +----+ | | | | | +----+ | | |
| | | | | | | | | | | |
| | |-============================================-| | | |-============================================-|
| | | | | | | | | |
Figure 14: Exemplary Message Sequence (focus on FPC reference point) Figure 17: Exemplary 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 port 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 Port Identifier (PRT_ID) to the PRT_ADD command. (1) and includes a Context Identifier (CONTEXT_ID) to the CONFIGURE
The LMA-C identifies the selected Anchor DPN by including the command. The LMA-C identifies the selected Anchor DPN by including
associated DPN identifier. the associated DPN identifier.
Subsequently, the LMA-C adds properties to the new port. One The LMA-C adds properties during the creaton of the new Context. One
property is added (2) to specify the forwarding tunnel type and property is added to specify the forwarding tunnel type and endpoints
endpoints (Anchor DPN, Edge DPN1). Another property is added (3) to (Anchor DPN, Edge DPN1) in each direction (as required). Another
specify the QoS differentiation, which the MN's traffic should property is added to specify the QoS differentiation, which the MN's
experience. At reception of the properties, the FPC Agent utilizes traffic should experience. At reception of the Context, the FPC
local configuration commands to create the tunnel (tun1) as well as Agent utilizes local configuration commands to create the tunnel
the traffic control (tc) to enable QoS differentiation. After (tun1) as well as the traffic control (tc) to enable QoS
configuration of port properties have been completed, the LMA binds differentiation. After configuration has been completed, the Agent
the traffic description for the MN's traffic to the port by sending a applies a new route to forward all traffic destined to the MN's HNP
TS_CONTAINER to the Agent and identifying the MN's Nome Network specified as a property in the Context to the configured tunnel
Prefix (HNP) in the traffic descriptor. At the reception of the interface (tun1).
traffic descriptor, the Agent applies a new route to forward all
traffic destined to the MN's HNP to the configured tunnel interface
(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 endpoint. The LMA-C sends a PROP_MOD to represent the new tunnel endpoints in the downlink and uplink, as
message (5) to the Agent to modify the existing tunnel property of requried. The LMA-C sends a CONFIGURE message (3) to the Agent to
the existing port and to update the tunnel endpoint from Edge DPN1 to modify the existing tunnel property of the existing Context and to
Edge DPN2. Upon reception of the PROP_MOD message, the Agent applies update the tunnel endpoint from Edge DPN1 to Edge DPN2. Upon
updated tunnel property to the local configuration. reception of the CONFIGURE message, the Agent applies updated tunnel
property to the local configuration and responds to the Client (4).
To reduce the number of protocol handshakes between the LMA-C and the +-------Router--------+
DPN, the LMA-C can append properties (PROP_TUN, PROP_QOS) and traffic +-----------+ |+-------+ +---------+|
descriptor attributes to the PRT_ADD message, as illustrated in +------+ +------+ +-----+ FPC | | FPC | | Anchor |
Figure 15. |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | |
|-------------PBU----->| | |
| | |---(1)--CONFIG(MODIFY)--->| |
|<------------PBA------| [ CONTEXT_ID, |--tun1 ->|
| | | DOWNLINK(TUN delete), | down |
| | | UPLINK(TUN delete) ] | |
| | | | |
| | |<-(2)- OK ----------------| |
| | | | |
| | [ MinDelayBeforeBCEDelete expires ] | |
| | | | |
| | |---(3)--CONFIG(DELETE)--->|-- tun1 -->|
| | | | delete |
| | |<-(4)- OK ----------------| |
| | | |-- route ->|
| | | | remove |
| | | | |
+-----------+ +-------+ +---------+ Figure 18: Exemplary Message Sequence (focus on FPC reference point)
+------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | |
|-------------PBU----->| | |
| | |----(1)-PRT_ADD----------->| |
| | | [PRT_ID,PROP_TUN, |--tun1 up->|
|<------------PBA------| PROP_QOS, |--tc qos-->|
| | | TS_CONTAINER(HNP)] |-route add>|
| [Edge]-=====================================================-|
| [DPN1| | | | |
| | | | |
| [MN handover] | | |
| |---PBU ---->| | |
| | |---------PROP_MOD--------->| |
| |<--PBA------| [PRT_ID,PROP_TUN] |-tun1 mod->|
| | | | |
| | [Edge]-===========================================-|
| | [DPN2] | | |
Figure 15: Example: Sequence for Message Aggregation (focus on FPC When a teardown of the session occurs, MAG-C1 will send a PBU with a
reference point) lifteime value of zero. The LMA-C sends a CONFIGURE message (1) to
the Agent to modify the existing tunnel property of the existing
Context to delete the tunnel information.) Upon reception of the
CONFIGRE message, the Agent removes the tunnel configuration and
responds to the Client (2). Per [RFC5213], the PBA is sent back
immediately after the PBA is received.
5. Protocol to support Model II If no valid PBA is recieved after the expiration of the
MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a
CONFIGURE (3) message with a deletion request for the Context. Upon
reception of the message, the Agent deletes the tunnel and route on
the DPN and responds to the Client (4).
5.1. Protocol Attributes 5.2.2. Policy And Mobility on the Agent
+---------------------------------------------------------------------+ A Client may build Policy and Topology using any mechanism on the
| Attribute | Format | Description | Agent. Such entities are not always required to be constructed in
+=====================================================================+ realtime and, therefore, there are no specific messages defined for
| IP Tunnel Attributes | them in this specification.
+---------------------------------------------------------------------+
|TUN_SRC_IP_ADDR |[IP address] | Tunnel Source IP |
| | | |
+---------------------------------------------------------------------+
|TUN_DST_IP_ADDR |[IP address] | Tunnel Destination IP |
| | | |
+---------------------------------------------------------------------+
|TUN_ENCAP_TYPE |[ENCAP_GRE, ENACP_UDP,| Encapsulation Type |
| | ENCAP_IP] | |
+---------------------------------------------------------------------+
|TUN_TYPE_UDP |[SRC_PRT, DST_PRT] | UDP Direction - Source |
| | | or Destination |
+---------------------------------------------------------------------+
|TUN_TYPE_GRE |[UPLINK_GRE_KEY, | GRE Tunnel Type |
| | DOWNLINK_GRE_KEY] | |
+---------------------------------------------------------------------+
|TUN_IF_MTU |[MTU] | Tunnel Interface MTU |
| | | |
+---------------------------------------------------------------------+
|TUN_PAYLOAD_TYPE |[PAYLOAD_IPV4, | Tunnel Payload Type |
| | PAYLOAD_IPV6, | |
| | PAYLOAD_DUAL] | |
+---------------------------------------------------------------------+
|TUN_VENDOR_SPEC_PARAM|[OPAQUE] | Tunnel Vendor Specific |
| | | Parameters |
+---------------------------------------------------------------------+
| Route Management Attributes |
+---------------------------------------------------------------------+
|INPUT_IF |[IF_INDEX] |Input Interface |
| | | |
+---------------------------------------------------------------------+
|OUTPUT_IF |[IF_INDEX] |Output Interface |
| | | |
+---------------------------------------------------------------------+
|NEXT_HOP_IP_GW_ADDR |[IP address] |Next Hop IP Gateway |
| | |Address |
+---------------------------------------------------------------------+
|TRAFFIC_SELECTOR_ACL |TBD | |
| | | |
+---------------------------------------------------------------------+
|DST_IP_SUBNET |[IP prefix] |Destination IP Subnet |
| | | |
+---------------------------------------------------------------------+
|DST_IP_SUBNET_MASK |[IP prefix] |Destination IP Subnet |
| | |Mask |
+---------------------------------------------------------------------+
| QoS Attributes |
+---------------------------------------------------------------------+
|AMBR |[Unsigned Integer |Aggregate Maximum |
| | (32 bit)] |Bitrate |
+---------------------------------------------------------------------+
|GBR |[Unsigned Integer |Guaranteed Bitrate |
| | (32 bit)] | |
+---------------------------------------------------------------------+
|TCLASS |[Unsigned Integer |Traffic Class |
| | (32 bit)] | |
+---------------------------------------------------------------------+
|TFT |TBD |Traffic Flow Template |
| | | |
+---------------------------------------------------------------------+
| Optional Attributes |
+---------------------------------------------------------------------+
|NSH_HEADER |[Service Path Id] |NSH Header |
| | Service Index, TFT] | |
+---------------------------------------------------------------------+
Figure 16: Model II Protocol Attributes: Traffic Treatment The Client may add, modify or delete many Ports and Contexts in a
single FPC message. This includes linking Contexts to Actions and
Descriptors, i.e. a Rule. As example, a Rule which performs re-
writing of an arriving packet's destination IP address from IP_A to
IP_B matching an associated Descriptor, can be enforced in the Data-
Plane via an Agent to implicitly consider matching arriving packet's
source IP address against IP_B and re- write the source IP address to
IP_A.
+---------------------------------------------------------------------+ Figure 19 illustrates the generic policy configuration model as used
| Attribute | Format | Description | between a FPC Client and a FPC Agent.
+=====================================================================+
| Identifier |
+---------------------------------------------------------------------+
|TUNNEL_IF_ID |[IF_INDEX] |Tunnel Interface |
| | |Identifier |
+---------------------------------------------------------------------+
|VRF_ID |[Unsigned INT] |VRF Identifier |
+---------------------------------------------------------------------+
|PBR_ID |[Unsigned INT] |Policy Based Routing |
| | |Identifier |
+---------------------------------------------------------------------+
|CTRL_PLANE_ID |IP address |Control-Plane Identifier |
+---------------------------------------------------------------------+
|CONTEXT_ID |TBD |Context Identifier |
+---------------------------------------------------------------------+
|QOS_SERVICE_ID |[Unsigned INT] |QoS Service Identifier |
+---------------------------------------------------------------------+
|SESSION_ID |[Unsigned INT] |Session Identifier |
+---------------------------------------------------------------------+
|ROUTE_ID |[Unsigned INT] |Route Identifier |
+---------------------------------------------------------------------+
| Optional Identifiers |
+---------------------------------------------------------------------+
|SERVICE_PATH_ID |[24-bit identifier] |Service Path Identifier |
+---------------------------------------------------------------------+
Figure 17: Model II Protocol Attributes: Identifiers Descriptor_1 -+ +- Action_1
| |
Descriptor_2 -+--<Rule>--+- Action_2
+------+
/Order#/-------------+
+------+ |
|
Descriptor_3 -+ +- Action_3 +-<PolicyID>
| | | ^
Descriptor_4 -+--<Rule>--+- Action_4 | |
+------+ | <PolicyGroupID>
/Order#/-------------+ ^
+------+ |
<PortID>
5.2. Protocol Messages and Semantics +-------------------+ +---------------------+
| Bind 1..M traffic | | Bind 1..N traffic |
| Descriptors to | --> | treatment actions |
| a Policy, | | to a Policy, |
| Policy-Group and | | Policy-Group and |
| Port | | Port |
+-------------------+ +---------------------+
+---------------------------------------------------------------------+ | |
| Message | Description | +-------------- Data-Plane Rule ------------------+
+=====================================================================+
| Tunnel Interface Management |
+---------------------------------------------------------------------+
| CREATE_TUNNEL_IF | Create a Tunnel Interface |
+---------------------------------------------------------------------+
| DELETE_TUNNEL_IF | Delete a Tunnel Interface |
+---------------------------------------------------------------------+
| UPDATE_TUNNEL_PARAMETER | Update a parameter of the specified |
| | tunnel |
+---------------------------------------------------------------------+
| QUERY_TUNNEL_IF | Request Tunnel Interface information |
+---------------------------------------------------------------------+
| Policy Route Management |
+---------------------------------------------------------------------+
| CREATE_POLICY_ROUTE | Create a Policy-based Route |
+---------------------------------------------------------------------+
| DELETE_POLICY_ROUTE | Deletes a Policy-based Route |
+---------------------------------------------------------------------+
| ADD_TRAFFIC_SELECTOR | Adds a Traffic Selector to a Policy- |
| | based Route |
+---------------------------------------------------------------------+
| DELETE_TRAFFIC_SELECTOR | Removes a Traffic Selector from |
| | a Policy-based Route |
+---------------------------------------------------------------------+
| QUERY_POLICY_ROUTE | Request Policy Route information |
+---------------------------------------------------------------------+
| IP Route Management |
+---------------------------------------------------------------------+
| CREATE_IP_ROUTE | Create an IP Route |
+---------------------------------------------------------------------+
| DELETE_IP_ROUTE | Delete an IP Route |
+---------------------------------------------------------------------+
| QUERY_IP_ROUTE | Request IP Route information |
+---------------------------------------------------------------------+
| IP QoS Management |
+---------------------------------------------------------------------+
| ALLOCATE_QOS_RESOURCES | Allocates QoS Resources, e.g. AMBR, to |
| | the specified Session / Context |
+---------------------------------------------------------------------+
| DEALLOCATE_QOS_RESOURCES | Removes applies QoS Resources from |
| | the specified Session / Context |
+---------------------------------------------------------------------+
| Optional Management |
+---------------------------------------------------------------------+
| ADD_NSH_HEADER | Add NSH Header for the classified |
| | IP flows |
+---------------------------------------------------------------------+
| DELETE_NSH_HEADER | Remove NSH Header for the classified |
| | IP flows |
+---------------------------------------------------------------------+
Figure 18: Model II Protocol Messages Figure 19: Structure of Policies and Ports
5.3. Protocol Operation As depicted in Figure 19, the Port represents the anchor of Rules
through the Policy-group, Policy, Rule heirarchy configured by any
mechanism including RPC or N. A Client and Agent use the identifier
of the associated Policy to directly access the Rule and perform
modifications of traffic Descriptors or Action references. A Client
and Agent use the identifiers to access the Descriptors or Actions to
perform modifications. From the viewpoint of packet processing,
arriving packets are matched against traffic Descriptors and
processed according to the treatment Actions specified in the list of
properties associated with the Port.
The following list comprises a description of each message's A Client complements a rule's Descriptors with a Rule's Order
semantic. (priority) value to allow unambiguous traffic matching on the Data-
Plane.
o CREATE_TUNNEL_IF - Message can include TUN_SRC_IP_ADDR, Figure 20 illustrates the generic context configuration model as used
TUN_DST_IP_ADDR, TUN_ENCAP_TYPE, TUN_IF_ID, TUN_TYPE_UDP, between a FPC Client and a FPC Agent.
TUN_TYPE_GRE, TUN_IF_MTU, TUN_PAYLOAD_TYPE, TUN_VENDOR_SPEC_PARAM,
VRF_ID, CTRL_PLANE_ID, CONTEXT_ID.
o DELETE_TUNNEL_IF - Message can include TUN_SRC_IP_ADDR, TrafficSelector_1
TUN_DST_IP_ADDR, TUN_ENCAP_TYPE, TUN_IF_ID, CTRL_PLANE_ID, |
CONTEXT_ID. profile-parameters
|
mobility-profile-- dl ------+
^ |
| qos-profile
<ContextID1> |
^ per-mn-agg-max-dl_2
|
<ContextID2>
o UPDATE_TUNNEL_PARAMETER - Message can include TUN_SRC_IP_ADDR, +-------------------+ +---------------------+
TUN_DST_IP_ADDR, TUN_ENCAP_TYPE, TUN_IF_ID, TUN_IF_MTU, | Bind 1..M traffic | | Bind 1..N traffic |
TUN_PAYLOAD_TYPE, TUN_VENDOR_SPEC_PARAM, CTRL_PLANE_ID, | selectors to | --> | treatment / qos |
CONTEXT_ID. | a Context | | actions to a |
| | | Context |
+-------------------+ +---------------------+
o QUERY_TUNNEL_IF - | |
+-------------- Data-Plane Rule ------------------+
o CREATE_POLICY_ROUTE - Message can include INPUT_IF, OUTPUT_IF, Figure 20: Structure of Contexts
NEXT_HOP_IP_GW_ADDR, VRF_ID, PBR_ID, CTRL_PLANE_ID, CONTEXT_ID.
o DELETE_POLICY_ROUTE - Message can include PBR_ID, CTRL_PLANE_ID, As depicted in Figure 20, the Context represents a mobiility session
CONTEXT_ID. heirarchy. A Client and Agent directly assigns values such as
dowlink traffic descriptors, QoS information, etc. A Client and
Agent use the context identifiers to access the descriptors, qos
information, etc. to perform modifications. From the viewpoint of
packet processing, arriving packets are matched against traffic
Descriptors and processed according to the qos or other mobility
profile related Actions specified in the Context's properties. If
present, the final action is to use a Context's tunnel information to
encapsulate and forward the packet.
o ADD_TRAFFIC_SELECTOR - Message can include TRAFFIC_SELECTOR_ACL, A second Context also references context1 in the figure. Based upon
PBR_ID, CTRL_PLANE_ID, CONTEXT_ID. the techology a property in a parent context MAY be inherited by its
descendants. This permits concise over the wire representation.
When a Client deletes a parent Context all children are also deleted.
o DELETE_TRAFFIC_SELECTOR - Message can include 5.2.3. Optimization for Current and Subsequent Messages
TRAFFIC_SELECTOR_ACL, PBR_ID, CTRL_PLANE_ID, CONTEXT_ID.
o QUERY_POLICY_ROUTE - 5.2.3.1. Bulk Data in a Single Operation
o CREATE_IP_ROUTE - Message can include DST_IP_SUBNET, A single operation MAY contain multiple entities. This permits
DST_IP_SUBNET_MASK, OUTPUT_IF, VRF_ID, ROUTE_ID, CTRL_PLANE_ID, bundling of requests into a single operation. In the example below
CONTEXT_ID. two PMIP sessions are created via two PBU messages and sent to the
Agent in a single CONFIGURE message (1). Upon receiveing the
message, the Agent responds back with an OK_NOTIFY_FOLLOWS (2),
completes work on the DPN to activate the assocaited sessions then
responds to the Client wiht a CONFIG_RESULT_NOTIFY (3).
o DELETE_IP_ROUTE - Message can include ROUTE_ID, CTRL_PLANE_ID, +-------Router--------+
CONTEXT_ID. +-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+
[MN1 attach] | | | |
|-------------PBU----->| | |
| [MN2 attach] | | |
| |---PBU----->| | |
| | | | |
| | |---(1)--CONFIG(CREATE)--->| |
|<------------PBA------| [ CONTEXT_ID 1, |--tun1 up->|
| | | DOWNLINK(QOS/TUN), | |
| |<--PBA------| UPLINK(QOS/TUN), |--tc1 qos->|
| | | IP_PREFIX(HNP) ] | |
| | | [ CONTEXT_ID 2, |-route1 |
| | | DOWNLINK(QOS/TUN), | add> |
| | | UPLINK(QOS/TUN), | |
| | | IP_PREFIX(HNP) ] |--tun2 up->|
| | |<-(2)- OK_NOTIFY_FOLLOWS--| |
| | | |--tc2 qos->|
|<------------PBA------| | |
| | | |-route2 |
| | |<(3) CONFIG_RESULT_NOTIFY | add> |
| | | [ Response Data ] | |
| | | | |
| | | | |
o QUERY_IP_ROUTE - Figure 21: Exemplary Bulk Entity with Asynchronous Notification
Sequence (focus on FPC reference point)
o ALLOCATE_QOS_RESOURCES - Message can include AMBR, GBR, TCLASS, 5.2.3.2. Configuration Bundles
TFT, QOS_SERVICE_ID, CONTEXT_ID.
o DEALLOCATE_QOS_RESOURCES - Message can include Session_ID, Bundles provide transaction boundaries around work in a single
QOS_SERVICE_ID, CONTEXT_ID. 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.
o ADD_NSH_HEADER - Message can include SERVICE_PATH_ID, The example bundle shows in Operation 1 (OP 1) the creation of a
SERVICE_INDEX, TFT 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 CONFIGURE_BUNDLES is preservation of dependency
orders in a single message as opposed to sending multiple CONFIGURE
messages and awaiting results from the Agent.
o DELETE_NSH_HEADER - Message can include SERVICE_PATH_ID, When a CONFIGURE_BUNDLES fails, any entities provisioned in the
SERVICE_INDEX, TFT CURRENT operation are removed, however, any successful operations
completed prior to the current operation are preserved in order to
reduce system load.
6. Security Considerations +-------Router--------+
+-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor |
| Client | | Agent | | DPN |
+-----------+ +-------+ +---------+
| | |
|-CONFIG_BUNDLES(CREATE)-->| |
| [ OP 1, [PORT X ] | |
| [ CONTEXT_ID 1, | |
| DOWNLINK(QOS/TUN), | |
| UPLINK(QOS/TUN), | |
| IP_PREFIX(HNP) ] | |
| [ OP 2, | |
| [ CONTEXT_ID 2, | |
| PARENT_CONTEXT_ID 1, | |
| UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ] ] | |
| | |
Figure 22: Exemplary Bundle Message (focus on FPC reference point)
5.2.3.3. Cloning Feature (Optional)
Cloning provides a high speed copy/paste mechanism. The example
below shows a single Context that will be copied two times. A
subsequent update then overrides the value. The avoid the accidental
activation of the Contexts on the DPN, the CONFIGURE (1) message with
the cloning instruction has a SESSION_STATE with a value of
'incomplete' and OP_TYPE of 'CREATE'. A second CONFIGURE (2) is sent
with the SESSION_STATE of 'complete' and OP_TYPE of 'UPDATE'. The
second message includes any differences between the original (copied)
Context and its Clones.
+-------Router--------+
+-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor |
| Client | | Agent | | DPN |
+-----------+ +-------+ +---------+
| | |
|-CONFIG_BUNDLES(CREATE)-->| |
| [ OP 1, | |
| [ SESSION_STATE | |
| (incomplete) ], | |
| [CLONE SRC=2, TARGET=3], | |
| [CLONE SRC=2, TARGET=4], | |
| [ CONTEXT_ID 2, | |
| PARENT_CONTEXT_ID 1, | |
| UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN), | |
| IP_PREFIX(HNP) ] ] | |
|<----- OK ----------------| |
| | |
|-CONFIG_BUNDLES(UPDATE)-->| |
| [ CONTEXT_ID 3, | |
| PARENT_CONTEXT_ID(empty),| |
| UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ], | |
| [ CONTEXT_ID 4, | |
| PARENT_CONTEXT_ID(empty),| |
| UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ] ] | |
|<----- OK ----------------| |
| | |
Figure 23: Exemplary Bundle Message (focus on FPC reference point)
Cloning has the added advantage of reducing the over the wire data
size required to create multiple entities. This can improve
performance if serializaiton / deserialization of multiple entities
incurs some form of performance penalty.
5.2.3.4. Command Bitsets (Optional)
Command Sets permit the ability to provide a single, unified data
structure, e.g. 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 sitations can increase the time to error
detection and overall system load withouth the Command Set
present.
o Unambiguous provisioning specification. The Agent is exactily 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
sent in the same message.
As Command Bitsets are technology specfic, 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 statless 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.5. Reference Scope(Optional)
Although entities MAY refer to any other entity of an appropriate
type, e.g. Contexts can refer to Ports or 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 CONFIG_BUNDLES
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 CONFIG_BUNDLES 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 CONFIG_BUNDLES 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 heirarchy 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 24 shows an example cache where each Cache where a
containment heirarchy is 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 24: Exemplary Heirarchical Cache
5.2.4. Pre-provisioning
Although Contexts are used for Session based lifecycle elements,
Ports may exist outside of a specific lifecycle and represent more
general policies that may affect multiple Contexts (sessions). The
use of pre-provisioning of Ports permits policy and administrative
use cases to be exected. For example, creating tunnels to forward
traffic to a trouble management platform and dropping packets to a
defective web server can be accomplished via provisioning of Ports.
The figure below shows a CONFIGURE (1) message used to install a
Policy-group, policy-group1, using a Context set aside for pre-
provisioning on a DPN.
+-------Router--------+
+-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor |
| Client | | Agent | | DPN |
+-----------+ +-------+ +---------+
| | |
|------CONFIG(CREATE)----->| |
| [ PORT_ID port1, | |
| [ policy-group1 ] ] | |
| [ CONTEXT_ID preprov, | |
| DPN_ID X, | |
| [ port1 ] ] | |
| | |
Figure 25: Exemplary Bundle Message (focus on FPC reference point)
5.2.4.1. 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
6.1.1. Policy Structures
+--------------+-----------------+----------------------------+
| Structure | Field | Type |
+--------------+-----------------+----------------------------+
| ACTION | ACTION_ID | FPC-Identity (Section 4.4) |
| | | |
| ACTION | TYPE | [32, unsigned integer] |
| | | |
| ACTION | VALUE | Type specific |
| | | |
| DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 4.4) |
| | | |
| DESCRIPTOR | TYPE | [32, unsigned integer] |
| | | |
| DESCRIPTOR | VALUE | Type specific |
| | | |
| POLICY | POLICY_ID | FPC-Identity (Section 4.4) |
| | | |
| POLICY | RULES | *[ RULE ] (See Table 4) |
| | | |
| POLICY-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 4.4) |
| | | |
| POLICY-GROUP | POLICIES | *[ POLICY_ID ] |
+--------------+-----------------+----------------------------+
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 |
+------------------+---------------+--------------------------------+
| ORDER | [16, INTEGER] | |
| | | |
| RULE_DESCRIPTORS | *[ | DIRECTION [2, unsigned bits] |
| | DESCRIPTOR_ID | is an ENUMERATION (uplink, |
| | DIRECTION ] | downlink or both). |
| | | |
| RULE_ACTIONS | *[ ACTION_ID | ORDER [8, unsigned integer] |
| | ORDER ] | specifies action execution |
| | | order. |
+------------------+---------------+--------------------------------+
Table 4: Rule Fields
6.1.2. Mobilty Structures
+----------+----------------------------+
| Field | Type |
+----------+----------------------------+
| PORT_ID | FPC-Identity (Section 4.4) |
| | |
| POLICIES | *[ POLICY_GROUP_ID ] |
+----------+----------------------------+
Table 5: Port Fields
+------------------------+------------------------------------+
| Field | Type |
+------------------------+------------------------------------+
| CONTEXT_ID | FPC-Identity (Section 4.4) |
| | |
| PORTS | *[ PORT_ID ] |
| | |
| DPN_GROUP_ID | FPC-Identity (Section 4.4) |
| | |
| DELEGATING IP PREFIXES | *[ IP_PREFIX ] |
| | |
| PARENT_CONTEXT_ID | FPC-Identity (Section 4.4) |
| | |
| UPLINK [NOTE 1] | MOB_FIELDS |
| | |
| DOWNLINK [NOTE 1] | MOB_FIELDS |
| | |
| DPNS [NOTE 2] | *[ DPN_ID DPN_DIRECTION MOB_FIELDS |
| | |
| MOB_FIELDS | All parameters from Table 7 |
+------------------------+------------------------------------+
Table 6: Context Fields
NOTE 1 - These fields are present when the Agent supports only a
single DPN.
NOTE 2 - This fields is present when the Agent supports multiple
DPNs.
+---------------------------+---------------------+-----------------+
| 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 | [ IP Address | MAC | [NOTE 1] |
| | Address | SPI | | |
| | MPLS Label | SID | | |
| | Interface Index ] | |
| | (See Table 19). | |
| | | |
| QOS_PROFILE_PARAMS | [ 3GPP_QOS | | [NOTE 1] |
| | PMIP_QOS ] | |
| | | |
| DPN_SPECIFIC_PARAMS | [ TUN_IF or Varies] | Specifies |
| | | optional node |
| | | specific |
| | | parameters in |
| | | need such as |
| | | if-index, |
| | | tunnel-if- |
| | | number that |
| | | must be unique |
| | | in the DPN. |
| | | |
| VENDOR_SPECIFIC_PARAM | *[ Varies ] | [NOTE 1] |
+---------------------------+---------------------+-----------------+
NOTE 1 - These parameters are extensible. The Types may be extended
for Field value by future specifications or in the case of Vendor
Specific Attributes by enterprises.
Table 7: Context Downlink/Uplink Field Definitions
6.1.3. Topology Structures
+----------------+------------------------------------+
| Field | Type |
+----------------+------------------------------------+
| DPN_ID | FPC-Identity. See Section 4.4 |
| | |
| DPN_NAME | [1024, OCTET STRING] |
| | |
| DPN_GROUPS | * [ FPC-Identity ] See Section 4.4 |
| | |
| NODE_REFERENCE | [1024, OCTET STRING] |
+----------------+------------------------------------+
Table 8: DPN Fields
+-------------+----------------------+
| Field | Type |
+-------------+----------------------+
| DOMAIN_ID | [1024, OCTET STRING] |
| | |
| DOMAIN_NAME | [1024, OCTET STRING] |
| | |
| DOMAIN_TYPE | [1024, OCTET STRING] |
+-------------+----------------------+
Table 9: Domain Fields
+------------------+------------------------------------------------+
| Field | Type |
+------------------+------------------------------------------------+
| DPN_GROUP_ID | FPC-Identity. See Section 4.4 |
| | |
| DATA_PLANE_ROLE | [4, ENUMERATION (data-plane, such as access- |
| | dpn, L2/L3 anchor-dpn.)] |
| | |
| ACCESS_TYPE | [4, ENUMERATION ()ethernet(802.3/11), 3gpp |
| | cellular(S1,RAB)] |
| | |
| MOBILITY_PROFILE | [4, ENUMERATION (ietf-pmip, 3gpp, or new |
| | profile)] |
| | |
| PEER_DPN_GROUPS | * [ DPN_GROUP_ID MOBILITY_PROFILE |
| | REMOTE_ENDPOINT_ADDRESS LOCAL_ENDPOINT_ADDRESS |
| | TUN_MTU DATA_PLANE_ROLE ] |
+------------------+------------------------------------------------+
Table 10: DPN Groups Fields
6.1.4. Monitors
+------------------+----------------------+-------------------------+
| Field | Type | Description |
+------------------+----------------------+-------------------------+
| MONITOR | MONITOR_ID TARGET | |
| | [REPORT_CONFIG] | |
| | | |
| MONITOR_ID | FPC-Identity. See | |
| | Section 4.4 | |
| | | |
| EVENT_TYPE_ID | [8, Event Type ID] | Event Type (unsigned |
| | | integer). |
| | | |
| TARGET | OCTET STRING (See | |
| | Section 4.3.3) | |
| | | |
| 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 11: Monitor Structures and Attributes
TRIGGERS include but are not limited to the following values:
o Events specified in the Event List of an EVENTS CONFIG
o LOW_THRESHOLD_CROSSED
o HIGH_THRESHOLD_CROSSED
o PERIODIC_REPORT
o SCHEDULED_REPORT
o PROBED
o DEREG_FINAL_VALUE
6.2. Message Attributes
6.2.1. Header
Each operation contains a header with the following fields:
+-------------+------------------------+----------------------------+
| Field | Type | Messages |
+-------------+------------------------+----------------------------+
| CLIENT_ID | FPC-Identity (Section | All |
| | 4.4) | |
| | | |
| DELAY | [32, unsigned integer] | All |
| | | |
| OP_ID | [64, unsigned integer] | All |
| | | |
| ADMIN_STATE | [8, admin state] | CONF, CONF_BUNDLES and |
| | | REG_MONITOR |
| | | |
| OP_TYPE | [8, op type] | CONF and CONF_BUNDLES |
+-------------+------------------------+----------------------------+
Table 12: Message Header Fields
6.2.2. CONF and CONF_BUNDLES Attributes and Notifications
+---------------+-----------------------+---------------------------+
| Field | Type | Operation Types |
| | | Create(C), Update(U), |
| | | Query(Q) and Delete(D) |
+---------------+-----------------------+---------------------------+
| SESSION_STATE | [8, session state] | C,U |
| | | |
| COMMAND_SET | FPC Command Bitset. | C,U |
| (1) | See Section 5.1.1.3. | |
| | | |
| CLONES (1) | *[ FPC-Identity FPC- | C,U |
| | Identity ] (Section | |
| | 4.4) | |
| | | |
| PORTS | *[ PORT ] | C,U |
| | | |
| CONTEXTS | *[ CONTEXT [ | C,U |
| | COMMAND_SET (1) ] ] | |
| | | |
| TARGETS | FPC-Identity (Section | Q,D |
| | 4.4) *[DPN_ID] | |
+---------------+-----------------------+---------------------------+
(1) - Only present if the corresponding feature is supported by the
Agent.
Table 13: CONF and CONF_BUNDLES OP_BODY Fields
+----------+-----------------------+--------------------------------+
| Field | Type | Operation Types Create(C), |
| | | Update(U), Query(Q) and |
| | | Delete(D) |
+----------+-----------------------+--------------------------------+
| PORTS | *[ PORT ] | C,U |
| | | |
| CONTEXTS | *[ CONTEXT [ | C,U |
| | COMMAND_SET (1) ] ] | |
| | | |
| TARGETS | *[ FPC-Identity | Q,D |
| | (Section 4.4) | |
| | *[DPN_ID] ] | |
+----------+-----------------------+--------------------------------+
(1) - Only present if the corresponding feature is supported by the
Agent.
Table 14: Immediate Response RESPONSE_BODY Fields
If an error occurs the following information is returned.
ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error
type
ERROR_INFORMATION - An OPTIONAL string of no more than 1024
characters.
+-----------------+--------------------+----------------------------+
| Field | Type | Description |
+-----------------+--------------------+----------------------------+
| AGENT_ID | FPC-Identity | |
| | (Section 4.4) | |
| | | |
| NOTIFICATION_ID | [32, unsigned | A Notification Identifier |
| | integer] | used to determine |
| | | notification order. |
| | | |
| TIMESTAMP | [32, unsigned | The time that the |
| | integer] | notification occured. |
| | | |
| DATA | *[ OP_ID | |
| | RESPONSE_BODY | |
| | (Table 14) ] | |
+-----------------+--------------------+----------------------------+
Table 15: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields
6.2.3. Monitors
+-----------------+---------------------+---------------------------+
| Field | Type | Description |
+-----------------+---------------------+---------------------------+
| NOTIFICATION_ID | [32, unsiged | |
| | integer] | |
| | | |
| TRIGGER | [32, unsigned | |
| | integer] | |
| | | |
| NOTIFY | NOTIFICATION_ID | Timestamp notes when the |
| | MONITOR_ID TRIGGER | event occurred. |
| | [32, timestamp] | Notification Data is |
| | [NOTIFICATION_DATA] | TRIGGER and Monitor type |
| | | specific. |
+-----------------+---------------------+---------------------------+
Table 16: Monitor Notifications
7. Derived and Subtyped Attributes
This section notes derived attributes.
+------------------+-------+---------------+------------------------+
| Field | Type | Type | Description |
| | Value | | |
+------------------+-------+---------------+------------------------+
| TO_PREFIX | 0 | [IP Address] | Aggregated or per-host |
| | | [ Prefix Len | destination IP |
| | | ] | address/prefix |
| | | | descriptor. |
| | | | |
| FROM_PREFIX | 1 | [IP Address] | Aggregated or per-host |
| | | [ Prefix Len | source IP |
| | | ] | address/prefix |
| | | | descriptor. |
| | | | |
| TRAFFIC_SELECTOR | 2 | Format per | Traffic Selector. |
| | | specification | |
| | | [RFC6088]. | |
+------------------+-------+---------------+------------------------+
Table 17: Descriptor Subtypes
+--------------+-------+---------------------+----------------------+
| Field | Type | Type | Description |
| | Value | | |
+--------------+-------+---------------------+----------------------+
| DROP | 0 | Empty | Drop the associated |
| | | | packets. |
| | | | |
| REWRITE | 1 | [in_src_ip] | Rewrite IP Address |
| | | [out_src_ip] | (NAT) or IP Address |
| | | [in_dst_ip] | / Port (NAPT). |
| | | [out_dst_ip] | |
| | | [in_src_port] | |
| | | [out_src_port] | |
| | | [in_dst_port] | |
| | | [out_dst_port] | |
| | | | |
| COPY_FORWARD | 2 | FPC-Identity. See | Copy all packets and |
| | | Section 4.4. | forward them to the |
| | | | provided identity. |
| | | | The value of the |
| | | | identity MUST be a |
| | | | port or context. |
+--------------+-------+---------------------+----------------------+
Table 18: Action Subtypes
+-----------------+-------+-------------------+---------------------+
| Field | Type | Type | Description |
| | Value | | |
+-----------------+-------+-------------------+---------------------+
| 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_ID] | Included NSH which |
| | | [8, unsigned | is a SPI and |
| | | integer] | Service Index (8 |
| | | | bits). |
| | | | |
| INTERFACE_INDEX | 5 | [16, unsigned | Interface Index (an |
| | | integer] | unsigned integer). |
+-----------------+-------+-------------------+---------------------+
Table 19: Next Hop Subtypes
+----------+-------+------------------+-----------------------------+
| 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 20: QoS Subtypes
+----------+---------+----------------+-----------------------------+
| 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 21: Tunnel Subtypes
The following COMMAND_SET values are supported for IETF_PMIP.
o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node.
o session - Assign values for the Session Level.
o uplink - Command applies to uplink.
o downlink - Command applies to downlink.
7.1. 3GPP Specific Extenstions
3GPP support is optional and detailed in this section. The following
acronyms are used:
APN-AMBR: Access Point Name Aggregate Maximum Bit Rate
ARP: Allocation of Retention Priority
EBI: EPS Bearer Identity
GBR: Guaranteed Bit Rate
GTP: GPRS (General Packet Radio Service) Tunneling Protocol
IMSI: International Mobile Subscriber Identity
MBR: Maximum Bit Rate
QCI: QoS Class Identifier
TEID: Tunnel Endpoint Identifier.
TFT: Traffic Flow Template (TFT)
UE-AMBR: User Equipment Aggregate Maximum Bit Rate
NOTE: GTP Sequence Number (SEQ_NUMBER) is used in failover and
handover.
+-------------+-------+-------------+-------------------------------+
| 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 22: 3GPP Attributes and Structures
The following COMMAND_SET values are supported for 3GPP.
o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node.
o assign-fteid-ip - Assign the Fully Qualified TEID (F-TEID) LOCAL
IP address.
o assign-fteid-teid - Assign the Fully Qualified TEID (F-TEID) LOCAL
TEID.
o session - Assign values for the Session Level. When this involves
'assign-fteid-ip' and 'assign-fteid-teid' this implies the values
are part of the default bearer.
o uplink - Command applies to uplink.
o downlink - Comman applies to downlink.
8. Implementation Status
Two FPC Agent implementations have been made to date. The first was
based upon Version 03 of the draft and followed Model 1. The second
follows Version 04 of the document. Both implementations were
OpenDaylight plug-ins developed in Java by Sprint. Version 03 was
known as fpcagent and version 04's implementation is simply referred
to as 'fpc'.
fpcagent's intent was to provide a proof of concept for FPC Version
03 Model 1 in January 2016 and research various optimiziations,
errors, corrections and optimizations that the Agent could make when
supporting multiple DPNs.
As the code developed to support OpenFlow and a proprietary DPN from
a 3rd party, several of the advantages of a multi-DPN Agent became
obvious including the use of machine learning to reduce the number of
Flows and Policy entities placed on the DPN. This work has driven
new efforts in the DIME WG, namely Diameter Policy Groups
[I-D.bertz-dime-policygroups].
A throughput performance of tens per second using various NetConf
based solutions in OpenDaylight made fpcagent undesirable for call
processing. The RPC implementration improved throughput by an order
of magnitude but was not useful based upon FPC's Version 03 design
using either model. During this time the features of version 04 and
its converged model became attractive and teh fpcagent project was
closed in August 2016. fpcagent will no longer be developed and will
remain a proprietary implemenation.
The learnings of fpcagent has influenced the second project, fpc.
Fpc is also an OpenDaylight project but is intended for open source
release, if circumstances permit. It is also scoped to be a fully
compliant FPC Agent that supports multiple DPNs including those that
communicate via OpenFlow. The following features present in this
draft and developed by the FPC co-authors have already lead to an
order of magnitude improvement.
Migration of non-realtime provisioning of entities such as
topology and policy allowed the implementation to focus only on
the rpc.
Using only 5 messages and 2 notifications has also reduced
implementation time. As of this writing the project is 4 weeks
old and currently supports CONFIGURE and CONFIGURE_BUNDLES based
upon the effort of 3 part time engineers.
Command Sets, an optional feature in this specfication, have
eliminated 80% of the time spent determining what needs to be
done with a Context during a Create or Update operation.
The addition of the DPN List in a Context Delete operation
permits the Agent to avoid lookups of Context data in the Cache
entirely. For 3GPP support, extra attributes are required in the
Delete to avoid any cache lookup.
Op Reference is an optional feature modeled after video delivery.
It has reduced unnecessary cache lookups. It also has the
additional benefit of allowing an Agent to become cacheless and
effectively act as a FPC protocol adapater remotely with multi-
DPN support or colocated on the DPN in a single-DPN support
model.
Multi-tenant support allows for Cache searches to be partitioned
for clustering and perforamnce improvements. This has not been
capitalized upon by the current implementation but is part of the
development roadmap.
Use of Contexts to pre-provision policy has also eliminated any
processing of Ports for DPNs which permitted the code for
CONFIGURE and CONFIGURE_BUNDLES to be implemented as a simple
nested FOR loops (see below).
Current performance results without code optimizations or tuning
allow 2-5K FPC Contexts processed per second on a Mac laptop sourced
in 2013. This results in 2x the number of transactions on the
southbound interface to a proprietary DPN API on the same machine.
fpc currently supports the following after 3 weeks of development by
two part time engineers:
1 proprietary DPN API
Policy and Topology as defined in this
specification using OpenDaylight North Bound
Interfaces such as NetConf and RestConf
CONFIGURE and CONFIGURE_BUNDLES (all
operations)
DPN assignment, Tunnel allocations and IPv4
address assignment by the Agent or Client.
Immediate Response is always an
OK_NOTIFY_FOLLOWS.
assignment system (receives rpc call):
perform basic operation integrity check
if CONFIGURE then
goto assignments
if assignments was ok then
send request to activation system
respond back to client with assignment data
else
send back error
end if
else if CONFIGURE_BUNDLES then
for each operation in bundles
goto assignments
if assignments was ok then
hold onto data
else
return error with the assignments that occurred in
prior operations (best effort)
end if
end for
send bundles to activation systems
end if
assignments:
assign DPN, IPv4 Address and/or tunnel info as requried
if an error occurs undo all assigments in this operation
return result
activation system:
build cache according to op-ref and operation type
for each operation
for each Context
for each DPN / direction in Context
perform actions on DPN according to Command Set
end for
end for
end for
commit changes to in memory cache
log transaction for tracking and nofication (CONFIG_RESULT_NOTIFY)
Figure 26: fpc pseudo code
As of this writing (Sept 2016) the implementation is 3 weeks old an
considered pre-alpha. It is scheduled to be conformant to all FPC
version 04 aspects within 60 days.
For further information please contact Lyle Bertz who is also a co-
author of this document.
NOTE: Tenant support requires binding a Client ID to a Tenant ID (it
is a one to many relation) but that is outside of the scope of this
specification. Otherwise, the specification is complete in terms of
providing sufficient information to implement an Agent.
9. 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.
7. IANA Considerations 10. IANA Considerations
This document provides a data model and protocol operation for DMM This document provides a data model and protocol operation for DMM
Forwarding Policy Configuration. YANG models are currently included Forwarding Policy Configuration. YANG models are currently included
in the Appendix and will be updated per the next revision of this in the Appendix and will be updated per the next revision of this
document to specify the data model as well as to enable an document to specify the data model as well as to enable an
implementation of the FPC protocol using RPC. implementation of the FPC protocol using RPC.
No actions from IANA are required. In case the semantics of this No actions from IANA are required. In case the semantics of this
specification will be mapped to a particular wire protocol, authors specification will be mapped to a particular wire protocol, authors
of an associated separate document will approach IANA for the of an associated separate document will approach IANA for the
associated action to create a registry or add registry entries. associated action to create a registry or add registry entries.
8. Work Team Participants 11. 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.
9. References 12. References
9.1. Normative References 12.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc6088>. <http://www.rfc-editor.org/info/rfc6088>.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
DOI 10.17487/RFC6089, January 2011,
<http://www.rfc-editor.org/info/rfc6089>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<http://www.rfc-editor.org/info/rfc7333>. <http://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 12.2. Informative References
CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015,
<http://www.rfc-editor.org/info/rfc7429>.
9.2. Informative References [I-D.bertz-dime-policygroups]
Bertz, L., "Diameter Policy Groups and Sets", draft-bertz-
dime-policygroups-01 (work in progress), July 2016.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", [I-D.ietf-dmm-deployment-models]
RFC 3344, DOI 10.17487/RFC3344, August 2002, Gundavelli, S. and S. Jeon, "DMM Deployment Models and
<http://www.rfc-editor.org/info/rfc3344>. Architectural Considerations", draft-ietf-dmm-deployment-
models-00 (work in progress), August 2016.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-16 (work in
progress), August 2016.
[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,
<http://www.rfc-editor.org/info/rfc5213>. <http://www.rfc-editor.org/info/rfc5213>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[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,
<http://www.rfc-editor.org/info/rfc7222>. <http://www.rfc-editor.org/info/rfc7222>.
Appendix A. YANG Data Model for the FPC protocol Appendix A. YANG Data Model for the FPC protocol
These modules define Model I YANG definitions. Four modules are These modules define YANG definitions. Seven modules are defined:
defined:
o ietf-dmm-fpcp-base (fpcp-base) - Defines the base model for Model o ietf-dmm-fpcbase (fpcbase) - Defines the base model for model as
I FPC as defined in this document defined in this document
o ietf-dmm-fpcagent (fpcagent) - Defines the FPC Agent entites and
messages as defined in this document
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-traffic-selectors-types (traffic-selectors) - Defines Traffic o ietf-traffic-selectors-types (traffic-selectors) - Defines Traffic
Selectors per RFC 6088 Selectors per RFC 6088
o ietf-dmm-fpcp-pmip - Augments fpcp-base to include PMIP Traffic o ietf-dmm-threegpp - Defines the base structures for 3GPP based IP
mobility and augments fpcagent to support these parameters.
o ietf-dmm-fpc-pmip - Augments fpcp-base to include PMIP Traffic
Selectors as a Traffic Descriptor subtype and pmip-qos QoS Selectors as a Traffic Descriptor subtype and pmip-qos QoS
parameters, where applicable, as properties. parameters, where applicable, as properties.
Note (2016-03-21): The YANG Data Model does not yet adopt all o ietf-dmm-fpc-policyext - defines basic policy extensions, e.g.
extensions per this version of the draft and will be updated shortly Actions and Descriptors, to fpcbase and as defined in this
after the IETF95 meeting. document.
A.1. FPC Base A.1. YANG Models
A.1.1. FPC Base YANG Model A.1.1. FPC Base YANG Model
module ietf-dmm-fpcp-base { module ietf-dmm-fpcbase {
namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpcp-base"; namespace "urn:ietf:params:xml:ns:yang:fpcbase";
prefix fpcp-base; prefix fpcbase;
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; revision-date 2013-07-15; }
organization "IETF DMM Working Group"; organization "IETF DMM Working Group";
contact "Satoru Matsushima <satoru.matsushima@g.softbank.co.jp>"; contact "Satoru Matsushima <satoru.matsushima@g.softbank.co.jp>";
description description
"This module contains YANG definition for "This module contains YANG definition for
Forwarding Policy Configuration Protocol.(FPCP)"; Forwarding Policy Configuration Protocol.(FPCP)";
revision 2016-01-18 { revision 2016-08-03 {
description "Changes based on -01 version of FPCP draft."; description "Changes based on -04 version of FPC draft.";
reference "draft-ietf-dmm-fpc-cpdp-01"; reference "draft-ietf-dmm-fpc-cpdp-04";
} }
feature fpc-basic-agent {
description "This is an agent co-located with a DPN. In this case
only DPN Peer Groups, the DPN Id and Control Protocols are exposed
along with the core structures.";
}
feature fpc-multi-dpn {
description "The agent supports multiple DPNs.";
}
typedef fpcp-name-type { typedef fpc-identity {
type string; type union {
description "FPCP common name type"; type uint32;
} type string;
type instance-identifier;
}
}
typedef fpcp-carrier-id { grouping target-value {
type uint16; leaf target {
description "Carrier-ID"; type fpc-identity;
} }
}
typedef fpcp-network-id { grouping targets-value {
type uint16; list targets {
description "Carrier-ID"; key "target";
leaf target {
type fpc-identity;
}
leaf dpn-id {
type fpcbase:fpc-dpn-id;
}
} }
}
typedef fpcp-client-id { // Descriptor Structure
type uint32; typedef fpc-descriptor-id-type {
description "Client-ID"; type fpcbase:fpc-identity;
description "Descriptor-ID";
}
identity fpc-descriptor-type {
description "A traffic descriptor";
}
grouping fpc-descriptor-id {
leaf descriptor-id {
type fpcbase:fpc-identity;
} }
}
grouping fpc-descriptor {
uses fpcbase:fpc-descriptor-id;
leaf descriptor-type {
mandatory true;
type identityref {
base "fpc-descriptor-type";
}
description "Descriptor Type";
}
choice descriptor-value {
case all-traffic {
leaf all-traffic {
type empty;
}
}
}
}
typedef fpcp-agent-id { // Action Structure
type uint32; typedef fpc-action-id-type {
description "Agent-ID"; type fpcbase:fpc-identity;
description "Action-ID";
}
identity fpc-action-type {
description "Action Type";
}
grouping fpc-action-id {
leaf action-id {
type fpcbase:fpc-action-id-type;
} }
}
grouping fpc-action {
uses fpcbase:fpc-action-id;
leaf action-type {
mandatory true;
type identityref {
base "fpc-action-type";
}
description "Action Type";
}
choice action-value {
case drop {
leaf drop {
type empty;
}
}
}
}
// Rule Structure
grouping fpc-rule {
description
"FPC Rule. When no actions are present the action is DROP.
When no Descriptors are empty the default is 'all traffic'.";
list descriptors {
key descriptor-id;
uses fpcbase:fpc-descriptor-id;
leaf direction {
type fpc-direction;
}
}
list actions {
key action-id;
leaf order {
type uint32;
}
uses fpcbase:fpc-action-id;
}
}
typedef fpcp-dpn-id { // Policy Structures
type uint32; typedef fpc-policy-id {
description "Carrier-ID"; type fpcbase:fpc-identity;
} }
grouping fpc-policy {
leaf policy-id {
type fpcbase:fpc-policy-id;
}
list rules {
key order;
leaf order {
type uint32;
}
uses fpcbase:fpc-rule;
}
}
typedef fpcp-port-id { // Policy Group
type uint32; typedef fpc-policy-group-id {
description "PRT_ID"; type fpcbase:fpc-identity;
}
grouping fpc-policy-group {
leaf policy-group-id {
type fpcbase:fpc-policy-group-id;
} }
leaf-list policies {
type fpcbase:fpc-policy-id;
typedef fpcp-property-id {
type uint8;
description "PRT_PROP_ID";
} }
}
typedef fpcp-rule-id { // Mobility Structures
type uint8; // Port Group
description "PRT_RULE_ID"; typedef fpc-port-id {
} type fpcbase:fpc-identity;
}
grouping fpc-port {
leaf port-id {
type fpcbase:fpc-port-id;
}
leaf-list policy-groups {
type fpcbase:fpc-policy-group-id;
}
}
typedef fpcp-qos-class-identifier { // Context Group
type uint8 { typedef fpc-context-id {
range "1..9"; type fpcbase:fpc-identity;
} }
description "QCI"; grouping fpc-context-profile {
} description "A profile that applies to a specific direction";
leaf tunnel-local-address {
type inet:ip-address;
description "Uplink endpoint address of the DPN which agent exists.";
}
leaf tunnel-remote-address {
type inet:ip-address;
description "Uplink endpoint address of the DPN which agent exists.";
}
leaf tunnel-mtu-size {
type uint32;
description "Tunnel MTU size";
}
container mobility-tunnel-parameters {
description "Specifies profile specific uplink tunnel parameters to the DPN which the agent exists. The profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf-pmip profile, or new profile if anyone will define it.";
uses fpcbase:mobility-info;
}
container nexthop {
uses fpcbase:fpc-nexthop;
}
container qos-profile-parameters {
uses fpcbase:fpc-qos-profile;
}
container dpn-parameters {
}
list vendor-parameters {
key "vendor-id vendor-type";
uses fpcbase:vendor-attributes;
}
}
typedef fpcp-qos-bandwidth { typedef fpc-direction {
type uint32; type enumeration {
description "Bandwith value in bit per second."; enum uplink;
} enum downlink;
}
}
identity tunnel-type { grouping fpc-context {
description leaf context-id {
"Base identity from which specific use of type fpcbase:fpc-context-id;
tunnels are derived."; }
} leaf-list ports {
type fpcbase:fpc-port-id;
}
leaf dpn-group {
type fpcbase:fpc-dpn-group-id;
}
leaf-list delegating-ip-prefixes {
type inet:ip-prefix;
}
container ul {
if-feature fpcbase:fpc-basic-agent;
uses fpcbase:fpc-context-profile;
}
container dl {
if-feature fpcbase:fpc-basic-agent;
uses fpcbase:fpc-context-profile;
}
list dpns {
if-feature fpcbase:fpc-multi-dpn;
key "dpn-id direction";
leaf dpn-id {
type fpcbase:fpc-dpn-id;
}
leaf direction {
mandatory true;
type fpcbase:fpc-direction;
}
uses fpcbase:fpc-context-profile;
}
leaf parent-context {
type fpcbase:fpc-context-id;
}
identity fpcp-tunnel-type { }
base "tunnel-type";
description
"Base identity from which specific tunnel
types in FPCP uses are derived.";
}
identity ip-in-ip { // Mobility (Tunnel) Information
base "fpcp-tunnel-type"; grouping mobility-info {
description "IP-in-IP tunnel"; choice profile-parameters {
} case nothing {
leaf none {
type empty;
}
}
}
}
identity gtp { // Next Hop Structures
base "fpcp-tunnel-type"; typedef fpcp-service-path-id {
description "GTP-U tunnel"; type uint32 {
} range "0..33554431";
}
description "SERVICE_PATH_ID";
}
identity gre { identity fpc-nexthop-type {
base "fpcp-tunnel-type"; description "Next Hop Type";
description "GRE tunnel"; }
} identity fpc-nexthop-ip {
base "fpcbase:fpc-nexthop-type";
}
identity fpc-nexthop-servicepath {
base "fpcbase:fpc-nexthop-type";
}
grouping fpc-nexthop {
leaf nexthop-type {
type identityref {
base "fpcbase:fpc-nexthop-type";
}
}
choice nexthop-value {
case ip {
leaf ip {
type inet:ip-address;
}
}
case servicepath {
leaf servicepath {
type fpcbase:fpcp-service-path-id;
}
}
}
identity service-function { }
description
"Base identity from which specific
service function types are derived.";
}
identity ip-protocol { // QoS Information
description identity fpc-qos-type {
"Base identity from which specific description "Base identity from which specific uses of QoS types are derived.";
IP protocol types are derived."; }
} grouping fpc-qos-profile {
leaf qos-type {
type identityref {
base fpcbase:fpc-qos-type;
}
description "the profile type";
}
choice value {
}
}
identity property-type { // Vendor Specific Attributes
description identity vendor-specific-type {
"Base identity of property"; description "Vendor Specific Attribute Type";
} }
grouping vendor-attributes {
leaf vendor-id {
type fpcbase:fpc-identity;
}
leaf vendor-type {
type identityref {
base "fpcbase:vendor-specific-type";
}
}
choice value {
case empty-type {
leaf empty-type {
type empty;
}
}
}
}
identity property-qos { // Topology
base "property-type"; typedef fpc-domain-id {
description type fpcbase:fpc-identity;
"QoS property"; }
grouping fpc-domain {
leaf domain-id {
type fpcbase:fpc-domain-id;
} }
leaf domain-name {
identity property-endpoint { type string;
base "property-type";
description
"Endpoint property";
} }
identity property-type-endpoint { leaf domain-type {
base "property-type"; type string;
description
"Endpoint property";
} }
}
identity qos-type { typedef fpc-dpn-id {
description type fpcbase:fpc-identity;
"Base identity from which specific description "DPN Identifier";
uses of QoS types are derived."; }
} identity fpc-dpn-control-protocol {
description "DPN Control Protocol";
}
grouping fpc-dpn {
leaf dpn-id {
type fpcbase:fpc-dpn-id;
}
leaf dpn-name {
type string;
}
leaf-list dpn-groups {
type fpcbase:fpc-dpn-group-id;
}
leaf node-reference {
type instance-identifier;
}
}
identity fpcp-qos-type { typedef fpc-dpn-group-id {
base "qos-type"; type fpcbase:fpc-identity;
description description "DPN Group Identifier";
"Base identity from which specific }
QoS types in FPCP uses are derived."; identity fpc-forwaridingplane-role {
} description "Role of DPN Group in the Forwarding Plane";
}
identity fpc-access-type {
description "Access Type of the DPN Group";
}
identity fpc-mobility-profile-type {
description "Mobility Profile Type";
}
identity fpcp-qos-type-gbr { grouping fpc-dpn-peer-group {
base "fpcp-qos-type"; leaf remote-dpn-group-id {
description type fpcbase:fpc-dpn-group-id;
"A QoS Type for Guaranteed Bit Rate (GBR)."; }
} leaf remote-mobility-profile {
type identityref {
base "fpcbase:fpc-mobility-profile-type";
}
}
leaf remote-data-plane-role {
type identityref {
base "fpcbase:fpc-forwaridingplane-role";
}
}
leaf remote-endpoint-address {
type inet:ip-address;
}
leaf local-endpoint-address {
type inet:ip-address;
}
leaf tunnel-mtu-size {
type uint32;
}
}
identity fpcp-qos-type-mbr { // Events, Probes & Notifications
base "fpcp-qos-type"; identity event-type {
description description "Base Event Type";
"A QoS Type for Maximum Bit Rate (MBR)."; }
}
identity fpcp-qos-index-type { typedef event-type-id {
base "qos-type"; type uint32;
} }
identity fpcp-qos-index { grouping monitor-id {
base "fpcp-qos-index-type"; leaf monitor-id {
type fpcbase:fpc-identity;
} }
}
identity traffic-descriptor-type { identity report-type {
} description "Type of Report";
}
identity periodic-report {
base "fpcbase:report-type";
}
identity threshold-report {
base "fpcbase:report-type";
}
identity scheduled-report {
base "fpcbase:report-type";
}
identity events-report {
base "fpcbase:report-type";
}
identity fpcp-traffic-descriptor { grouping report-config {
base "traffic-descriptor-type"; choice event-config-value {
case periodic-config {
leaf period {
type uint32;
}
}
case threshold-config {
leaf lo-thresh {
type uint32;
}
leaf hi-thresh {
type uint32;
}
}
case scheduled-config {
leaf report-time {
type uint32;
}
}
case events-config-ident {
leaf-list event-identities {
type identityref {
base "fpcbase:event-type";
}
}
}
case events-config {
leaf-list event-ids {
type uint32;
}
}
} }
}
grouping carrier { grouping monitor-config {
description "Identify FPCP Carrier"; uses fpcbase:monitor-id;
leaf carrier-id { uses fpcbase:target-value;
type fpcp-carrier-id; uses fpcbase:report-config;
mandatory true; }
description "Carrier ID";
}
}
grouping agent { grouping report {
description "AGT_ID to identify FPCP Agent"; uses fpcbase:monitor-config;
leaf agent-id { choice report-value {
type fpcp-agent-id; leaf trigger {
description "Agent ID"; type fpcbase:event-type-id;
}
case simple-empty {
leaf nothing {
type empty;
} }
} }
case simple-val32 {
grouping client { leaf val32 {
description "CLI_ID to identify FPCP Client"; type uint32;
leaf client-id {
type fpcp-client-id;
description "Client ID";
} }
}
} }
}
}
grouping network { Figure 27: FPC YANG base
description "Identify FPCP Network";
leaf network-id {
type fpcp-network-id;
description "Network ID";
}
}
grouping dpn { A.1.2. FPC Agent YANG Model
description "Identify FPCP Data-Plane Node";
leaf dpn-id {
type fpcp-dpn-id;
description "DPN ID";
}
}
grouping port { module ietf-dmm-fpcagent {
description "Identify FPCP Port"; namespace "urn:ietf:params:xml:ns:yang:fpcagent";
leaf port-id { prefix fpcagent;
type fpcp-port-id;
description "Port-ID"; import ietf-dmm-fpcbase { prefix fpcbase; revision-date 2016-08-03; }
import ietf-inet-types { prefix inet; revision-date 2013-07-15; }
organization "IETF DMM Working Group";
contact "Satoru Matsushima <satoru.matsushima@g.softbank.co.jp>";
description
"This module contains YANG definition for
Forwarding Policy Configuration Protocol.(FPCP)";
revision 2016-08-03 {
description "Changes based on -04 version of FPC draft.";
reference "draft-ietf-dmm-fpc-cpdp-04";
}
feature fpc-cloning {
description "An ability to support cloning in the RPC.";
}
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-client-binding {
description "Allows a FPC Client to bind a DPN to an Topology Object";
}
feature fpc-auto-binding {
description "Allows a FPC Agent to advertise Topology Objects that could be DPNs";
}
feature instruction-bitset {
description "Allows the expression of instructions (bit sets) over FPC.";
}
feature operation-ref-scope {
description "Provides the scope of refeneces in an operation. Used to optmize
the Agent processing.";
}
typedef agent-identifier {
type fpcbase:fpc-identity;
}
typedef client-identifier {
type fpcbase:fpc-identity;
}
grouping basename-info {
leaf basename {
if-feature fpcagent:fpc-basename-registry;
description "Rules Basename";
type fpcbase:fpc-identity;
} }
} leaf base-state {
grouping property { if-feature fpcagent:fpc-basename-registry;
description "Identify FPCP Property"; type string;
leaf property-id {
type fpcp-property-id;
description "Property-ID";
} }
} leaf base-checkpoint {
if-feature fpcagent:fpc-basename-registry;
grouping rule { type string;
description "Identify FPCP Rule";
leaf rule-id {
type fpcp-rule-id;
description "Rule-ID";
} }
} }
grouping fpcp-carrier { // Top Level Structures
description "Define FPCP network"; container tenants {
uses carrier; description "";
uses agent;
list client { list tenant {
key client-id; description "";
description "List of FPCP Clients"; key "tenant-id";
leaf name { leaf tenant-id {
type fpcp-name-type; type fpcbase:fpc-identity;
description "Client Name";
}
container fpc-policy {
list policy-groups {
key "policy-group-id";
uses fpcbase:fpc-policy-group;
} }
uses client; list policies {
} key "policy-id";
list dpn { uses fpcbase:fpc-policy;
key dpn-id;
description "List of FPCP DPNs";
leaf name {
type fpcp-name-type;
description "DPN Name";
} }
uses dpn; list descriptors {
} key descriptor-id;
} uses fpcbase:fpc-descriptor;
grouping dpn-set {
description "DPNs which consist a DPN set.";
leaf name {
type fpcp-name-type;
description "DPN set name";
}
leaf network {
type leafref {
path "/fpcp-carriers/carrier/network/network-id";
} }
description "Network-ID which a DPN-set is belonging to."; list actions {
} key action-id;
leaf role { uses fpcbase:fpc-action;
type enumeration {
enum anchor-l3 {
description "";
}
enum anchor-l2 {
description "";
}
enum access {
description "";
}
} }
description "Define DPNs role in data-plane."; }
}
list endpoint-dp { container fpc-mobility {
key local-address; config false;
description "List of data-plane endpoint properties of a list contexts {
set of DPNs."; key context-id;
leaf local-address { uses fpcbase:fpc-context;
type inet:ip-address;
description "";
} }
leaf remote-dpn { list ports {
type leafref { key port-id;
path "/fpcp-carriers/carrier/dpn-group/name"; uses fpcbase:fpc-port;
}
description "";
} }
leaf default-tunnel-type { list monitors {
type identityref { uses fpcbase:monitor-config;
base "fpcp-tunnel-type"; }
} }
description "Tunnel Type"; container fpc-topology {
// Basic Agent Topology Structures
list domains {
key domain-id;
uses fpcbase:fpc-domain;
uses fpcagent:basename-info;
} }
}
grouping dpn-set {
description "DPNs which consist a DPN set.";
leaf name {
type fpcp-name-type;
description "DPN set name";
}
leaf network {
type leafref {
path "/fpcp-carriers/carrier/network/network-id";
list dpn-group-peers {
if-feature fpcbase:fpc-basic-agent;
key "remote-dpn-group-id";
uses fpcbase:fpc-dpn-peer-group;
} }
description "Network-ID which a DPN-set is belonging to."; leaf dpn-id {
} if-feature fpcbase:fpc-basic-agent;
leaf role { type fpcbase:fpc-dpn-id;
type enumeration {
enum anchor-l3 {
description "";
}
enum anchor-l2 {
description "";
}
enum access {
description "";
}
} }
description "Define DPNs role in data-plane."; leaf-list control-protocols {
} if-feature fpcbase:fpc-basic-agent;
list endpoint-dp { type identityref {
key local-address; base "fpcbase:fpc-dpn-control-protocol";
description "List of data-plane endpoint properties of a }
set of DPNs.";
leaf local-address {
type inet:ip-address;
description "";
} }
leaf remote-dpn {
type leafref { list dpn-groups {
path "/fpcp-carriers/carrier/dpn-group/name"; if-feature fpcbase:fpc-multi-dpn;
key dpn-group-id;
uses fpcagent:fpc-dpn-group;
list domains {
key domain-id;
uses fpcbase:fpc-domain;
uses fpcagent:basename-info;
} }
description "";
} }
leaf default-tunnel-type { list dpns {
type identityref { if-feature fpcbase:fpc-multi-dpn;
base "fpcp-tunnel-type"; key dpn-id;
} uses fpcbase:fpc-dpn;
description "Tunnel Type";
} }
} }
list dpn {
key dpn-id; }
uses dpn; }
description "DPN list in a DPN set";
} container fpc-agent-info {
// General Agent Structures
leaf-list supported-features {
type string;
} }
grouping tunnel-endpoints { // Common Agent Info
description list supported-events {
"PROP_TUN property as a set of tunnel endpoints"; key event;
leaf tunnel-type { leaf event {
type identityref { type identityref {
base "fpcp-tunnel-type"; base "fpcbase:event-type";
}
description "Tunnel Type";
}
leaf remote-address {
type inet:ip-address;
description "Remote endpoint";
}
leaf local-address {
type inet:ip-address;
description "Local endpoint";
} }
}
leaf event-id {
type fpcbase:event-type-id;
}
} }
grouping gtp-attributes { list supported-error-types {
description key error-type;
"GTP_CONF as GTP tunnel specific attributes"; leaf error-type {
leaf remote-teid { type identityref {
type uint32; base "fpcagent:error-type";
description "TEID of remote-endpoint";
}
leaf local-teid {
type uint32;
description "TEID of local-endpoint";
} }
}
leaf error-type-id {
type fpcagent:error-type-id;
}
} }
grouping gre-attributes { }
description
"GRE_CONF as GRE tunnel specific attribute"; // Multi-DPN Agent Structures
leaf key { grouping fpc-dpn-group {
type uint32; leaf dpn-group-id {
description "GRE_KEY"; type fpcbase:fpc-dpn-group-id;
} }
leaf data-plane-role {
type identityref {
base "fpcbase:fpc-forwaridingplane-role";
}
}
leaf access-type {
type identityref {
base "fpcbase:fpc-access-type";
}
}
leaf mobility-profile {
type identityref {
base "fpcbase:fpc-mobility-profile-type";
}
}
list dpn-group-peers {
key "remote-dpn-group-id";
uses fpcbase:fpc-dpn-peer-group;
}
}
// RPC
// RPC Specific Structures
//Input Structures
typedef admin-status {
type enumeration {
enum enabled { value 0; }
enum disabled { value 1; }
enum virtual { value 2; }
}
}
typedef session-status {
type enumeration {
enum complete { value 0; }
enum incomplete { value 1; }
enum outdated { value 2; }
}
}
typedef op-delay {
type uint32;
}
typedef op-identifier {
type uint64;
}
typedef ref-scope {
description "Search scope for references in the operation.
op - All references are contained in the operation body (intra-op)
bundle - All references in exist in bundle (inter-operation/intra-bundle).
NOTE - If this value comes in CONFIG call it is equivalen to 'op'.
storage - One or more references exist outside of the operation and bundle.
A lookup to a cache / storage is required.
unknown - the location of the references are unknown. This is treated as
a 'storage' type.";
type enumeration {
enum none { value 0; }
enum op { value 1; }
enum bundle { value 2; }
enum storage { value 3; }
enum unknown { value 4; }
} }
}
grouping rewriting-properties { grouping instructions {
description container instructions {
"PROP_REWR. TBD for which type of rewriting functions if-feature instruction-bitset;
need to be defined"; choice instr-type {
leaf type { }
type identityref {
base service-function;
}
description "The type of service-function";
}
} }
grouping fpcp-qosattribute { }
leaf qci { grouping op-header {
type fpcp-qos-class-identifier; leaf client-id {
} type fpcagent:client-identifier;
leaf attributetype {
type identityref {
base fpcp-qos-type;
}
description "the attribute type";
}
leaf bandwidth {
type fpcp-qos-bandwidth;
}
} }
leaf delay {
type op-delay;
}
leaf session-state {
type session-status;
}
leaf admin-state {
type admin-status;
}
leaf op-type {
type enumeration {
enum create { value 0; }
enum update { value 1; }
enum query { value 2; }
enum delete { value 3; }
}
}
leaf op-ref-scope {
if-feature operation-ref-scope;
type fpcagent:ref-scope;
}
uses fpcagent:instructions;
}
grouping fpcp-qos-property { grouping clone-ref {
description "PROP_QOS"; leaf entity {
leaf name { type fpcbase:fpc-identity;
type fpcp-name-type;
}
leaf qos-index-type {
type identityref {
base "fpcp-qos-index-type";
}
}
choice index-type {
case qci {
when "../qos-index-type = 'fpcp-qos-index'";
container uplink {
uses fpcp-qosattribute;
}
container downlink {
uses fpcp-qosattribute;
}
}
}
} }
leaf source {
type fpcbase:fpc-identity;
}
}
grouping traffic-descriptor { identity command-set {
description description "protocol specific commands";
"Traffic descriptor group collects parameters to }
identify target traffic flow.";
leaf destination-ip { grouping context-operation {
type inet:ip-prefix; uses fpcbase:fpc-context;
description "Rule of destination IP"; uses fpcagent:instructions;
} }
leaf source-ip {
type inet:ip-prefix; grouping port-operation {
description "Rule of source IP"; uses fpcbase:fpc-port;
uses fpcagent:instructions;
}
// Output Structure
grouping payload {
list ports {
uses fpcagent:port-operation;
}
list contexts {
uses fpcagent:context-operation;
}
}
grouping op-input {
uses fpcagent:op-header;
leaf op-id {
type op-identifier;
}
choice op_body {
case create_or_update {
list clones {
if-feature fpc-cloning;
key entity;
uses fpcagent:clone-ref;
} }
uses fpcagent:payload;
}
case delete_or_query {
uses fpcbase:targets-value;
}
} }
}
grouping fpcp-traffic-descriptor { typedef result {
leaf name { type enumeration {
type fpcp-name-type; enum ok { value 0; }
enum err { value 1; }
enum ok-notify-follows { value 2; }
}
}
identity error-type {
description "Base Error Type";
}
identity name-already-exists {
description "Notification that an entity of the same name already exists";
}
typedef error-type-id {
description "Integer form of the Error Type";
type uint32;
}
grouping op-status-value {
leaf op-status {
type enumeration {
enum ok { value 0; }
enum err { value 1; }
}
}
}
grouping result-body {
leaf op-id {
type op-identifier;
}
choice result-type {
case err {
leaf error-type-id {
type fpcagent:error-type-id;
} }
leaf traffic-discriptor-type { leaf error-info {
type identityref { type string {
base "traffic-descriptor-type"; length "1..1024";
} }
} }
}
case create-or-update-success {
uses fpcagent:payload;
}
case delete_or_query-success {
uses fpcbase:targets-value;
}
case empty-case {
}
}
}
choice descriptor-type { // Common RPCs
case fpcp-traffic-descriptor { rpc configure {
when "../descriptor-type = 'fpcp-traffic-descriptor'"; input {
uses traffic-descriptor; uses fpcagent:op-input;
}
}
} }
output {
leaf result {
type result;
grouping fpcp-forwarding-rule { }
uses rule; uses fpcagent:result-body;
uses fpcp-traffic-descriptor;
} }
}
grouping fpcp-port-properties { rpc configure-bundles {
description if-feature fpcagent:fpc-bundles;
"A set of port property attributes"; input {
leaf highest-op-ref-scope {
if-feature operation-ref-scope;
type fpcagent:ref-scope;
}
list bundles {
key op-id;
uses fpcagent:op-input;
}
}
output {
list bundles {
key op-id;
uses fpcagent:result-body;
}
}
}
uses property; rpc bind-dpn {
list attached-dpns { if-feature fpcagent:fpc-client-binding;
key name; input {
leaf name { leaf node-id {
type fpcp-name-type; type inet:uri;
description "DPN group name of which port attached."; }
} uses fpcbase:fpc-dpn;
description "Port attached DPN group list."; }
} output {
container endpoints { uses fpcagent:result-body;
description "Tunnel Endpoint";
uses tunnel-endpoints;
choice tunnel {
description "Tunnel-Type";
case gtp-u {
when "tunnel-type = 'gtp'" {
description "In case of GTP-U is tunnel-type";
}
uses gtp-attributes;
}
case gre {
when "tunnel-type = 'gre'" {
description "In case of GRE is tunnel-type";
}
uses gre-attributes;
}
}
}
container qos {
description "QoS Type";
uses fpcp-qos-property;
list port-in-aggregated-bandwidth {
key port-id;
uses port;
}
}
container rewriting {
description "Rewriting function";
uses rewriting-properties;
}
} }
}
rpc unbind-dpn {
if-feature fpcagent:fpc-client-binding;
input {
leaf dpn-id {
type fpcbase:fpc-dpn-id;
}
}
output {
uses fpcagent:result-body;
}
}
// Notification Messages & Structures
typedef notification-id {
type uint32;
}
grouping port-field { grouping notification-header {
description "Definition of attributes of port field"; leaf notification-id {
uses port; type fpcagent:notification-id;
uses carrier;
uses network;
} }
leaf timestamp {
type uint32;
}
}
// Container for configurations sets. notification config-result-notification {
uses fpcagent:notification-header;
choice value {
case config-result {
uses fpcagent:op-status-value;
uses fpcagent:result-body;
}
case config-bundle-result {
list bundles {
uses fpcagent:op-status-value;
uses fpcagent:result-body;
}
}
}
}
container fpcp-carriers { rpc event_register {
description "Attributes set of FPCP network"; description "Used to register monitoring of parameters/events";
input {
uses fpcbase:monitor-config;
}
output {
leaf monitor-result {
type fpcagent:result;
}
}
}
list carrier { rpc event_deregister {
key carrier-id; description "Used to de-register monitoring of parameters/events";
description "List of carriers"; input {
leaf name { list monitors {
type fpcp-name-type; uses fpcbase:monitor-id;
description "FPCP Carrier name"; }
}
uses fpcp-carrier; }
list network { output {
key network-id; leaf monitor-result {
description "List of networks in a carrier."; type fpcagent:result;
leaf name { }
type fpcp-name-type; }
description "Define visible name of a network."; }
}
uses network; rpc probe {
description "Probe the status of a registered monitor";
input {
uses fpcbase:targets-value;
}
output {
leaf monitor-result {
type fpcagent:result;
}
}
}
notification notify {
uses fpcagent:notification-header;
choice value {
case dpn-candidate-available {
if-feature fpcagent:fpc-auto-binding;
leaf node-id {
type inet:uri;
} }
list dpn-group { leaf-list access-types {
key name; type identityref {
description "List of DPN groups in a carrier."; base "fpcbase:fpc-access-type";
uses dpn-set; }
} }
list qos-profile { leaf-list mobility-profiles {
key name; type identityref {
uses fpcp-qos-property; base "fpcbase:fpc-mobility-profile-type";
}
} }
list traffic-descriptor { leaf-list forwarding-plane-roles {
key name; type identityref {
uses fpcp-traffic-descriptor; base "fpcbase:fpc-forwaridingplane-role";
}
} }
} }
} case monitor-notification {
choice monitor-notification-value {
case simple-monitor {
uses fpcbase:report;
// Port Entries }
case bulk-monitors {
list reports {
uses fpcbase:report;
}
}
}
}
}
}
}
container port-entries { Figure 28: FPC YANG agent
config false;
description
"This container binds set of traffic-descriptor and
port properties to a port and lists them as a port entry.";
list port-entry { A.1.3. PMIP QoS Model
key port-id;
description "List of port entries";
uses port-field;
list property { module ietf-pmip-qos {
key property-id; yang-version 1;
description "Attributes set of properties";
uses fpcp-port-properties;
}
list forwarding-rule { namespace
key rule-id; "urn:ietf:params:xml:ns:yang:ietf-pmip-qos";
description "Rule and traffic-descriptor";
uses fpcp-forwarding-rule;
} prefix "qos-pmip";
}
}
// PRT_ADD import ietf-inet-types {
prefix inet;
revision-date 2013-07-15;
}
import ietf-traffic-selector-types { prefix traffic-selectors; }
rpc port_add { organization
description "PRT_ADD"; "IETF DMM (Dynamic Mobility Management) Working Group";
input {
list adding-port {
description "Ports that are added to an agent";
uses port-field;
list forwarding-rule {
key rule-id;
description "Rule and traffic-descriptor";
uses fpcp-forwarding-rule;
}
list property {
key property-id;
description "Attributes set of properties";
uses fpcp-port-properties;
}
}
}
}
// PRT_DEL contact
"WG Web: <https://datatracker.ietf.org/wg/dmm/>
WG List: <mailto:dmm@ietf.org>
rpc port_delete { WG Chair: Dapeng Liu
description "PRT_DEL"; <mailto:maxpassion@gmail.com>
input {
list deleting-port {
description "Ports that are deleted from an agent";
uses port-field;
}
}
}
// PROP_ADD WG Chair: Jouni Korhonen
<mailto:jouni.nospam@gmail.com>
rpc port_property_add { Editor:
description "PROP_ADD"; <mailto:>";
input {
list adding-property {
description "Properties that are added to an agent";
uses port-field;
list property {
key property-id;
description "Attributes set of properties";
uses fpcp-port-properties;
}
}
}
}
// PROP_MOD description
"This module contains a collection of YANG definitions for
rpc port_property_modify { quality of service paramaters used in Proxy Mobile IPv6.
description "PROP_MOD";
input {
list modifying-property {
description
"Properties that are modified in an agent";
uses port-field;
list property { Copyright (c) 2015 IETF Trust and the persons identified as
key property-id; authors of the code. All rights reserved.
description "Attributes set of properties";
uses fpcp-port-properties;
}
}
}
}
// PROP_DEL Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
rpc port_property_delete { This version of this YANG module was created as part of the IETF
description "PROP_DEL"; DMM FPC YANG modules; see the RFC itself for full legal notices.";
input {
list deleting-property {
description
"Target port/property-id of deleting properties";
uses port-field;
leaf property-id { revision 2016-02-10 {
type fpcp-property-id; description "Initial revision";
mandatory true; reference
description "Property ID"; "RFC 7222: Quality-of-Service Option for Proxy Mobile IPv6";
} }
}
}
}
// RULE_ADD
rpc rule_add { // Type Definitions
description
"TBD for input parameters of which RULE_ADD includes
but now just traffic-descriptor.";
input {
list adding-rule {
description "Rules that are added to an agent";
uses port-field;
list forwarding-rule { // QoS Option Field Type Definitions
description "Added rule"; typedef sr-id {
uses fpcp-forwarding-rule; type uint8;
} description
} "An 8-bit unsigned integer used
for identifying the QoS Service Request. Its uniqueness is within
the scope of a mobility session. The local mobility anchor always
allocates the Service Request Identifier. When a new QoS Service
Request is initiated by a mobile access gateway, the Service
Request Identifier in the initial request message is set to a
value of (0), and the local mobility anchor allocates a Service
Request Identifier and includes it in the response. For any new
QoS Service Requests initiated by a local mobility anchor, the
Service Request Identifier is set to the allocated value.";
} }
}
// RULE_MOD typedef traffic-class {
type inet:dscp;
description
"Traffic Class consists of a 6-bit DSCP field followed by a 2-bit
reserved field.";
reference
"RFC 3289: Management Information Base for the Differentiated
Services Architecture
RFC 2474: Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers
RFC 2780: IANA Allocation Guidelines For Values In
the Internet Protocol and Related Headers";
}
rpc rule_modify { typedef operational-code {
description type enumeration {
"TBD for input parameters of which RULE_MOD includes enum RESPONSE { value 0; }
but now just traffic-descriptor."; enum ALLOCATE { value 1; }
input { enum DE-ALLOCATE { value 2; }
list modifying-rule { enum MODIFY { value 3; }
description "Rules that are modified in an agent"; enum QUERY { value 4; }
uses port-field; enum NEGOTIATE { value 5; }
}
description
"1-octet Operational code indicates the type of QoS request.
list forwarding-rule { RESPONSE: (0)
description "Modified rule"; Response to a QoS request
uses fpcp-forwarding-rule;
}
}
}
}
// RULE_DEL ALLOCATE: (1)
Request to allocate QoS resources
rpc rule_delete { DE-ALLOCATE: (2)
description Request to de-Allocate QoS resources
"TBD for input parameters of which RULE_DEL includes
but now just traffic-descriptor.";
input {
list deleting-rule {
description "Rules that are deleted from an agent";
uses port-field;
list target-rule {
description "Deleting rules";
leaf target-rule-id {
type fpcp-rule-id;
mandatory true;
description "Rule ID";
}
}
}
}
}
// EVENT_REG MODIFY: (3)
Request to modify QoS parameters for a previously negotiated
QoS Service Request
rpc event_register { QUERY: (4)
description Query to list the previously negotiated QoS Service Requests
"TBD for registered parameters included in EVENT_REG."; that are still active
}
// PROBE NEGOTIATE: (5)
Response to a QoS Service Request with a counter QoS proposal
rpc probe { Reserved: (6) to (255)
description Currently not used. Receiver MUST ignore the option received
"TBD for retrieved parameters included in PROBE."; with any value in this range.";
} }
// NOTIFY // QoS Attribute Types
notification notify { //The enumeration value for mapping - don't confuse with the identities
description typedef qos-attrubite-type-enum {
"TBD for which status and event are reported to client."; type enumeration {
} enum Reserved { value 0; }
enum Per-MN-Agg-Max-DL-Bit-Rate { value 1; }
enum Per-MN-Agg-Max-UL-Bit-Rate { value 2; }
enum Per-Session-Agg-Max-DL-Bit-Rate { value 3; }
enum Per-Session-Agg-Max-UL-Bit-Rate { value 4; }
enum Allocation-Retention-Priority { value 5; }
enum Aggregate-Max-DL-Bit-Rate { value 6; }
enum Aggregate-Max-UL-Bit-Rate { value 7; }
enum Guaranteed-DL-Bit-Rate { value 8; }
enum Guaranteed-UL-Bit-Rate { value 9; }
enum QoS-Traffic-Selector { value 10; }
enum QoS-Vendor-Specific-Attribute { value 11; }
}
description
"8-bit unsigned integer indicating the type of the QoS
attribute. This specification reserves the following values.
(0) - Reserved
This value is reserved and cannot be used
} (1) - Per-MN-Agg-Max-DL-Bit-Rate
Per-Mobile-Node Aggregate Maximum Downlink Bit Rate.
Figure 19: FPC YANG base (2) - Per-MN-Agg-Max-UL-Bit-Rate
Per-Mobile-Node Aggregate Maximum Uplink Bit Rate.
A.1.2. FPC Base tree (3) - Per-Session-Agg-Max-DL-Bit-Rate
Per-Mobility-Session Aggregate Maximum Downlink Bit Rate.
module: ietf-dmm-fpcp-base (4) - Per-Session-Agg-Max-UL-Bit-Rate
+--rw fpcp-carriers Per-Mobility-Session Aggregate Maximum Uplink Bit Rate.
| +--rw carrier* [carrier-id]
| +--rw name? fpcp-name-type
| +--rw carrier-id fpcp-carrier-id
| +--rw agent-id? fpcp-agent-id
| +--rw client* [client-id]
| | +--rw name? fpcp-name-type
| | +--rw client-id fpcp-client-id
| +--rw dpn* [dpn-id]
| | +--rw name? fpcp-name-type
| | +--rw dpn-id fpcp-dpn-id
| +--rw network* [network-id]
| | +--rw name? fpcp-name-type
| | +--rw network-id fpcp-network-id
| +--rw dpn-group* [name]
| | +--rw name fpcp-name-type
| | +--rw network? -> /fpcp-carriers/carrier/network/network-id
| | +--rw role? enumeration
| | +--rw endpoint-dp* [local-address]
| | | +--rw local-address inet:ip-address
| | | +--rw remote-dpn? -> /fpcp-carriers/carrier/dpn-group/name
| | | +--rw default-tunnel-type? identityref
| | +--rw dpn* [dpn-id]
| | +--rw dpn-id fpcp-dpn-id
| +--rw qos-profile* [name]
| | +--rw name fpcp-name-type
| | +--rw qos-index-type? identityref
| | +--rw (index-type)?
| | +--:(qci)
| | +--rw uplink
| | | +--rw qci? fpcp-qos-class-identifier
| | | +--rw attributetype? identityref
| | | +--rw bandwidth? fpcp-qos-bandwidth
| | +--rw downlink
| | +--rw qci? fpcp-qos-class-identifier
| | +--rw attributetype? identityref
| | +--rw bandwidth? fpcp-qos-bandwidth
| +--rw traffic-descriptor* [name]
| +--rw name fpcp-name-type
| +--rw traffic-discriptor-type? identityref
| +--rw (descriptor-type)?
| +--:(fpcp-traffic-descriptor)
| +--rw destination-ip? inet:ip-prefix
| +--rw source-ip? inet:ip-prefix
+--ro port-entries
+--ro port-entry* [port-id]
+--ro port-id fpcp-port-id
+--ro carrier-id fpcp-carrier-id
+--ro network-id? fpcp-network-id
+--ro property* [property-id]
| +--ro property-id fpcp-property-id
| +--ro attached-dpns* [name]
| | +--ro name fpcp-name-type
| +--ro endpoints
| | +--ro tunnel-type? identityref
| | +--ro remote-address? inet:ip-address
| | +--ro local-address? inet:ip-address
| | +--ro (tunnel)?
| | +--:(gtp-u)
| | | +--ro remote-teid? uint32
| | | +--ro local-teid? uint32
| | +--:(gre)
| | +--ro key? uint32
| +--ro qos
| | +--ro name? fpcp-name-type
| | +--ro qos-index-type? identityref
| | +--ro (index-type)?
| | | +--:(qci)
| | | +--ro uplink
| | | | +--ro qci? fpcp-qos-class-identifier
| | | | +--ro attributetype? identityref
| | | | +--ro bandwidth? fpcp-qos-bandwidth
| | | +--ro downlink
| | | +--ro qci? fpcp-qos-class-identifier
| | | +--ro attributetype? identityref
| | | +--ro bandwidth? fpcp-qos-bandwidth
| | +--ro port-in-aggregated-bandwidth* [port-id]
| | +--ro port-id fpcp-port-id
| +--ro rewriting
| +--ro type? identityref
+--ro forwarding-rule* [rule-id]
+--ro rule-id fpcp-rule-id
+--ro name? fpcp-name-type
+--ro traffic-discriptor-type? identityref
+--ro (descriptor-type)?
+--:(fpcp-traffic-descriptor)
+--ro destination-ip? inet:ip-prefix
+--ro source-ip? inet:ip-prefix
rpcs: (5) - Allocation-Retention-Priority