draft-ietf-dmm-fpc-cpdp-08.txt   draft-ietf-dmm-fpc-cpdp-09.txt 
DMM Working Group S. Matsushima DMM Working Group S. Matsushima
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track L. Bertz Intended status: Standards Track L. Bertz
Expires: March 17, 2018 Sprint Expires: May 3, 2018 Sprint
M. Liebsch M. Liebsch
NEC NEC
S. Gundavelli S. Gundavelli
Cisco Cisco
D. Moses D. Moses
Intel Corporation Intel Corporation
C. Perkins C. Perkins
Futurewei Futurewei
September 13, 2017 October 30, 2017
Protocol for Forwarding Policy Configuration (FPC) in DMM Protocol for Forwarding Policy Configuration (FPC) in DMM
draft-ietf-dmm-fpc-cpdp-08 draft-ietf-dmm-fpc-cpdp-09
Abstract Abstract
This document describes a way, called Forwarding Policy Configuration This document describes a way, called Forwarding Policy Configuration
(FPC) to manage the separation of data-plane and control-plane. FPC (FPC) to manage the separation of data-plane and control-plane. FPC
defines a flexible mobility management system using FPC agent and FPC defines a flexible mobility management system using FPC agent and FPC
client functions. An FPC agent provides an abstract interface to the client functions. An FPC agent provides an abstract interface to the
data-plane. The FPC client configures data-plane nodes by using the data-plane. The FPC client configures data-plane nodes by using the
functions and abstractions provided by the FPC agent for that data- functions and abstractions provided by the FPC agent for that data-
plane nodes. The data-plane abstractions presented in this document plane nodes. The data-plane abstractions presented in this document
skipping to change at page 1, line 40 skipping to change at page 1, line 40
management systems and data-plane functions. management systems and data-plane functions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 17, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3. FPC Design Objectives and Deployment . . . . . . . . . . . . 5
4. Information Model for FPC . . . . . . . . . . . . . . . . . . 8 4. FPC Mobility Information Model . . . . . . . . . . . . . . . 8
4.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Model Notation and Conventions . . . . . . . . . . . . . 8
4.1.1. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Core Structure - Information Model Components . . . . . . 9
4.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 10 4.3. Topology . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Domains . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. DPN . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. DPN-Type . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 13 4.3.3. DPN-Group . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Domain . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 16 4.5. Configurable Policy . . . . . . . . . . . . . . . . . . . 18
4.3. FPC for Mobility Management . . . . . . . . . . . . . . . 16 4.6. Mobility-Context . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Vport . . . . . . . . . . . . . . . . . . . . . . . . 16 4.7. Monitors . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 17 4.8. Namespace and Format . . . . . . . . . . . . . . . . . . 23
4.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 22 4.9. Attribute Application . . . . . . . . . . . . . . . . . . 24
4.4. Namespace and Format . . . . . . . . . . . . . . . . . . 23 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5. Attribute Application . . . . . . . . . . . . . . . . . . 24 5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 24
5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.1. CONFIG and CONF_BUNDLE Messages . . . . . . . . . . . 27
5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 25 5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1. CONFIG and CONF_BUNDLE Messages . . . . . . . . . . . 28 5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 30
5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 30
5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 32 5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 36
5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 32 5.2.3. Optimization for Current and Subsequent Messages . . 38
5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 37 6. Protocol Message Details . . . . . . . . . . . . . . . . . . 41
5.2.3. Optimization for Current and Subsequent Messages . . 39 6.1. Data Structures And Type Assignment . . . . . . . . . . . 41
5.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 44 6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 41
6. Protocol Message Details . . . . . . . . . . . . . . . . . . 45 6.1.2. Mobility Structures . . . . . . . . . . . . . . . . . 43
6.1. Data Structures And Type Assignment . . . . . . . . . . . 45 6.1.3. Message Attributes . . . . . . . . . . . . . . . . . 47
6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 45 7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 51
6.1.2. Mobility Structures . . . . . . . . . . . . . . . . . 47 7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 56
6.1.3. Topology Structures . . . . . . . . . . . . . . . . . 49 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 58
6.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . . 62
6.2. Message Attributes . . . . . . . . . . . . . . . . . . . 52 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
6.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 52 11. Work Team Participants . . . . . . . . . . . . . . . . . . . 64
6.2.2. CONFIG and CONF_BUNDLE Attributes and Notifications . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 55 12.1. Normative References . . . . . . . . . . . . . . . . . . 65
7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . 65
7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 58 Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 66
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 60 A.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . . . 67
9. Security Considerations . . . . . . . . . . . . . . . . . . . 64 A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 89
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 A.2.1. FPC YANG Settings and Extensions Model . . . . . . . 89
11. Work Team Participants . . . . . . . . . . . . . . . . . . . 67 A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 105
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 117
12.1. Normative References . . . . . . . . . . . . . . . . . . 67 A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 125
12.2. Informative References . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128
Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 69
A.1. FPC Agent YANG Model . . . . . . . . . . . . . . . . . . 69
A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 86
A.2.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . 86
A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 102
A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 115
A.2.4. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 127
A.2.5. FPC / PMIP Integration YANG Model . . . . . . . . . . 144
A.2.6. FPC Policy Extension YANG Model . . . . . . . . . . . 151
A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 155
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159
1. Introduction 1. Introduction
This document describes Forwarding Policy Configuration (FPC), a This document describes Forwarding Policy Configuration (FPC), a
system for managing the separation of data-plane and control-plane. system for managing the separation of data-plane and control-plane.
FPC enables flexible mobility management using FPC agent and FPC FPC enables flexible mobility management using FPC agent and FPC
client functions. An FPC agent exports an abstract interface to the client functions. An FPC agent exports an abstract interface to the
data-plane. To configure data-plane nodes and functions, the FPC data-plane. To configure data-plane nodes and functions, the FPC
client uses the interface to the data-plane offered by the FPC agent. client uses the interface to the data-plane offered by the FPC agent.
skipping to change at page 4, line 18 skipping to change at page 4, line 5
DPN-groups that enables definition of a topology for the DPN-groups that enables definition of a topology for the
forwarding plane. For example, access nodes may be assigned to a forwarding plane. For example, access nodes may be assigned to a
DPN-group which peers to a DPN-group of anchor nodes. DPN-group which peers to a DPN-group of anchor nodes.
Policy: A Policy embodies the mechanisms for processing specific Policy: A Policy embodies the mechanisms for processing specific
traffic flows or packets. This is needed for QoS, for packet traffic flows or packets. This is needed for QoS, for packet
processing to rewrite headers, etc. A Policy consists of one or processing to rewrite headers, etc. A Policy consists of one or
more rules. Each rule is composed of Descriptors and Actions. more rules. Each rule is composed of Descriptors and Actions.
Descriptors in a rule identify traffic flows, and Actions apply Descriptors in a rule identify traffic flows, and Actions apply
treatments to packets that match the Descriptors in the rule. An treatments to packets that match the Descriptors in the rule. An
arbitrary set of policies can be abstracted as a Policy-group to arbitrary set of policies can applied to a particular collection
be applied to a particular collection of flows, which is called of flows throgh the use of a Configurable-Policy.
the Virtual Port (Vport).
Mobility: A mobility session which is active on a mobile node is Mobility: A mobility session which is active on a mobile node is
abstracted as a Context with associated runtime concrete abstracted as a Mobility-Context with associated runtime concrete
attributes, such as tunnel endpoints, tunnel identifiers, attributes, such as tunnel endpoints, tunnel identifiers,
delegated prefix(es), routing information, etc. Contexts are delegated prefix(es), routing information, etc. Mobility-Contexts
attached to DPN-groups along with consequence of the control are attached to DPNs via DPN-References. The References assign
plane. One or multiple Contexts which have same sets of policies pre-defined Policies that were requested to be enforced as part of
are assigned Vports which abstract those policy sets. A Context the mobility signaling request. Policy may also be realized by
can belong to multiple Vports which serve various kinds of purpose Embedded-Rules in the DPN-Reference. Such policies are typically
and policy. Monitors provide a mechanism to produce reports when highly specialized (e.g. negotiated as a part of signaling), were
events regarding Vports, Sessions, DPNs or the Agent occur. not pre-provisioned or designed as a template. Hence, they are
not reusable across Mobility-Contexts.
Monitors provide a mechanism to produce reports when events
regarding Configurable Policies, Mobility Contexts, DPNs or the
Agent occur.
The Agent assembles applicable sets of forwarding policies for the The Agent assembles applicable sets of forwarding policies for the
mobility sessions from the data model, and then renders those mobility sessions from the data model, and then renders those
policies into specific configurations for each DPN to which the policies into specific configurations for each DPN to which the
sessions attached. The specific protocols and configurations to sessions attached. The specific protocols and configurations to
configure DPN from a FPC Agent are outside the scope of this configure DPN from a FPC Agent are outside the scope of this
document. document.
The data-plane abstractions may be extended to support many different The data-plane abstractions may be extended to support many different
mobility management systems and data-plane functions. The mobility management systems and data-plane functions. The
skipping to change at page 5, line 27 skipping to change at page 5, line 19
Tenant: An operational entity that manages mobility Tenant: An operational entity that manages mobility
management systems or applications which management systems or applications which
require data-plane functions. require data-plane functions.
Domain: One or more DPNs that form a data-plane Domain: One or more DPNs that form a data-plane
network. A mobility management system or an network. A mobility management system or an
application in a tenant may utilize a single application in a tenant may utilize a single
or multiple domains. or multiple domains.
Virtual Port (Vport): A set of forwarding policies. Configurable Policy: A set of Rules (forwarding policies)
installed upon a DPN.
Context: An abstracted endpoint of a mobility session Mobility Context: An abstracted endpoint of a mobility session
associated with runtime attributes. Vports associated with runtime attributes.
may apply to Context which instantiates those
forwarding policies on a DPN.
3. FPC Architecture 3. FPC Design Objectives and Deployment
To fulfill the requirements described in [RFC7333], FPC enables To fulfill the requirements described in [RFC7333], FPC enables
mobility control-planes and applications to configure DPNs with mobility control-planes and applications to configure DPNs with
various roles of the mobility management as described in various roles of the mobility management as described in
[I-D.ietf-dmm-deployment-models]. [I-D.ietf-dmm-deployment-models].
FPC defines building blocks of FPC Agent and FPC Client, as well as FPC defines building blocks of FPC Agent and FPC Client, as well as
data models for the necessary data-plane abstractions. The data models for the necessary data-plane abstractions. The
attributes defining those data models serve as protocol elements for attributes defining those data models serve as protocol elements for
the interface between the FPC Agent and the FPC Client. the interface between the FPC Agent and the FPC Client.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
Note that all FPC models SHOULD be configurable. The FPC interface Note that all FPC models SHOULD be configurable. The FPC interface
protocol in Figure 1 is only required to handle runtime data in the protocol in Figure 1 is only required to handle runtime data in the
Mobility model. The rest of the FPC models, namely Topology and Mobility model. The rest of the FPC models, namely Topology and
Policy, may be pre-configured, and in that case real-time protocol Policy, may be pre-configured, and in that case real-time protocol
exchanges would not be required for them. Operators that are tenants exchanges would not be required for them. Operators that are tenants
in the FPC data-plane could configure Topology and Policy on the in the FPC data-plane could configure Topology and Policy on the
Agent through other means, such as Restconf Agent through other means, such as Restconf
[I-D.ietf-netconf-restconf] or Netconf [RFC6241]. [I-D.ietf-netconf-restconf] or Netconf [RFC6241].
4. Information Model for FPC 4. FPC Mobility Information Model
This section presents an information model representing the abstract 4.1. Model Notation and Conventions
concepts of FPC, which are language and protocol neutral. Figure 2
shows an overview of the FPC data-plane information model.
(Mobile operator tenant that abstracted data-plane is used) In order to clarify the description of the information model, this
| draft uses the convention describe in the below.
+---FPC-Topology
| |
| +---DPNs
| |
| +---DPN-groups
| |
| +---Domains
|
+---FPC-Policy
| |
| +---Descriptors
| |
| +---Actions
| |
| +---Policies
| |
| +---Policy-groups
|
+---FPC-Mobility
|
+---Vports
|
+---Contexts
Figure 2: FPC Data-plane Information Model Information model entities, e.g. DPNs, Rules, etc., are listed in a
hierarchical notation where all entities with the same hierarchical
level are located on the same left-justified position one after the
other. When entities are composed of sub-entities, they will appear
shifted to the right.
4.1. FPC-Topology |
+-[entity2]
| +-[entity2.1]
| +-[entity2.2]
Topology abstraction enables a physical data-plane network to support Figure 2: Model Notation - An Example
multiple overlay topologies. An FPC-Topology consists of DPNs, DPN-
groups and Domains which abstract data-plane topologies for the
Client's mobility control-planes and applications.
Utilizing a FPC Agent, a mobile operator can create virtual DPNs in Some entities MAY have one or more sub-types placed on the right hand
an overlay network. Those such virtual DPNs are treated the same as side of the element definition in pointing brackets. Common types
physical forwarding DPNs in this document. include:
4.1.1. DPNs List: A collection of entities (some could be of the same kind)
The DPNs define all available nodes to a tenant of the FPC data-plane Set: A collection of entities without duplications
network. FPC Agent defines DPN binding to actual nodes. The role of
a DPN in the data-plane is determined at the time the DPN is assigned
to a DPN-group.
(FPC-Topology) Name: a human-readable string
|
+---DPNs
|
+---DPN-id
|
+---DPN-name
|
+---DPN-groups
|
+---Node-reference
Figure 3: DPNs Model Structure Key: a unique value. There are 3 types of keys:
DPN-id: The identifier for the DPN. The ID format MUST conform to U-Key: a universally unique key across all tenants. U-Key spaces
Section 4.4. are typically involve the use of registries or language
specific mechanisms that guarantee universal uniqueness of
values.
DPN-name: The name of the DPN. G-Key: a globally unique key - unique within a tenant
L-Key: a unique key within the set of values in local namespace.
For example, there exist interfaces with teh same name, e.g.
"interface0", in two different DPNs within the same tenant but
there can only be one "interface0" within each DPN, i.e. its
local Interface-Id L-Key space.
DPN-groups: The list of DPN-groups to which the DPN belongs. The Settings pattern, i.e. attributes whose names contain the word
'Settings', is a genera set that holds unique properties. If
multiple values of a property are present they are held in a List for
the property within the settings container. The container acts as an
extensible placeholder for properties (attribute/value pairs).
Node-reference: Indicates a physical node, or a platform of Each entity or its subtype may be optional (O) or mandatory (M).
virtualization, to which the DPN is bound by the Agent. The Entities that are not marked as optional are mandatory.
Agent SHOULD maintain that node's information, including IP
address of management and control protocol to connect them. In
the case of a node as a virtualization platform, FPC Agent
directs the platform to instantiate a DPN to which a DPN-group
attributes.
4.1.2. DPN-groups Example: The following example shows 3 entities:
- Entity1 is a globally unique key and has an
optional, associated Name
- Entity2 is a list
- Entity3 is a set and is optional
+
|
+-[entity1] <G-Key> (M), <Name> (O)
+-[entity2] <List>
+-[entity3] <Set> (O)
|
+
A DPN-group is a set of DPNs which share certain specified data-plane Figure 3
attributes. DPN-groups define the data-plane topology consisting of
a DPN-group of access nodes connecting to an anchor node's DPN-group.
A DPN-group has attributes such as its data-plane role, supported When expanding entity1 into an information model such as YANG it
access technologies, mobility profiles, connected peer groups and would result in two values: entity1-GKey and entity1-Name.
domain. A DPN may be assigned to multiple DPN-groups in different
data-plane roles or different domains. 4.2. Core Structure - Information Model Components
The substructures that comprise the information model are:
Topology: defines the different DPNs and links between them.
Policy-Definitions: describes how to handle flows: how to identify
traffic and what actions are performed on data packets
Configurable-Policy: policies that are relatively static. These
policies are usually pre-provisioned and are modified only when
the network configuration is updated or when new policy rules are
configured
Mobility-Context: policies that are created or modified during the
network's operation. In most cases, on a per-flow or per session
basis
Monitor: a list of events that trigger notification messages from
FPC Agents to FPC Clients
:
|
+-[Mobility]
| +
| |
: +-[Topology]
|
+-[Policy]
|
+-[Configurable-Policy] <Set>
|
+-[Mobility-Context] <Set>
|
+-[Monitor] <Set>
Figure 4: Mobility Information Model - Core Structure
4.3. Topology
The Topology sub-structure specifies virtual DPNs and the relations
between them. It is used by the network management entity to select
the most appropriate DPN resources for handling specific session
flows.
A virtual DPN is a logical entity that performs DPN functionality
(packet movement and management). It may represent a physical DPN
unit, a sub-function of a physical DPN or a collection of physical
DPNs. The motivation to refer to virtual DPNs in the information
model rather than physical DPNs is to provide flexibility for network
architects to define which DPN-selection capabilities are performed
by the FPC Agent (distributed) and which by the FPC client
(centralized).
When a virtual DPN is mapped to a physical DPN, the FPC client has
maximum knowledge of the DPN architecture and uses it to perform DPN
selection for specific sessions. When a virtual DPN is mapped to a
collection of physical DPNs, the FPC client cannot select a specific
physical DPN because it is hidden by the abstraction and only the FPC
Agent can address the specific associated physical DPNs.
The Topology sub-structure is comprised of the following sub-
structures:
DPN-Set: the set of virtual DPNs in a network configuration
DPN-Type-Set: a set of DPN-Type entities
DPN-Group-Set: a set of virtual DPNs that supports a specific
administrative purpose (in/out bound, roaming, subnetwork with
common specific configuration etc.)
Domain: a set of Domains tha represent a logical partition of
network resources
(FPC-Topology)
| |
+---DPN-groups +-[Topology]
| | +-[DPN] <Set>
+---DPN-group-id | +-[DPN-Type] <Set>
| | +-[DPN-Group] <Set>
+---Data-plane-role | +-[Domain] <Set>
|
+---Domains
|
+---Access-type
|
+---Mobility-profile
|
+---DPN-group-peers
Figure 4: DPN-groups Model Structure Figure 5: Topology Substructure
DPN-group-id: The identifier of the DPN-group. The ID format MUST 4.3.1. DPN
conform to Section 4.4.
Data-plane-role: The data-plane role of the DPN-group, such as The DPN set sub-structure specifies a subset of virtual DPNs in the
access-dpn, anchor-dpn. network . Some of the DPNs may be identical in functionality and only
differ by their key.
Domains: The domains to which the DPN-group belongs. |
+-[DPN] <Set>
| +-[DPN-Id] <G-Key>, <Name> (O)
| +-[DPN-Resource-Mapping-Reference] (O)
| +-[Interface] <Set>
| +-[Interface-Reference]
| | +-[Access-Technology] <U-Key>
| | +-[Role] <U-Key>
| | +-[Interface-Id] <L-Key>
| +-[Interface-Settings] <Set> (O)
Access-type: The access type supported by the DPN-group such as Figure 6: DPN Substructure
ethernet(802.3/11), 3gpp cellular(S1, RAB), if any.
Mobility-profile: Identifies a supported mobility profile, such as Each DPN entry contains the following information:
ietf-pmip, or 3gpp. New profiles may be defined as extensions of
this specification. Mobility profiles are defined so that some
or all data-plane parameters of the mobility contexts that are
part of the profile can be automatically determined by the FPC
Agent.
DPN-group-peers: The remote peers of the DPN-group with parameters DPN-Id (Key): A unique Identifier of the virtual DPN
described in Section 4.1.2.1.
4.1.2.1. DPN-group Peers DPN-Id (Name): the human-readable display string
DPN-Resource-Mapping-Reference (O): A reference to the underlying
implementation, e.g. physical node, virtual element, etc. that
supports this DPN. This value MUST be non-empty prior to Dynamic-
Policies being installed upon the DPN.
DPN-group-peers lists relevant parameters of remote peer DPNs as Interface-Set: the set of interfaces (through which data packets are
illustrated in Figure 5. received and transmitted) of that Virtual DPN. The virtual DPN
abstracts one or multiple physical DPNs each having one or more
interfaces. The Interface-set sub-structure is a collection of
all interface types available by this virtual DPN. The purpose of
this information is not to describe each interface of each DPN,
but rather, to indicate the entire set of interface types for the
sake of the DPN selection process, when a DPN with specific
interface capabilities is required. Each interface entry has a
reference to a defined DPN-Type entry in the DPN-Type-Set sub-
structure defined below and additional information that is
specific to that interface:
(DPN-groups) Interface-Reference - a 3-tuple key that uniquely references an
| entry in the DPN-Type-Set sub-structure: Access-Technology,
+---DPN-group-peers Role and Interface-Id.
|
+---Remote-DPN-group-id
|
+---Remote-mobility-profile
|
+---Remote-data-plane-role
|
+---Remote-endpoint-address
|
+---Local-endpoint-address
|
+---MTU-size
Figure 5: DPN-groups Peer Model Structure Interface-Settings - An optional set of settings of this
interface (that do not affect the DPN selection of active or
enabled interfaces). Examples: MTU size, display name, etc.
Remote-DPN-group-id: The ID of the peering DPN-Group. The ID format 4.3.2. DPN-Type
MUST conform to Section 4.4.
Remote-mobility-profile: The mobility-profile for the peering DPN- DPN-Type is the collection of all possible types of interfaces
group. Currently defined profiles are ietf-pmip, or 3gpp. New defined for DPNs in the network. The interfaces are grouped
profiles may be defined as extensions of this specification. according to their access technology, e.g. 3GPP, WiMAX, 802.x and
Role, e.g. LMA, MAG, PGW, AMF etc. Within a group, interfaces may
have additional properties that are more specific, a list of features
and optionally settings relevant to DPN selection. This information
is used when searching for resources in a network to carry out
required operations on data traffic.
Remote-data-plane-role: The data-plane role of the peering DPN- |
group. +-[DPN-Type] <Set>
| +-[Access-Technology] <U-Key>,<Name> (O)
| +-[Role] <U-Key>, <Name> (O)
| +-[Interface] <Set>
| +-[Interface-Id] <L-Key>, <Name> (O)
| +-[Interface-Protocol] <Set>
| +-[Features] <Set> (O)
| +-[Interface-Settings] <Set> (O)
Remote-endpoint-address: Defines Endpoint address of the peering Figure 7: DPN Type
DPN-group.
Local-endpoint-address: Defines Endpoint address of its own DPN- Each DPN-Type entry contains the following information:
group to peer the remote DPN-group.
MTU-size: Defines MTU size of traffic between the DPN-Group and this Access-technology: the technology used in the access network that
DPN-group-peer. originated the signaling (WiMAX, 3GPP, 802.x etc.)
4.1.3. Domains Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing the
interfaces specified below.
A domain is defined by an operator to refer to a particular network, Interface: A set of interfaces possible for the group above. Each
considered as a system of cooperating DPN-groups. Domains may interface carries the following information:
represent services or applications that are resident within an
operator's network.
(FPC-Topology) Interface-Id: a key that is used together with the 2-tuple
| Access-Technology and Role, to create a 3-tuple key that is
+---Domains referred to be the interface definition of virtual DPNs
|
+---Domain-id
|
+---Domain-name
|
+---Domain-type
|
+---Domain-reference
Figure 6: Domain Model Structure Interface-Protocols: rotocols supported by this interface -
PMIP, S5-GTP, S5-PMIP etc.
Domain-id: Identifier of Domain. The ID format MUST conform to Features: an optional set of supported features which further
Section 4.4. determine the suitability of the interface to the desired
operation
Domain-name: The name of the Domain. Interface-Settings: an optional set of settings that MUST be
known when determining the suitability of an interface for the
specific request. The difference between 'Features' and
'Settings' is that 'Features' are static while 'Settings' may
be configured. Examples: SequenceNumber=ON/OFF
Domain-type: Specifies which address families are supported within The entries Access-Technology and Role represent a tuple key that
the domain. uniquely identifies the set of interfaces that may be available for
DPNs of the specific type.
Domain-reference: Indicates a set of resources for the domain which 4.3.3. DPN-Group
consists a topology of physical nodes, platforms of
virtualization and physical/virtual links with certain bandwidth,
etc,.
4.2. FPC-Policy A DPN-Group is a list of a group of DPNs serving some administrative
purpose. Each group contains a list of DPNs (referenced by DPN-Id)
and selected interfaces (referenced by the interface's 3-tuple key).
The interfaces are listed rather than referred implicitly by each
specific DPN to enable to define a subset of a DPN interfaces to be
part of the group.
The FPC-Policy consists of Descriptors, Actions, Policies and Policy- |
groups. These can be viewed as configuration data, in contrast to +-[DPN-Group] <Set>
Contexts and Vports, which are structures that are instantiated on | +-[DPN-Group-Id] <G-Key>, <Name> (O)
the Agent. The Descriptors and Actions in a Policy referenced by a +-[Referenced-Interface] <Set>
Vport are active when the Vport is in an active Context, i.e. they | +-[Interface-Id] <L-Key>
can be applied to traffic on a DPN. | +-[Role] <U-Key>
| +-[Access-Technology] <U-Key>
| +-[Supporting-DPN-Id] <Set>
| +-[DPN-Group-Peer-Reference] <Set> (O)
+-[DPN-Peer-Group] <Set>
| +-[Remote-DPN-Group-Id] <L-key>
| +-[Interface-Settings] <Set> (O)
+-[Domain-Id-Reference]
4.2.1. Descriptors Figure 8: DPN Group
Descriptors defines classifiers of specific traffic flows, such as Each DPN-Group entry contains the following information:
those based on source and destination addresses, protocols, port
numbers of TCP/UDP/SCTP/DCCP, or any way of classifying packets.
Descriptors are defined by specific profiles that may be produced by
3gpp, ietf or other SDOs. Many specifications also use the terms
Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A packet
that meets the criteria of a Descriptor is said to satisfy, pass or
be consumed by the Descriptor. Descriptors are assigned an
identifier and contain a type and value.
(FPC-Policy) DPN-Group (Key): A unique Identifer of the DPN-Group
|
+---Descriptors
|
+---Descriptor-id
|
+---Descriptor-type
|
+---Descriptor-value
Figure 7: Descriptor Model Structure DPN-Group (Name): the human-readable display string
Descriptor-id: Identifier of Descriptor. The ID format MUST conform Referenced-Interfaces: A set of interfaces and the DPNs / associated
to Section 4.4. DPN-Peer-Groups that support them. Each entry contains
Descriptor-type: The descriptor type, which determines the Interface-Id: a key that is used together with the 2-tuple
classification of a specific traffic flows, such as source and Access-Technology and Role, to create a 3-tuple key that is
destination addresses, protocols, port numbers of TCP/UDP/SCTP/ referred to be the interface definition of virtual DPNs
DCCP, or any other way of selecting packets.
Descriptor-value: The value of Descriptor such as IP prefix/address, Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing
protocol number, port number, etc. the interfaces specified below.
4.2.2. Actions Access-technology: the technology used in the access network
that originated the signaling (WiMAX, 3GPP, 802.x etc.)
A Policy defines a list of Actions that are to be applied to traffic Role: the role (MAG, LMA, PGW, AMF etc.) of the device sharing
meeting the criteria defined by the Descriptors. Actions include the interfaces specified below.
traffic management such as shaping, policing based on given
bandwidth, and connectivity actions such as pass, drop, forward to
given nexthop. Actions may be defined as part of specific profiles
which are produced by 3gpp, ietf or other SDOs.
(FPC-Policy) Supporting-DPN-Id (Set): A set of DPN-Id-References that support
| the specific interface for this DPN-Group.
+---Actions
|
+---Action-id
|
+---Action-type
|
+---Action-value
Figure 8: Action Model Structure Interface-Settings: an optional set of settings that MUST be
known when determining the suitability of an interface for the
specific request.F
Action-id: Identifier for the Action. The ID format MUST conform to DPN-Peer-Group: A set of Remote (from the DPN-Group's point of view)
Section 4.4. DPN-Groups. When communication occurs between the DPN-Group and
DPN-Peer-Group the Interface-Settings MUST be used. Each entry
contains the following information: entry contains
Action-type: The type of the action -- i.e. how to treat the Remote-DPN-Group-Id: A unique Identifier of the DPN-Peer-Group
specified traffic flows. Examples include pass, drop, forward to
a given nexthop value, shape or police based on given bandwidth
value, etc.
Action-value: Specifies a value for the Action-type, such as Interface-Settings: an optional set of settings that MUST be
bandwidth, nexthop address or drop, etc. known when determining the suitability of an interface for the
specific request.
4.2.3. Policies 4.3.4. Domain
Policies are collections of Rules. Each Policy has a Policy A Domain represents a logica abstraction of a group of heterogeneous
Identifier and a list of Rule/Order pairs. The Order and Rule values Topology resources. Other models, outside of the scope of this
MUST be unique in the Policy. Unlike the AND filter matching of each specificaiton, provide the details for the Domain.
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 (not references to Rules).
(FPC-Policy) |
| +-[Domain] <Set>
+---Policies | +-[Domain-Id] <G-Key>, <Name> (O)
| +-[Domain-Reference]
+---Policy-id
|
+---Rules
|
+---Order
|
+---Descriptors
| |
| +---Descriptor-id
| |
| +---Direction
|
+---Actions
|
+---Action-id
|
+---Action-Order
Figure 9: Model Structure for Policies Figure 9: Domainn
Policy-id: Identifier of Policy. The ID format MUST conform to Each Domain entry contains the following information:
Section 4.4.
Rules: List of Rules which are a collection of Descriptors and Domain (Key): A unique Identifier of the Domain
Actions. All Descriptors MUST be satisfied before the Actions
are taken. This is known as an AND Descriptor list, i.e.
Descriptor 1 AND Descriptor 2 AND ... Descriptor X all MUST be
satisfied for the Rule to apply.
Order: Specifies ordering if the Rule has multiple Descriptors and Domain (Name): the human-readable display string
Action sets. Order values MUST be unique within the Rules list.
Descriptors: The list of Descriptors. Domain-Reference: A link to the underlying resource / informaiton
that provides further details regarding the domain.
Descriptor-id: Identifies each Descriptor in the Rule. 4.4. Policy
Direction: Specifies which direction applies, such as uplink, The Policy substructure defines and identifies grouped Rules for
downlink or both. enforcement on the data plane. Rules comprise traffic descriptors
and actions on how to treat traffic in case the traffic descriptor
matches a data packet. The Policy substructure is independent of a
policy context, whether it's an administratively configurable policy
which applies to all or a defined aggregate of data flows, or a
mobility context-related policy, which is associated with a mobility
session and may apply only to data traffic of an associated mobile
node while being registered.
Actions: List of Actions. In addition to the Policy substructure, the Core Structure per
Section 4.2 holds accordingly separate entries for the Configurable-
Policy as well as for Mobility-Context, which do not only define
their own policies by embedded rules, but comprise references to
policy definitions in the Policy substructure, to which additional
settings can be applies on a per-Configurable-Policy basis and on a
per-Mobility-Context bases respectively.
Action-id: Indicates each Action in the rule. Traffic descriptions and traffic treatment actions are defined
separately in Descriptor-Definition and Action-Definition
respectively. Binding between traffic descriptors and associated
traffic treatment action is defined in a set of rule definition
entries (Rule-Definition) which comprise references to entries in the
set of traffic descriptors (Descriptor-Reference) and traffic
treatment actions (Action-Reference). Accordingly, a single rule or
a group of rules are bound to a policy in the set of policy
definitions (Policy-Definition) by reference to entries in the set of
rule definitions (Rule-Id).
Action-Order: Specifies Action ordering if the Rule has multiple |
actions. Action-Order values MUST be unique within the Actions +-[Policy]
list. | +-[Policy-Definition] <Set>
| | +-[Policy-Id] <G-Key> (M)
| | +-[Rule-Reference] Set (M)
| | +-[Precedence] <L-Key> (M)
| | +-[Rule-Id-Reference] (M)
| +-[Rule-Definition] <Set>
| | +-[Rule-Id] <L-Key> (M)
| | +-[Descriptor-Match-Type] (M)
| | +-[Descriptor-Reference] <Set>
| | | +-[Descriptor-Id-Reference]
| | | +-[Direction] (O)
| | +-[Action-Reference] <Set>
| | +-[Action-Id-Reference]
| | +-[Action-Order]
| +-[Descriptor-Definition] <Set>
| | +-[Descriptor -Id] <L-Key> (M)
| | +-[Descriptor-Type]
| | +-[Descriptor-Value]
| +-[Action-Definition] <Set>
| +-[Action-Id] <L-Key> (M)
| +-[Action-Type]
| +-[Action-Value]
|
4.2.4. Policy-groups Figure 10: Policy Substructure
List of Policy-groups which are an aggregation of Policies. Common The Policy Substructure contains the following entries:
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) Policy-Definition: A set of policy definitions which bind a single
| or multiple rules to a policy.
+---Policy-groups
|
+---Policy-group-id
|
+---Policies
Figure 10: Policy-group Model Structure Policy-Id: Identifies a policy definition.
Policy-group-id: The identifier of the Policy-group. The ID format Rule-Reference: Assigns a set of rule definitions, which are
MUST conform to Section 4.4. bound to a policy definition, by reference to the associated
Rule in the Rule-Definition Substructure.
Policies: List of Policies in the Policy-group. Precedence: Defines the order with which the rules must be
applied.
4.3. FPC for Mobility Management Rule-Id-Reference: Identifies a rule.
The FPC-Mobility consists of Vports and Contexts. A mobility session Rule-Definition: A set of rule definitions which bind a single or
is abstracted as a Context with its associated runtime concrete multiple traffic descriptors (by reference to Descriptor-
attributes, such as tunnel endpoints, tunnel identifiers, delegated Definition) to a single or multiple traffic treatment actions (by
prefix(es) and routing information, etc. A Vport abstracts a set of reference to Action-Definition).
policies applied to the Context.
4.3.1. Vport Rule-Id: Identifies a rule definition.
A Vport represents a collection of policy groups, that is, a group of Descriptor-Match-Type: Conjuction of Descriptor-Values to apply
rules that can exist independently of the mobility/session lifecycle. as match to DPN traffic, which can be either OR or AND. The
Mobility control-plane applications create, modify and delete Vports identified conjunction applies to all Descriptor-Definitions in
on FPC Agent through the FPC Client. the given Rule-Definition.
When a Vport is indicated in a Context, the set of Descriptors and Descriptor-Reference: Assigns a set of descriptors to the rule
Actions in the Policies of the Vport are collected and applied to the by reference to the associated Descriptor-Definition.
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.
(FPC-Mobility) Descriptor-Id-Reference: Identifies the referred Descriptor-
| Definition
+---Vports
|
+---Vport-id
|
+---Policy-groups
Figure 11: Vport Model Structure Direction: Indicates if a rule applies to uplink traffic, to
downlink traffic, or to both, uplink- and downlink traffic.
Applying a rule to both, uplink- and downlink traffic, in case
of symmetric rules, allows omitting a separate entry for each
direction. When not present, the direction is implied by the
Descriptor's values.
Vport-id: The identifier of Vport. The ID format MUST conform to Action-Reference: Assigns a set of actions to the rule by
Section 4.4. reference to the associated Action-Definition.
Policy-groups: List of references to Policy-groups which apply to Action-Id-Reference: Identifies the referred Action-Definition.
the Vport.
4.3.2. Context Action-Order: Defines the order how actions are executed in case
the rule applies per match of the associated traffic
descriptor.
An endpoint of a mobility session is abstracted as a Context with its Descriptor-Definition: A set of descriptor definitions, each being
associated runtime concrete attributes, such as tunnel endpoints, identified by a key (Descriptor-Id)
tunnel identifiers, delegated prefix(es) and routing information,
etc. A mobility control-plane, or other applications, can create,
modify and delete contexts on an FPC Agent by using the FPC Client.
FPC Agent SHOULD determine runtime attributes of a Context from the Descriptor-Id: Identifies a descriptor definition.
Vport's policies and the attached DPN's attributes. A mobility
control-plane, or other applications, MAY set some of the runtime
attributes directly when they create data-plane related attributes.
In the case of that a mobility control-plane assigns tunnel
identifiers, for instance.
(FPC-Mobility) Descriptor-Type: Identifies the type of descriptor, e.g. an IPv6
| traffic selector per [RFC 6088], for unambiguous 2
+---Contexts interpretation of a Descriptor-Value.
|
+---Context-id
|
+---Vports
|
+---DPN-group
|
+---Delegated-ip-prefixes
|
+---Parent-context
Figure 12: Common Context Model Structure Descriptor-Value: Defines all required attribute-value pairs per
the traffic descriptor type identified in Descriptor-Type.
Context-id: Identifier of the Context. The ID format MUST conform Action-Definition: A set of action definitions.
to Section 4.4.
Vports: List of Vports. When a Context is applied to a Vport, the Action-Id: Identifies an action definition.
context is configured by policies at each such Vport. Vport-id
references indicate Vports which apply to the Context. Context
can be a spread over multiple Vports which have different
policies.
DPN-group: The DPN-group assigned to the Context. Action-Type: Identifies the type of an action for unambiguous
interpretation of an Action-Value entry.
Delegated-ip-prefixes: List of IP prefixes to be delegated to the Action-Value: Defines all required attribute-value pairs per the
mobile node of the Context. action type identified in Action-Type.
Parent-context: Indicates a parent context from which this context 4.5. Configurable Policy
inherits.
4.3.2.1. Single DPN Agent Case |
+-[Configurable-Policy] <Set>
| +-[DPN-Id-Reference] <U-Key>
| +-[Installed-Policy] <List>
| | +-[Installed-Policy-Id] <G-Key>
| | +-[Policy-Id-Reference]
| | +-[Policy-Settings] <Set> (O)
| +-[Settings] <Set> (O)
|
In the case where a FPC Agent supports only one DPN, the Agent MUST Figure 11: Configurable Policy
maintain Context data just for the DPN. The Agent does not need to
maintain a Topology model. Contexts in single DPN case consists of
following parameters for both direction of uplink and downlink.
(Contexts) The Configurable-Policy Substructure contains the following entries:
|
+---UL-Tunnel-local-address
|
+---UL-Tunnel-remote-address
|
+---UL-MTU-size
|
+---UL-Mobility-specific-tunnel-parameters
|
+---UL-Nexthop
|
+---UL-QoS-profile-specific-parameters
|
+---UL-DPN-specific-parameters
|
+---UL-Vendor-specific-parameters
Figure 13: Uplink Context Model of Single DPN Structure DPN-Id-Reference: Refers to the DPN to which the policy applies.
UL-Tunnel-local-address: Specifies uplink endpoint address of the Installed-Policy: A list of policies that apply to an identified
DPN. DPN.
UL-Tunnel-remote-address: Specifies uplink endpoint address of the Installed-Policy-Id: Holds the identifier of the DPN at which
remote DPN. the policy has been installed.
UL-MTU-size: Specifies the uplink MTU size. Policy-Id-Reference: Assigns a policy by reference to the
associated Policy-Definition.
UL-Mobility-specific-tunnel-parameters: Specifies profile specific Policy-Settings: Settings that apply to the previously
uplink tunnel parameters to the DPN which the agent exists. This referenced policy to complement rules or make them concrete,
may, for example, include GTP/TEID for 3gpp profile, or GRE/Key e.g. in case the descriptor representing a packet match has not
for ietf-pmip profile. or unambiguously been defined in the poliicy sub-structure.
UL-Nexthop: Indicates next-hop information of uplink in external Settings: Settings that apply to multiple policies at the
network such as IP address, MAC address, SPI of service function identified DPN.
chain [I-D.ietf-sfc-nsh], SID of segment
routing[I-D.ietf-6man-segment-routing-header]
[I-D.ietf-spring-segment-routing-mpls], etc.
UL-QoS-profile-specific-parameters: Specifies profile specific QoS 4.6. Mobility-Context
parameters of uplink, such as QCI/TFT for 3gpp profile,
[RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles
defined by extensions of this specification.
UL-DPN-specific-parameters: Specifies optional node specific The Mobility-Context Substructure holds entries associated with a
parameters needed by uplink such as if-index, tunnel-if-number mobile node's mobility sessions. At least one instance is created at
that must be unique in the DPN. the mobile node's registration to serve as parent context.
Additional instances holding child context with reference to parent
context can be created. Child context holds, for example,
descriptors of mobile node data traffic which needs to be treated
different from traffic that matches descriptor of the parent context,
e.g. in terms of QoS. Child context can inherit some attributes/
values from parent context, such as traffic encapsulation and
forwarding information, but can hold different or additional
attributes/values that apply to traffic that matches the descriptor
of the child context.
UL-Vendor-specific-parameters: Specifies a vendor specific parameter Termination a parent context implies termination of all dependent
space for the uplink. child context, e.g. at deregistration of a mobile node.
(Contexts) |
| +-[Mobility-Context] <Set>
+---DL-Tunnel-local-address | +-[Mobility-Context-Id] <G-Key>
| | +-[DPN-Group-Id-Reference] (O)
+---DL-Tunnel-remote-address | +-[Parent-Mobility-Context-Id-Reference] (O)
| | +-[DPN-References] <List>
+---DL-MTU-size | | +-[DPN-Id-Reference]
| | | +-[Direction] (O)
+---DL-Mobility-specific-tunnel-parameters | | +-[DPN-Settings-Complementary]
| | | +-[Interface-Id-Reference]
+---DL-Nexthop | | +-[Embedded-Rule] <Set> (O)
| | | +-[Assigned-Policy-Reference] <Set> (O)
+---DL-QoS-profile-specific-parameters | +-[Requested-Policy-Reference] <Set> (O)
| | +-[Context-Settings-Complementary] <Set> (O)
+---DL-DPN-specific-parameters
|
+---DL-Vendor-specific-parameters
Figure 14: Downlink Context Model of Single DPN Structure Figure 12: Mobility Context
DL-Tunnel-local-address: Specifies downlink endpoint address of the The Mobility-Context Substructure holds the following entries:
DPN.
DL-Tunnel-remote-address: Specifies downlink endpoint address of the Mobility-Context-Id: Identifies a Mobility-Context
remote DPN.
DL-MTU-size: Specifies the downlink MTU size of tunnel. DPN-Group-Id-Reference: Assigns a DPN-Group, which groups DPN that
are used during the DPN selection procedure, by reference.
DL-Mobility-specific-tunnel-parameters: Specifies profile specific Parent-Mobility-Context-Id-Reference: Assigns a parent Mobility-
downlink tunnel parameters to the DPN which the agent exists. Context to aquire settings as required.
This may, for example, include GTP/TEID for 3gpp profile, or GRE/
Key for ietf-pmip profile.
DL-Nexthop: Indicates next-hop information of downlink in external DPN-References: Holds a list of DPNs with the associated concrete
network such as IP address, MAC address, SPI of service function policies that apply to the DPN. An entry MUST have at least one
chain [I-D.ietf-sfc-nsh], SID of segment value present in its Assigned-Policy-Refence or Embedded-Rule sets
routing[I-D.ietf-6man-segment-routing-header] in order to be valid.
[I-D.ietf-spring-segment-routing-mpls], etc.
DL-QoS-profile-specific-parameters: Specifies profile specific QoS DPN-Id-Reference: Assigns a DPN, to which the policy applies, by
parameters of downlink, such as QCI/TFT for 3gpp profile, reference.
[RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles
defined by extensions of this specification.
DL-DPN-specific-parameters: Specifies optional node specific Direction: Indicates if a rule applies to uplink or downlink
parameters needed by downlink such as if-index, tunnel-if-number traffic, or to both, uplink- and downlink traffic. Applying a
that must be unique in the DPN. rule to both, uplink- and downlink traffic, in case of
symmetric rules, allows omitting a separate entry for each
direction. When not present the value is assumed to apply to
both directions.
DL-Vendor-specific-parameters: Specifies a vendor specific parameter DPN-Settings-Complementary: Complementary seeings that apply to
space for the downlink. the DPN for the given Mobility-Context.
4.3.2.2. Multiple DPN Agent Case Interface-Id-Reference: Assigns the selected interface of the
DPN my reference.
Alternatively, a FPC Agent may connect to multiple DPNs. The Agent Embedded-Rule: Rule that applies to the DPN for this Mobility-
MUST maintain a set of Context data for each DPN. The Context Context. This rule is embedded and not refereced in the Policy
contains a list of DPNs, where each entry of the list consists of the substructure.
parameters in Figure 15. A Context data for one DPN has two entries
- one for uplink and another for downlink or, where applicable, a
direction of 'both'.
(Contexts) Assigned-Policy-Reference: A set of references to the list of
| Requested-Policy-References per this Mobility-Context.
+---DPNs
|
+---DPN-id
|
+---Direction
|
+---Tunnel-local-address
|
+---Tunnel-remote-address
|
+---MTU-size
|
+---Mobility-specific-tunnel-parameters
|
+---Nexthop
|
+---QoS-profile-specific-parameters
|
+---DPN-specific-parameters
|
+---Vendor-specific-parameters
Figure 15: Multiple-DPN Supported Context Model Structure Requested-Policy-Reference: Assigns a list of policies in Policy-
Definitions that can apply to any DPN per this Mobility-Context.
DPN-Reference entries can select from this list of policy
references to apply to the associated DPN.
DPN-id: Indicates DPN of which the runtime Context data installed. Context-Settings-Complementary: Complementary settings that apply
to the referenced policies per this Mobility-Context.
Direction: Specifies which side of connection at the DPN indicated - The Rules Template format is aligned with the Rule Substructure. It
uplink, downlink or both. can represent an Embedded-Rule per the Mobility-Context Substructure.
Tunnel-local-address: Specifies endpoint address of the DPN at the |
uplink or downlink. +-[Embedded-Rule] <List>
| +-[Rule-Id] (M)
| +-[Precedence] <L-Key>
| +-[Descriptor-Match-Type] (M)
| +-[Descriptor-Definition] <Set>
| | +-[Descriptor-Id] <L-Key> (M)
| | +-[Descriptor-Type]
| | +-[Descriptor-Value]
| +-[Action-Definition] <Set>
| +-[Action-Order] <L-Key> (M)
| +-[Action-Id] (O)
| +-[Action-Type]
| +-[Action-Value]
Tunnel-remote-address: Specifies endpoint address of remote DPN at Figure 13: Rule Template
the uplink or downlink.
MTU-size: Specifies the packet MTU size on uplink or downlink. The Embedded-Rule template holds the following entries:
Mobility-specific-tunnel-parameters: Specifies profile specific Rule-Id: Identifies a rule definition. It is provided for
tunnel parameters for uplink or downlink to the DPN. This may, convenience.
for example, include GTP/TEID for 3gpp profile, or GRE/Key for
ietf-pmip profile.
Nexthop: Indicates next-hop information for uplink or downlink in Precedence: Defines the order with which the rules must be applied
external network such as IP address, MAC address, SPI of service and is used as the key.
function chain [I-D.ietf-sfc-nsh], SID of segment
routing[I-D.ietf-6man-segment-routing-header]
[I-D.ietf-spring-segment-routing-mpls], etc.
QoS-profile-specific-parameters: Specifies profile specific QoS Descriptor-Match-Type: Conjuction of Descriptor-Values to apply as
parameters for uplink or downlink to the DPN, such as QCI/TFT for match to DPN traffic, which can be either OR or AND. The
3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or parameters of identified conjunction applies to all Descriptor-Definitions in
new profiles defined by extensions of this specification. the given Rule-Definition
DPN-specific-parameters: Specifies optional node specific parameters Descriptor-Definition: A set of descriptor definitions, each being
needed by uplink or downlink to the DPN such like if-index, identified by a key (Descriptor-Id)
tunnel-if-number that must be unique in the DPN.
Vendor-specific-parameters: Specifies a vendor specific parameter Descriptor-Id: Identifies a Descriptor-Definition
space for the DPN.
Multi-DPN Agents will use only the DPNs list of a Context for Descriptor-Type: Identifies the type of descriptor, e.g. an IPv6
processing as described in this section. A single-DPN Agent MAY use traffic selector per [RFC 6088], for unambiguous 2
both the Single Agent DPN model Section 4.3.2.1 and the multi-DPN interpretation of a Descriptor-Value
Agent Context described here.
4.3.3. Monitors Descriptor-Value: Defines all required attribute-value pairs per
the traffic descriptor type identified in Descriptor-Type.
Action-Definition: A set of action definitions.
Action-Order: Defines the order how actions are executed in case
the rule applies per match of the associated traffic
descriptor.
Action-Id: Identifies an action definition.
Action-Type: Identifies the type of an action for unambiguous
interpretation of an Action-Value entry.
Action-Value: Defines all required attribute-value pairs per the
action type identified in Action-Type.
4.7. Monitors
Monitors provide a mechanism to produce reports when events occur. A Monitors provide a mechanism to produce reports when events occur. A
Monitor will have a target that specifies what is to be watched. Monitor will have a target that specifies what is to be watched.
When a Monitor is specified, the configuration MUST be applicable to When a Monitor is specified, the configuration MUST be applicable to
the attribute/entity monitored. For example, a Monitor using a the attribute/entity monitored. For example, a Monitor using a
Threshold configuration cannot be applied to a Context, because Threshold configuration cannot be applied to a Context, because
Contexts do not have thresholds. But such a monitor could be applied Contexts do not have thresholds. But such a monitor could be applied
to a numeric threshold property of a Context. to a numeric threshold property of a Context.
(FPC-Mobility) |
| +-[Monitor] <List>
+---Monitors | +-[Monitor-Id] <U-Key>
| | +-[Target]
+---Monitor-id | +-[Binding-Information] (O)
| | +-[Deterrable] (O)
+---Target | +-[Configuration]
|
+---Configuration
Figure 16: Common Monitor Model Structure Figure 14: Monitor Substructure
Monitor-id: Name of the Monitor. The ID format MUST conform to Monitor-Id: Name of the Monitor. The Id format MUST conform to
Section 4.4. Section 4.8.
Target: Target to be monitored. This may be an event, a Context, a Target: Description of what is to be monitored. This can be an
Vport or attribute(s) of Contexts. When the type is an Event, a Dynamic Policy, an installed DPN Policy, or values of a
attribute(s) of a Context, the target name is a concatenation of Dynamic-Policy attribute. When the type is an attribute of
the Context-Id and the relative path (separated by '/') to the Mobility-Context, the target name is a concatenation of the
attribute(s) to be monitored. Context-Id and the relative path (separated by '/') to the
attribute(s) to be monitored. Target must provide unambiguously
identify the monitored attribute and the location (DPN).
Configuration: Determined by the Monitor subtype. Four report types Binding-Information: Complements (ambigous) Target information to
are defined: define the Monitor in an unambigous way.
* Periodic reporting specifies an interval by which a Deterrable: Indicates that a monitoring report can be delayed in a
notification is sent to the Client. defined delay budget for possible bundling with other reports
* Event reporting specifies a list of event types that, if they Configuration: Determined by the Monitor subtype. The recipient of
occur and are related to the monitored attribute, will result a notification as monitor report is specified in the
in sending a notification to the Client. Configuration. Four reporting types are defined:
* Scheduled reporting specifies the time (in seconds since Jan * Periodic reporting specifies an interval by which a
1, 1970) when a notification for the monitor should be sent to notification is sent.
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 * Event reporting specifies a list of event types that, if they
threshold. When these values are crossed a corresponding occur and are related to the monitored attribute, will result
notification is sent to the Client. in sending a notification.
4.4. Namespace and Format * Scheduled reporting specifies the time (in seconds since Jan 1,
1970) when a notification for the monitor should be sent. Once
this Monitor's notification is completed the Monitor is
automatically de-registered.
* Threshold reporting specifies one or both of a low and high
threshold. When these values are crossed a corresponding
notification is sent.
4.8. Namespace and Format
The identifiers and names in FPC models which reside in the same The identifiers and names in FPC models which reside in the same
namespace must be unique. That uniqueness must be kept in agent or namespace must be unique. That uniqueness must be kept in agent or
data-plane tenant namespace on an Agent. The tenant namespace data-plane tenant namespace on an Agent. The tenant namespace
uniqueness MUST be applied to all elements of the tenant model, i.e. uniqueness MUST be applied to all elements of the tenant model, i.e.
Topology, Policy and Mobility models. Topology, Policy and Mobility models.
When a Policy needs to be applied to Contexts in all tenants on an 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 Agent, the Agent SHOULD define that policy to be visible from all the
tenants. In this case, the Agent assigns an unique identifier in the tenants. In this case, the Agent assigns an unique identifier in the
agent namespace. agent namespace and effectively creates a U-Key although only a G-Key
is required.
The format of identifiers can utilize any format with agreement The format of identifiers can utilize any format with agreement
between data-plane agent and client operators. The formats include between data-plane agent and client operators. The formats include
but are not limited to Globally Unique IDentifiers (GUIDs), but are not limited to Globally Unique IDentifiers (GUIDs),
Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names
(FQDNs), Fully Qualified Path Names (FQPNs) and Uniform Resource (FQDNs), Fully Qualified Path Names (FQPNs) and Uniform Resource
Identifiers (URIs). Identifiers (URIs).
The FPC model does not limit the types of format that dictate the The FPC model does not limit the types of format that dictate the
choice of FPC protocol. However the choice of identifiers which are choice of FPC protocol. However the choice of identifiers which are
used in Mobility model need to be considered to handle runtime used in Mobility model need to be considered to handle runtime
parameters in real-time. The Topology and Policy models are not parameters in real-time.
restricted to meet that requirement, as described in Section 3.
4.5. Attribute Application 4.9. Attribute Application
Attributes in FPC Topology and Policy SHOULD be pre-configured in a When search for attributes in Settings to apply for Embeded Rules or
FPC Agent prior to Contexts and Vports. The FPC Agent requires those Assigned-Policy-References the following search order is applied by
pre-configured attributes to be able to derive a Context's detailed the Agent / DPN for Mobilty-Contexts:
runtime attributes.
When a FPC Client creates a Context, the FPC Client is then able to 1. DPN-Settings-Complementary of the DPN-Reference entry
indicate specific DPN-group(s) instead of all endpoint addresses of
the DPN(s) and MTU-size of the tunnels for example. This is because
that the FPC Agent can derive data for those details from the pre-
configured DPN-group information in the FPC Topology.
Similarly when a Vport is created for the Context, the FPC Agent can 2. Context-Settings-Complementary of the Mobility-Context
derive detailed forwarding policies from the pre-configured Policy
information in the FPC Policy. The FPC Client thereby has no need to
indicate those specific policies to all of the Contexts which share
the same set of Policy-groups.
This is intentional as it provides FPC Clients the ability to reuse 3. If Parent-Mobility-Context-Id-Reference is not empty the
pre-configured FPC Topology and FPC Policy attributes. It helps to following are also searched:
minimize over the wire exchanges and reduce system errors by
exchanging less information.
The Agent turns those derived data into runtime attributes of UL and 1. DPN-Settings-Complementary of the DPN-Reference entry for the
DL objects which are in the DPNs list of the Context (multiple-DPNs same interface, if present.
Agent case) or directly under the Context (single-DPN Agent case).
The Agent consequently instantiates forwarding policies on DPN(s)
based on those attributes.
When a Context inherits another Context as its parent, missing 2. Context-Settings-Complementary of this parent Mobility-
attributes in the child Context are provided by the Parent Context Context
(for example, IMSI defined in the 3GPP extension) .
It is noted that the Agent SHOULD update the Context's attributes 3. Optionally, if this Mobility-Context has a non-empty Parent-
which are instantiated on DPN(s) when the applied attributes of Mobility-Context-Id-Reference this step MAY be repeated but
Topology and Policy are changed. it is NOT reccommended as it could slow system performance.
In the case of FPC Client modifying an existing runtime attribute of 4. Interface-Settings of the DPN interface
a Context which the FPC Agent derived, the FPC Agent MUST overwrite
that attribute with the value which the Client brings to the Agent. Only looking at settings of the first Parent-Mobility-Context-Id-
However risks exist, for example, the attributes could be outside of Reference is recommended for performance reasons. If further depth
allowable range of DPNs which the FPC Agent managed. of search is supported the Agent MUST make this known to the Client.
For Configurable Policy the following search order is applied:
1. Policy-Settings of the Installed-Policy
2. Settings of the Configurable-Policy
5. Protocol 5. Protocol
NOTE - The terms Context and Mobility-Context are used
interchangeable throughout the rest of this document.
5.1. Protocol Messages and Semantics 5.1. Protocol Messages and Semantics
Five message types are supported: Five message types are supported:
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| Message | Type | Description | | Message | Type | Description |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
| CONF | HEADER | Configure processes a single | | CONF | HEADER OP_TYPE | Configure processes a single |
| | ADMIN_STATE | operation. | | | BODY | operation. |
| | SESSION_STATE | |
| | OP_TYPE BODY | |
| | | | | | | |
| CONF_BUNDLE | 1*[HEADER | A Conf-bundle takes multiple | | CONF_BUNDLE | HEADER OP_TYPE | A Conf-bundle takes multiple |
| | ADMIN_STATE | operations that are to be | | | REF_SCOPE | operations that are to be |
| | SESSION_STATE | executed as a group with partial | | | TRANS_STRATEGY | executed as a group with partial |
| | TRANS_STRATEGY | failures allowed. They are | | | 1*[OP_ID BODY] | failures allowed. They are |
| | OP_TYPE BODY] | executed according to the OP_ID | | | | executed according to the OP_ID |
| | | value in the OP_BODY in | | | | value coupled with the BODY in |
| | | ascending order. If a | | | | ascending order. If a |
| | | CONF_BUNDLE fails, any entities | | | | CONF_BUNDLE fails, any entities |
| | | provisioned in the CURRENT | | | | provisioned in the CURRENT |
| | | operation are removed. However, | | | | operation are removed. However, |
| | | any successful operations | | | | any successful operations |
| | | completed prior to the current | | | | completed prior to the current |
| | | operation are preserved in order | | | | operation are preserved in order |
| | | to reduce system load. | | | | to reduce system load. |
| | | | | | | |
| REG_MONITOR | HEADER | Register a monitor at an Agent. | | REG_MONITOR | HEADER *[ | Register a monitor at an Agent. |
| | ADMIN_STATE *[ | The message includes information | | | MONITOR ] | The message includes information |
| | MONITOR ] | about the attribute to monitor | | | | about the attribute to monitor |
| | | and the reporting method. Note | | | | and the reporting method. Note |
| | | that a MONITOR_CONFIG is | | | | that a MONITOR_CONFIG is |
| | | required for this operation. | | | | required for this operation. |
| | | | | | | |
| DEREG_MONITOR | HEADER *[ | Deregister monitors from an | | DEREG_MONITOR | HEADER 1*[ | Deregister monitors from an |
| | MONITOR_ID ] [ | Agent. Monitor IDs are provided. | | | MONITOR_ID ] [ | Agent. Monitor IDs are provided. |
| | boolean ] | Boolean (optional) indicates if | | | SEND_DATA ] | SEND_DATA is an optional boolen |
| | | a successful DEREG triggers a | | | | that indicates if a successful |
| | | NOTIFY with final data. | | | | DEREG triggers a NOTIFY with |
| | | final data. |
| | | | | | | |
| PROBE | HEADER | Probe the status of a registered | | PROBE | HEADER | Probe the status of a registered |
| | MONITOR_ID | monitor. | | | MONITOR_ID | monitor. |
+---------------+----------------+----------------------------------+ +---------------+----------------+----------------------------------+
Table 1: Client to Agent Messages Table 1: Client to Agent Messages
Each message contains a header with the Client Identifier, an Each message contains a header with the Client Identifier, an
execution delay timer and an operation identifier. The delay, in ms, execution delay timer and an operation identifier. The delay, in ms,
is processed as the delay for operation execution from the time the is processed as the delay for operation execution from the time the
operation is received by the Agent. operation is received by the Agent.
The Client Identifier is used by the Agent to associate specific The Client Identifier is used by the Agent to associate specific
configuration characteristics, e.g. options used by the Client when configuration characteristics, e.g. options used by the Client when
communicating with the Agent, as well as the association of the communicating with the Agent, as well as the association of the
Client and tenant in the information model. Client and tenant in the information model.
Messages that create or update Monitors and Entities, i.e. CONFIG,
CONF_BUNDLE 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, and if that entity exists on the DPN, then an
operation to disable the associated entity will occur on the DPN . If
set to 'active' the DPN will be provisioned. Values are 'enabled',
'disabled', and 'virtual'.
CONF_BUNDLE also has the Transaction Strategy (TRANS_STRATEGY) CONF_BUNDLE also has the Transaction Strategy (TRANS_STRATEGY)
attribute. This value specifies the behavior of the Agent when an attribute. This value specifies the behavior of the Agent when an
operation fails while processing a CONF_BUNDLE message. The value of operation fails while processing a CONF_BUNDLE message. The value of
'default' uses the default strategy defined for the message. The 'default' uses the default strategy defined for the message. The
value 'all_or_nothing' will roll back all successfully executed value 'all_or_nothing' will roll back all successfully executed
operations within the bundle as well as the operation that failed. operations within the bundle as well as the operation that failed.
An FPC interface protocol used to support this specification may not An FPC interface protocol used to support this specification may not
need to support CONF_BUNDLE messages or specific TRANS_STRATEGY types need to support CONF_BUNDLE messages or specific TRANS_STRATEGY types
beyond 'default' when the protocol provides similar semantics. beyond 'default' when the protocol provides similar semantics.
However, this MUST be clearly defined in the specification that However, this MUST be clearly defined in the specification that
defines the interface protocol. defines the interface protocol.
An Agent will respond with an ERROR, OK, or an OK WITH INDICATION 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 that remaining data will be sent via a notify from the Agent to the
Client Section 5.1.1.6.2 for CONFIG and CONF_BUNDLE requests. When Client Section 5.1.1.4.2 for CONFIG and CONF_BUNDLE requests. When
returning an 'ok' of any kind, optional data may be present. returning an 'ok' of any kind, optional data MAY be present.
Two Agent notifications are supported: Two Agent notifications are supported:
+----------------------+----------+---------------------------------+ +----------------------+----------+---------------------------------+
| Message | Type | Description | | Message | Type | Description |
+----------------------+----------+---------------------------------+ +----------------------+----------+---------------------------------+
| CONFIG_RESULT_NOTIFY | See | An asynchronous notification | | CONFIG_RESULT_NOTIFY | See | An asynchronous notification |
| | Table 15 | from Agent to Client based upon | | | Table 13 | from Agent to Client based upon |
| | | a previous CONFIG or | | | | a previous CONFIG or |
| | | CONF_BUNDLE request. | | | | CONF_BUNDLE request. |
| | | | | | | |
| NOTIFY | See | An asynchronous notification | | NOTIFY | See | An asynchronous notification |
| | Table 16 | from Agent to Client based upon | | | Table 14 | from Agent to Client based upon |
| | | a registered MONITOR. | | | | a registered MONITOR. |
+----------------------+----------+---------------------------------+ +----------------------+----------+---------------------------------+
Table 2: Agent to Client Messages (notifications) Table 2: Agent to Client Messages (notifications)
5.1.1. CONFIG and CONF_BUNDLE Messages The HEADER is a part of all messages and is comprised of the
following information:
CONFIG and CONF_BUNDLE specify the following information for each CLT_ID: The Client Identifier
operation in addition to the header information:
SESSION_STATE: sets the expected state of the entities embedded in DELAY (OPTIONAL): The time (in ms) to delay the execution of ther
the operation body after successful completion of the operation. operaiton on the DPN once it is received by the Agent.
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' OP_ID: Operation Identifier
(0), 'update' (1), 'query' (2) or 'delete' (3). Results will be supplied per operation input. Each result contains
the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS
values are:
COMMAND_SET: If the feature is supported, specifies the Command Set OK - Success
(see Section 5.1.1.4).
BODY: A list of Clones, if supported, Vports and Contexts when the ERR - An Error has occurred
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 If an error occurs, information MUST be returned in the response.
Error informaiton is comprised of the following:
The Agent will process entities provided in an operation in the ERROR_TYPE_ID (Unsigned 32, REQUIRED) - The identifier of a
following order: specific error type The values are TRANSPORT (0), RPC (1),
PROTOCOL(2) or APPLICATION (3).
1. Clone Instructions, if the feature is supported ERROR_TAG - (String, REQUIRED) - enumerated error tag.
2. Vports ERROR_APP_TAG - (String, OPTIONAL) - Application specific error
3. Contexts according to COMMAND_SET order processing tag.
The following Order Processing occurs when COMMAND Sets are present ERROR_MESSAGE - (String, OPTIONAL) - A message describing the
error.
1. The Entity-specific COMMAND_SET is processed according to its bit ERROR_INFO - (Any Data, OPTIONAL) - Any data required for the
order unless otherwise specified by the technology specific response.
COMMAND_SET definition.
2. Operation specific COMMAND_SET is processed upon all applicable 5.1.1. CONFIG and CONF_BUNDLE Messages
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. CONFIG and CONF_BUNDLE include OP_TYPE as part of the header
information:
When deleting objects only their name needs to be provided. However, OP_TYPE: specifies the type of operation. Valid values are 'create'
attributes MAY be provided if the Client wishes to avoid requiring (0), 'update' (1), 'query' (2) or 'delete' (3).
the Agent cache lookups.
When deleting an attribute, a leaf reference should be provided. The BODY is comprised of the following information:
This is a path to the attributes.
5.1.1.2. Policy RPC Support COMMAND_SET: Specifies the Command Set (see Section 5.1.1.2).
This optional feature permits policy elements, (Policy-Group, Policy, REF_SCOPE: If supported, specifies the Reference Scope (see
Action and Descriptor), values to be in CONFIG or CONF_BUNDLE Section 5.1.1.3)
requests. It enables RPC based policy provisioning.
5.1.1.3. Cloning BODY INTERNALS: A list of entities under Policy, e.g. Policy-
Definitions, Action-Definitions, etc. as well as Installed
Policies and Contexts when the OP_TYPE is 'create' or 'update'.
Otherwise it is a list of Targets for 'query' or 'deletion'. See
Section 6.1.3.2 for details.
Cloning is an optional feature that allows a Client to copy one CONF_BUNDLES includes an OP_ID with each body for tracking of the
structure to another in an operation. Cloning is always done first bundle's subtransactions.
within the operation (see Operation Order of Execution for more
detail). If a Client wants to build an object then Clone it, use
CONF_BUNDLE 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 Vports and Contexts can
be cloned.
5.1.1.4. Command Bitsets 5.1.1.1. Agent Operation Processing
The COMMAND_SET is a technology specific bitset that allows for a The Agent will process entities provided in an operation in the
single entity to be sent in an operation with requested sub- following order:
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 1. Action-Definitions
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.5. Reference Scope 2. Descriptor Defintions
3. Rule Definitions
4. Policy Definitions
5. Installed Policies
6. Mobility Contexts according to COMMAND_SET
5.1.1.2. Command Bitsets
The COMMAND_SET is a technology specific bitset that allows for a
single entity to be sent in an operation with multiple requested sub-
transactions to be completed. It can also provide clarity for a
request. For example, a Mobility-Context could have the Home Network
Prefix absent but it is unclear if the Client would like the address
to be assigned by the Agent or if this is an error. Rather than
creating a specific command for assigning the IP a bit position in a
COMMAND_SET is reserved for Agent based IP assignment.
5.1.1.3. Reference Scope
The Reference Scope is an optional feature that provides the scope of The Reference Scope is an optional feature that provides the scope of
references used in a configuration command, i.e. CONFIG or references used in a configuration command, i.e. CONFIG or
CONF_BUNDLE. These scopes are defined as CONF_BUNDLE. These scopes are defined as
o none - all entities have no references to other entities. This o none - All entities have no references to other entities.
implies only Contexts are present. Vports MUST have references to
Policy-Groups.
o op - All references are contained in the operation body, i.e. only o op - All references are contained in the operation body, i.e. only
intra-operation references exist. intra-operation references exist.
o bundle - All references exist in bundle (inter-operation/intra- o bundle - All references exist in bundle (inter-operation/intra-
bundle). NOTE - If this value is present in a CONFIG message it bundle). NOTE - If this value is present in a CONFIG message it
is equivalent to 'op'. is equivalent to 'op'.
o storage - One or more references exist outside of the operation o storage - One or more references exist outside of the operation
and bundle. A lookup to a cache / storage is required. and bundle. A lookup to cache / storage is required.
o unknown - the location of the references are unknown. This is o unknown - the location of the references are unknown. This is
treated as a 'storage' type. treated as a 'storage' type.
If supported by the Agent, when cloning instructions are present, the
scope MUST NOT be 'none'. When Vports are present the scope MUST be
'storage' or 'unknown'.
An agent that only accepts 'op' or 'bundle' reference scope messages An agent that only accepts 'op' or 'bundle' reference scope messages
is referred to as 'stateless' as it has no direct memory of is referred to as 'stateless' as it has no direct memory of
references outside messages themselves. This permits low memory references outside messages themselves. This permits low memory
footprint Agents. Even when an Agent supports all message types an footprint Agents. Even when an Agent supports all message types an
'op' or 'bundle' scoped message can be processed quickly by the Agent 'op' or 'bundle' scoped message can be processed quickly by the Agent
as it does not require storage access. as it does not require storage access.
5.1.1.6. Operation Response 5.1.1.4. Operation Response
5.1.1.6.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 entities created or partially 5.1.1.4.1. Immediate Response
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.4).
If an error occurs the following information is returned. For CONF and CONF_BUNDLE the Response MAY include the the following:
ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error NOTIFY_FOLLOWS - A boolean indicator that the Operation has been
type accepted by the Agent but further processing is required. A
CONFIG_RESULT_NOTIFY will be sent once the processing has
succeeded or failed.
ERROR_INFORMATION - An OPTIONAL string of no more than 1024 ENTITIES - Optionally, entities created or partially fulfilled as
characters. part of the operation as specified in Table 12 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.2).
5.1.1.6.2. Asynchronous Notification 5.1.1.4.2. Asynchronous Notification
A CONFIG_RESULT_NOTIFY occurs after the Agent has completed A CONFIG_RESULT_NOTIFY occurs after the Agent has completed
processing related to a CONFIG or CONF_BUNDLE request. It is an processing related to a CONFIG or CONF_BUNDLE request. It is an
asynchronous communication from the Agent to the Client. asynchronous communication from the Agent to the Client.
The values of the CONFIG_RESULT_NOTIFY are detailed in Table 15. The values of the CONFIG_RESULT_NOTIFY are detailed in Table 13.
5.1.2. Monitors 5.1.2. Monitors
An Agent may reject a registration if it or the DPN has insufficient
resources.
An Agent or DPN may temporarily suspend monitoring if insufficient
resources exist. In such a case the Agent MUST notify the Client.
When a monitor has a reporting configuration of SCHEDULED it is When a monitor has a reporting configuration of SCHEDULED it is
automatically de-registered after the NOTIFY occurs. An Agent or DPN automatically de-registered after the last NOTIFY occurs.
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 If a SCHEDULED or PERIODIC configuration is provided during
the PROBE message. Thus, reporting configuration is optional and registration with the time related value (time or period
when not present only PROBE messages may be used for monitoring. If respectively) of 0 a NOTIFY is sent and the monitor is immediately
a SCHEDULED or PERIODIC configuration is provided during registration de-registered. This method should, when a MONITOR has not been
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 installed, result in an immediate NOTIFY sufficient for the Client's
needs and lets the Agent realize the Client has no further need for needs and lets the Agent realize the Client has no further need for
the monitor to be registered. An Agent may reject a registration if the monitor to be registered.
it or the DPN has insufficient resources.
PROBE messages are also used by a Client to retrieve information PROBE messages are also used by a Client to retrieve information
about a previously installed monitor. The PROBE message SHOULD about a previously installed monitor. The PROBE message SHOULD
identify one or more monitors by means of including the associated identify one or more monitors by means of including the associated
monitor identifier. An Agent receiving a PROBE message sends the monitor identifier. An Agent receiving a PROBE message sends the
requested information in a single or multiple NOTIFY messages. requested information in a single or multiple NOTIFY messages.
5.1.2.1. Operation Response If the Monitor configuration associated with a NOTIFY is deterrable
then the NOTIFY MAY be bundled with other messages back to the Agent
5.1.2.1.1. Immediate Response even if this results in a delay of the NOTIFY.
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
Any OK result will contain no more information.
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.2.1.2. Asynchronous Notification 5.1.2.1. Asynchronous Notification
A NOTIFY can be sent as part of de-registraiton, a trigger based upon A NOTIFY can be sent as part of de-registraiton, a trigger based upon
a Monitor Configuration or a PROBE. A NOTIFY is comprised of unique a Monitor Configuration or a PROBE. A NOTIFY is comprised of unique
Notification Identifier from the Agent, the Monitor ID the Notification Identifier from the Agent, the Monitor ID the
notification applies to, the Trigger for the notification, a notification applies to, the Trigger for the notification, a
timestamp of when the notification's associated event occurs and data timestamp of when the notification's associated event occurs and data
that is specific to the monitored value's type. that is specific to the monitored value's type.
5.2. Protocol Operation 5.2. Protocol Operation
skipping to change at page 33, line 12 skipping to change at page 30, line 48
of an FPC message can unambiguously identify the sender of the FPC 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 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 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 Agent selects a suitable DPN to enforce a Context and notifies
the Client about the selected DPN using the DPN_ID. the Client about the selected DPN using the DPN_ID.
All messages sent from a Client to an Agent MUST be acknowledged by All messages sent from a Client to an Agent MUST be acknowledged by
the Agent. The response must include all entities as well as status the Agent. The response must include all entities as well as status
information, which indicates the result of processing the message, information, which indicates the result of processing the message,
using the RESPONSE_BODY property. In case the processing of the using the RESPONSE_BODY property. In case the processing of the
message results in a failure, the Agent sets the ERROR_TYPE_ID and message results in a failure, the Agent sets the ERROR_TYPE and
ERROR_INFORMATION accordingly and MAY clear the Context or Vport, ERROR_TAG accordingly and MAY clear the entity, e.g. Context or
which caused the failure, in the response. Configurable-Policy, which caused the failure, in the response.
If based upon Agent configuration or the processing of the request If based upon Agent configuration or the processing of the request
possibly taking a significant amount of time the Agent MAY respond possibly taking a significant amount of time the Agent MAY respond
with an OK_NOTIFY_FOLLOWS with an optional RESPONSE_BODY containing with a NOTIFY_FOLLOWS indicaiton with an optional RESPONSE_BODY
the partially completed entities. When an OK_NOTIFY_FOLLOWS is sent, containing the partially completed entities. When a NOTIFY_FOLLOWS
the Agent will, upon completion or failure of the operation, respond indication is indicated, the Agent will, upon completion or failure
with an asynchronous CONFIG_RESULT_NOTIFY to the Client. 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 A Client MAY add a property to a Context without providing all
required details of the attribute's value. In such case the Agent required details of the attribute's value. In such case the Agent
SHOULD determine the missing details and provide the completed SHOULD determine the missing details and provide the completed
property description back to the Client. If the processing will take property description back to the Client. If the processing will take
too long or based upon Agent configuration, the Agent MAY respond too long or based upon Agent configuration, the Agent MAY respond
with an OK_NOTIFY_FOLLOWS with a RESPONSE_BODY containing the with an OK that indicates a NOTIFY_FOLLOWS and also includes a
partially completed entities. RESPONSE_BODY containing the partially completed entities.
In case the Agent cannot determine the missing value of an In case the Agent cannot determine the missing value of an
attribute's value per the Client's request, it leaves the attribute's attribute's value per the Client's request, it leaves the attribute's
value cleared in the RESPONSE_BODY and sets the RESULT to Error, value cleared in the RESPONSE_BODY and sets the RESULT to Error,
ERROR_TYPE_ID and ERROR_INFORMATION. As example, the Control-Plane ERROR_TYPE and ERROR_TAG. As example, the Control-Plane needs to
needs to setup a tunnel configuration in the Data-Plane but has to setup a tunnel configuration in the Data-Plane but has to rely on the
rely on the Agent to determine the tunnel endpoint which is Agent to determine the tunnel endpoint which is associated with the
associated with the DPN that supports the Context. The Client adds DPN that supports the Context. The Client adds the tunnel property
the tunnel property attribute to the FPC message and clears the value attribute to the FPC message and clears the value of the attribute
of the attribute (e.g. IP address of the local tunnel endpoint). (e.g. IP address of the local tunnel endpoint). The Agent
The Agent determines the tunnel endpoint and includes the completed determines the tunnel endpoint and includes the completed tunnel
tunnel property in its response to the Client. property in its response to the Client.
Figure 17 illustrates an exemplary session life-cycle based on Proxy Figure 15 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)--CONFIG(CREATE)--->| | | | |---(1)--CONFIG(CREATE)--->| |
| | | [ CONTEXT_ID, |--tun1 up->| | | | [ MOBILTY_CONTEXT_ID, |--tun1 up->|
| | | DPNREFLIST:[[DPN1, BOTH | |
| | | DPN_SETTINGS_COMPL:[ | |
| | | DOWNLINK(QOS/TUN), | | | | | DOWNLINK(QOS/TUN), | |
| | | UPLINK(QOS/TUN), |--tc qos-->| | | | UPLINK(QOS/TUN)] ]] |--tc qos-->|
| | | IP_PREFIX(HNP) ] | | | | | CTXT_SETTINGS_COMPL:[ | |
| | | IP_PREFIX(HNP) ] ] | |
| | |<---(2)- OK --------------|-route add>| | | |<---(2)- OK --------------|-route add>|
| | | | | | | | | |
|<------------PBA------| | | |<------------PBA------| | |
| | | | | | | | | |
| +----+ | | | | | +----+ | | | |
| |Edge| | | | | | |Edge| | | | |
| |DPN1| | | | | | |DPN1| | | | |
| +----+ | | | | | +----+ | | | |
| | | | | |
| |-=======================================================-| | |-=======================================================-|
| | | | | | | |
| [MN handover] | | | | [MN handover] | | |
| |---PBU ---->| | | | |---PBU ---->| | |
| | |--(3)- CONFIG(MODIFY)---->| | | | |--(3)- CONFIG(MODIFY)---->| |
| |<--PBA------| [ CONTEXT_ID |-tun1 mod->| | |<--PBA------| [ MOBILTY_CONTEXT_ID |-tun1 mod->|
| | | DOWNLINK(TUN), | | | | | DPNREFLIST:[[DPN1, BOTH | |
| | +----+ | UPLINK(TUN) ] | | | | | DPN_SETTINGS_COMPL:[ | |
| | | DOWNLINK(TUN), | |
| | +----+ | UPLINK(TUN)] ]] ] | |
| | |Edge| |<---(4)- OK --------------| | | | |Edge| |<---(4)- OK --------------| |
| | |DPN2| | | | | | |DPN2| | | |
| | +----+ | | | | | +----+ | | |
| | | | | | | | | | | |
| | |-============================================-| | | |-============================================-|
| | | | | | | | | |
Figure 17: Exemplary Message Sequence (focus on FPC reference point) Figure 15: 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 Context to the DPN to treat the MN's traffic LMA-C adds a new logical Context to the DPN to treat the MN's traffic
(1) and includes a Context Identifier (CONTEXT_ID) to the CONFIG (1) and includes a Context Identifier (CONTEXT_ID) to the CONFIG
command. The LMA-C identifies the selected Anchor DPN by including command. The LMA-C identifies the selected Anchor DPN by including
the associated DPN identifier. the associated DPN identifier and the Direction the entry applies to,
BOTH.
The LMA-C adds properties during the creation of the new Context. The LMA-C adds properties during the creation of the new Context.
One property is added to specify the forwarding tunnel type and One property is added to the DPN Settings Complimentary, to specify
endpoints (Anchor DPN, Edge DPN1) in each direction (as required). the forwarding tunnel type and endpoints (Anchor DPN, Edge DPN1) in
Another property is added to specify the QoS differentiation, which each direction (as required). Another property is added to specify
the MN's traffic should experience. At reception of the Context, the the QoS differentiation, which the MN's traffic should experience.
FPC Agent utilizes local configuration commands to create the tunnel At reception of the Context, the FPC Agent utilizes local
(tun1) as well as the traffic control (tc) to enable QoS configuration commands to create the tunnel (tun1) as well as the
differentiation. After configuration has been completed, the Agent traffic control (tc) to enable QoS differentiation. After
applies a new route to forward all traffic destined to the MN's HNP configuration has been completed, the Agent applies a new route to
specified as a property in the Context to the configured tunnel forward all traffic destined to the MN's HNP specified as a property
interface (tun1). in the Context's Complementary Settings and applied 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 endpoints in the downlink and uplink, as to represent the new tunnel endpoints in the downlink and uplink, as
required. The LMA-C sends a CONFIG message (3) to the Agent to required. The LMA-C sends a CONFIG message (3) to the Agent to
modify the existing tunnel property of the existing Context and to modify the existing tunnel property of the existing Context and to
update the tunnel endpoint from Edge DPN1 to Edge DPN2. Upon update the tunnel endpoint from Edge DPN1 to Edge DPN2. Upon
reception of the CONFIG message, the Agent applies updated tunnel reception of the CONFIG message, the Agent applies updated tunnel
property to the local configuration and responds to the Client (4). property to the local configuration and responds to the Client (4).
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(MODIFY)--->| | | | |---(1)--CONFIG(MODIFY)--->| |
|<------------PBA------| [ CONTEXT_ID, |--tun1 ->| |<------------PBA------| [ CONTEXT_ID, |--tun1 ->|
| | | DPNREFLIST:[[DPN1, BOTH | |
| | | DPN_SETTINGS_COMPL:[ | |
| | | DOWNLINK(TUN delete), | down | | | | DOWNLINK(TUN delete), | down |
| | | UPLINK(TUN delete) ] | | | | | UPLINK(TUN delete)] ]] ] | |
| | | | | | | | | |
| | |<-(2)- OK ----------------| | | | |<-(2)- OK ----------------| |
| | | | | | | | | |
| | [ MinDelayBeforeBCEDelete expires ] | | | | [ MinDelayBeforeBCEDelete expires ] | |
| | | | | | | | | |
| | |---(3)--CONFIG(DELETE)--->|-- tun1 -->| | | |---(3)--CONFIG(DELETE)--->|-- tun1 -->|
| | | | delete | | | | | delete |
| | |<-(4)- OK ----------------| | | | |<-(4)- OK ----------------| |
| | | |-- route ->| | | | |-- route ->|
| | | | remove | | | | | remove |
| | | | | | | | | |
Figure 18: Exemplary Message Sequence (focus on FPC reference point) Figure 16: Exemplary Message Sequence (focus on FPC reference point)
When a teardown of the session occurs, MAG-C1 will send a PBU with a When a teardown of the session occurs, MAG-C1 will send a PBU with a
lifetime value of zero. The LMA-C sends a CONFIG message (1) to the lifetime value of zero. The LMA-C sends a CONFIG message (1) to the
Agent to modify the existing tunnel property of the existing Context Agent to modify the existing tunnel property of the existing Context
to delete the tunnel information.) Upon reception of the CONFIG to delete the tunnel information.) Upon reception of the CONFIG
message, the Agent removes the tunnel configuration and responds to message, the Agent removes the tunnel configuration and responds to
the Client (2). Per [RFC5213], the PBA is sent back immediately the Client (2). Per [RFC5213], the PBA is sent back immediately
after the PBA is received. after the PBA is received.
If no valid PBA is received after the expiration of the If no valid PBA is received after the expiration of the
MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a
CONFIG (3) message with a deletion request for the Context. Upon CONFIG (3) message with a deletion request for the Context. Upon
reception of the message, the Agent deletes the tunnel and route on reception of the message, the Agent deletes the tunnel and route on
the DPN and responds to the Client (4). the DPN and responds to the Client (4).
When a multi-DPN Agent is used the DPN list permits several DPNs to When a multi-DPN Agent is used the DPN list permits several DPNs to
be provisioned in a single message. be provisioned in a single message for the single Conext.
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN1 | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN1 |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(CREATE)--->| | | | |---(1)--CONFIG(CREATE)--->| |
| | | [ CONTEXT_ID, DPNS [ |--tun1 up->| | | | [ MOBILTY_CONTEXT_ID, |--tun1 up->|
| | |[DPN1,DOWNLINK(QOS/TUN)], | | | | | DPNREFLIST:[[DPN1, BOTH | |
| | | [DPN1,UPLINK(QOS/TUN)], |--tc qos-->| | | | DPN_SETTINGS_COMPL:[ | |
| | |[DPN2,DOWNLINK(QOS/TUN)], | | | | | DOWNLINK(QOS/TUN), | |
| | | [DPN2,UPLINK(QOS/TUN)], | | | | | UPLINK(QOS/TUN) ] ], |--tc qos-->|
| | | IP_PREFIX(HNP) ] | | | | | [DPN2, BOTH | |
| | | DPN_SETTINGS_COMPL:[ | |
| | | DOWNLINK(QOS/TUN), | |
| | | UPLINK(QOS/TUN) ] ] ], | |
| | | CTXT_SETTINGS_COMPL [ | |
| | | IP_PREFIX(HNP) ] ] | |
| | |<-(2)- OK_NOTIFY_FOLLOWS -|-route add>| | | |<-(2)- OK_NOTIFY_FOLLOWS -|-route add>|
| | | | | | | | | |
|<------------PBA------| | | |<------------PBA------| | |
| | | | | | | | | |
| +----+ | | | | +----+ | | |
| |Edge| | | | | |Edge| | | |
| |DPN2| | | | | |DPN2| | | |
| +----+ | | | | +----+ | | |
| |<---------------------- tun1 up -------------| | | |<---------------------- tun1 up -------------| |
| |<---------------------- tc qos --------------| | | |<---------------------- tc qos --------------| |
| |<---------------------- route add -----------| | | |<---------------------- route add -----------| |
| | | | | | | | | |
| | |<(3) CONFIG_RESULT_NOTIFY | | | | |<(3) CONFIG_RESULT_NOTIFY | |
| | | [ Response Data ] | | | | | [ Response Data ] | |
| | | | | | | | | |
Figure 19: Exemplary Message Sequence for Multi-DPN Agent Figure 17: Exemplary Message Sequence for Multi-DPN Agent
Figure 19 shows how the first 2 messages in Figure 17 are supported Figure 17 shows how the first 2 messages in Figure 15 are supported
when a multi-DPN Agent communicates with both Anchor DPN1 and Edge when a multi-DPN Agent communicates with both Anchor DPN1 and Edge
DPN2. In such a case, the FPC Client sends the downlink and uplink DPN2. In such a case, the FPC Client sends the downlink and uplink
for both DPNs in the "DPNS" list of the same Context. Message 1 for both DPNs in the DPN Reference List of the same Context. Message
shows the DPNS list with all entries. Each entry identifies the DPN 1 shows the DPN Reference List with all entries. Each entry
and direction (one of 'uplink', 'downlink' or 'both'). Generally, identifies the DPN and direction (one of 'uplink', 'downlink' or
the 'both' direction is not used for normal mobility session 'both').
processing. It is commonly used for the instantiation of Policies on
a specific DPN (see Section 5.2.4).
The Agent responds with an OK_NOTIFY_FOLLOWS while it simultaneoulsy The Agent responds with an OK and NOTIFY_FOLLOWS indication while it
provisions both DPNs. Upon successful completion, the Agent responds simultaneoulsy provisions both DPNs. Upon successful completion, the
to the Client with a CONFIG_RESULT_NOTIFY indicating the operation Agent responds to the Client with a CONFIG_RESULT_NOTIFY indicating
status. the operation status.
5.2.2. Policy And Mobility on the Agent 5.2.2. Policy And Mobility on the Agent
A Client may build Policy and Topology using any mechanism on the A Client may build Policy and Topology using any mechanism on the
Agent. Such entities are not always required to be constructed in Agent. Such entities are not always required to be constructed in
realtime and, therefore, there are no specific messages defined for realtime and, therefore, there are no specific messages defined for
them in this specification. them in this specification.
The Client may add, modify or delete many Vports and Contexts in a The Client may add, modify or delete many Installed Policies and
single FPC message. This includes linking Contexts to Actions and Contexts in a single FPC message. This includes linking Contexts to
Descriptors, i.e. a Rule. As example, a Rule which performs re- Actions and Descriptors, i.e. a Rule. As example, a Rule which
writing of an arriving packet's destination IP address from IP_A to performs re-writing of an arriving packet's destination IP address
IP_B matching an associated Descriptor, can be enforced in the Data- from IP_A to IP_B matching an associated Descriptor, can be enforced
Plane via an Agent to implicitly consider matching arriving packet's in the Data-Plane via an Agent to implicitly consider matching
source IP address against IP_B and re- write the source IP address to arriving packet's source IP address against IP_B and re- write the
IP_A. source IP address to IP_A.
Figure 20 illustrates the generic policy configuration model as used Figure 18 illustrates the generic policy configuration model as used
between a FPC Client and a FPC Agent. between a FPC Client and a FPC Agent.
Descriptor_1 -+ +- Action_1 Descriptor_1 -+ +- Action_1
| | | |
Descriptor_2 -+--<Rule>--+- Action_2 Descriptor_2 -+--<Rule>--+- Action_2
+------+ +------+
/Order#/-------------+ /Order#/-------------+
+------+ | +------+ |
| |
Descriptor_3 -+ +- Action_3 +-<PolicyID> Descriptor_3 -+ +- Action_3 +-<Policy>
| | | ^ | | | ^
Descriptor_4 -+--<Rule>--+- Action_4 | | Descriptor_4 -+--<Rule>--+- Action_4 | |
+------+ | <PolicyGroupID> +------+ | |
/Order#/-------------+ ^ /Order#/-------------+ |
+------+ | +------+ |
<VportID> <Intsalled-Policy>
+-------------------+ +---------------------+ +---------------------+ +----------------------+
| Bind 1..M traffic | | Bind 1..N traffic | | Bind 1..M traffic | | Bind 1..N traffic |
| Descriptors to | --> | treatment actions | | Descriptors to | --> | treatment actions |
| a Policy, | | to a Policy, | | to a Policy and | | to a Policy and |
| Policy-Group and | | Policy-Group and | | Configurable-Policy | | Configurable-Policy |
| Vport | | Vport | +---------------------+ +----------------------+
+-------------------+ +---------------------+
| | | |
+-------------- Data-Plane Rule ------------------+ +-------------- Data-Plane Rule ------------------+
Figure 20: Structure of Policies and Vports Figure 18: Structure of Configurable Policies
As depicted in Figure 20, the Vport represents the anchor of Rules As depicted in Figure 18, the Configurable-Policy represents the
through the Policy-group, Policy, Rule hierarchy configured by any anchor of Rules through the Policy / Rule hierarchy. A Client and
mechanism including RPC or N. A Client and Agent use the identifier Agent use the identifier of the associated Policy to directly access
of the associated Policy to directly access the Rule and perform the Rule and perform modifications of traffic Descriptors or Action
modifications of traffic Descriptors or Action references. A Client references. A Client and Agent use the identifiers to access the
and Agent use the identifiers to access the Descriptors or Actions to Descriptors or Actions to perform modifications. From the viewpoint
perform modifications. From the viewpoint of packet processing, of packet processing, arriving packets are matched against traffic
arriving packets are matched against traffic Descriptors and Descriptors and processed according to the treatment Actions
processed according to the treatment Actions specified in the list of specified in the list of properties associated with the Configurable-
properties associated with the Vport. Policy.
A Client complements a rule's Descriptors with a Rule's Order A Client complements a rule's Descriptors with a Rule's Order
(priority) value to allow unambiguous traffic matching on the Data- (priority) value to allow unambiguous traffic matching on the Data-
Plane. Plane.
Figure 21 illustrates the generic context configuration model as used Figure 19 illustrates the generic context configuration model as used
between a FPC Client and a FPC Agent. between a FPC Client and a FPC Agent.
TrafficSelector_1 TrafficSelector_1
| |
profile-parameters profile-parameters
| |
mobility-profile-- dl ------+ mobility-profile-- dl ------+
^ | ^ |
| qos-profile | qos-profile
<ContextID1> | <ContextID1> |
skipping to change at page 39, line 27 skipping to change at page 37, line 45
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| Bind 1..M traffic | | Bind 1..N traffic | | Bind 1..M traffic | | Bind 1..N traffic |
| selectors to | --> | treatment / qos | | selectors to | --> | treatment / qos |
| a Context | | actions to a | | a Context | | actions to a |
| | | Context | | | | Context |
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| | | |
+-------------- Data-Plane Rule ------------------+ +-------------- Data-Plane Rule ------------------+
Figure 21: Structure of Contexts Figure 19: Structure of Contexts
As depicted in Figure 21, the Context represents a mobility session As depicted in Figure 19, the Context represents a mobility session
hierarchy. A Client and Agent directly assigns values such as hierarchy. A Client and Agent directly assigns values such as
downlink traffic descriptors, QoS information, etc. A Client and downlink traffic descriptors, QoS information, etc. A Client and
Agent use the context identifiers to access the descriptors, qos Agent use the context identifiers to access the descriptors, qos
information, etc. to perform modifications. From the viewpoint of information, etc. to perform modifications. From the viewpoint of
packet processing, arriving packets are matched against traffic packet processing, arriving packets are matched against traffic
Descriptors and processed according to the qos or other mobility Descriptors and processed according to the qos or other mobility
profile related Actions specified in the Context's properties. If profile related Actions specified in the Context's properties. If
present, the final action is to use a Context's tunnel information to present, the final action is to use a Context's tunnel information to
encapsulate and forward the packet. encapsulate and forward the packet.
A second Context also references context1 in the figure. Based upon A second Context also references context1 in the figure. Based upon
the technology a property in a parent context MAY be inherited by its the technology a property in a parent context (parent mobility-
descendants. This permits concise over the wire representation. context-id reference) MAY be inherited by its descendants. This
When a Client deletes a parent Context all children are also deleted. permits concise over the wire representation. When a Client deletes
a parent Context all children are also deleted.
5.2.3. Optimization for Current and Subsequent Messages 5.2.3. Optimization for Current and Subsequent Messages
5.2.3.1. Bulk Data in a Single Operation 5.2.3.1. Configuration Bundles
A single operation MAY contain multiple entities. This permits
bundling of requests into a single operation. In the example below
two PMIP sessions are created via two PBU messages and sent to the
Agent in a single CONFIG message (1). Upon recieveing the message,
the Agent responds back with an OK_NOTIFY_FOLLOWS (2), completes work
on the DPN to activate the associated sessions then responds to the
Client with a CONFIG_RESULT_NOTIFY (3).
+-------Router--------+
+-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ 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 ] | |
| | | | |
| | | | |
Figure 22: Exemplary Bulk Entity with Asynchronous Notification
Sequence (focus on FPC reference point)
5.2.3.2. Configuration Bundles
Bundles provide transaction boundaries around work in a single Bundles provide transaction boundaries around work in a single
message. Operations in a bundle MUST be successfully executed in the message. Operations in a bundle MUST be successfully executed in the
order specified. This allows references created in one operation to order specified. This allows references created in one operation to
be used in a subsequent operation in the bundle. be used in a subsequent operation in the bundle.
The example bundle shows in Operation 1 (OP 1) the creation of a The example bundle shows in Operation 1 (OP 1) the creation of a
Context 1 which is then referenced in Operation 2 (OP 2) by Context 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 CONTEXT_ID 2. If OP 1 fails then OP 2 will not be executed. The
advantage of the CONF_BUNDLE is preservation of dependency orders in advantage of the CONF_BUNDLE is preservation of dependency orders in
skipping to change at page 41, line 17 skipping to change at page 39, line 12
prior to the current operation are preserved in order to reduce prior to the current operation are preserved in order to reduce
system load. system load.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor | | FPC | | FPC | | Anchor |
| Client | | Agent | | DPN | | Client | | Agent | | DPN |
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
| | | | | |
|--CONF_BUNDLE(CREATE)---->| | |--CONF_BUNDLE(CREATE)---->| |
| [ OP 1, [VPORT X ] | | | [ OP 1, | |
| [ CONTEXT_ID 1, | | | [ MOBILTY_CONTEXT_ID 1, |--tun1 up->|
| DPNREFLIST:[[DPN1, BOTH | |
| DPN_SETTINGS_COMPL:[ | |
| DOWNLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN), | |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN)] ]] |--tc qos-->|
| IP_PREFIX(HNP) ] | | | CTXT_SETTINGS_COMPL:[ | |
| [ OP 2, | | | IP_PREFIX(HNP) ] ] ],| |
| [ CONTEXT_ID 2, | | | [ OP 2, | |
| PARENT_CONTEXT_ID 1, | | | [ MOBILTY_CONTEXT_ID, |--tun1 up->|
| UPLINK(QOS/TUN), | | | DPNREFLIST:[[DPN1, BOTH | |
| DOWNLINK(QOS/TUN) ] ] | | | DPN_SETTINGS_COMPL:[ | |
| | |
Figure 23: 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 will then override copied values. To avoid the
accidental activation of the Contexts on the DPN, the CONFIG (1)
message with the cloning instruction has a SESSION_STATE with a value
of 'incomplete' and OP_TYPE of 'CREATE'. A second CONFIG (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 |
+-----------+ +-------+ +---------+
| | |
|--CONF_BUNDLE(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), | | | DOWNLINK(QOS/TUN), | |
| IP_PREFIX(HNP) ] ] | | | UPLINK(QOS/TUN)] ]] |--tc qos-->|
|<----- OK ----------------| | | PARENT_CONTEXT_ID_REF=1 | |
| | | | ] ] | |
|--CONF_BUNDLE(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 24: Exemplary Bundle Message (focus on FPC reference point) Figure 20: 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 serialization / deserialization of multiple entities
incurs some form of performance penalty.
5.2.3.4. Command Bitsets (Optional) 5.2.3.2. Command Bitsets (Optional)
Command Sets permit the ability to provide a single, unified data Command Sets permit the ability to provide a single, unified data
structure, e.g. CONTEXT, and specify which activities are expected structure, e.g. Mobility-Context, and specify which activities are
to be performed on the DPN. This has some advantages expected to be performed on the DPN. This has some advantages
o Rather than sending N messages with a single operation performed 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 on the DPN a single message can be used with a Command Set that
specifies the N DPN operations to be executed. specifies the N DPN operations to be executed.
o Errors become more obvious. For example, if the HNP is NOT o Errors become more obvious. For example, if the HNP is NOT
provided but the Client did not specify that the HNP should be provided but the Client did not specify that the HNP should be
assigned by the Agent this error is easily detected. Without the assigned by the Agent this error is easily detected. Without the
Command Set the default behavior of the Agent would be to assign 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 the HNP and then respond back to the Client where the error would
skipping to change at page 43, line 21 skipping to change at page 40, line 9
the error. Such situations can increase the time to error the error. Such situations can increase the time to error
detection and overall system load without the Command Set present. detection and overall system load without the Command Set present.
o Unambiguous provisioning specification. The Agent is exactly in o Unambiguous provisioning specification. The Agent is exactly in
sync with the expectations of the Client as opposed to guessing sync with the expectations of the Client as opposed to guessing
what DPN work could be done based upon data present at the Agent. what DPN work could be done based upon data present at the Agent.
This greatly increases the speed by which the Agent can complete This greatly increases the speed by which the Agent can complete
work. work.
o Permits different technologies with different instructions to be o Permits different technologies with different instructions to be
sent in the same message. supported in FPC.
As Command Bitsets are technology specific, e.g. PMIP or 3GPP As Command Bitsets are technology specific, e.g. PMIP or 3GPP
Mobility, the type of work varies on the DPN and the amount of data 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 present in a Context or Port will vary. Using the technology
specific instructions allows the Client to serve multiple specific instructions allows the Client to serve multiple
technologies and MAY result in a more stateless Client as the technologies and MAY result in a more stateless Client as the
instructions are transferred the Agent which will match the desired, instructions are transferred the Agent which will match the desired,
technology specific instructions with the capabilities and over the technology specific instructions with the capabilities and over the
wire protocol of the DPN more efficiently. wire protocol of the DPN more efficiently.
5.2.3.5. Reference Scope(Optional) 5.2.3.3. Reference Scope(Optional)
Although entities MAY refer to any other entity of an appropriate Although entities MAY refer to any other entity of an appropriate
type, e.g. Contexts can refer to Vports or Contexts, the Reference type, e.g. Contexts can refer to Policies or other Contexts, the
Scope gives the Agent an idea of where those references reside. They Reference Scope gives the Agent an idea of where those references
may be in the same operation, an operation in the same CONF_BUNDLE reside. They may be in the same operation, an operation in the same
message or in storage. There may also be no references. This CONF_BUNDLE message or in storage. There may also be no references.
permits the Agent to understand when it can stop searching for This permits the Agent to understand when it can stop searching for
reference it cannot find. For example, if a CONF_BUNDLE message uses reference it cannot find. For example, if a CONF_BUNDLE message uses
a Reference Scope of type 'op' then it merely needs to keep an a Reference Scope of type 'op' then it merely needs to keep an
operation level cache and consume no memory or resources searching operation level cache and consume no memory or resources searching
across the many operations in the CONF_BUNDLE message or the data across the many operations in the CONF_BUNDLE message or the data
store. store.
Agents can also be stateless by only supporting the 'none', 'op' and Agents can also be stateless by only supporting the 'none', 'op' and
'bundle' reference scopes. This does not imply they lack storage but 'bundle' reference scopes. This does not imply they lack storage but
merely the search space they use when looking up references for an merely the search space they use when looking up references for an
entity. The figure below shows the caching hierarchy provided by the entity. The figure below shows the caching hierarchy provided by the
skipping to change at page 44, line 4 skipping to change at page 40, line 39
a Reference Scope of type 'op' then it merely needs to keep an a Reference Scope of type 'op' then it merely needs to keep an
operation level cache and consume no memory or resources searching operation level cache and consume no memory or resources searching
across the many operations in the CONF_BUNDLE message or the data across the many operations in the CONF_BUNDLE message or the data
store. store.
Agents can also be stateless by only supporting the 'none', 'op' and Agents can also be stateless by only supporting the 'none', 'op' and
'bundle' reference scopes. This does not imply they lack storage but 'bundle' reference scopes. This does not imply they lack storage but
merely the search space they use when looking up references for an merely the search space they use when looking up references for an
entity. The figure below shows the caching hierarchy provided by the entity. The figure below shows the caching hierarchy provided by the
Reference Scope Reference Scope
Caches are temporarily created at each level and as the scope Caches are temporarily created at each level and as the scope
includes more caches the amount of entities that are searched includes more caches the amount of entities that are searched
increases. Figure 25 shows an example containment hierarchy provided increases. Figure 21 shows an example containment hierarchy provided
for all caches. for all caches.
+---------------+ +---------------+
| Global Cache | | Global Cache |
| (storage) | | (storage) |
+------+--------+ +------+--------+
| |
+----------------------+ +----------------------+
| | | |
+------+--------+ +------+--------+ +------+--------+ +------+--------+
skipping to change at page 44, line 30 skipping to change at page 41, line 26
| |
+--------------------+--------------------+ +--------------------+--------------------+
| | | | | |
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
| Operation Cache | | Operation Cache | | Operation Cache | | Operation Cache | | Operation Cache | | Operation Cache |
| (op) | | (op) | | (op) | | (op) | | (op) | | (op) |
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
(no cache) (no cache)
Figure 25: Exemplary Hierarchical Cache Figure 21: Exemplary Hierarchical Cache
5.2.4. Pre-provisioning
Although Contexts are used for Session based lifecycle elements,
Vports may exist outside of a specific lifecycle and represent more
general policies that may affect multiple Contexts (sessions). The
use of pre-provisioning of Vports permits policy and administrative
use cases to be executed. 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 Vports.
The figure below shows a CONFIG (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)----->| |
| [ VPORT_ID port1, | |
| [ policy-group1 ] ] | |
| [ CONTEXT_ID preprov, | |
| DPN_ID X, | |
| [ port1 ] ] | |
| | |
Figure 26: Exemplary Config Message for policy pre-provisioning
5.2.4.1. Basename Registry Feature (Optional) 5.2.3.4. Basename Registry Feature (Optional)
The Optional BaseName Registry support feature is provided to permit The Optional BaseName Registry support feature is provided to permit
Clients and tenants with common scopes, referred to in this Clients and tenants with common scopes, referred to in this
specification as BaseNames, to track the state of provisioned policy specification as BaseNames, to track the state of provisioned policy
information on an Agent. The registry records the BaseName and information on an Agent. The registry records the BaseName and
Checkpoint set by a Client. If a new Client attaches to the Agent it 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 can query the Registry to determine the amount of work that must be
executed to configure the Agent to a BaseName / checkpoint revision. executed to configure the Agent to a BaseName / checkpoint revision.
A State value is also provided in the registry to help Clients A State value is also provided in the registry to help Clients
coordinate work on common BaseNames. coordinate work on common BaseNames.
6. Protocol Message Details 6. Protocol Message Details
6.1. Data Structures And Type Assignment 6.1. Data Structures And Type Assignment
This section provides a type mapping for FPC structures. When being
mapped to a specific information such as YANG the data type MAY
change.
6.1.1. Policy Structures 6.1.1. Policy Structures
+--------------+-----------------+----------------------------+ +------------+------------------+-----------------------------------+
| Structure | Field | Type | | Structure | Field | Type |
+--------------+-----------------+----------------------------+ +------------+------------------+-----------------------------------+
| ACTION | ACTION_ID | FPC-Identity (Section 4.4) | | ACTION | ACTION_ID | FPC-Identity (Section 4.8) |
| | | | | | | |
| ACTION | TYPE | [32, unsigned integer] | | ACTION | ACTION_TYPE | [32, unsigned integer] |
| | | | | | | |
| ACTION | VALUE | Type specific | | ACTION | ACTION_VALUE | Type specific |
| | | | | | | |
| DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 4.4) | | DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 4.8) |
| | | | | | | |
| DESCRIPTOR | TYPE | [32, unsigned integer] | | DESCRIPTOR | DESCRIPTOR_TYPE | [32, unsigned integer] |
| | | | | | | |
| DESCRIPTOR | VALUE | Type specific | | DESCRIPTOR | DESCRIPTOR_VALUE | Type specific |
| | | | | | | |
| POLICY | POLICY_ID | FPC-Identity (Section 4.4) | | POLICY | POLICY_ID | FPC-Identity (Section 4.8) |
| | | | | | | |
| POLICY | RULES | *[ RULE ] (See Table 4) | | POLICY | RULES | *[ PRECEDENCE RULE_ID ] |
| | | | | | | PRECENDENCE is [32, unsigned |
| POLICY-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 4.4) | | | | integer]. For Rule see Table 4 |
| | | | +------------+------------------+-----------------------------------+
| POLICY-GROUP | POLICIES | *[ POLICY_ID ] |
+--------------+-----------------+----------------------------+
Table 3: Action Fields Table 3: Action Fields
Policies contain a list of Rules by their order value. Each Rule Policies contain a list of Rules by their order value. Each Rule
contains Descriptors with optional directionality and Actions with contains Descriptors with optional directionality and Actions with
order values that specifies action execution ordering if the Rule has order values that specifies action execution ordering if the Rule has
multiple actions. multiple actions.
Rules consist of the following fields. Rules consist of the following fields.
+------------------+---------------+--------------------------------+ +------------------+-------------------+----------------------------+
| Field | Type | Sub-Fields | | Field | Type | Sub-Fields |
+------------------+---------------+--------------------------------+ +------------------+-------------------+----------------------------+
| ORDER | [16, INTEGER] | | | RULE_ID | FPC-Identity | |
| | | | | | (Section 4.8) | |
| RULE_DESCRIPTORS | *[ | DIRECTION [2, unsigned bits] | | | | |
| | DESCRIPTOR_ID | is an ENUMERATION (uplink, | | MATCH_TYPE | ENUMERATION [2, | |
| | DIRECTION ] | downlink or both). | | | unsigned bits] | |
| | | | | | ('AND' or 'OR') | |
| RULE_ACTIONS | *[ ACTION_ID | ACTION-ORDER [8, unsigned | | | | |
| | ACTION-ORDER | integer] specifies action | | RULE_DESCRIPTORS | *[ DESCRIPTOR_ID | DIRECTION [2, unsigned |
| | ] | execution order. | | | DIRECTION ] | bits] is an ENUMERATION |
+------------------+---------------+--------------------------------+ | | | (uplink, downlink or |
| | | both). |
| | | |
| RULE_ACTIONS | *[ ACTION_ID | ACTION-ORDER [8, unsigned |
| | ACTION_ORDER ] | integer] specifies action |
| | | execution order. |
+------------------+-------------------+----------------------------+
Table 4: Rule Fields Table 4: Rule Fields
6.1.2. Mobility Structures 6.1.2. Mobility Structures
+----------+----------------------------+ +---------------------------------+---------------------------------+
| Field | Type | | Field | Type |
+----------+----------------------------+ +---------------------------------+---------------------------------+
| VPORT_ID | FPC-Identity (Section 4.4) | | DPN_ID | FPC-Identity (Section 4.8) |
| | | | | |
| POLICIES | *[ POLICY_GROUP_ID ] | | 1*[ INSTALLED_POLICY_ID | |
+----------+----------------------------+ | POLICY_ID_REFERENCE | |
| POLICY_SETTINGS ] | |
Table 5: Vport Fields | DPN_POLICY_SETTINGS | |
| | |
+-----------------------+--------------------------------------+ | INSTALLED_POLICY_ID | FPC-Identity (Section 4.8) |
| Field | Type | | | |
+-----------------------+--------------------------------------+ | POLICY_ID_REFERENCE | POLICY_ID |
| CONTEXT_ID | FPC-Identity (Section 4.4) | | | |
| | | | POLICY_SETTINGS | A collection of policy specific |
| VPORTS | *[ VPORT_ID ] | | | setings (properties) |
| | | | | |
| DPN_GROUP_ID | FPC-Identity (Section 4.4) | | DPN_POLICY_SETTINGS | A collection of setings |
| | | | | (properties) that affect |
| DELEGATED IP PREFIXES | *[ IP_PREFIX ] | | | multiple installed policies. |
| | | +---------------------------------+---------------------------------+
| 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 field 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 Table 5: Configurable-Policy Fields
+----------------+------------------------------------+ +-------------------------------------+-----------------------------+
| Field | Type | | Field | Type |
+----------------+------------------------------------+ +-------------------------------------+-----------------------------+
| DPN_ID | FPC-Identity. See Section 4.4 | | MOBILITY_CONTEXT_ID | FPC-Identity (Section 4.8) |
| | | | | |
| DPN_NAME | [1024, OCTET STRING] | | DPN_GROUP_ID_REFERENCE | FPC-Identity (Section 4.8) |
| | | | | |
| DPN_GROUPS | * [ FPC-Identity ] See Section 4.4 | | PARENT_MOBILITY_CONTEXT_ID_REFERNCE | FPC-Identity (Section 4.8) |
| | | | | |
| NODE_REFERENCE | [1024, OCTET STRING] | | DPNS [NOTE 2] | *[ DPN_REFERENCE ] |
+----------------+------------------------------------+ | | |
| REQUEST_POLICY_REFERENCES | * [ POLICY_ID ] |
| | |
| CONTEXT_SETTINGS_COMPLEMENTARY | A Collection of Settings |
| | (properties). |
+-------------------------------------+-----------------------------+
Table 8: DPN Fields Table 6: Mobility Context Fields
+------------------+----------------------+ +----------------------------+--------------------------------------+
| Field | Type | | Field | Type |
+------------------+----------------------+ +----------------------------+--------------------------------------+
| DOMAIN_ID | [1024, OCTET STRING] | | DPN_ID | FPC-Identity (Section 4.8) |
| | | | | |
| DOMAIN_NAME | [1024, OCTET STRING] | | DIRECTION | See Table 4 |
| | | | | |
| DOMAIN_TYPE | [1024, OCTET STRING] | | INTERFACE_ID_REF | FPC-Identity (Section 4.8) |
| | | | | |
| DOMAIN_REFERENCE | [1024, OCTET STRING] | | EMBEDDED_RULES | *[ EMBEDDED_RULE ] |
+------------------+----------------------+ | | |
| DPN_SETTINGS_COMPLEMENTARY | A Collection of Settings |
| | (properties). |
| | |
| ASSIGNED_POLICY_REFERENCES | * [ POLICY_ID ] |
+----------------------------+--------------------------------------+
Table 9: Domain Fields Table 7: DPN_REFERENCE Fields
+------------------+------------------------------------------------+ +---------------------------+---------------------------------------+
| Field | Type | | Field | Type |
+------------------+------------------------------------------------+ +---------------------------+---------------------------------------+
| DPN_GROUP_ID | FPC-Identity. See Section 4.4 | | RULE_ID | FPC-Identity (Section 4.8) |
| | | | | |
| DATA_PLANE_ROLE | [4, ENUMERATION (data-plane, such as access- | | MATCH_TYPE | See Table 4 |
| | dpn, L2/L3 anchor-dpn.)] | | | |
| | | | PRECEDENCE | See Table 3 |
| ACCESS_TYPE | [4, ENUMERATION ()ethernet(802.3/11), 3gpp | | | |
| | cellular(S1,RAB)] | | ACTION_DEFINITION_SET | *[ ACTION_ORDER ACTION_ID ACTION_TYPE |
| | | | | ACTION_VALUE ] |
| MOBILITY_PROFILE | [4, ENUMERATION (ietf-pmip, 3gpp, or new | | | |
| | profile)] | | DESCRIPTOR_DEFINITION_SET | *[ DESCRIPTOR_ID DESCRIPTOR_TYPE |
| | | | | DESCRIPTOR_VALUE ] |
| PEER_DPN_GROUPS | * [ DPN_GROUP_ID MOBILITY_PROFILE | +---------------------------+---------------------------------------+
| | REMOTE_ENDPOINT_ADDRESS LOCAL_ENDPOINT_ADDRESS |
| | TUN_MTU DATA_PLANE_ROLE ] |
+------------------+------------------------------------------------+
Table 10: DPN Groups Fields Table 8: EMBEDDED_RULE Fields
6.1.4. Monitors 6.1.2.1. Monitors
+------------------+----------------------+-------------------------+ +---------------------+-------------------------+-------------------+
| Field | Type | Description | | Field | Type | Description |
+------------------+----------------------+-------------------------+ +---------------------+-------------------------+-------------------+
| MONITOR | MONITOR_ID TARGET | | | MONITOR | MONITOR_ID DETERRABLE | |
| | [REPORT_CONFIG] | | | | TARGET | |
| | | | | | BINDING_INFORMATION | |
| MONITOR_ID | FPC-Identity. See | | | | [REPORT_CONFIG] | |
| | Section 4.4 | | | | | |
| | | | | DETERRABLE | boolean | Deterrability |
| EVENT_TYPE_ID | [8, Event Type ID] | Event Type (unsigned | | | | indicator. |
| | | integer). | | | | |
| | | | | BINDING_INFORMATION | String | |
| TARGET | OCTET STRING (See | | | | | |
| | Section 4.3.3) | | | MONITOR_ID | FPC-Identity. See | |
| | | | | | Section 4.8 | |
| REPORT_CONFIG | [8, REPORT-TYPE] | | | | | |
| | [TYPE_SPECIFIC_INFO] | | | EVENT_TYPE_ID | [8, Event Type ID] | Event Type |
| | | | | | | (unsigned |
| PERIODIC_CONFIG | [32, period] | report interval (ms). | | | | integer). |
| | | | | | | |
| THRESHOLD_CONFIG | [32, low] [32, hi] | thresholds (at least | | TARGET | OCTET STRING (See | |
| | | one value must be | | | Section 4.7) | |
| | | present) | | | | |
| | | | | REPORT_CONFIG | [8, REPORT-TYPE] | |
| SCHEDULED_CONFIG | [32, time] | | | | [TYPE_SPECIFIC_INFO] | |
| | | | | | | |
| EVENTS_CONFIG | *[EVENT_TYPE_ID] | | | 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 Table 9: Monitor Structures and Attributes
TRIGGERS include but are not limited to the following values: TRIGGERS include but are not limited to the following values:
o Events specified in the Event List of an EVENTS CONFIG o Events specified in the Event List of an EVENTS CONFIG
o LOW_THRESHOLD_CROSSED o LOW_THRESHOLD_CROSSED
o HIGH_THRESHOLD_CROSSED o HIGH_THRESHOLD_CROSSED
o PERIODIC_REPORT o PERIODIC_REPORT
o SCHEDULED_REPORT o SCHEDULED_REPORT
o PROBED o PROBED
o DEREG_FINAL_VALUE o DEREG_FINAL_VALUE
6.2. Message Attributes 6.1.3. Message Attributes
6.2.1. Header 6.1.3.1. Header
Each operation contains a header with the following fields: Each operation contains a header with the following fields:
+-------------+------------------------+----------------------------+ +--------------+----------------+-----------------------------------+
| Field | Type | Messages | | Field | Type | Messages |
+-------------+------------------------+----------------------------+ +--------------+----------------+-----------------------------------+
| CLIENT_ID | FPC-Identity (Section | All | | CLIENT_ID | FPC-Identity | All |
| | 4.4) | | | | (Section 4.8) | |
| | | | | | | |
| DELAY | [32, unsigned integer] | All | | DELAY | [32, unsigned | All |
| | | | | | integer] | |
| OP_ID | [64, unsigned integer] | All | | | | |
| | | | | OP_ID | [64, unsigned | All |
| ADMIN_STATE | [8, admin state] | CONFIG, CONF_BUNDLE and | | | integer] | |
| | | REG_MONITOR | | | | |
| | | | | OP_REF_SCOPE | [4, | Values are none(0), op(1), |
| OP_TYPE | [8, op type] | CONFIG and CONF_BUNDLE | | | ENUMERATION] | bundle(2), storage(3) or |
+-------------+------------------------+----------------------------+ | | | unknown(4) |
+--------------+----------------+-----------------------------------+
Table 12: Message Header Fields
6.2.2. CONFIG and CONF_BUNDLE Attributes and Notifications Table 10: Message Header Fields
+---------------+----------------------+----------------------------+
| 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 [NOTE 1] |
| | See Section 5.1.1.4. | |
| | | |
| CLONES | *[ FPC-Identity FPC- | C,U [NOTE 1] |
| | Identity ] (Section | |
| | 4.4) | |
| | | |
| VPORTS | *[ VPORT ] | C,U |
| | | |
| CONTEXTS | *[ CONTEXT [ | C,U |
| | COMMAND_SET [NOTE 1] | |
| | ] ] | |
| | | |
| TARGETS | FPC-Identity | Q,D |
| | (Section 4.4) | |
| | *[DPN_ID] | |
| | | |
| POLICY_GROUPS | *[ POLICY-GROUP ] | C,U [NOTE 1] |
| | | |
| POLICIES | *[ POLICY ] | C,U [NOTE 1] |
| | | |
| DESCRIPTORS | *[ DESCRIPTOR ] | C,U [NOTE 1] |
| | | |
| ACTIONS | *[ ACTION ] | C,U [NOTE 1] |
+---------------+----------------------+----------------------------+
NOTE 1 - Only present if the corresponding feature is supported by 6.1.3.2. CONFIG and CONF_BUNDLE Attributes and Notifications
the Agent. +--------------------+--------------------+-------------------------+
| Field | Type | Operation Types |
| | | Create(C), Update(U), |
| | | Query(Q) and Delete(D) |
+--------------------+--------------------+-------------------------+
| OP_TYPE | [8, op type] | CONFIG and CONF_BUNDLE |
| | | |
| COMMAND_SET | FPC Command | C,U |
| | Bitset. See | |
| | Section 5.1.1.2. | |
| | | |
| INSTALLED_POLICIES | *[ | C,U |
| | INSTALLED_POLICY ] | |
| | | |
| MOBILITY-CONTEXTS | *[ MOBILITY- | C,U |
| | CONTEXT [ | |
| | COMMAND_SET [NOTE | |
| | 1] ] ] | |
| | | |
| TARGETS | FPC-Identity | Q,D |
| | (Section 4.8) | |
| | *[DPN_ID] | |
| | | |
| POLICIES | *[ POLICY ] | C,U |
| | | |
| RULES | *[ RULE ] | C,U |
| | | |
| DESCRIPTORS | *[ DESCRIPTOR ] | C,U |
| | | |
| ACTIONS | *[ ACTION ] | C,U |
+--------------------+--------------------+-------------------------+
Table 13: CONFIG and CONF_BUNDLE OP_BODY Fields Table 11: CONFIG and CONF_BUNDLE OP_BODY Fields
+-------------------+--------------------+--------------------------+ +--------------------+------------------+---------------------------+
| Field | Type | Operation Types | | Field | Type | Operation Types |
| | | Create(C), Update(U), | | | | Create(C), Update(U), |
| | | Query(Q) and Delete(D) | | | | Query(Q) and Delete(D) |
+-------------------+--------------------+--------------------------+ +--------------------+------------------+---------------------------+
| VPORTS | *[ VPORT ] | C,U [NOTE 2] | | OP_ID | [64, unsigned | All |
| | | | | | integer] | |
| CONTEXTS | *[ CONTEXT [ | C,U [NOTE 2] | | | | |
| | COMMAND_SET [NOTE | | | STATUS | [1, Enumerated] | OK(0) or Error(1) |
| | 1] ] ] | | | | | |
| | | | | NOTIFY_FOLLOWS | boolean | |
| TARGETS | *[ FPC-Identity | Q,D [NOTE 2] | | | | |
| | (Section 4.4) | | | POLICIES | *[ POLICY ] | C,U |
| | *[DPN_ID] ] | | | | | |
| | | | | RULES | *[ RULE ] | C,U |
| ERROR_TYPE_ID | [32, unsigned | All [NOTE 3] | | | | |
| | integer] | | | DESCRIPTORS | *[ DESCRIPTOR ] | C,U |
| | | | | | | |
| ERROR_INFORMATION | [1024, octet | All [NOTE 3] | | ACTIONS | *[ ACTION ] | C,U |
| | string] | | | | | |
+-------------------+--------------------+--------------------------+ | INSTALLED_POLICIES | *[ | C,U [NOTE 1] |
| | INSTALLED_POLICY | |
| | ] | |
| | | |
| CONTEXTS | *[ CONTEXT [ | C,U [NOTE 1] |
| | COMMAND_SET | |
| | [NOTE 1] ] ] | |
| | | |
| TARGETS | *[ FPC-Identity | Q,D [NOTE 1] |
| | (Section 4.8) ] | |
| | | |
| ERROR_TYPE_ID | [32, unsigned | All [NOTE 2] |
| | integer] | |
| | | |
| ERROR_TAG | [1024, octet | All [NOTE 2, 3] |
| | string] | |
+--------------------+------------------+---------------------------+
Table 14: Immediate Response RESPONSE_BODY Fields Table 12: Immediate Response RESPONSE_BODY Fields
Notes: Notes:
NOTE 1 - Only present if the corresponding feature is supported by NOTE 1 - Present in OK and OK with NOTIFY_FOLLOWS for both CONFIG
the Agent. and CONF_BUNDLE. MAY also be present in an CONF_BUNDLE Error
response (ERR) if one of the operations completed successfully.
NOTE 2 - Present in OK and OK_NOTIFY_FOLLOWS for both CONFIG and
CONF_BUNDLE. MAY also be present in an CONF_BUNDLE Error response
(ERR) if one of the operations completed successfully.
NOTE 3 - Present only for Error (ERR) responses. NOTE 2 - Present only for Error (ERR) responses.
+-----------------+--------------------+----------------------------+ NOTE 3 - Other Error Info (Strings) MAY also be present.
| 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 occurred. |
| | | |
| DATA | *[ OP_ID | |
| | RESPONSE_BODY | |
| | (Table 14) ] | |
+-----------------+--------------------+----------------------------+
Table 15: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields +-----------------+----------------------+--------------------------+
| Field | Type | Description |
+-----------------+----------------------+--------------------------+
| AGENT_ID | FPC-Identity | |
| | (Section 4.8) | |
| | | |
| OP_ID | [64, unsigned | All |
| | integer] | |
| | | |
| STATUS | [1, Enumerated] | OK(0) or Error(1) |
| | | |
| NOTIFICATION_ID | [32, unsigned | A Notification |
| | integer] | Identifier used to |
| | | determine notification |
| | | order. |
| | | |
| TIMESTAMP | [32, unsigned | The time that the |
| | integer] | notification occurred. |
| | | |
| DATA | *[ [OP_ID (if | |
| | CONF_BUNDLE) ] | |
| | RESPONSE_BODY (Table | |
| | 12) ] | |
+-----------------+----------------------+--------------------------+
6.2.3. Monitors Table 13: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields
6.1.3.3. Monitors
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
| Field | Type | Description | | Field | Type | Description |
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
| NOTIFICATION_ID | [32, unsiged | | | NOTIFICATION_ID | [32, unsiged | |
| | integer] | | | | integer] | |
| | | | | | | |
| TRIGGER | [32, unsigned | | | TIMESTAMP | [32, unsigned | |
| | integer] | | | | integer] | |
| | | | | | | |
| NOTIFY | NOTIFICATION_ID | Timestamp notes when the | | CAUSE | [32, unsigned | |
| | MONITOR_ID TRIGGER | event occurred. | | | integer] | |
| | [32, timestamp] | Notification Data is | | | | |
| | [NOTIFICATION_DATA] | TRIGGER and Monitor type | | NOTIFY | MONITOR | NOTIFICATION_DATA is the |
| | | specific. | | | [NOTIFICATION_DATA] | value of the monitored |
| | | target if this is not ean |
| | | error. |
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
Table 16: Monitor Notifications Table 14: Monitor Notifications
7. Derived and Subtyped Attributes 7. Derived and Subtyped Attributes
This section notes derived attributes. This section notes settings and derived attributes.
+------------------+-------+---------------+------------------------+ +---------------------------+---------------------+-----------------+
| Field | Type | Type | Description | | Field | Type | Detail |
| | Value | | | +---------------------------+---------------------+-----------------+
+------------------+-------+---------------+------------------------+ | TUN_LOCAL_ADDRESS | IP Address | [NOTE 1] |
| TO_PREFIX | 0 | [IP Address] | Aggregated or per-host | | | | |
| | | [ Prefix Len | destination IP | | TUN_REMOTE_ADDRESS | IP Address | [NOTE 1] |
| | | ] | address/prefix | | | | |
| | | | descriptor. | | TUN_MTU | [32, unsigned | |
| | | | | | | integer] | |
| FROM_PREFIX | 1 | [IP Address] | Aggregated or per-host | | | | |
| | | [ Prefix Len | source IP | | TUN_PAYLOAD_TYPE | [2, bits] | Enumeration: pa |
| | | ] | address/prefix | | | | yload_ipv4(0), |
| | | | descriptor. | | | | payload_ipv6(1) |
| | | | | | | | or payload_dual |
| TRAFFIC_SELECTOR | 2 | Format per | Traffic Selector. | | | | (2). |
| | | specification | | | | | |
| | | [RFC6088]. | | | TUN_TYPE | [8, unsigned | Enumeration: |
+------------------+-------+---------------+------------------------+ | | integer] | IP-in-IP(0), |
| | | UDP(1), GRE(2) |
| | | and GTP(3). |
| | | |
| TUN_IF | [16, unsigned | Input interface |
| | integer] | index. |
| | | |
| MOBILITY_SPECIFIC_TUN_PAR | [ IETF_PMIP_MOB_PRO | [NOTE 1] |
| AMS | FILE | | |
| | 3GPP_MOB_PROFILE ] | |
| | | |
| NEXTHOP | Varies | [NOTE 1] See |
| | | Table 18. |
| | | |
| QOS_PROFILE_PARAMS | [ 3GPP_QOS | | [NOTE 1] |
| | PMIP_QOS ] | |
+---------------------------+---------------------+-----------------+
Table 17: Descriptor Subtypes 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 15: Context Tunnel And QoS Settings
| 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 Value | Type | Description |
| (Type | | | |
| Value) | | | |
+-----------+------------------+--------------------+---------------+
| TO_PREFIX | [IP Address] [ | Aggregated or per- | FROM_PREFIX |
| (0) | Prefix Len ] | host destination | (1) |
| | | IP address/prefix | |
| | | descriptor. | |
| | | | |
| [IP | Aggregated or | TRAFFIC_SELECTOR | Format per |
| Address] | per-host source | (2) | specification |
| [ Prefix | IP | | [RFC6088]. |
| Len ] | address/prefix | | |
| | descriptor. | | |
| | | | |
| Traffic |
| Selector. |
+-----------+------------------+--------------------+---------------+
+-----------------+-------+-------------------+---------------------+ Table 16: Descriptor Subtypes
| 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). |
| | | | |
| SEGMENT_ID | 5 | [128, unsigned | Segement |
| | | integer] | Identifier. |
+-----------------+-------+-------------------+---------------------+
Table 19: Next Hop Subtypes +--------------+-------------------------+--------------------------+
| Field (Type | Type | Description |
| Value) | | |
+--------------+-------------------------+--------------------------+
| DROP (0) | Empty | Drop the associated |
| | | packets. |
| | | |
| REWRITE (1) | [in_src_ip] | Rewrite IP Address (NAT) |
| | [out_src_ip] | or IP Address / Port |
| | [in_dst_ip] | (NAPT). |
| | [out_dst_ip] | |
| | [in_src_port] | |
| | [out_src_port] | |
| | [in_dst_port] | |
| | [out_dst_port] | |
| | | |
| COPY_FORWARD | FPC-Identity. See | Copy all packets and |
| (2) | Section 4.8. | forward them to the |
| | | provided identity. The |
| | | value of the identity |
| | | MUST be a port or |
| | | context. |
+--------------+-------------------------+--------------------------+
Table 17: Action Subtypes
+--------------------------------+----------------+-----------------+
| Field (Type Value) | Type | Description |
+--------------------------------+----------------+-----------------+
| IP_ADDR (0) | IP Address | An IP Address. |
| | | |
| MAC_ADDR (1) | MAC Address | A MAC Address. |
| | | |
| SERVICE_PATH_ID (2) | [24, unsigned | Service Path |
| | integer] | Identifier |
| | | (SPI) |
| | | |
| MPLS_LABEL (3) | [20, unsigned | MPLS Label |
| | integer] | |
| | | |
| NSH (4) | [SERVICE_PATH_ | See [I-D.ietf-s |
| | ID] [8, | fc-nsh] |
| | unsigned | |
| | integer] | |
| | | |
| INTERFACE_INDEX (5) | [16, unsigned | Interface Index |
| | integer] | (an unsigned |
| | | integer). |
| | | |
| SEGMENT_ID (6) | [128, unsigned | Segement |
| | integer] | Identifier. |
| | | |
| MPLS_LABEL_STACK (7) | 7 | 1*[20 bit |
| | | labels] |
| | | |
| MPLS SR Stack. See [I-D.ietf-s | SRV6_STACK (8) | 32+ Bytes |
| pring-segment-routing-mpls]. | | |
| | | |
| See [I-D.ietf-6man-segment-rou |
| ting-header]. |
+--------------------------------+----------------+-----------------+
Table 18: Next Hop Subtypes
+----------+-------+------------------+-----------------------------+ +----------+-------+------------------+-----------------------------+
| Field | Type | Type | Description | | Field | Type | Type | Description |
| | Value | | | | | Value | | |
+----------+-------+------------------+-----------------------------+ +----------+-------+------------------+-----------------------------+
| QOS | 0 | [qos index type] | Refers to a single index | | QOS | 0 | [qos index type] | Refers to a single index |
| | | [index] [DSCP] | and DSCP to write to the | | | | [index] [DSCP] | and DSCP to write to the |
| | | | packet. | | | | | packet. |
| | | | | | | | | |
| GBR | 1 | [32, unsigned | Guaranteed bit rate. | | GBR | 1 | [32, unsigned | Guaranteed bit rate. |
| | | integer] | | | | | integer] | |
| | | | | | | | | |
| MBR | 2 | [32, unsigned | Maximum bit rate. | | MBR | 2 | [32, unsigned | Maximum bit rate. |
| | | integer] | | | | | integer] | |
| | | | | | | | | |
| PMIP_QOS | 3 | Varies by Type | A non-traffic selector PMIP | | PMIP_QOS | 3 | Varies by Type | A non-traffic selector PMIP |
| | | | QoS Attribute per [RFC7222] | | | | | QoS Attribute per [RFC7222] |
+----------+-------+------------------+-----------------------------+ +----------+-------+------------------+-----------------------------+
Table 20: QoS Subtypes Table 19: QoS Subtypes
+----------+---------+----------------+-----------------------------+ +----------+---------+----------------+-----------------------------+
| Field | Type | Type | Description | | Field | Type | Type | Description |
| | Value | | | | | Value | | |
+----------+---------+----------------+-----------------------------+ +----------+---------+----------------+-----------------------------+
| IPIP_TUN | 0 | | IP in IP Configuration | | IPIP_TUN | 0 | | IP in IP Configuration |
| | | | | | | | | |
| UDP_TUN | 1 | [src_port] | UDP Tunnel - source and/or | | UDP_TUN | 1 | [src_port] | UDP Tunnel - source and/or |
| | | [dst_port] | destination port | | | | [dst_port] | destination port |
| | | | | | | | | |
| GRE_TUN | 2 | [32, GRE Key] | GRE Tunnel. | | GRE_TUN | 2 | [32, GRE Key] | GRE Tunnel. |
+----------+---------+----------------+-----------------------------+ +----------+---------+----------------+-----------------------------+
Table 21: Tunnel Subtypes Table 20: Tunnel Subtypes
The following COMMAND_SET values are supported for IETF_PMIP. The following COMMAND_SET values are supported for IETF_PMIP.
o assign-ip - Assign the IP Address for the mobile session. o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node. o assign-dpn - Assign the Dataplane Node.
o session - Assign values for the Session Level. o session - Assign values for the Session Level.
o uplink - Command applies to uplink. o uplink - Command applies to uplink.
skipping to change at page 59, line 51 skipping to change at page 57, line 44
| | | attribute) | | | | | attribute) | |
| | | | | | | | | |
| 3GPP_QOS | 4 | QoS | [8, qci] [32, gbr] [32, mbr] | | 3GPP_QOS | 4 | QoS | [8, qci] [32, gbr] [32, mbr] |
| | | Subtypes | [32, apn_ambr] [32, ue_ambr] | | | | Subtypes | [32, apn_ambr] [32, ue_ambr] |
| | | namespace. | ARP | | | | namespace. | ARP |
| | | | | | | | | |
| ARP | N/A | N/A | See Allocation-Retention- | | ARP | N/A | N/A | See Allocation-Retention- |
| | | | Priority from [RFC7222] | | | | | Priority from [RFC7222] |
+-------------+-------+-------------+-------------------------------+ +-------------+-------+-------------+-------------------------------+
Table 22: 3GPP Attributes and Structures Table 21: 3GPP Attributes and Structures
The following COMMAND_SET values are supported for 3GPP. The following COMMAND_SET values are supported for 3GPP.
o assign-ip - Assign the IP Address for the mobile session. o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node. o assign-dpn - Assign the Dataplane Node.
o assign-fteid-ip - Assign the Fully Qualified TEID (F-TEID) LOCAL o assign-fteid-ip - Assign the Fully Qualified TEID (F-TEID) LOCAL
IP address. IP address.
skipping to change at page 60, line 27 skipping to change at page 58, line 21
o session - Assign values for the Session Level. When this involves o session - Assign values for the Session Level. When this involves
'assign-fteid-ip' and 'assign-fteid-teid' this implies the values 'assign-fteid-ip' and 'assign-fteid-teid' this implies the values
are part of the default bearer. are part of the default bearer.
o uplink - Command applies to uplink. o uplink - Command applies to uplink.
o downlink - Command applies to downlink. o downlink - Command applies to downlink.
8. Implementation Status 8. Implementation Status
Two FPC Agent implementations have been made to date. The first was Three FPC Agent implementations have been made to date. The first
based upon Version 03 of the draft and followed Model 1. The second was based upon Version 03 of the draft and followed Model 1. The
follows Version 04 of the document. Both implementations were second follows Version 04 of the document. Both implementations were
OpenDaylight plug-ins developed in Java by Sprint. Version 03 was OpenDaylight plug-ins developed in Java by Sprint. Version 03 was
known as fpcagent and version 04's implementation is simply referred known as fpcagent and version 04's implementation is simply referred
to as 'fpc'. to as 'fpc'. A third has been devloped on an ONOS Controller for use
in MCORD projects.
fpcagent's intent was to provide a proof of concept for FPC Version fpcagent's intent was to provide a proof of concept for FPC Version
03 Model 1 in January 2016 and research various errors, corrections 03 Model 1 in January 2016 and research various errors, corrections
and optimizations that the Agent could make when supporting multiple and optimizations that the Agent could make when supporting multiple
DPNs. DPNs.
As the code developed to support OpenFlow and a proprietary DPN from 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 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 obvious including the use of machine learning to reduce the number of
Flows and Policy entities placed on the DPN. This work has driven Flows and Policy entities placed on the DPN. This work has driven
skipping to change at page 61, line 8 skipping to change at page 58, line 51
A throughput performance of tens per second using various NetConf A throughput performance of tens per second using various NetConf
based solutions in OpenDaylight made fpcagent undesirable for call based solutions in OpenDaylight made fpcagent undesirable for call
processing. The RPC implementation improved throughput by an order processing. The RPC implementation improved throughput by an order
of magnitude but was not useful based upon FPC's Version 03 design of magnitude but was not useful based upon FPC's Version 03 design
using two information models. During this time the features of using two information models. During this time the features of
version 04 and its converged model became attractive and the fpcagent version 04 and its converged model became attractive and the fpcagent
project was closed in August 2016. fpcagent will no longer be project was closed in August 2016. fpcagent will no longer be
developed and will remain a proprietary implementation. developed and will remain a proprietary implementation.
The learnings of fpcagent has influenced the second project, fpc. The learnings of fpcagent has influenced the second project, fpc.
Fpc is also an OpenDaylight project but is being prepared for open Fpc is also an OpenDaylight project but is an open source release as
source release as the Opendaylight FpcAgent plugin the Opendaylight FpcAgent plugin (https://wiki.opendaylight.org/view/
(https://wiki.opendaylight.org/view/Project_Proposals:FpcAgent). Project_Proposals:FpcAgent). This project is scoped to be a fully
This project is scoped to be a fully compliant FPC Agent that compliant FPC Agent that supports multiple DPNs including those that
supports multiple DPNs including those that communicate via OpenFlow. communicate via OpenFlow. The following features present in this
The following features present in this draft and others developed by draft and others developed by the FPC development team have already
the FPC development team have already lead to an order of magnitude lead to an order of magnitude improvement.
improvement.
Migration of non-realtime provisioning of entities such as Migration of non-realtime provisioning of entities such as
topology and policy allowed the implementation to focus only on topology and policy allowed the implementation to focus only on
the rpc. the rpc.
Using only 5 messages and 2 notifications has also reduced Using only 5 messages and 2 notifications has also reduced
implementation time. implementation time.
Command Sets, an optional feature in this specification, have Command Sets, an optional feature in this specification, have
eliminated 80% of the time spent determining what needs to be eliminated 80% of the time spent determining what needs to be
skipping to change at page 61, line 44 skipping to change at page 59, line 37
Multi-tenant support allows for Cache searches to be partitioned Multi-tenant support allows for Cache searches to be partitioned
for clustering and performance improvements. This has not been for clustering and performance improvements. This has not been
capitalized upon by the current implementation but is part of the capitalized upon by the current implementation but is part of the
development roadmap. development roadmap.
Use of Contexts to pre-provision policy has also eliminated any Use of Contexts to pre-provision policy has also eliminated any
processing of Ports for DPNs which permitted the code for processing of Ports for DPNs which permitted the code for
CONFIGURE and CONF_BUNDLE to be implemented as a simple nested CONFIGURE and CONF_BUNDLE to be implemented as a simple nested
FOR loops (see below). FOR loops (see below).
Current performance results without code optimizations or tuning Initial v04 performance results without code optimizations or tuning
allow 2-5K FPC Contexts processed per second on a 2013 Mac laptop. allow 2-5K FPC Contexts processed per second on a 2013 Mac laptop.
This results in 2x the number of transactions on the southbound This results in 2x the number of transactions on the southbound
interface to a proprietary DPN API on the same machine. interface to a proprietary DPN API on the same machine.
Current v04 performance results without code optimizations or tuning
allow 1-2K FPC Contexts processed per second on a 2013 Mac laptop.
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: fpc currently supports the following:
1 proprietary DPN API 1 proprietary DPN API
Policy and Topology as defined in this Policy and Topology as defined in this
specification using OpenDaylight North Bound specification using OpenDaylight North Bound
Interfaces such as NetConf and RestConf Interfaces such as NetConf and RestConf
CONFIG and CONF_BUNDLE (all operations) CONFIG and CONF_BUNDLE (all operations)
DPN assignment, Tunnel allocations and IPv4 DPN assignment, Tunnel allocations and IPv4
skipping to change at page 63, line 46 skipping to change at page 61, line 46
for each Context for each Context
for each DPN / direction in Context for each DPN / direction in Context
perform actions on DPN according to Command Set perform actions on DPN according to Command Set
end for end for
end for end for
end for end for
commit changes to in memory cache commit changes to in memory cache
log transaction for tracking and notification log transaction for tracking and notification
(CONFIG_RESULT_NOTIFY) (CONFIG_RESULT_NOTIFY)
Figure 27: fpc pseudo code Figure 22: fpc pseudo code
For further information please contact Lyle Bertz who is also a co- For further information please contact Lyle Bertz who is also a co-
author of this document. author of this document.
NOTE: Tenant support requires binding a Client ID to a Tenant ID (it NOTE: Tenant support requires binding a Client ID to a Tenant ID (it
is a one to many relation) but that is outside of the scope of this is a one to many relation) but that is outside of the scope of this
specification. Otherwise, the specification is complete in terms of specification. Otherwise, the specification is complete in terms of
providing sufficient information to implement an Agent. providing sufficient information to implement an Agent.
9. Security Considerations 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.
The YANG modules defined in this memo is designed to be accessed via The YANG modules defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest
secure transport layer and the mandatory-to-implement secure NETCONF layer is the secure transport layer and the mandatory-to-
transport is SSH [RFC6242]. implement secure transport is SSH [RFC6242].
The information model defined in the memo is designed to be access by The information model defined in the memo is designed to be access by
protocols specified in extensions to this document or, if using the protocols specified in extensions to this document or, if using the
YANG modules, as described above. YANG modules, as described above.
There are a number of data nodes defined which are There are a number of data nodes defined which are
writable/creatable/deletable. These data nodes may be considered writable/creatable/deletable. These data nodes may be considered
sensitive or vulnerable in some network environments. Write sensitive or vulnerable in some network environments. Write
operations (e.g., a NETCONF edit-config) to these data nodes without operations (e.g., a NETCONF edit-config) to these data nodes without
proper protection can have a negative effect on network operations. proper protection can have a negative effect on network operations.
skipping to change at page 65, line 35 skipping to change at page 63, line 35
vulnerable information. vulnerable information.
Notications MUST be treated with same level of protection and Notications MUST be treated with same level of protection and
scrutiny as the operations they correspond to. For example, a scrutiny as the operations they correspond to. For example, a
CONFIG_RESULT_NOTIFY notification provides the same information CONFIG_RESULT_NOTIFY notification provides the same information
that is sent as part of the input and output of the CONFIG and that is sent as part of the input and output of the CONFIG and
CONF_BUNDLE RPC operations. CONF_BUNDLE RPC operations.
General usage of FPC MUST consider the following: General usage of FPC MUST consider the following:
FPC Naming Section 4.4 permits arbirtrary string values but a FPC Naming Section 4.8 permits arbirtrary string values but a
users MUST avoid placing sensitive or vulnerable information in users MUST avoid placing sensitive or vulnerable information in
those values. those values.
Policies that are very narrow and permit the identification of Policies that are very narrow and permit the identification of
specific traffic, e.g. that of a single user, SHOULD be avoided. specific traffic, e.g. that of a single user, SHOULD be avoided.
10. IANA Considerations 10. IANA Considerations
This document registers six URIs in the "IETF XML Registry" This document registers six URIs in the "IETF XML Registry"
[RFC3688]. Following the format in RFC 3688, the following [RFC3688]. Following the format in RFC 3688, the following
registrations have been made. registrations have been made.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp
Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos URI: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-traffic-selector-types URI: urn:ietf:params:xml:ns:yang:ietf-dmm-traffic-selector-types
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext
Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip
Registrant Contact: The DMM WG of the IETF. Registrant Contact: The DMM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]. Module Names" registry [RFC6020].
name: ietf-dmm-fpc name: ietf-dmm-fpc
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc
prefix: fpc prefix: fpc
reference: TBD1 reference: TBD1
name: ietf-dmm-threegpp
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp
prefix: threegpp
reference: TBD1
name: ietf-dmm-pmip-qos name: ietf-dmm-pmip-qos
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos
prefix: qos-pmip prefix: qos-pmip
reference: TBD1 reference: TBD2
name: ietf-dmm-traffic-selector-types name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang: namespace: urn:ietf:params:xml:ns:yang:
ietf-dmm-traffic-selector-types ietf-dmm-traffic-selector-types
prefix: traffic-selectors prefix: traffic-selectors
reference: TBD1 reference: TBD3
name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext
prefix: fpcpolicyext
reference: TBD1
name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip
prefix: fpc-pmip
reference: TBD1
The document registers the following YANG submodules in the "YANG
Module Names" registry [RFC6020].
name: ietf-dmm-fpc-base name: ietf-dmm-fpc-settingsext
parent: ietf-dmm-fpc namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext
reference: TBD1 prefix: fpcbase
reference: TBD4
11. 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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017. segment-routing-header-07 (work in progress), July 2017.
skipping to change at page 67, line 37 skipping to change at page 65, line 16
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017. segment-routing-header-07 (work in progress), July 2017.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-20 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress),
September 2017. October 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10 data plane", draft-ietf-spring-segment-routing-mpls-10
(work in progress), June 2017. (work in progress), June 2017.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://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, <https://www.rfc- DOI 10.17487/RFC6088, January 2011,
editor.org/info/rfc6088>. <https://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, <https://www.rfc-
editor.org/info/rfc6089>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [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,
<https://www.rfc-editor.org/info/rfc7333>. <https://www.rfc-editor.org/info/rfc7333>.
skipping to change at page 68, line 43 skipping to change at page 66, line 16
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-02 (work in progress), August 2017. models-02 (work in progress), August 2017.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016. progress), October 2016.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>. <https://www.rfc-editor.org/info/rfc5213>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
Gundavelli, "Quality-of-Service Option for Proxy Mobile Gundavelli, "Quality-of-Service Option for Proxy Mobile
IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014,
<https://www.rfc-editor.org/info/rfc7222>. <https://www.rfc-editor.org/info/rfc7222>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
Appendix A. YANG Data Model for the FPC protocol Appendix A. YANG Data Model for the FPC protocol
These modules define YANG definitions. Seven modules are defined: These modules define YANG definitions. When mapping from the FPC
model was performed U-Key values, ACTION_TYPES and DESCRIPTOR_TYPES
as well as many enumerations were mapped to identity types.
ACTION_TYPES and DESCRIPTOR_TYPES are also optional as the type can
be inferred from the value. Four modules are defined:
o ietf-dmm-fpc (fpc) - Defines the base model and messages for FPC o ietf-dmm-fpc (fpc) - Defines the base model and messages for FPC
that are meant to be static in FPC.
o ietf-dmm-fpc-base An FPC submodule that defines the information o ietf-dmm-fpc-settingsext An FPC module that defines the
model that is specified in this document information model elements that are likely to be extended in FPC.
o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS
parameters per RFC 7222 parameters per RFC 7222
o ietf-traffic-selectors-types (traffic-selectors) - Defines Traffic o ietf-trafficselectors-types (traffic-selectors) - Defines Traffic
Selectors per RFC 6088 Selectors per RFC 6088
o ietf-dmm-threegpp - Defines the base structures for 3GPP based IP A.1. FPC YANG Model
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
parameters, where applicable, as properties.
o ietf-dmm-fpc-policyext - defines basic policy extensions, e.g.
Actions and Descriptors, to fpcbase and as defined in this
document.
A.1. FPC Agent YANG Model
This module defines the information model and protocol elements This module defines the information model and protocol elements
specified in this document. specified in this document.
This module references [RFC6991] and the fpc-base module defined in This module references [RFC6991], [RFC8040] and the fpc-settingsext
this document. module defined in this document.
<CODE BEGINS> file "ietf-dmm-fpc@2017-03-08.yang" <CODE BEGINS> file "ietf-dmm-fpc@2017-09-27.yang"
module ietf-dmm-fpc { module ietf-dmm-fpc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc"; namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc";
prefix fpc; prefix fpc;
import ietf-inet-types { prefix inet; revision-date 2013-07-15; } import ietf-inet-types { prefix inet;
revision-date 2013-07-15; }
include ietf-dmm-fpc-base; import ietf-restconf { prefix restconf;
revision-date 2017-01-26; }
import ietf-dmm-fpc-settingsext { prefix fpcbase;
revision-date 2017-09-27;
}
organization "IETF Distributed Mobility Management (DMM) organization "IETF Distributed Mobility Management (DMM)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Dapeng Liu WG Chair: Dapeng Liu
<mailto:maxpassion@gmail.com> <mailto:maxpassion@gmail.com>
skipping to change at page 70, line 50 skipping to change at page 68, line 23
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License."; without warranty as described in the Simplified BSD License.";
revision 2017-03-08 { revision 2017-09-27 {
description "Version 06 updates."; description "Version 10 updates.";
reference "draft-ietf-dmm-fpc-cpdp-06"; reference "draft-ietf-dmm-fpc-cpdp-10";
}
} revision 2017-07-22 {
description "Version 08 updates.";
revision 2016-08-03 { reference "draft-ietf-dmm-fpc-cpdp-08";
description "Initial Revision."; }
reference "draft-ietf-dmm-fpc-cpdp-05"; revision 2017-03-08 {
} description "Version 06 updates.";
feature fpc-cloning { reference "draft-ietf-dmm-fpc-cpdp-06";
description "An ability to support cloning in the RPC."; }
} revision 2016-08-03 {
description "Initial Revision.";
reference "draft-ietf-dmm-fpc-cpdp-05";
}
feature fpc-basename-registry { feature fpc-basename-registry {
description "Ability to track Base Names already provisioned description "Ability to track Base Names already provisioned
on the Agent"; on the Agent";
} }
feature fpc-bundles { feature fpc-bundles {
description "Ability for Client to send multiple bundles of description "Ability for Client to send multiple bundles of
actions to an Agent"; 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 { feature fpc-auto-binding {
description "Allows a FPC Agent to advertise Topology Objects description "Allows a FPC Agent to advertise Topology Objects
that could be DPNs"; that could be DPNs";
} }
feature instruction-bitset {
description "Allows the expression of instructions (bit sets)
over FPC.";
}
feature operation-ref-scope { feature operation-ref-scope {
description "Provides the scope of refeneces in an operation. description "Provides the scope of refeneces in an operation.
Used to optmize the Agent processing."; Used to optmize the Agent processing.";
} }
feature policy-rpc-provisioning {
description "Enables the ability to send policy elements
(Policy Groups, Policies, Descriptors and Actions) to be sent
in CONF or CONF_BUNDLE operations.";
}
typedef agent-identifier { //General Structures
type fpc:fpc-identity; typedef fpc-identity {
description "Agent Identifier"; type union {
type uint32;
type string;
type instance-identifier;
}
description "FPC Identity";
} }
grouping target-value {
typedef client-identifier { leaf target {
type fpc-identity;
mandatory true;
description "Target Identity";
}
description "FPC Target Value";
}
// Topology
typedef fpc-interface-id {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Client Identifier"; description "DPN interface Identifier";
}
identity interface-protocols {
description "Protocol supported by the interface";
} }
grouping basename-info { identity features {
leaf basename { description "Protocol features";
if-feature fpc:fpc-basename-registry;
type fpc:fpc-identity;
description "Rules Basename";
}
leaf base-state {
if-feature fpc:fpc-basename-registry;
type string;
description "Current State";
}
leaf base-checkpoint {
if-feature fpc:fpc-basename-registry;
type string;
description "Checkpoint";
}
description "Basename Information";
} }
// Settings
// Top Level Structures grouping settings {
container tenants { container settings-set {
list tenant { uses fpcbase:fpc-settings;
key "tenant-id"; description "Settings";
leaf tenant-id {
type fpc:fpc-identity;
description "Tenant ID";
}
container fpc-policy {
list policy-groups {
key "policy-group-id";
uses fpc:fpc-policy-group;
description "Policy Groups";
}
list policies {
key "policy-id";
uses fpc:fpc-policy;
description "Policies";
}
list descriptors {
key descriptor-id;
uses fpc:fpc-descriptor;
description "Descriptors";
}
list actions {
key action-id;
uses fpc:fpc-action;
description "Actions";
}
description "Policy";
}
container fpc-mobility {
config false;
list contexts {
key context-id;
uses fpc:fpc-context;
description "Contexts";
}
list vports {
key vport-id;
uses fpc:fpc-vport;
description "Ports";
}
list monitors {
uses fpc:monitor-config;
description "Monitors";
}
description "Mobility";
}
container fpc-topology {
// Basic Agent Topology Structures
list domains {
key domain-id;
uses fpc:fpc-domain;
uses fpc:basename-info;
description "Domains";
}
leaf dpn-id {
if-feature fpc:fpc-basic-agent;
type fpc:fpc-dpn-id;
description "DPN ID";
}
leaf-list control-protocols {
if-feature fpc:fpc-basic-agent;
type identityref {
base "fpc:fpc-dpn-control-protocol";
}
description "Control Protocols";
}
list dpn-groups {
if-feature fpc:fpc-multi-dpn;
key dpn-group-id;
uses fpc:fpc-dpn-group;
list domains {
key domain-id;
uses fpc:fpc-domain;
uses fpc:basename-info;
description "Domains";
}
description "DPN Groups";
}
list dpns {
if-feature fpc:fpc-multi-dpn;
key dpn-id;
uses fpc:fpc-dpn;
description "DPNs";
}
description "Topology";
}
description "Tenant";
}
description "Tenant List";
} }
description "Settings container";
container fpc-agent-info { }
// General Agent Structures //Topology - Groupings
leaf-list supported-features { grouping interface-settings {
container interface-settings-set {
description "Interface settings";
}
description "Generic interface settings container";
}
grouping access-technology-key {
leaf access-technology {
type identityref {
base "fpcbase:access-technology";
}
mandatory true;
description "Access Technology";
}
description "Access Technology key";
}
grouping role-key {
leaf role {
type identityref {
base "fpcbase:role";
}
mandatory true;
description "Access Technology Role";
}
description "Access Technology Role key";
}
grouping interface-id-key {
leaf interface-id {
type fpc:fpc-interface-id;
mandatory true;
description "interface identifier";
}
description "Interface Identifier key";
}
grouping dpn-identifier-key {
leaf dpn-id {
type fpc:fpc-identity;
mandatory true;
description "DPN Identifier Type";
}
description "DPN Identifier key";
}
grouping dpn-interface-reference {
uses fpc:access-technology-key;
uses fpc:role-key;
uses fpc:interface-id-key;
description "A reference to a DPN interface";
}
// Topology Grouping
grouping fpc-topology {
list dpn-set {
key dpn-id;
uses fpc:dpn-identifier-key;
leaf dpn-name {
type string; type string;
description "Agent Features"; description "DPN name";
} }
leaf dpn-resource-mapping-reference {
// Common Agent Info type string;
list supported-events { description "Reference to underlying DPN resource(s)";
key event; }
leaf event { list interface-set {
key "access-technology role interface-id";
uses fpc:dpn-interface-reference;
uses fpc:interface-settings;
description "DPN interfaces";
}
description "Set of DPNs";
}
list dpn-type-set {
key "access-technology role";
uses fpc:access-technology-key;
leaf access-technology-name {
type string;
description "Access Technology Name";
}
uses fpc:role-key;
leaf role-name {
type string;
description "Access Technology Role Name";
}
list interface-set {
key interface-id;
uses fpc:interface-id-key;
leaf interface-name {
type string;
description "DPN-Type Interface Name";
}
leaf-list interface-protocol-set {
type identityref { type identityref {
base "fpc:event-type"; base "interface-protocols";
} }
description "Event Types"; description "Supported protocols";
}
leaf event-id {
type fpc:event-type-id;
description "Event ID";
} }
description "Supported Events"; leaf-list feature-set {
}
list supported-error-types {
key error-type;
leaf error-type {
type identityref { type identityref {
base "fpc:error-type"; base "interface-protocols";
} }
description "Error Type"; description "Supported features";
} }
leaf error-type-id { uses fpc:interface-settings;
type fpc:error-type-id; description "A DPN interface types";
description "Error Type ID"; }
description "Set of DPN types";
}
list dpn-group-set {
key "dpn-group-id";
leaf dpn-group-id {
type fpc:fpc-identity;
mandatory true;
description "DPN Group Identifier";
}
list referenced-dpns-set {
key "access-technology role interface-id";
uses fpc:dpn-interface-reference;
leaf-list supporting-dpn-id-set {
type fpc:fpc-identity;
description "DPNs that suppport this group";
} }
description "Supported Error Types"; leaf-list dpn-group-peer-id-set {
type fpc:fpc-identity;
description "DPN Peer Groups reference";
}
description "A list of DPNs supporting a group
by DPN Type";
} }
description "General Agent Information"; list dpn-group-peer-set {
key remote-dpn-group-id;
leaf remote-dpn-group-id {
type fpc:fpc-identity;
mandatory true;
description "Remote DPN Group identifier";
}
uses fpc:interface-settings;
description "Locally applied settings used for
the referenced DPN-Group (peer group).";
}
leaf domain-id {
type fpc:fpc-identity;
description "Domain Identiifer";
}
description "List of DPN groups";
} }
list domain-set {
// Multi-DPN Agent Structures key domain-id;
grouping fpc-dpn-group { leaf domain-id {
leaf dpn-group-id { type fpc:fpc-identity;
type fpc:fpc-dpn-group-id; mandatory true;
description "DPN Group ID"; description "Domain Identifier";
}
leaf domain-name {
type string;
description "Domain displayname";
}
leaf domain-reference {
type string;
description "Reference to domain resources";
}
description "List of Domains";
}
description "FPC Topology grouping";
}
// Policy Structures
// Descriptor Structure
identity fpc-descriptor-type {
description "A traffic descriptor";
}
grouping descriptor-definition {
leaf descriptor-id {
type fpc:fpc-identity;
mandatory true;
description "Descriptor Id";
} }
leaf data-plane-role { leaf descriptor-type {
type identityref { type identityref {
base "fpc:fpc-data-plane-role"; base "fpc-descriptor-type";
} }
description "Dataplane Role"; description "Descriptor Type Value";
} }
leaf access-type { uses fpcbase:fpc-descriptor-value;
type identityref { description "FPC Descriptor Definition";
base "fpc:fpc-access-type"; }
} // Action Structure
description "Access Type"; identity fpc-action-type {
description "Action Type";
}
grouping action-definition {
leaf action-id {
type fpc:fpc-identity;
description "Action Identifier";
} }
leaf mobility-profile { leaf action-type {
type identityref { type identityref {
base "fpc:fpc-mobility-profile-type"; base "fpc-action-type";
} }
description "Mobility Profile"; description "Action Type";
} }
list dpn-group-peers { uses fpcbase:fpc-action-value;
key "remote-dpn-group-id"; description "FPC Action Definition";
uses fpc:fpc-dpn-peer-group;
description "Peer DPN Groups"; }
// Rule Structure
typedef fpc-direction-type {
type enumeration {
enum uplink {
description "uplink";
}
enum downlink {
description "Downlink";
}
enum both {
description "Both";
} }
description "FPC DPN Group"; }
description "FPC Direction";
} }
grouping fpc-rule-id {
// RPC leaf rule-id {
// RPC Specific Structures type fpc:fpc-identity;
//Input Structures mandatory true;
typedef admin-status { description "Rule Identifier";
type enumeration { }
enum enabled { description "FPC Rule-Id key";
}
grouping match-type {
leaf descriptor-match-type {
type enumeration {
enum or {
value 0; value 0;
description "enabled"; description "OR logic";
} }
enum disabled { enum and {
value 1; value 1;
description "disabled"; description "AND logic";
}
enum virtual {
value 2;
description "virtual";
} }
}
mandatory true;
description "Type of Match (OR or AND) applied to the
descriptor-reference-set.";
}
description "Map Type Grouping";
}
grouping fpc-action-order {
leaf action-order {
type uint32;
mandatory true;
description "Action Execution Order";
} }
description "Adminstrative Status"; description "Action Order Leaf";
} }
grouping rule-definition {
typedef session-status { uses fpc:fpc-rule-id;
type enumeration { uses fpc:match-type;
enum complete { list descriptor-reference-set {
value 0; key "descriptor-id-reference";
description "complete"; leaf descriptor-id-reference {
} type fpc:fpc-identity;
enum incomplete { mandatory true;
value 1; description "Descriptor Id Reference";
description "incomplete"; }
} leaf direction {
enum outdated { type fpc:fpc-direction-type;
value 2; description "Direction";
description "outdated"; }
} description "A set of Descriptor references";
} }
description "Session Status"; list action-reference-set {
key "action-order";
uses fpc:fpc-action-order;
leaf action-id-reference {
type fpc:fpc-identity;
mandatory true;
description "Action Identifier Reference";
}
description "A set of Action references";
}
description
"Rule.Definition";
} }
// Policy Structures
typedef op-delay { grouping fpc-precedence {
type uint32; leaf precedence {
description "Operation Delay (ms)"; type uint32;
mandatory true;
description "Rule Precedence";
} }
description "FPC Rule Precedence";
typedef op-identifier {
type uint64;
description "Operation Identifier";
} }
typedef ref-scope { grouping policy {
type enumeration { leaf policy-id {
enum none { type fpc:fpc-identity;
value 0; description "Policy Identifier";
description "no references";
} }
enum op { list rule-set {
value 1; key "precedence";
description "op - All references are contained in the unique "rule-id-reference";
operation body (intra-op)"; uses fpc:fpc-precedence;
leaf rule-id-reference {
type fpc:fpc-identity;
mandatory true;
description "Rule Identifier";
}
description "Rule Entry";
} }
enum bundle { description "FPC Policy";
value 2; }
description "bundle - All references in exist in bundle // FPC Policy
(inter-operation/intra-bundle). grouping fpc-policy {
NOTE - If this value comes in CONFIG call it is list action-definition-set {
equivalent to 'op'."; key action-id;
uses fpc:action-definition;
description "List of Actions";
}
list descriptor-definition-set {
key descriptor-id;
uses fpc:descriptor-definition;
description "List of Descriptors";
}
list rule-definition-set {
key rule-id;
uses fpc:rule-definition;
description "List of Rules";
}
list policy-definition-set {
key policy-id;
uses fpc:policy;
description "List of Policies";
}
description "FPC Policy Structures";
}
// Mobility Structures
grouping configurable-policy-set {
list installed-policy-list {
key dpn-id-reference;
leaf dpn-id-reference {
type fpc:fpc-identity;
description "Installed Policy identifier";
}
list installed-policy-set {
key installed-policy-id;
leaf installed-policy-id {
type fpc:fpc-identity;
description "Installed Policy Identifier";
} }
enum storage { leaf policy-id-reference {
value 3; type fpc:fpc-identity;
description "storage - One or more references exist outside description "Installed Policy Identifier";
of the operation and bundle. A lookup to a cache /
storage is required.";
} }
enum unknown { container policy-settings {
value 4; uses fpcbase:fpc-settings;
description " unknown - the location of the references are description "Policy Settings";
unknown. This is treated as a 'storage' type.";
} }
description "Policy installed upon a DPN";
} }
description "Search scope for references in the operation."; description "Configurable Policy";
uses fpc:settings;
} }
description "List of installed DPN policies and settings";
grouping instructions { }
container instructions { // Dynamic Policy
if-feature instruction-bitset; grouping mobility-context {
choice instr-type { leaf mobility-context-id {
description "Instruction Value Choice"; type fpc:fpc-identity;
} mandatory true;
description "Instructions"; description "Mobility Context Identifier";
}
description "Instructions Value";
} }
leaf dpn-group-id-reference {
grouping op-header { type fpc:fpc-identity;
leaf client-id { description "Group ID used when DPN selecitons were
type fpc:client-identifier; made";
description "Client ID"; }
leaf parent-mobility-context-id-reference {
type fpc:fpc-identity;
description "Parent Mobility Context";
}
list dpn-reference-list {
key "dpn-id-reference direction";
leaf dpn-id-reference {
type fpc:fpc-identity;
mandatory true;
description "DPN Id reference";
} }
leaf delay { leaf direction {
type op-delay; type fpc:fpc-direction-type;
description "Delay"; mandatory true;
description "Direction of DPN assignment";
} }
leaf session-state { container dpn-settings-complementary {
type session-status; uses fpcbase:fpc-settings;
description "Session State"; description "Complentary Settings";
} }
leaf admin-state { leaf interface-id-reference {
type admin-status; type fpc:fpc-interface-id;
description "Admin State"; mandatory true;
description "referenced interface";
} }
leaf op-type { list embedded-rule-set {
type enumeration { key "precedence";
enum create { unique "rule-id";
value 0; uses fpc:fpc-rule-id;
description "create"; uses fpc:match-type;
} uses fpc:fpc-precedence;
enum update { list action-definition-set {
value 1; key "action-order";
description "update"; uses fpc:fpc-action-order;
} uses fpc:action-definition;
enum query { description "List of Actions";
value 2;
description "query";
}
enum delete {
value 3;
description "delete";
}
} }
description "Type"; list descriptor-definition-set {
} key descriptor-id;
leaf op-ref-scope { uses fpc:descriptor-definition;
if-feature operation-ref-scope; description "List of Descriptors";
type fpc:ref-scope; }
description "Reference Scope"; description "List of FPC Embedded Rule Definitions";
}
uses fpc:instructions;
description "Operation Header";
}
grouping clone-ref {
leaf entity {
type fpc:fpc-identity;
description "Clone ID";
} }
leaf source { leaf-list assigned-policy-reference-set {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Source"; description "List of Policies request to be enforced for
this Mobility Context";
} }
description "Clone Reference"; description "DPN List";
} }
identity command-set { leaf-list requested-policy-reference-set {
description "protocol specific commands"; type fpc:fpc-identity;
description "List of Policies request to be enforced for
this Mobility Context";
} }
container context-settings-complementary {
grouping context-operation { uses fpcbase:fpc-settings;
uses fpc:fpc-context; description "Context Settings";
uses fpc:instructions;
description "Context Operation";
} }
description "Mobility Context";
// Output Structure }
grouping payload { // Events, Probes & Notifications
list ports { identity event-type {
uses fpc:fpc-vport; description "Base Event Type";
description "Ports"; }
} typedef event-type-id {
list contexts { type uint32;
uses fpc:context-operation; description "Event ID Type";
description "Contexts"; }
grouping monitor-id {
leaf monitor-id {
type fpc:fpc-identity;
mandatory true;
description "Monitor Identifier";
}
description "Monitor Id";
}
grouping monitor-config {
uses fpc:monitor-id;
leaf deterrable {
type boolean;
description "Indicates reports related to this
config can be delayed.";
}
container binding-information {
description "Placeholder for information helpful
to binding the monitor ot the correct target";
}
uses fpc:target-value;
choice configuration {
mandatory true;
case periodic-config {
leaf period {
type uint32;
description "Period";
}
description "Periodic Config Case";
} }
list policy-groups { case threshold-config {
if-feature fpc:policy-rpc-provisioning; leaf lo-thresh {
key "policy-group-id"; type uint32;
uses fpc:fpc-policy-group; description "lo threshold";
description "Policy Groups"; }
leaf hi-thresh {
type uint32;
description "hi threshold";
}
description "Threshold Config Case";
} }
list policies { case scheduled-config {
if-feature fpc:policy-rpc-provisioning; leaf report-time {
key "policy-id"; type uint32;
uses fpc:fpc-policy; description "Reporting Time";
description "Policies"; }
description "Scheduled Config Case";
} }
list descriptors { case events-config-ident {
if-feature fpc:policy-rpc-provisioning; leaf-list event-identities {
key descriptor-id; type identityref {
uses fpc:fpc-descriptor; base "fpc:event-type";
description "Descriptors"; }
description "Event Identities";
}
description "Events Config Identities Case";
} }
list actions { case events-config {
if-feature fpc:policy-rpc-provisioning; leaf-list event-ids {
key action-id; type uint32;
uses fpc:fpc-action; description "Event IDs";
description "Actions"; }
description "Events Config Case";
} }
description "Payload"; description "Event Config Value";
} }
description "Monitor Configuration";
grouping op-input { }
uses fpc:op-header; grouping report {
leaf op-id { uses fpc:monitor-config;
type op-identifier; choice report-value {
description "Operation ID"; leaf trigger {
} type fpc:event-type-id;
choice op_body { description "Trigger Identifier";
case create_or_update { }
list clones { case simple-empty {
if-feature fpc-cloning; leaf nothing {
key entity; type empty;
uses fpc:clone-ref; description "Empty Value";
description "Clones";
} }
uses fpc:payload; description "Empty Case";
description "Create/Update input";
} }
case delete_or_query { case simple-val32 {
uses fpc:targets-value; leaf val32 {
description "Delete/Query input"; type uint32;
description "Unsigned 32 bit value";
}
description "Simple Value Case";
} }
description "Opeartion Input value"; case list-simple-val32 {
leaf-list val32-list {
type uint32;
description "Unsigned 32 bit value";
}
description "Simple Value Case";
}
description "Report Value";
} }
description "Operation Input"; description "Monitor Report";
}
typedef agent-identifier {
type fpc:fpc-identity;
description "Agent Identifier";
}
typedef client-identifier {
type fpc:fpc-identity;
description "Client Identifier";
}
grouping basename-info {
leaf basename {
type fpc:fpc-identity;
description "Rules Basename";
}
leaf base-state {
type string;
description "Current State";
}
leaf base-checkpoint {
type string;
description "Checkpoint";
}
description "Basename Information";
} }
// Top Level Structures
container tenants {
list tenant {
key "tenant-id";
leaf tenant-id {
type fpc:fpc-identity;
description "Tenant ID";
}
container mobility {
container topology {
uses fpc:fpc-topology;
uses fpc:basename-info {
if-feature fpc:fpc-basename-registry;
}
description "Topology";
}
container policy {
uses fpc:fpc-policy;
uses fpc:basename-info {
if-feature fpc:fpc-basename-registry;
typedef result { }
description "Policy";
}
uses fpc:configurable-policy-set;
list mobility-context-set {
key "mobility-context-id";
config false;
uses fpc:mobility-context;
description "Mobility Context Set";
}
list monitor-set {
key monitor-id;
uses fpc:monitor-config;
description "Monitor Configurations";
}
description "Mobility Elements";
}
description "Tenant";
}
description "Tenant List";
}
// RPC
// RPC Specific Structures
typedef op-identifier {
type uint64;
description "Operation Identifier";
}
typedef ref-scope {
type enumeration { type enumeration {
enum ok { enum none {
value 0; value 0;
description "OK"; description "no references";
} }
enum err { enum op {
value 1; value 1;
description "Error"; description "All references are intra-operation";
} }
enum ok-notify-follows { enum bundle {
value 2; value 2;
description "OK with NOTIFY following"; description "All references in exist in bundle";
} }
} enum storage {
description "Result Status"; value 3;
description "One or more references exist in storage.";
}
enum unknown {
value 4;
description "The location of the references are unknown.";
}
}
description "Search scope for references in the operation.";
} }
grouping context-operation {
identity error-type { uses fpc:mobility-context;
description "Base Error Type"; uses fpcbase:instructions;
description "Context Operation";
} }
identity name-already-exists { grouping payload {
description "Notification that an entity of the same name uses fpc:configurable-policy-set;
already exists"; list mobility-context-set {
key "mobility-context-id";
uses fpc:mobility-context;
description "Mobility Context Set";
} }
uses fpc:fpc-policy;
typedef error-type-id { description "Payload";
}
grouping op-header {
leaf client-id {
type fpc:client-identifier;
mandatory true;
description "Client ID";
}
leaf delay {
type uint32; type uint32;
description "Integer form of the Error Type"; description "Operation Delay (ms)";
} }
leaf op-id {
grouping op-status-value { type op-identifier;
leaf op-status { mandatory true;
type enumeration { description "Operation Identifier";
enum ok {
value 0;
description "OK";
}
enum err {
value 1;
description "Error";
}
}
description "Operation Status";
}
description "Operation Status Value";
} }
description "Common Operation header";
grouping error-info {
leaf error-type-id {
type fpc:error-type-id;
description "Error ID";
}
leaf error-info {
type string {
length "1..1024";
}
description "Error Detail";
}
description "Error Information";
} }
grouping fpc-op-type {
grouping result-body { leaf op-type {
leaf op-id { type enumeration {
type op-identifier; enum create {
description "Operation Identifier"; value 0;
} description "create";
choice result-type {
case err {
uses fpc:error-info;
description "Error Information";
} }
case create-or-update-success { enum update {
uses fpc:payload; value 1;
description "Create/Update Success"; description "update";
} }
case delete_or_query-success { enum query {
uses fpc:targets-value; value 2;
description "Delete/Query Success"; description "query";
} }
case empty-case { enum delete {
description "Empty Case"; value 3;
description "delete";
} }
description "Result Value";
} }
description "Result Body"; mandatory true;
description "Type";
} }
description "FPC Operation Type";
// Common RPCs }
rpc configure { grouping fpc-op-ref-scope {
description "CONF message"; leaf op-ref-scope {
input { if-feature operation-ref-scope;
uses fpc:op-input; type fpc:ref-scope;
description "Reference Scope";
}
description "FPC OP-REF Scope";
}
grouping op-input {
uses fpc:fpc-op-ref-scope;
uses fpcbase:instructions;
choice op_body {
case create_or_update {
uses fpc:payload;
description "Create/Update input";
} }
output { case delete_or_query {
leaf result { uses fpc:target-value;
type result; description "Delete/Query input";
description "Result";
}
uses fpc:result-body;
} }
description "Opeartion Input value";
} }
description "Operation Input";
rpc configure-bundles { }
if-feature fpc:fpc-bundles; typedef result-status {
description "CONF_BUNDLES message"; type enumeration {
input { enum ok {
leaf highest-op-ref-scope { value 0;
if-feature operation-ref-scope; description "OK";
type fpc:ref-scope;
description "Highest Op-Ref used in the input";
}
list bundles {
key op-id;
uses fpc:op-input;
description "List of operations";
}
} }
output { enum err {
list bundles { value 1;
key op-id; description "Error";
uses fpc:result-body; }
}
description "Result Status";
}
grouping status-value {
leaf op-id {
type op-identifier;
mandatory true;
description "Operation Identifier";
}
leaf status {
type result-status;
mandatory true;
description "Status";
}
description "Status value for all messages";
}
grouping result {
uses fpc:status-value;
uses fpc:result-body;
description "General Result grouping";
}
grouping result-body {
leaf notify-follows {
type boolean;
description "Indicates that a notification will
follow regarding this result";
}
choice result-type {
case err {
uses restconf:errors;
description "Error Information";
}
case create-or-update-success {
uses fpc:payload;
description "Create/Update Success";
}
case delete_or_query-success {
uses fpc:target-value;
description "Delete/Query Success";
}
case empty-case {
description "Empty Case";
}
description "Result Value";
}
description "Common Result member body";
}
// Common RPCs
rpc configure {
description "CONF message";
input {
uses fpc:op-header;
uses fpc:fpc-op-type;
uses fpc:op-input;
}
output {
uses fpc:result;
}
}
rpc configure-bundles {
if-feature fpc:fpc-bundles;
description "CONF_BUNDLES message";
input {
uses fpc:op-header;
uses fpc:fpc-op-type;
uses fpc:fpc-op-ref-scope;
list bundles {
key op-id;
leaf op-id {
type op-identifier;
mandatory true;
description "Operation Identifier"; description "Operation Identifier";
} }
uses fpc:op-input;
description "List of operations";
} }
} }
output {
// Notification Messages & Structures uses fpc:status-value;
typedef notification-id { list bundles {
type uint32; key op-id;
description "Notification Identifier"; uses fpc:result;
description "Operation Identifier";
}
} }
}
grouping notification-header { rpc reg_monitor {
leaf notification-id { description "Used to register monitoring of parameters/events";
type fpc:notification-id; input {
description "Notification ID"; uses fpc:op-header;
uses fpc:monitor-config;
}
output {
uses fpc:status-value;
uses restconf:errors;
}
}
rpc dereg_monitor {
description "Used to de-register monitoring of
parameters/events";
input {
uses fpc:op-header;
leaf-list monitor-set {
type fpc:fpc-identity;
min-elements 1;
description "Monitor Identifier";
} }
leaf timestamp { leaf send_data {
type uint32; type boolean;
description "timestamp"; description "Indicates if NOTIFY with final data
is desired upon deregistration";
} }
description "Notification Header";
} }
output {
notification config-result-notification { uses fpc:status-value;
uses fpc:notification-header; uses restconf:errors;
choice value { }
case config-result { }
uses fpc:op-status-value; rpc probe {
uses fpc:result-body; description "Probe the status of a registered monitor";
description "CONF Result"; input {
} uses fpc:op-header;
case config-bundle-result { uses fpc:monitor-id;
list bundles { }
uses fpc:op-status-value; output {
uses fpc:result-body; uses fpc:status-value;
description "Operation Results"; uses restconf:errors;
} }
description "CONF_BUNDLES Result"; }
// Notification Messages & Structures
grouping notification-header {
leaf notification-id {
type uint32;
description "Notification Identifier";
}
leaf timestamp {
type uint32;
description "timestamp";
}
description "Notification Header";
}
notification config-result-notification {
uses fpc:notification-header;
uses fpc:status-value;
choice value {
case config-result {
uses result-body;
description "CONF Result";
}
case config-bundle-result {
list bundles {
key op-id;
uses fpc:result;
description "Operation Identifier";
} }
description "Config Result value"; description "CONF_BUNDLES Result";
} }
description "CONF/CONF_BUNDLES Async Result"; description "Config Result value";
} }
description "CONF/CONF_BUNDLES Async Result";
rpc event_register { }
description "Used to register monitoring of parameters/events"; identity notification-cause {
input { description "Notification Cause";
uses fpc:monitor-config; }
} identity dpn-availabilty-change {
output { base "notification-cause";
leaf monitor-result { description "DPN Candidate/Exisitng DPN Availablity Change";
type fpc:result; }
description "Result"; identity monitoring-suspension {
} base "notification-cause";
uses fpc:error-info; description "Indicates monitoring suspension";
} }
identity monitoring-resumption {
base "notification-cause";
description "Indicates that monitoring has resumed";
}
identity monitor-notification {
base "notification-cause";
description "Indicates 1+ monitor reports";
}
notification notify {
uses fpc:notification-header;
leaf cause {
type identityref {
base "notification-cause";
}
description "Notification Cause";
} }
choice value {
rpc event_deregister { case dpn-candidate-available {
description "Used to de-register monitoring of if-feature fpc:fpc-auto-binding;
parameters/events"; leaf node-id {
input { type inet:uri;
list monitors { description "Topology URI";
uses fpc:monitor-id;
description "Monitor ID";
}
}
output {
leaf monitor-result {
type fpc:result;
description "Result";
}
uses fpc:error-info;
} }
list supported-interface-list {
} key "access-technology role";
uses fpc:access-technology-key;
rpc probe { uses fpc:role-key;
description "Probe the status of a registered monitor"; description "Support Intefaces";
input {
uses fpc:targets-value;
} }
output { description "DPN Candidate Information";
leaf monitor-result { }
type fpc:result; case dpn-unavailable {
description "Result"; leaf dpn-id {
type fpc:fpc-identity;
} description "DPN Identifier";
uses fpc:error-info;
} }
} description "DPN Unavailable";
}
notification notify { case monitor-notification {
uses fpc:notification-header; list reports {
choice value { uses fpc:report;
case dpn-candidate-available { description "Reports";
if-feature fpc:fpc-auto-binding;
leaf node-id {
type inet:uri;
description "Topology URI";
}
leaf-list access-types {
type identityref {
base "fpc:fpc-access-type";
}
description "Access Types";
}
leaf-list mobility-profiles {
type identityref {
base "fpc:fpc-mobility-profile-type";
}
description "Mobility Profiles";
}
leaf-list forwarding-plane-roles {
type identityref {
base "fpc:fpc-data-plane-role";
}
description "Forwarding Plane Role";
}
description "DPN Candidate Availability";
}
case monitor-notification {
choice monitor-notification-value {
case monitoring-suspension {
leaf monitoring-suspended {
type empty;
description "Indicates that monitoring has
uspended";
}
leaf suspension-note {
type string;
description "Indicates the monitoring
suspension reason";
}
}
case monitoring-resumption {
leaf monitoring-resumed {
type empty;
description "Indicates that monitoring
has resumed";
}
}
case simple-monitor {
uses fpc:report;
description "Report";
}
case bulk-monitors {
list reports {
uses fpc:report;
description "Reports";
}
description "Bulk Monitor Response";
}
description "Monitor Notification value";
}
description "Monitor Notification";
}
description "Notify Value";
} }
description "Notify Message"; description "Monitor Notification";
}
description "Notify Value";
} }
description "Notify Message";
}
} }
<CODE ENDS> <CODE ENDS>
A.2. YANG Models A.2. YANG Models
A.2.1. FPC YANG Model A.2.1. FPC YANG Settings and Extensions Model
This module defines the base data elements specified in this This module defines the base data elements in FPC that are likely to
document. be extended.
This module references [RFC6991]. This module references [RFC6991], ietf-trafficselector-types and
ietf-pmip-qos modules.
<CODE BEGINS> file "ietf-dmm-fpc-base@2017-03-08.yang" <CODE BEGINS> file "ietf-dmm-fpc-settingsext@2017-09-27.yang"
submodule ietf-dmm-fpc-base { module ietf-dmm-fpc-settingsext {
belongs-to ietf-dmm-fpc { yang-version 1.1;
prefix fpc; namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-settingsext";
} prefix fpcbase;
import ietf-inet-types { prefix inet; revision-date 2013-07-15; } import ietf-inet-types { prefix inet;
revision-date 2013-07-15; }
import ietf-trafficselector-types { prefix traffic-selectors;
revision-date 2017-10-29; }
import ietf-yang-types { prefix ytypes; import ietf-yang-types { prefix ytypes;
revision-date 2013-07-15; } revision-date 2013-07-15; }
import ietf-pmip-qos { prefix pmipqos;
revision-date 2016-02-10; }
organization "IETF Distributed Mobility Management (DMM) organization "IETF Distributed Mobility Management (DMM)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Dapeng Liu WG Chair: Dapeng Liu
<mailto:maxpassion@gmail.com> <mailto:maxpassion@gmail.com>
skipping to change at page 87, line 28 skipping to change at page 90, line 35
Editor: Satoru Matsushima Editor: Satoru Matsushima
<mailto:satoru.matsushima@g.softbank.co.jp> <mailto:satoru.matsushima@g.softbank.co.jp>
Editor: Lyle Bertz Editor: Lyle Bertz
<mailto:lylebe551144@gmail.com>"; <mailto:lylebe551144@gmail.com>";
description description
"This module contains YANG definition for "This module contains YANG definition for
Forwarding Policy Configuration Protocol(FPCP). Forwarding Policy Configuration Protocol(FPCP).
It contains Settings defintions as well as Descriptor and
Action extensions.
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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License."; without warranty as described in the Simplified BSD License.";
revision 2017-03-08 { revision 2017-09-27 {
description "Version 06 updates."; description "Version 10 updates.";
reference "draft-ietf-dmm-fpc-cpdp-06"; reference "draft-ietf-dmm-fpc-cpdp-10";
} }
revision 2017-07-22 {
revision 2016-08-03 { description "Version 08 updates.";
description "Initial Revision.";