draft-ietf-dmm-fpc-cpdp-05.txt   draft-ietf-dmm-fpc-cpdp-06.txt 
DMM Working Group S. Matsushima DMM Working Group S. Matsushima
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track L. Bertz Intended status: Standards Track L. Bertz
Expires: May 4, 2017 Sprint Expires: September 14, 2017 Sprint
M. Liebsch M. Liebsch
NEC NEC
S. Gundavelli S. Gundavelli
Cisco Cisco
D. Moses D. Moses
Intel Corporation Intel Corporation
October 31, 2016 C. Perkins
Futurewei
March 13, 2017
Protocol for Forwarding Policy Configuration (FPC) in DMM Protocol for Forwarding Policy Configuration (FPC) in DMM
draft-ietf-dmm-fpc-cpdp-05.txt draft-ietf-dmm-fpc-cpdp-06.txt
Abstract Abstract
This document describes the solution of data-plane separation from This document describes a way, called Forwarding Policy Configuration
control-plane which enables a flexible mobility management system (FPC) to manage the separation of data-plane and control-plane. FPC
using agent and client functions. To configure data-plane nodes and defines a flexible mobility management system using FPC agent and FPC
functions, the data-plane is abstracted by an agent interface to the client functions. An FPC agent provides an abstract interface to the
client. The data-plane abstraction model is extensible in order to data-plane. The FPC client configures data-plane nodes by using the
support many different type of mobility management systems and data- functions and abstractions provided by the FPC agent for that data-
plane functions. plane nodes. The data-plane abstractions presented in this document
is extensible, in order to support many different types of mobility
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 5
4. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 5 4. Information Model for FPC . . . . . . . . . . . . . . . . . . 8
5. Information Model . . . . . . . . . . . . . . . . . . . . . . 8 4.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 9
5.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Domains . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Domains . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 14 4.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 16
5.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 16 4.3. FPC for Mobility Management . . . . . . . . . . . . . . . 16
5.3. FPC-Mobility . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1. Vport . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Port . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 22
5.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Namespace and Format . . . . . . . . . . . . . . . . . . 23
5.4. Namespace and Format . . . . . . . . . . . . . . . . . . 23 4.5. Attribute Application . . . . . . . . . . . . . . . . . . 24
5.5. Attribute Application . . . . . . . . . . . . . . . . . . 24 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.6. Policy and Runtime Data . . . . . . . . . . . . . . . . . 25 5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 25
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.1. CONFIG and CONF_BUNDLE Messages . . . . . . . . . . . 28
6.1. Protocol Messages and Semantics . . . . . . . . . . . . . 25 5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 31
6.1.1. CONF and CONF_BUNDLES Messages . . . . . . . . . . . 28 5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 32
6.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 32
6.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 32 5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 37
6.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 32 5.2.3. Optimization for Current and Subsequent Messages . . 39
6.2.2. Policy And Mobility on the Agent . . . . . . . . . . 37 5.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 44
6.2.3. Optimization for Current and Subsequent Messages . . 39 6. Protocol Message Details . . . . . . . . . . . . . . . . . . 45
6.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 44 6.1. Data Structures And Type Assignment . . . . . . . . . . . 45
7. Protocol Message Details . . . . . . . . . . . . . . . . . . 45 6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 45
7.1. Data Structures And Type Assignment . . . . . . . . . . . 45 6.1.2. Mobility Structures . . . . . . . . . . . . . . . . . 47
7.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 45 6.1.3. Topology Structures . . . . . . . . . . . . . . . . . 49
7.1.2. Mobilty Structures . . . . . . . . . . . . . . . . . 47 6.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 50
7.1.3. Topology Structures . . . . . . . . . . . . . . . . . 49 6.2. Message Attributes . . . . . . . . . . . . . . . . . . . 52
7.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.2. CONFIG and CONF_BUNDLE Attributes and Notifications . 52
7.2. Message Attributes . . . . . . . . . . . . . . . . . . . 52 6.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 55
7.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 52 7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 55
7.2.2. CONF and CONF_BUNDLES Attributes and Notifications . 52 7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 58
7.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 55 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 60
8. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 55 9. Security Considerations . . . . . . . . . . . . . . . . . . . 64
8.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 60 11. Work Team Participants . . . . . . . . . . . . . . . . . . . 67
10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 67
12. Work Team Participants . . . . . . . . . . . . . . . . . . . 67 12.2. Informative References . . . . . . . . . . . . . . . . . 68
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 69
13.1. Normative References . . . . . . . . . . . . . . . . . . 67
13.2. Informative References . . . . . . . . . . . . . . . . . 67
Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 68
A.1. FPC Agent YANG Model . . . . . . . . . . . . . . . . . . 69 A.1. FPC Agent YANG Model . . . . . . . . . . . . . . . . . . 69
A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 85 A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 86
A.2.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . 85 A.2.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . 86
A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 99 A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 102
A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 112 A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 115
A.2.4. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 123 A.2.4. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 127
A.2.5. FPC / PMIP Integration YANG Model . . . . . . . . . . 138 A.2.5. FPC / PMIP Integration YANG Model . . . . . . . . . . 144
A.2.6. FPC Policy Extension YANG Model . . . . . . . . . . . 145 A.2.6. FPC Policy Extension YANG Model . . . . . . . . . . . 151
A.3. FPC nformation Model YANG Tree . . . . . . . . . . . . . 148 A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 155
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159
1. Introduction 1. Introduction
This document describes Forwarding Policy Configuration (FPC), the This document describes Forwarding Policy Configuration (FPC), a
solution of data-plane separation from control-plane which enables system for managing the separation of data-plane and control-plane.
flexible mobility management systems using agent and client FPC enables flexible mobility management using FPC agent and FPC
functions. To configure data-plane nodes and functions, the data- client functions. An FPC agent exports an abstract interface to the
plane is abstracted in the agent which provides an interface to the data-plane. To configure data-plane nodes and functions, the FPC
client. client uses the interface to the data-plane offered by the FPC agent.
Control planes of mobility management systems, and/or any Control planes of mobility management systems, or other applications
applications which require data-plane control, can utilize the FPC which require data-plane control, can utilize the FPC client at
Client in flexible granularities of operation. The configuration various granularities of operation. The operations are capable of
operations are capable of configuring not only single Data-Plane Node configuring a single Data-Plane Node (DPN) directly, as well as
(DPN) directly, but also multiple DPNs from abstracted data-plane multiple DPNs as determined by abstracted data-plane models on the
models on the FPC agent. FPC agent.
FPC agent provides the data-plane abstraction models in the following A FPC agent provides data-plane abstraction in the following three
three areas: areas:
Topology: DPNs are grouped and abstracted in terms of roles of Topology: DPNs are grouped and abstracted according to well-known
mobility management such as access, anchors and domains. FPC concepts of mobility management such as access networks, anchors
Agent abstracts DPN-groups and consists of forwarding plane and domains. A FPC agent provides an interface to the abstract
topology, such as access nodes assigned to a DPN-group which peers DPN-groups that enables definition of a topology for the
to a DPN-group of anchor nodes. forwarding plane. For example, access nodes may be assigned to a
DPN-group which peers to a DPN-group of anchor nodes.
Policy: Policy abstracts policies which handle specific traffic Policy: A Policy embodies the mechanisms for processing specific
flows or packets such as QoS, packet processing to rewrite traffic flows or packets. This is needed for QoS, for packet
headers, etc. A policy consists of one or multiple rules which processing to rewrite headers, etc. A Policy consists of one or
are composed of Descriptors and Actions. Descriptors in a rule more rules. Each rule is composed of Descriptors and Actions.
identify traffic flows and Actions apply treatments to packets Descriptors in a rule identify traffic flows, and Actions apply
matched to the Descriptors in the rule. An arbitrary set of treatments to packets that match the Descriptors in the rule. An
policies is abstracted as a Policy-group which is applied to arbitrary set of policies can be abstracted as a Policy-group to
Ports. be applied to a particular collection of flows, which is called
the Virtual Port (Vport).
Mobility: An endpoint of a mobility session is abstracted as a Mobility: A mobility session which is active on a mobile node is
Context with its associated runtime concrete attributes, such as abstracted as a Context with associated runtime concrete
tunnel endpoints, tunnel identifiers, delegated prefix(es), attributes, such as tunnel endpoints, tunnel identifiers,
routing information, etc. Contexts are attached to DPN-groups delegated prefix(es), routing information, etc. Contexts are
along with consequence of the control plane. One or multiple attached to DPN-groups along with consequence of the control
Contexts which have same sets of policies are assigned Ports which plane. One or multiple Contexts which have same sets of policies
abstract those policy sets. A Context can belong to multiple are assigned Vports which abstract those policy sets. A Context
Ports which serve different kinds of purpose and policy. Monitors can belong to multiple Vports which serve various kinds of purpose
provide a mechanism to produce reports when events regarding and policy. Monitors provide a mechanism to produce reports when
Ports, Sessions, DPNs or the Agent occurs. events regarding Vports, Sessions, DPNs or the Agent occur.
The Agent collects 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. Specific protocols and configurations to sessions attached. The specific protocols and configurations to
configure DPN from FPC Agent are out of scope of this document. configure DPN from a FPC Agent are outside the scope of this
document.
The data-plane abstraction model is extensible in order to support The data-plane abstractions may be extended to support many different
many different types of mobility management systems and data-plane mobility management systems and data-plane functions. The
functions. The architecture and protocol design of FPC intends not architecture and protocol design of FPC is not tied to specific types
to tie to specific types of access technologies and mobility of access technologies and mobility protocols.
protocols.
2. Conventions 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology
DPN: A data-plane node (DPN) is capable of DPN: A data-plane node (DPN) is capable of
deploying data-plane features. DPNs may be deploying data-plane features. DPNs may be
switches or routers regardless of their switches or routers regardless of their
realiziation, i.e. whether they are hardware realiziation, i.e. whether they are hardware
or software based. or software based.
FPC Agent: A functional entity in FPC that manages DPNs FPC Agent: A functional entity in FPC that manages DPNs
and provides abstracted data-plane networks and provides abstracted data-plane networks
to mobility management systems and/or to mobility management systems and/or
applications through FPC Clients. applications through FPC Clients.
skipping to change at page 5, line 24 skipping to change at page 5, line 27
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.
Port: A set of forwarding policies. Virtual Port (Vport): A set of forwarding policies.
Context: An abstracted endpoint of a mobility session Context: An abstracted endpoint of a mobility session
associated with runtime attributes. Ports associated with runtime attributes. Vports
may apply to Context which instantiates those may apply to Context which instantiates those
forwarding policies on a DPN. forwarding policies on a DPN.
4. FPC Architecture 3. FPC Architecture
In accordance with the requirements of flexible data-plane functions To fulfill the requirements described in [RFC7333], FPC enables
deployment described in [RFC7333], FPC provides a means for mobility mobility control-planes and applications to configure DPNs with
control-plane and applications to handle DPNs that must be configured various roles of the mobility management as described in
with various roles of the mobility management aspect described in
[I-D.ietf-dmm-deployment-models]. [I-D.ietf-dmm-deployment-models].
FPC uses building blocks of Agent, Client and data-plane abstraction FPC defines building blocks of FPC Agent and FPC Client, as well as
models as the interface between the agent and the client. data models for the necessary data-plane abstractions. The
attributes defining those data models serve as protocol elements for
the interface between the FPC Agent and the FPC Client.
Mobility control-plane and applications integrate the FPC Client Mobility control-planes and applications integrate the FPC Client
function and connect to FPC Agent functions. The Client and the function. The FPC Client connects to FPC Agent functions. The
Agent communicate based on data-plane abstraction models described in Client and the Agent communicate based on information models for the
Section 5. Along with models, the control-plane and the applications data-plane abstractions described in Section 4. The data models
put forwarding policies for their mobility sessions on the Agent. allow the control-plane and the applications to support forwarding
policies on the Agent for their mobility sessions.
The Agent connects to DPN(s) to manage their configuration. These The FPC Agent carries out the required configuration and management
configurations are rendered from the forwarding policies by the of the DPN(s). The Agent determines DPN configurations according to
Agent. FPC Agent may be implemented in a network controller that the forwarding policies requested by the FPC Client. The DPN
handles multiple DPNs or it also may be integrated into a DPN. configurations could be specific to each DPN implementation such that
how FPC Agent determines implementation specific configuration for a
DPN is outside of the scope of this document. Along with the models,
the control-plane and the applications put Policies to the Agent
prior to creating their mobility sessions.
The FPC architecture supports multi-tenancy where the FPC enabled Once the Topology of DPN(s) and domains are defined for a data plane
data-plane supports multiple tenants of mobile operator networks and/ on an Agent, the data-plane nodes (DPNs) are available for further
or applications. DPNs on the data-plane run in multiple data-plane configuration. The FPC Agent connects those DPNs to manage their
roles which are defined per session, domain and tenant. configurations.
This architecture is illustrated in Figure 1. This document does not This architecture is illustrated in Figure 1. An FPC Agent may be
adopt a specific protocol for the FPC envelope protocol and it is out implemented in a network controller that handles multiple DPNs, or
of scope. However it must be capable of supporting FPC protocol there is a simple case where another FPC Agent may itself be
messages and transactions described in Section 6. integrated into a DPN.
This document does not adopt a specific protocol for the FPC
interface protocol and it is out of scope. However it must be
capable of supporting FPC protocol messages and transactions
described in Section 5.
+-------------------------+ +-------------------------+
| Mobility Control-Plane | | Mobility Control-Plane |
| and | | and |
| Applications | | Applications |
|+-----------------------+| |+-----------------------+|
|| FPC Client || || FPC Client ||
|+----------^------------+| |+----------^------------+|
+-----------|-------------+ +-----------|-------------+
FPC envelope protocol | FPC interface protocol |
+---------------+-----------------+ +---------------+-----------------+
| | | |
Network | | Network | |
Controller | DPN | Controller | DPN |
+-----------|-------------+ +----------|---------+ +-----------|-------------+ +----------|---------+
|+----------v------------+| |+---------v--------+| |+----------v------------+| |+---------v--------+|
|| [Data-plane model] || ||[Data-plane model]|| || [Data-plane model] || ||[Data-plane model]||
|| FPC Agent || || FPC Agent || || FPC Agent || || FPC Agent ||
|+-----------------------+| |+------------------+| |+-----------------------+| |+------------------+|
|+------------+----------+| | | |+------------+----------+| | |
||SB Protocols|FPC Client|| | DPN Configuration | ||SB Protocols|FPC Client|| | DPN Configuration |
|| Modules | Module || +--------------------+ || Modules | Module || +--------------------+
|+------^-----+----^-----+| |+------^-----+----^-----+|
+-------|----------|------+ +-------|----------|------+
| | | |
Other | | FPC envelope Other | | FPC interface
Southband | | Protocol Southband | | Protocol
Protocols | | Protocols | |
| +-----------------+ | +-----------------+
| | | |
DPN | DPN | DPN | DPN |
+----------|---------+ +----------|---------+ +----------|---------+ +----------|---------+
|+---------v--------+| |+---------v--------+| |+---------v--------+| |+---------v--------+|
|| Configuration || ||[Data-plane model]|| || Configuration || ||[Data-plane model]||
|| Protocol module || || FPC Agent || || Protocol module || || FPC Agent ||
|+------------------+| |+------------------+| |+------------------+| |+------------------+|
| | | | | | | |
| DPN Configuration | | DPN Configuration | | DPN Configuration | | DPN Configuration |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1: Reference Forwarding Policy Configuration (FPC) Figure 1: Reference Forwarding Policy Configuration (FPC)
Architecture Architecture
Note that the FPC envelope protocol is only required to handle The FPC architecture supports multi-tenancy; an FPC enabled data-
runtime data in the Mobility model. The rest of the FPC models, plane supports tenants of multiple mobile operator networks and/or
namely Topology and Policy, are pre-configured, therefore real-time applications. It means that the FPC Client of each tenant connects
data handling capabilities are not required for them. Operators that to the FPC Agent and it MUST partition namespace and data for their
are tenants in the FPC data-plane can configure Topology and Policy data-planes. DPNs on the data-plane may fulfill multiple data-plane
on the Agent through other means, such as Restconf roles which are defined per session, domain and tenant.
Note that all FPC models SHOULD be configurable. The FPC interface
protocol in Figure 1 is only required to handle runtime data in the
Mobility model. The rest of the FPC models, namely Topology and
Policy, may be pre-configured, and in that case real-time protocol
exchanges would not be required for them. Operators that are tenants
in the FPC data-plane could configure Topology and Policy on the
Agent through other means, such as Restconf
[I-D.ietf-netconf-restconf] or Netconf [RFC6241]. [I-D.ietf-netconf-restconf] or Netconf [RFC6241].
5. Information Model 4. Information Model for FPC
This section describes information model that represents the concept This section presents an information model representing the abstract
of FPC which is language and protocol neutral. Figure 2 is an concepts of FPC, which are language and protocol neutral. Figure 2
overview of FPC data-plane abstraction model. shows an overview of the FPC data-plane information model.
(Mobile operator tenant that abstracted data-plane is used) (Mobile operator tenant that abstracted data-plane is used)
| |
+---FPC-Topology +---FPC-Topology
| | | |
| +---Domains | +---DPNs
| | | |
| +---DPN-groups | +---DPN-groups
| | | |
| +---DPNs | +---Domains
| |
+---FPC-Policy +---FPC-Policy
| | | |
| +---Descriptors | +---Descriptors
| | | |
| +---Actions | +---Actions
| | | |
| +---Policies | +---Policies
| | | |
| +---Policy-groups | +---Policy-groups
| |
+---FPC-Mobility +---FPC-Mobility
| |
+---Ports +---Vports
| |
+---Contexts +---Contexts
Figure 2: FPC Data-plane Abstraction Model Figure 2: FPC Data-plane Information Model
5.1. FPC-Topology 4.1. FPC-Topology
Topology abstraction enables an actual data-plane network to support Topology abstraction enables a physical data-plane network to support
multiple mobile operator's topologies of their data-plane. The FPC- multiple overlay topologies. An FPC-Topology consists of DPNs, DPN-
Topology consists of DPNs, DPN-groups and Domains which abstract groups and Domains which abstract data-plane topologies for the
data-plane topologies for the Client's mobility control-planes and Client's mobility control-planes and applications.
applications.
A mobile operator who utilizes a FPC enabled data-plane network can Utilizing a FPC Agent, a mobile operator can create virtual DPNs in
virtually create their DPNs along with their data-plane design on the an overlay network. Those such virtual DPNs are treated the same as
Agent. The operator also creates a DPN-group of which the DPNs are physical forwarding DPNs in this document.
attributed roles of mobility management such as access, anchors and
domains.
5.1.1. Domains 4.1.1. DPNs
A domain is defined by the operators to attribute DPN-groups to the The DPNs define all available nodes to a tenant of the FPC data-plane
domain. Domains may represent services or applications within the network. FPC Agent defines DPN binding to actual nodes. The role of
operator. a DPN in the data-plane is determined at the time the DPN is assigned
to a DPN-group.
(FPC-Topology) (FPC-Topology)
| |
+---Domains +---DPNs
| |
+---Domain-id +---DPN-id
| |
+---Domain-name +---DPN-name
| |
+---Domain-type +---DPN-groups
|
+---Node-reference
Figure 3: Domain Model Structure Figure 3: DPNs Model Structure
Domain-id: Identifier of Domain. The ID format SHOULD refer to DPN-id: The identifier for the DPN. The ID format MUST conform to
Section 5.4. Section 4.4.
Domain-name: Defines Domain name. DPN-name: The name of the DPN.
Domain-type: Specifies which type of communication allowed within DPN-groups: The list of DPN-groups to which the DPN belongs.
the domain, such as ipv4, ipv6, ipv4v6 or ieee802.
5.1.2. DPN-groups Node-reference: Indicates a physical node, or a platform of
virtualization, to which the DPN is bound by the Agent. The
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.
A DPN-group defines a set of DPNs which share common data-plane 4.1.2. DPN-groups
attributes. DPN-groups consist data-plane topology that consists of
a DPN-group of access nodes connecting to an anchor nodes DPN-group.
DPN Group has attributes such as the data-plane role, supported A DPN-group is a set of DPNs which share certain specified data-plane
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
access technologies, mobility profiles, connected peer groups and access technologies, mobility profiles, connected peer groups and
domain. domain. A DPN may be assigned to multiple DPN-groups in different
data-plane roles or different domains.
(FPC-Topology) (FPC-Topology)
| |
+---DPN-groups +---DPN-groups
| |
+---DPN-group-id +---DPN-group-id
| |
+---Data-plane-role +---Data-plane-role
| |
+---Domains +---Domains
| |
+---Access-type +---Access-type
| |
+---Mobility-profile +---Mobility-profile
| |
+---DPN-group-peers +---DPN-group-peers
Figure 4: DPN-groups Model Structure Figure 4: DPN-groups Model Structure
DPN-group-id: Defines identifier of DPN-group. The ID format SHOULD DPN-group-id: The identifier of the DPN-group. The ID format MUST
refer to Section 5.4. conform to Section 4.4.
Data-plane-role: Defines data-plane role of the DPN-group, such as Data-plane-role: The data-plane role of the DPN-group, such as
access-dpn, L2/L3 or anchor-dpn. access-dpn, anchor-dpn.
Domains: Specifies domains which the DPN-group belongs to. Domains: The domains to which the DPN-group belongs.
Access-type: Defines access type which the DPN-group supports such Access-type: The access type supported by the DPN-group such as
as ethernet(802.3/11), 3gpp cellular(S1, RAB), if any. ethernet(802.3/11), 3gpp cellular(S1, RAB), if any.
Mobility-profile: Defines supported mobility profile, such as ietf- Mobility-profile: Identifies a supported mobility profile, such as
pmip, 3gpp, or new profiles defined as extensions of this ietf-pmip, or 3gpp. New profiles may be defined as extensions of
specification. When those profiles are correctly defined, some this specification. Mobility profiles are defined so that some
or all data-plane parameters of contexts can be automatically or all data-plane parameters of the mobility contexts that are
derived from this profile by FPC Agent. part of the profile can be automatically determined by the FPC
Agent.
DPN-group-peers: Defines remote peers of DPN-group with parameters DPN-group-peers: The remote peers of the DPN-group with parameters
described in Section 5.1.2.1. described in Section 4.1.2.1.
5.1.2.1. DPN-group Peers 4.1.2.1. DPN-group Peers
DPN-group-peers defines parameters of remote peer DPNs as illustrated DPN-group-peers lists relevant parameters of remote peer DPNs as
in Figure 5. illustrated in Figure 5.
(DPN-groups) (DPN-groups)
| |
+---DPN-group-peers +---DPN-group-peers
| |
+---Remote-DPN-group-id +---Remote-DPN-group-id
| |
+---Remote-mobility-profile +---Remote-mobility-profile
| |
+---Remote-data-plane-role +---Remote-data-plane-role
| |
+---Remote-endpoint-address +---Remote-endpoint-address
| |
+---Local-endpoint-address +---Local-endpoint-address
| |
+---MTU-size +---MTU-size
Figure 5: DPN-groups Peer Model Structure Figure 5: DPN-groups Peer Model Structure
Remote-DPN-group-id: Indicates peering DPN-Group. Remote-DPN-group-id: The ID of the peering DPN-Group. The ID format
MUST conform to Section 4.4.
Remote-mobility-profile: Defines mobility-profile used for this Remote-mobility-profile: The mobility-profile for the peering DPN-
peer, currently defined profiles are ietf-pmip, 3gpp, or new group. Currently defined profiles are ietf-pmip, or 3gpp. New
profiles defined as extensions of this specification. profiles may be defined as extensions of this specification.
Remote-data-plane-role: Defines forwarding-plane role of peering Remote-data-plane-role: The data-plane role of the peering DPN-
DPN-group. group.
Remote-endpoint-address: Defines Endpoint address of the peering Remote-endpoint-address: Defines Endpoint address of the peering
DPN-group. DPN-group.
Local-endpoint-address: Defines Endpoint address of its own DPN- Local-endpoint-address: Defines Endpoint address of its own DPN-
group to peer the remote DPN-group. group to peer the remote DPN-group.
MTU-size: Defines MTU size of traffic between the DPN-Group and this MTU-size: Defines MTU size of traffic between the DPN-Group and this
DPN-group-peer. DPN-group-peer.
5.1.3. DPNs 4.1.3. Domains
List of DPNs which defines all available nodes for a tenant of the
FPC data-plane network. Role of a DPN in the data-plane is not
determined until the DPN is attributed to a DPN-group.
A DPN may have multiple DPN-groups which are in different data-plane A domain is defined by an operator to refer to a particular network,
roles or domains. Mobility sessions of that DPN-groups are installed considered as a system of cooperating DPN-groups. Domains may
into actual data-plane nodes. The Agent defines DPN binding to represent services or applications that are resident within an
actual nodes. operator's network.
(FPC-Topology) (FPC-Topology)
| |
+---DPNs +---Domains
| |
+---DPN-id +---Domain-id
| |
+---DPN-name +---Domain-name
| |
+---DPN-groups +---Domain-type
| |
+---Node-reference +---Domain-reference
Figure 6: DPNs Model Structure Figure 6: Domain Model Structure
DPN-id: Defines identifier of DPN. The ID format SHOULD refer to Domain-id: Identifier of Domain. The ID format MUST conform to
Section 5.4. Section 4.4.
DPN-name: Defines name of DPN. Domain-name: The name of the Domain.
DPN-groups: List of DPN-group which the DPN belongs to. Domain-type: Specifies which address families are supported within
the domain.
Node-reference: Indicates an actual node to which the Agent binds Domain-reference: Indicates a set of resources for the domain which
the DPN. The Agent SHOULD maintain that nodes information consists a topology of physical nodes, platforms of
including IP address of management and control protocol to virtualization and physical/virtual links with certain bandwidth,
connect them. etc,.
5.2. FPC-Policy 4.2. FPC-Policy
The FPC-Policy consists of Descriptors, Actions, Policies and Policy- The FPC-Policy consists of Descriptors, Actions, Policies and Policy-
groups, which can be viewed as configuration data while Contexts and groups. These can be viewed as configuration data, in contrast to
Ports are akin to structures that are instantiated on the Agent. The Contexts and Vports, which are structures that are instantiated on
Descriptors and Actions in a Policy referenced by a Port are active the Agent. The Descriptors and Actions in a Policy referenced by a
when the Port is in a active Context, i.e. they can be applied to Vport are active when the Vport is in an active Context, i.e. they
traffic on a DPN. can be applied to traffic on a DPN.
5.2.1. Descriptors 4.2.1. Descriptors
List of Descriptors which defines classifiers of specific traffic Descriptors defines classifiers of specific traffic flows, such as
flow, such as those based on source and destination addresses, those based on source and destination addresses, protocols, port
protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet. Note numbers of TCP/UDP/SCTP/DCCP, or any way of classifying packets.
that Descriptors are extensibly defined by specific profiles which Descriptors are defined by specific profiles that may be produced by
3gpp, ietf or other SDOs produce. Many specifications also use the 3gpp, ietf or other SDOs. Many specifications also use the terms
terms Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A packet
packet that meets the criteria of a Descriptor is said to satisfy, that meets the criteria of a Descriptor is said to satisfy, pass or
pass or is consumed by the Descriptor. Descriptors are assigned an be consumed by the Descriptor. Descriptors are assigned an
identifier and contain a type and value. identifier and contain a type and value.
(FPC-Policy) (FPC-Policy)
| |
+---Descriptors +---Descriptors
| |
+---Descriptor-id +---Descriptor-id
| |
+---Descriptor-type +---Descriptor-type
| |
+---Descriptor-value +---Descriptor-value
Figure 7: Descriptor Model Structure Figure 7: Descriptor Model Structure
Descriptor-id: Identifier of Descriptor. The ID format SHOULD refer Descriptor-id: Identifier of Descriptor. The ID format MUST conform
to Section 5.4. to Section 4.4.
Descriptor-type: Defines descriptor type, which classifies specific Descriptor-type: The descriptor type, which determines the
traffic flow, such as source and destination addresses, classification of a specific traffic flows, such as source and
protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet. destination addresses, protocols, port numbers of TCP/UDP/SCTP/
DCCP, or any other way of selecting packets.
Descriptor-value: Specifies the value of Descriptor such as IP Descriptor-value: The value of Descriptor such as IP prefix/address,
prefix/address, protocol number, port number, etc. protocol number, port number, etc.
5.2.2. Actions 4.2.2. Actions
List of Actions which defines treatment/actions to apply to A Policy defines a list of Actions that are to be applied to traffic
classified traffic meeting the criteria defined by Descriptors. meeting the criteria defined by the Descriptors. Actions include
Actions include traffic management related activity such as shaping, traffic management such as shaping, policing based on given
policing based on given bandwidth, and connectivity management bandwidth, and connectivity actions such as pass, drop, forward to
actions such as pass, drop, forward to given nexthop. Note that given nexthop. Actions may be defined as part of specific profiles
Actions are extensibly defined by specific profiles which 3gpp, ietf which are produced by 3gpp, ietf or other SDOs.
or other SDOs produce.
(FPC-Policy) (FPC-Policy)
| |
+---Actions +---Actions
| |
+---Action-id +---Action-id
| |
+---Action-type +---Action-type
| |
+---Action-value +---Action-value
Figure 8: Action Model Structure Figure 8: Action Model Structure
Action-id: Identifier of Action. The ID format SHOULD refer to Action-id: Identifier for the Action. The ID format MUST conform to
Section 5.4. Section 4.4.
Action-type: Defines action type, i.e. how to treat the specified Action-type: The type of the action -- i.e. how to treat the
traffic flow, e.g. pass, drop, forward to given nexthop value and specified traffic flows. Examples include pass, drop, forward to
shape, police based on given bandwidth value, etc. a given nexthop value, shape or police based on given bandwidth
value, etc.
Action-value: Specifies value of Action, such as bandwidth, nexthop Action-value: Specifies a value for the Action-type, such as
address or drop explicitly, etc. bandwidth, nexthop address or drop, etc.
5.2.3. Policies 4.2.3. Policies
Policies are collections of Rules. Each Policy has a Policy Policies are collections of Rules. Each Policy has a Policy
Identifier and a list of Rule/Order pairs. The Order and Rule values Identifier and a list of Rule/Order pairs. The Order and Rule values
MUST be unique in the Policy. Unlike the AND filter matching of each MUST be unique in the Policy. Unlike the AND filter matching of each
Rule the Policy uses an OR matching to find the first Rule whose 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 Descriptors are satisfied by the packet. The search for a Rule to
apply to packet is executed according to the unique Order values of 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 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 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 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. tested. If a Rule is not found then the Policy does not apply.
Policies contain Rules as opposed to references to Rules. Policies contain Rules (not references to Rules).
(FPC-Policy) (FPC-Policy)
| |
+---Policies +---Policies
| |
+---Policy-id +---Policy-id
| |
+---Rules +---Rules
| |
+---Order +---Order
skipping to change at page 15, line 25 skipping to change at page 15, line 25
+---Descriptors +---Descriptors
| | | |
| +---Descriptor-id | +---Descriptor-id
| | | |
| +---Direction | +---Direction
| |
+---Actions +---Actions
| |
+---Action-id +---Action-id
| |
+---Order +---Action-Order
Figure 9: Policies Model Structure Figure 9: Model Structure for Policies
Policy-id: Identifier of Policy. The ID format SHOULD refer to Policy-id: Identifier of Policy. The ID format MUST conform to
Section 5.4. Section 4.4.
Rules: List of Rules which are a collection of Descriptors and Rules: List of Rules which are a collection of Descriptors and
Actions. All Descriptors MUST be satisfied before the Actions Actions. All Descriptors MUST be satisfied before the Actions
are taken. This is known as an AND Descriptor list, i.e. are taken. This is known as an AND Descriptor list, i.e.
Descriptor 1 AND Descriptor 2 AND ... Descriptor X MUST be Descriptor 1 AND Descriptor 2 AND ... Descriptor X all MUST be
satisfied for the Rule to apply. These are internal structure to satisfied for the Rule to apply.
the Policy, i.e. it is not a first class, visible object at the
top level of an Agent.
Order: Specifies ordering if the Rule has multiple Descriptors and Order: Specifies ordering if the Rule has multiple Descriptors and
Action sets. Action sets. Order values MUST be unique within the Rules list.
Descriptors: List of Descriptors. Descriptors: The list of Descriptors.
Descriptor-id: Indicates each Descriptor in the Rule. Descriptor-id: Identifies each Descriptor in the Rule.
Direction: Specifies which direction applies, such as upstream, Direction: Specifies which direction applies, such as uplink,
downstream or both. downlink or both.
Actions: List of Actions. Actions: List of Actions.
Action-id: Indicates each Action in the rule. Action-id: Indicates each Action in the rule.
Order: Specifies Action ordering if the Rule has multiple actions. Action-Order: Specifies Action ordering if the Rule has multiple
actions. Action-Order values MUST be unique within the Actions
list.
5.2.4. Policy-groups 4.2.4. Policy-groups
List of Policy-groups which are an aggregation of Policies. Common List of Policy-groups which are an aggregation of Policies. Common
applications include aggregating Policies that are defined by applications include aggregating Policies that are defined by
different functions, e.g. Network Address Translation, Security, different functions, e.g. Network Address Translation, Security,
etc. The structure has an Identifier and references the Policies via etc. The structure has an Identifier and references the Policies via
their Identifiers. their Identifiers.
(FPC-Policy) (FPC-Policy)
| |
+---Policy-groups +---Policy-groups
| |
+---Policy-group-id +---Policy-group-id
| |
+---Policies +---Policies
Figure 10: Policy-group Model Structure Figure 10: Policy-group Model Structure
Policy-group-id: Identifier of Policy-group. The ID format SHOULD Policy-group-id: The identifier of the Policy-group. The ID format
refer to Section 5.4. MUST conform to Section 4.4.
Policies: List of Policies in the Policy-group. Policies: List of Policies in the Policy-group.
5.3. FPC-Mobility 4.3. FPC for Mobility Management
The FPC-Mobility consists of Port and Context. A mobility session is The FPC-Mobility consists of Vports and Contexts. A mobility session
abstracted as a Context with its associated runtime concrete is abstracted as a Context with its associated runtime concrete
attributes, such as tunnel endpoints, tunnel identifiers, delegated attributes, such as tunnel endpoints, tunnel identifiers, delegated
prefix(es) and routing information, etc. A Port abstracts a set of prefix(es) and routing information, etc. A Vport abstracts a set of
policies applied to the Context. policies applied to the Context.
5.3.1. Port 4.3.1. Vport
A port represents a collection of policy groups, a group of rules A Vport represents a collection of policy groups, that is, a group of
that can exist independent of the mobility/session lifecycle. rules that can exist independently of the mobility/session lifecycle.
Mobility control-plane or applications create, modify and delete Mobility control-plane applications create, modify and delete Vports
Ports on FPC Agent through the FPC Client. on FPC Agent through the FPC Client.
When a Port is indicated in a Context, the set of Descriptors and When a Vport is indicated in a Context, the set of Descriptors and
Actions in the Policies of the Port are collected and applied to the Actions in the Policies of the Vport are collected and applied to the
Context. They must be instantiated on the DPN as forwarding related Context. They must be instantiated on the DPN as forwarding related
actions such as QoS differentiations, packet processing of encap/ actions such as QoS differentiations, packet processing of encap/
decap, header rewrite, route selection, etc. decap, header rewrite, route selection, etc.
(FPC-Mobility) (FPC-Mobility)
| |
+---Ports +---Vports
| |
+---Port-id +---Vport-id
| |
+---Policy-groups +---Policy-groups
Figure 11: Port Model Structure Figure 11: Vport Model Structure
Port-id: Identifier of Port. The ID format SHOULD refer to Vport-id: The identifier of Vport. The ID format MUST conform to
Section 5.4. Section 4.4.
Policy-groups: List of references to Policy-groups which apply to Policy-groups: List of references to Policy-groups which apply to
the Port. the Vport.
5.3.2. Context 4.3.2. Context
An endpoint of a mobility session or the instantiation of policy- An endpoint of a mobility session is abstracted as a Context with its
groups is abstracted as a Context with its associated runtime associated runtime concrete attributes, such as tunnel endpoints,
concrete attributes, such as tunnel endpoints, tunnel identifiers, tunnel identifiers, delegated prefix(es) and routing information,
delegated prefix(es) and routing information, etc. Mobility control- etc. A mobility control-plane, or other applications, can create,
plane or applications create, modify and delete contexts on FPC Agent modify and delete contexts on an FPC Agent by using the FPC Client.
through the FPC Client.
A Context directly describes traffic treatment policies in QoS FPC Agent SHOULD determine runtime attributes of a Context from the
profile and Mobility profiles or indirectly via Ports. Parameters in Vport's policies and the attached DPN's attributes. A mobility
these profiles may be set by the FPC Client directly or indirectly control-plane, or other applications, MAY set some of the runtime
derived from the set of Descriptors and Actions when the Ports attributes directly when they create data-plane related attributes.
indicate Policies which specify those descriptors and actions. If a In the case of that a mobility control-plane assigns tunnel
Context doesn't have any Port, all parameters of the Context must be identifiers, for instance.
set by the Client.
(FPC-Mobility) (FPC-Mobility)
| |
+---Contexts +---Contexts
| |
+---Context-id +---Context-id
| |
+---Ports +---Vports
| |
+---DPN-group +---DPN-group
| |
+---Delegating-ip-prefixes +---Delegated-ip-prefixes
| |
+---Parent-context +---Parent-context
Figure 12: Common Context Model Structure Figure 12: Common Context Model Structure
Context-id: Identifier of Context. The ID format SHOULD refer to Context-id: Identifier of the Context. The ID format MUST conform
Section 5.4. to Section 4.4.
Ports: List of Ports. When a Context is applied to Port(s), the Vports: List of Vports. When a Context is applied to a Vport, the
context is configured by policies of those Port(s). Port-id context is configured by policies at each such Vport. Vport-id
references indicate Ports which apply to the Context. Context references indicate Vports which apply to the Context. Context
can be a part of multiple Ports which have different policies. can be a spread over multiple Vports which have different
policies.
DPN-group: The DPN-group assigned to the Context. DPN-group: The DPN-group assigned to the Context.
Delegating-ip-prefixes: List of IP prefixes to be delegated to the Delegated-ip-prefixes: List of IP prefixes to be delegated to the
mobile node of the context. mobile node of the Context.
Parent-context: Indicates context which the context inherits. Parent-context: Indicates a parent context from which this context
inherits.
5.3.2.1. Single DPN Agent Case 4.3.2.1. Single DPN Agent Case
In the case where a FPC Agent supports only one DPN, the Agent MUST In the case where a FPC Agent supports only one DPN, the Agent MUST
maintain context data just for the DPN. The Agent does not need to maintain Context data just for the DPN. The Agent does not need to
maintain a Topology model. The Context in single DPN case consists maintain a Topology model. Contexts in single DPN case consists of
of following parameters for both direction of uplink and downlink. following parameters for both direction of uplink and downlink.
(Contexts) (Contexts)
| |
+---UL-Tunnel-local-address +---UL-Tunnel-local-address
| |
+---UL-Tunnel-remote-address +---UL-Tunnel-remote-address
| |
+---UL-MTU-size +---UL-MTU-size
| |
+---UL-Mobility-specific-tunnel-parameters +---UL-Mobility-specific-tunnel-parameters
skipping to change at page 19, line 31 skipping to change at page 19, line 31
+---UL-Vendor-specific-parameters +---UL-Vendor-specific-parameters
Figure 13: Uplink Context Model of Single DPN Structure Figure 13: Uplink Context Model of Single DPN Structure
UL-Tunnel-local-address: Specifies uplink endpoint address of the UL-Tunnel-local-address: Specifies uplink endpoint address of the
DPN. DPN.
UL-Tunnel-remote-address: Specifies uplink endpoint address of the UL-Tunnel-remote-address: Specifies uplink endpoint address of the
remote DPN. remote DPN.
UL-MTU-size: Specifies uplink MTU size. UL-MTU-size: Specifies the uplink MTU size.
UL-Mobility-specific-tunnel-parameters: Specifies profile specific UL-Mobility-specific-tunnel-parameters: Specifies profile specific
uplink tunnel parameters to the DPN which the agent exists. The uplink tunnel parameters to the DPN which the agent exists. This
profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf- may, for example, include GTP/TEID for 3gpp profile, or GRE/Key
pmip profile, or new profiles defined by extensions of this for ietf-pmip profile.
specification.
UL-Nexthop: Indicates nexthop information of uplink in external UL-Nexthop: Indicates next-hop information of uplink in external
network such as IP address, MAC address, SPI of service function network such as IP address, MAC address, SPI of service function
chain, SID of segment routing, etc. 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 UL-QoS-profile-specific-parameters: Specifies profile specific QoS
parameter of uplink, such as QCI/TFT for 3gpp profile, parameters of uplink, such as QCI/TFT for 3gpp profile,
[RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by [RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles
extensions of this specification. defined by extensions of this specification.
UL-DPN-specific-parameters: Specifies optional node specific UL-DPN-specific-parameters: Specifies optional node specific
parameters of uplink in need, such as if-index, tunnel-if-number parameters needed by uplink such as if-index, tunnel-if-number
that must be unique in the DPN. that must be unique in the DPN.
UL-Vendor-specific-parameters: Specifies a vendor specific parameter UL-Vendor-specific-parameters: Specifies a vendor specific parameter
space for uplink. space for the uplink.
(Contexts) (Contexts)
| |
+---DL-Tunnel-local-address +---DL-Tunnel-local-address
| |
+---DL-Tunnel-remote-address +---DL-Tunnel-remote-address
| |
+---DL-MTU-size +---DL-MTU-size
| |
+---DL-Mobility-specific-tunnel-parameters +---DL-Mobility-specific-tunnel-parameters
skipping to change at page 20, line 34 skipping to change at page 20, line 34
+---DL-Vendor-specific-parameters +---DL-Vendor-specific-parameters
Figure 14: Downlink Context Model of Single DPN Structure Figure 14: Downlink Context Model of Single DPN Structure
DL-Tunnel-local-address: Specifies downlink endpoint address of the DL-Tunnel-local-address: Specifies downlink endpoint address of the
DPN. DPN.
DL-Tunnel-remote-address: Specifies downlink endpoint address of the DL-Tunnel-remote-address: Specifies downlink endpoint address of the
remote DPN. remote DPN.
DL-MTU-size: Specifies downlink MTU size of tunnel. DL-MTU-size: Specifies the downlink MTU size of tunnel.
DL-Mobility-specific-tunnel-parameters: Specifies profile specific DL-Mobility-specific-tunnel-parameters: Specifies profile specific
downlink tunnel parameters to the DPN which the agent exists. downlink tunnel parameters to the DPN which the agent exists.
The profiles includes GTP/TEID for 3gpp profile, GRE/Key for This may, for example, include GTP/TEID for 3gpp profile, or GRE/
ietf-pmip profile, or new profiles defined by extensions of this Key for ietf-pmip profile.
specification.
DL-Nexthop: Indicates nexthop information of downlink in external DL-Nexthop: Indicates next-hop information of downlink in external
network such as IP address, MAC address, SPI of service function network such as IP address, MAC address, SPI of service function
chain, SID of segment routing, etc. 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.
DL-QoS-profile-specific-parameters: Specifies profile specific QoS DL-QoS-profile-specific-parameters: Specifies profile specific QoS
parameter of downlink, such as QCI/TFT for 3gpp profile, parameters of downlink, such as QCI/TFT for 3gpp profile,
[RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by [RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles
extensions of this specification. defined by extensions of this specification.
DL-DPN-specific-parameters: Specifies optional node specific DL-DPN-specific-parameters: Specifies optional node specific
parameters of downlink in need such as if-index, tunnel-if-number parameters needed by downlink such as if-index, tunnel-if-number
that must be unique in the DPN. that must be unique in the DPN.
DL-Vendor-specific-parameters: Specifies a vendor specific parameter DL-Vendor-specific-parameters: Specifies a vendor specific parameter
space for downlink. space for the downlink.
5.3.2.2. Multiple DPN Agent Case 4.3.2.2. Multiple DPN Agent Case
Another case is when a FPC Agent connects to multiple DPNs. This Alternatively, a FPC Agent may connect to multiple DPNs. The Agent
Agent MUST maintain a set of Context data for each DPN. The Context MUST maintain a set of Context data for each DPN. The Context
contains a DPNs list where each entry of the list consists of the contains a list of DPNs, where each entry of the list consists of the
parameters in Figure 15. A Context data for one DPN has two entries parameters in Figure 15. A Context data for one DPN has two entries
for each direction of uplink and downlink or, where applicable, a - one for uplink and another for downlink or, where applicable, a
direction of 'both'. direction of 'both'.
(Contexts) (Contexts)
| |
+---DPNs +---DPNs
| |
+---DPN-id +---DPN-id
| |
+---Direction +---Direction
| |
skipping to change at page 21, line 47 skipping to change at page 21, line 47
+---Nexthop +---Nexthop
| |
+---QoS-profile-specific-parameters +---QoS-profile-specific-parameters
| |
+---DPN-specific-parameters +---DPN-specific-parameters
| |
+---Vendor-specific-parameters +---Vendor-specific-parameters
Figure 15: Multiple-DPN Supported Context Model Structure Figure 15: Multiple-DPN Supported Context Model Structure
DPN-id: Indicates DPN of which the runtime context data installed. DPN-id: Indicates DPN of which the runtime Context data installed.
Direction: Specifies which side of connection at the DPN indicated, Direction: Specifies which side of connection at the DPN indicated -
"uplink", "downlink" or "both". uplink, downlink or both.
Tunnel-local-address: Specifies endpoint address of the DPN at the Tunnel-local-address: Specifies endpoint address of the DPN at the
uplink or downlink. uplink or downlink.
Tunnel-remote-address: Specifies endpoint address of remote DPN at Tunnel-remote-address: Specifies endpoint address of remote DPN at
the uplink or downlink. the uplink or downlink.
MTU-size: Specifies the packet MTU size on uplink or downlink. MTU-size: Specifies the packet MTU size on uplink or downlink.
Mobility-specific-tunnel-parameters: Specifies profile specific Mobility-specific-tunnel-parameters: Specifies profile specific
tunnel parameters for uplink or downlink of the DPN. The tunnel parameters for uplink or downlink to the DPN. This may,
profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf- for example, include GTP/TEID for 3gpp profile, or GRE/Key for
pmip profile, or new profiles defined by extensions of this ietf-pmip profile.
specification.
Nexthop: Indicates nexthop information for uplink or downlink in Nexthop: Indicates next-hop information for uplink or downlink in
external network of the DPN such as IP address, MAC address, SPI external network such as IP address, MAC address, SPI of service
of service function chain, SID of segment routing, etc. 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 QoS-profile-specific-parameters: Specifies profile specific QoS
parameter for uplink or downlink of the DPN, such as QCI/TFT for parameters for uplink or downlink to the DPN, such as QCI/TFT for
3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or new profiles 3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or parameters of
defined by extensions of this specification. new profiles defined by extensions of this specification.
DPN-specific-parameters: Specifies optional node specific parameters DPN-specific-parameters: Specifies optional node specific parameters
for uplink or downlink of the DPN in need, such like if-index, needed by uplink or downlink to the DPN such like if-index,
tunnel-if-number that must be unique in the DPN. tunnel-if-number that must be unique in the DPN.
Vendor-specific-parameters: Specifies a vendor specific parameter Vendor-specific-parameters: Specifies a vendor specific parameter
space for the DPN. space for the DPN.
Multi-DPN Agents will only use the DPNs list of a Context for Multi-DPN Agents will use only the DPNs list of a Context for
processing as described in this section. A single-DPN Agent MAY use processing as described in this section. A single-DPN Agent MAY use
both the Single Agent DPN model Section 5.3.2.1 and the multi-DPN both the Single Agent DPN model Section 4.3.2.1 and the multi-DPN
Agent Context described here. However, Agent feature support MUST be Agent Context described here.
discoverable by the FPC Client in order to determine which option(s)
an Agent supports.
5.3.3. Monitors 4.3.3. 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, e.g. a Monitor using a Threshold the attribute/entity monitored. For example, a Monitor using a
configuration cannot be applied to a context but it can be applied to Threshold configuration cannot be applied to a Context, because
a numeric property. Contexts do not have thresholds. But such a monitor could be applied
to a numeric threshold property of a Context.
(FPC-Mobility) (FPC-Mobility)
| |
+---Monitors +---Monitors
| |
+---Monitor-id +---Monitor-id
| |
+---Target +---Target
| |
+---Configuration +---Configuration
Figure 16: Common Monitor Model Structure Figure 16: Common Monitor Model Structure
Monitor-id: Name of the Monitor. The ID format SHOULD refer to Monitor-id: Name of the Monitor. The ID format MUST conform to
Section 5.4. Section 4.4.
Target: Target to be monitored. This may be an event, a Context, a Target: Target to be monitored. This may be an event, a Context, a
Port or attribute(s) of Contexts. When the type is an Vport or attribute(s) of Contexts. When the type is an
attribute(s) of a Context, the target name is a concatenation of attribute(s) of a Context, the target name is a concatenation of
the Context-Id and the relative path (separated by '/') to the the Context-Id and the relative path (separated by '/') to the
attribute(s)to be monitored. attribute(s) to be monitored.
Configuration: Determined by the Monitor subtype. Four report types Configuration: Determined by the Monitor subtype. Four report types
are defined: are defined:
* Periodic reporting specifies an interval by which a * Periodic reporting specifies an interval by which a
notification is sent to the Client. notification is sent to the Client.
* Event reporting specifies a list of even types that, if they * Event reporting specifies a list of event types that, if they
occur and are related to the monitored attribute, will result occur and are related to the monitored attribute, will result
in sending a notification to the Client in sending a notification to the Client.
* Scheduled reporting specifies the time (in seconds since Jan * Scheduled reporting specifies the time (in seconds since Jan
1, 1970) when a notification for the monitor should be sent to 1, 1970) when a notification for the monitor should be sent to
the Client. Once this Monitor's notification is completed the the Client. Once this Monitor's notification is completed the
Monitor is automatically de-registered. Monitor is automatically de-registered.
* Threshold reporting specifies one or both of a low and high * Threshold reporting specifies one or both of a low and high
threshold. When these values are crossed a corresponding threshold. When these values are crossed a corresponding
notification is sent to the Client. notification is sent to the Client.
5.4. Namespace and Format 4.4. 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 assign an unique identifier in the tenants. In this case, the Agent assigns an unique identifier in the
agent namespace. agent namespace.
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 MUST 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. It is noted that the choice of identifiers choice of FPC protocol. However the choice of identifiers which are
which are used in Mobility model should be suitable 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. The Topology and Policy models are not
restricted to meet that requirement as described in Section 4. restricted to meet that requirement, as described in Section 3.
5.5. Attribute Application 4.5. Attribute Application
Attributes in FPC Topology and Policy are pre-configured in a FPC Attributes in FPC Topology and Policy SHOULD be pre-configured in a
Agent prior to Contexts and Ports. Those pre-configured attributes FPC Agent prior to Contexts and Vports. The FPC Agent requires those
SHOULD NOT be instantiated on DPN(s) until the Contexts and Ports pre-configured attributes to be able to derive a Context's detailed
indicate them. runtime attributes.
This is intentional as it provides FPC Clients ability to reuse When a FPC Client creates a Context, the FPC Client is then able to
attributes that helps to minimize over the wire exchanges and reduce indicate specific DPN-group(s) instead of all endpoint addresses of
system errors by exchanging less information. 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.
When an Client creates Context, the Client would be able to indicate Similarly when a Vport is created for the Context, the FPC Agent can
just DPN-group(s) instead of all endpoint addresses of the DPN(s) and derive detailed forwarding policies from the pre-configured Policy
MTU-size of the tunnels for example. This is because that the Agent information in the FPC Policy. The FPC Client thereby has no need to
can derive data for those details from pre-configured DPN-group indicate those specific policies to all of the Contexts which share
information in the Topology. the same set of Policy-groups.
This is intentional as it provides FPC Clients the ability to reuse
pre-configured FPC Topology and FPC Policy attributes. It helps to
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 The Agent turns those derived data into runtime attributes of UL and
DL objects which are in the DPNs list of the Context (multiple-DPNs DL objects which are in the DPNs list of the Context (multiple-DPNs
Agent case) or direct under the Context (single-DPN Agent case). The Agent case) or directly under the Context (single-DPN Agent case).
Agent consequently instantiates forwarding policies on DPN(s) based The Agent consequently instantiates forwarding policies on DPN(s)
on that attributes. based on those attributes.
When the attribute is a direct value of the Context, e.g. IMSI When a Context inherits another Context as its parent, missing
defined in the 3GPP extension, only missing values can be provided by attributes in the child Context are provided by the Parent Context
the Parent Context. (for example, IMSI defined in the 3GPP extension) .
It is noted that the Agent SHOULD update the Context's attributes It is noted that the Agent SHOULD update the Context's attributes
which are instantiated on DPN(s) when the applied attributes of which are instantiated on DPN(s) when the applied attributes of
Topology and Policy are changed. Topology and Policy are changed.
5.6. Policy and Runtime Data In the case of FPC Client modifying an existing runtime attribute of
a Context which the FPC Agent derived, the FPC Agent MUST overwrite
Contexts and Ports that are supporting runtime, realtime mobility that attribute with the value which the Client brings to the Agent.
sessions which are produced in the mobility control plane. These However risks exist, for example, the attributes could be outside of
could be installed using any number of protocols, but in case of they allowable range of DPNs which the FPC Agent managed.
need to be delivered in realtime that Restconf
[I-D.ietf-netconf-restconf] and/or Netconf [RFC6241] will not
fullfill, an appropriate FPC envelope protocol MUST be required.
When data is delivered as part of the FPC envelop protocol it should
be part of a Context. If it is a binding to a generic policy that
could be used by multiple Contexts a Port is used. Given the support
for pre-configuration of policies and references by identifiers, e.g
a Rule ID, most policies do not require realtime delivery.
In case of modifying an existing Context attribute, the Agent MUST
overwrite that attribute with the value of which the Client brings to
the Agent.
6. Protocol 5. Protocol
6.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 | Configure processes a single |
| | ADMIN_STATE | operation. | | | ADMIN_STATE | operation. |
| | SESSION_STATE | | | | SESSION_STATE | |
| | OP_TYPE BODY | | | | OP_TYPE BODY | |
| | | | | | | |
| CONF_BUNDLES | 1*[HEADER | Configure-bundles takes multiple | | CONF_BUNDLE | 1*[HEADER | A Conf-bundle takes multiple |
| | ADMIN_STATE | operations that are to be | | | ADMIN_STATE | operations that are to be |
| | SESSION_STATE | executed as a group with partial | | | SESSION_STATE | executed as a group with partial |
| | TRANS_STRATEGY | failures allowed. They are | | | TRANS_STRATEGY | failures allowed. They are |
| | OP_TYPE BODY] | executed according to the OP_ID | | | OP_TYPE BODY] | executed according to the OP_ID |
| | | value in the OP_BODY in | | | | value in the OP_BODY in |
| | | ascending order. If a | | | | ascending order. If a |
| | | CONFIGURE_BUNDLES fails, any | | | | CONF_BUNDLE fails, any entities |
| | | entities provisioned in the | | | | provisioned in the CURRENT |
| | | CURRENT operation are removed, | | | | operation are removed. However, |
| | | however, any successful | | | | any successful operations |
| | | operations completed prior to | | | | completed prior to the current |
| | | the current operation are | | | | operation are preserved in order |
| | | preserved in order to reduce | | | | to reduce system load. |
| | | system load. |
| | | | | | | |
| REG_MONITOR | HEADER | Install a monitor at an Agent. | | REG_MONITOR | HEADER | Register a monitor at an Agent. |
| | ADMIN_STATE *[ | The message includes information | | | ADMIN_STATE *[ | The message includes information |
| | MONITOR ] | about the attribute to monitor | | | 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 *[ | Remove monitors from an Agent. | | DEREG_MONITOR | HEADER *[ | Deregister monitors from an |
| | MONITOR_ID ] [ | Monitor IDs are provided. | | | MONITOR_ID ] [ | Agent. Monitor IDs are provided. |
| | boolean ] | Boolean (optional) indicates if | | | boolean ] | Boolean (optional) indicates if |
| | | a successful DEREG triggers a | | | | a successful DEREG triggers a |
| | | NOTIFY with final data. | | | | 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. CONF, Messages that create or update Monitors and Entities, i.e. CONFIG,
CONF_BUNDLES and REG_MONITOR, specify an Administrative State which CONF_BUNDLE and REG_MONITOR, specify an Administrative State which
specifies the Administrative state of the message subject(s) after specifies the Administrative state of the message subject(s) after
the successful completion of the operation. If the status is set to 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 virtual, any existing data on the DPN is removed. If the value is
set to disabled, then an operation to disable the associated entity set to disabled, and if that entity exists on the DPN, then an
will occur on the DPN IF that entity exists on the DPN. If set to operation to disable the associated entity will occur on the DPN . If
'active' the DPN will be provisioned. Values are 'enabled', set to 'active' the DPN will be provisioned. Values are 'enabled',
'disabled' or 'virtual'. 'disabled', and 'virtual'.
CONF_BUNDLES 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 prodessing a CONF_BUNDLES message. The value operation fails while processing a CONF_BUNDLE message. The value of
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.
It is important to note that an envelope protocol used to support An FPC interface protocol used to support this specification may not
this specification may not need to support CONF_BUNDLES messages or need to support CONF_BUNDLE messages or specific TRANS_STRATEGY types
specific TRANS_STRATEGY types beyond 'default' when the protocol beyond 'default' when the protocol provides similar semantics.
provides similar semantics. However, this MUST be clearly defined in However, this MUST be clearly defined in the specification that
the specification that defines how the envelope protocol supports defines the interface protocol.
this specificaiton.
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 6.1.1.6.2 for CONF and CONF_BUNDLES requests. When Client Section 5.1.1.6.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 15 | from Agent to Client based upon |
| | | a previous CONFIG or | | | | a previous CONFIG or |
| | | CONFIG_BUNDLES request. | | | | CONF_BUNDLE request. |
| | | | | | | |
| NOTIFY | See | An asynchronous notification | | NOTIFY | See | An asynchronous notification |
| | Table 16 | from Agent to Client based upon | | | Table 16 | 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)
6.1.1. CONF and CONF_BUNDLES Messages 5.1.1. CONFIG and CONF_BUNDLE Messages
CONF and CONF_BUNDLES specify the following information for each CONFIG and CONF_BUNDLE specify the following information for each
operation in addition to the header information: operation in addition to the header information:
SESSION_STATE: sets the expected state of the entities embedded in SESSION_STATE: sets the expected state of the entities embedded in
the operation body after successful completion of the operation. the operation body after successful completion of the operation.
Values can be 'complete', 'incomplete' or 'outdated'. Any Values can be 'complete', 'incomplete' or 'outdated'. Any
operation that is 'incomplete' MAY NOT result in communication operation that is 'incomplete' MAY NOT result in communication
between the Agent and DPN. If the result is 'outdated' any new between the Agent and DPN. If the result is 'outdated' any new
operations on these entities or new references to these entities operations on these entities or new references to these entities
have unpredictable results. have unpredictable results.
OP_TYPE: specifies the type of operation. Valid values are 'create' OP_TYPE: specifies the type of operation. Valid values are 'create'
(0), 'update' (1), 'query' (2) or 'delete' (3). (0), 'update' (1), 'query' (2) or 'delete' (3).
COMMAND_SET: specifies the Command Set IF the feature is supported COMMAND_SET: If the feature is supported, specifies the Command Set
(see Section 6.1.1.4). (see Section 5.1.1.4).
BODY A list of Clones, if supported, Ports and Contexts when the BODY: A list of Clones, if supported, Vports and Contexts when the
OP_TYPE is 'create' or 'update'. Otherwise it is a list of OP_TYPE is 'create' or 'update'. Otherwise it is a list of
Targets for 'query' or 'deletion'. See Section 7.2.2 for Targets for 'query' or 'deletion'. See Section 6.2.2 for
details. details.
6.1.1.1. Agent Operation Processing 5.1.1.1. Agent Operation Processing
The Agent will process entities provided in an operation in the The Agent will process entities provided in an operation in the
following order: following order:
1. Clone Instructions, if the feature is supported 1. Clone Instructions, if the feature is supported
2. Ports 2. Vports
3. Contexts according to COMMAND_SET order processing 3. Contexts according to COMMAND_SET order processing
The following Order Processing occurs when COMMAND Sets are present The following Order Processing occurs when COMMAND Sets are present
1. The Entity specific COMMAND_SET is processed according to its bit 1. The Entity-specific COMMAND_SET is processed according to its bit
order unless otherwise specified by the technology specific order unless otherwise specified by the technology specific
COMMAND_SET definition. COMMAND_SET definition.
2. Operation specific COMMAND_SET is processed upon all applicable 2. Operation specific COMMAND_SET is processed upon all applicable
entities (even if they had Entity specific COMMAND_SET values entities (even if they had Entity-specific COMMAND_SET values
present) according to its bit order unless otherwise specified by present) according to its bit order unless otherwise specified by
the technology specific COMMAND_SET definition. the technology specific COMMAND_SET definition.
3. Operation OP_TYPE is processed for all entities. 3. Operation OP_TYPE is processed for all entities.
When deleting objects only their name needs to be provided. However, When deleting objects only their name needs to be provided. However,
attributes MAY be provided if the Client wishes to avoid requiring attributes MAY be provided if the Client wishes to avoid requiring
the Agent cache lookups. the Agent cache lookups.
When deleting an attribute, a leaf reference should be provided. When deleting an attribute, a leaf reference should be provided.
This is a path to the attributes. This is a path to the attributes.
6.1.1.2. Policy RPC Support 5.1.1.2. Policy RPC Support
This optional feature permits policy elements, (Policy-Group, Policy, This optional feature permits policy elements, (Policy-Group, Policy,
Action and Descriptor), values to be in CONF or CONF_BUNDLES Action and Descriptor), values to be in CONFIG or CONF_BUNDLE
requests. It enables RPC based policy provisioning. requests. It enables RPC based policy provisioning.
6.1.1.3. Cloning 5.1.1.3. Cloning
Cloning is an optional feature that allows a Client to copy one Cloning is an optional feature that allows a Client to copy one
structure to another in an operation. Cloning is always done first structure to another in an operation. Cloning is always done first
within the operation (see Operation Order of Execution for more within the operation (see Operation Order of Execution for more
detail). If a Client wants to build an object then Clone it, use detail). If a Client wants to build an object then Clone it, use
CONFIG_BUNDLES with the first operation being the entities to be CONF_BUNDLE with the first operation being the entities to be copied
copied and a second operation with the Cloning instructions. A CLONE and a second operation with the Cloning instructions. A CLONE
operation takes two arguments, the first is the name of the target to 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. clone and the second is the name of the newly created entity.
Individual attributes are not clonable; only Ports and Contexts can Individual attributes are not clonable; only Vports and Contexts can
be cloned. be cloned.
6.1.1.4. Command Bitsets 5.1.1.4. Command Bitsets
The COMMAND_SET is a technology specific bitset that allows for a The COMMAND_SET is a technology specific bitset that allows for a
single entity to be sent in an operation with requested sub- single entity to be sent in an operation with requested sub-
transactions to be completed. For example, a Context could have the transactions to be completed. For example, a Context could have the
Home Network Prefix absent but it is unclear if the Client would like 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. 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 Rather than creating a specific command for assigning the IP a bit
position in a COMMAND_SET is reserved for Agent based IP assignment. position in a COMMAND_SET is reserved for Agent based IP assignment.
Alternatively, an entity could be sent in an update operation that Alternatively, an entity could be sent in an update operation that
would be considered incomplete, e.g. missing some required data in would be considered incomplete, e.g. missing some required data in
for the entity, but has sufficient data to complete the instructions for the entity, but has sufficient data to complete the instructions
provided in the COMMAND_SET. provided in the COMMAND_SET.
6.1.1.5. Reference Scope 5.1.1.5. 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
CONFIG_BUNDLES. 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. This
implies only Contexts are present Ports MUST have references to implies only Contexts are present. Vports MUST have references to
Policy-Groups. 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-operaion references exist. intra-operation references exist.
o bundle - All references in exist in bundle (inter-operation/intra- o bundle - All references exist in bundle (inter-operation/intra-
bundle). NOTE - If this value comes in CONFIG call it is bundle). NOTE - If this value is present in a CONFIG message it
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 a 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 If supported by the Agent, when cloning instructions are present, the
scope MUST NOT be 'none'. When Ports are present the scope MUST be scope MUST NOT be 'none'. When Vports are present the scope MUST be
'storage' or 'unknown'. '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.
6.1.1.6. Operation Response 5.1.1.6. Operation Response
6.1.1.6.1. Immediate Response 5.1.1.6.1. Immediate Response
Results will be supplied per operation input. Each result contains Results will be supplied per operation input. Each result contains
the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS
values are: values are:
OK - SUCCESS OK - Success
ERR - An Error has occurred ERR - An Error has occurred
OK_NOTIFY_FOLLOWS - The Operation has been accepted by the Agent OK_NOTIFY_FOLLOWS - The Operation has been accepted by the Agent
but further processing is required. A CONFIG_RESULT_NOTIFY will but further processing is required. A CONFIG_RESULT_NOTIFY will
be sent once the processing has succeeded or failed. be sent once the processing has succeeded or failed.
Any result MAY contain nothing or a entities created or partially Any result MAY contain nothing or entities created or partially
fulfilled as part of the operation as specified in Table 14. For fulfilled as part of the operation as specified in Table 14. For
Clients that need attributes back quickly for call processing, the Clients that need attributes back quickly for call processing, the
AGENT MUST respond back with an OK_NOTIFY_FOLLOWS and minimally the AGENT MUST respond back with an OK_NOTIFY_FOLLOWS and minimally the
attributes assigned by the Agent in the response. These situations attributes assigned by the Agent in the response. These situations
MUST be determined through the use of Command Sets (see MUST be determined through the use of Command Sets (see
Section 6.1.1.4). Section 5.1.1.4).
If an error occurs the following information is returned. If an error occurs the following information is returned.
ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error
type type
ERROR_INFORMATION - An OPTIONAL string of no more than 1024 ERROR_INFORMATION - An OPTIONAL string of no more than 1024
characters. characters.
6.1.1.6.2. Asynchronous Notification 5.1.1.6.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 CONFIG_BUNDLES 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 15.
6.1.2. Monitors 5.1.2. Monitors
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 NOTIFY occurs. An Agent or DPN
may temporarily suspend monitoring if insufficient resources exist. may temporarily suspend monitoring if insufficient resources exist.
In such a case the Agent MUST notify the Client. In such a case the Agent MUST notify the Client.
All monitored data can be requested by the Client at any time using All monitored data can be requested by the Client at any time using
the PROBE message. Thus, reporting configuration is optional and the PROBE message. Thus, reporting configuration is optional and
when not present only PROBE messages may be used for monitoring. If when not present only PROBE messages may be used for monitoring. If
a SCHEDULED or PERIODIC configuration is provided during registration a SCHEDULED or PERIODIC configuration is provided during registration
skipping to change at page 32, line 13 skipping to change at page 32, line 13
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. An Agent may reject a registration if
it or the DPN has insufficient resources. 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.
6.1.2.1. Operation Response 5.1.2.1. Operation Response
6.1.2.1.1. Immediate Response 5.1.2.1.1. Immediate Response
Results will be supplied per operation input. Each result contains Results will be supplied per operation input. Each result contains
the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS
values are: values are:
OK - SUCCESS OK - Success
ERR - An Error has occurred ERR - An Error has occurred
Any OK result will contain no more information. Any OK result will contain no more information.
If an error occurs the following information is returned. If an error occurs the following information is returned.
ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error
type type
ERROR_INFORMATION - An OPTIONAL string of no more than 1024 ERROR_INFORMATION - An OPTIONAL string of no more than 1024
characters. characters.
6.1.2.1.2. Asynchronous Notification 5.1.2.1.2. Asynchronous Notification
A NOTIFY is sent as part of de-registraiton, a trigger based upon a A NOTIFY can be sent as part of de-registraiton, a trigger based upon
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.
6.2. Protocol Operation 5.2. Protocol Operation
6.2.1. Simple RPC Operation 5.2.1. Simple RPC Operation
An FPC Client and Agent MUST identify themselves using the CLI_ID and An FPC Client and Agent MUST identify themselves using the CLI_ID and
AGT_ID respectively to ensure that for all transactions a recipient AGT_ID respectively to ensure that for all transactions a recipient
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_ID and
ERROR_INFORMATION accordingly and MAY clear the Context or Port, ERROR_INFORMATION accordingly and MAY clear the Context or Vport,
which caused the failure, in the response. 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 an OK_NOTIFY_FOLLOWS with an optional RESPONSE_BODY containing
the partially completed entities. When an OK_NOTIFY_FOLLOWS is sent, the partially completed entities. When an OK_NOTIFY_FOLLOWS is sent,
the Agent will, upon completion or failure of the operation, respond the Agent will, upon completion or failure of the operation, respond
with an asynchronous CONFIG_RESULT_NOTIFY to the Client. 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
skipping to change at page 34, line 6 skipping to change at page 34, line 6
Figure 17 illustrates an exemplary session life-cycle based on Proxy Figure 17 illustrates an exemplary session life-cycle based on Proxy
Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1) Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1)
and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1 and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1
represents the Proxy CoA after attachment, whereas Edge DPN2 serves represents the Proxy CoA after attachment, whereas Edge DPN2 serves
as Proxy CoA after handover. As exemplary architecture, the FPC as Proxy CoA after handover. As exemplary architecture, the FPC
Agent and the network control function are assumed to be co-located Agent and the network control function are assumed to be co-located
with the Anchor-DPN, e.g. a Router. with the Anchor-DPN, e.g. a Router.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
+------+ +------+ +-----+ FPC | | FPC | | Anchor | +------+ +------+ +-----+ FPC | | FPC | | Anchor |
|MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN attach] | | | | [MN attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| | |---(1)--CONFIG(CREATE)--->| | | | |---(1)--CONFIG(CREATE)--->| |
| | | [ CONTEXT_ID, |--tun1 up->| | | | [ CONTEXT_ID, |--tun1 up->|
| | | DOWNLINK(QOS/TUN), | | | | | DOWNLINK(QOS/TUN), | |
| | | UPLINK(QOS/TUN), |--tc qos-->| | | | UPLINK(QOS/TUN), |--tc qos-->|
| | | IP_PREFIX(HNP) ] | | | | | 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------| [ CONTEXT_ID |-tun1 mod->|
| | | DOWNLINK(TUN), | | | | | DOWNLINK(TUN), | |
| | +----+ | UPLINK(TUN) ] | | | | +----+ | UPLINK(TUN) ] | |
| | |Edge| |<---(4)- OK --------------| | | | |Edge| |<---(4)- OK --------------| |
| | |DPN2| | | | | | |DPN2| | | |
| | +----+ | | | | | +----+ | | |
| | | | | | | | | | | |
| | |-============================================-| | | |-============================================-|
| | | | | | | | | |
Figure 17: Exemplary Message Sequence (focus on FPC reference point) Figure 17: Exemplary Message Sequence (focus on FPC reference point)
After reception of the Proxy Binding Update (PBU) at the LMA Control- After reception of the Proxy Binding Update (PBU) at the LMA Control-
Plane function (LMA_C), the LMA-C selects a suitable DPN, which Plane function (LMA-C), the LMA-C selects a suitable DPN, which
serves as Data-Plane anchor to the mobile node's (MN) traffic. The serves as Data-Plane anchor to the mobile node's (MN) traffic. The
LMA-C adds a new logical 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 CONFIGURE (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.
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 specify the forwarding tunnel type and
endpoints (Anchor DPN, Edge DPN1) in each direction (as required). endpoints (Anchor DPN, Edge DPN1) in each direction (as required).
Another property is added to specify the QoS differentiation, which Another property is added to specify the QoS differentiation, which
the MN's traffic should experience. At reception of the Context, the the MN's traffic should experience. At reception of the Context, the
FPC Agent utilizes local configuration commands to create the tunnel FPC Agent utilizes local configuration commands to create the tunnel
(tun1) as well as the traffic control (tc) to enable QoS (tun1) as well as the traffic control (tc) to enable QoS
differentiation. After configuration has been completed, the Agent differentiation. After configuration has been completed, the Agent
applies a new route to forward all traffic destined to the MN's HNP applies a new route to forward all traffic destined to the MN's HNP
specified as a property in the Context to the configured tunnel specified as a property in the Context to the configured tunnel
interface (tun1). 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 CONFIGURE 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 CONFIGURE 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 ->|
| | | 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 18: 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 CONFIGURE message (1) to lifetime value of zero. The LMA-C sends a CONFIG message (1) to the
the Agent to modify the existing tunnel property of the existing Agent to modify the existing tunnel property of the existing Context
Context to delete the tunnel information.) Upon reception of the to delete the tunnel information.) Upon reception of the CONFIG
CONFIGURE message, the Agent removes the tunnel configuration and message, the Agent removes the tunnel configuration and responds to
responds to the Client (2). Per [RFC5213], the PBA is sent back the Client (2). Per [RFC5213], the PBA is sent back immediately
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
CONFIGURE (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.
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
+------+ +------+ +-----+ 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->| | | | [ CONTEXT_ID, DPNS [ |--tun1 up->|
| | |[DPN1,DOWNLINK(QOS/TUN)], | | | | |[DPN1,DOWNLINK(QOS/TUN)], | |
| | | [DPN1,UPLINK(QOS/TUN)], |--tc qos-->| | | | [DPN1,UPLINK(QOS/TUN)], |--tc qos-->|
| | |[DPN2,DOWNLINK(QOS/TUN)], | | | | |[DPN2,DOWNLINK(QOS/TUN)], | |
| | | [DPN2,UPLINK(QOS/TUN)], | | | | | [DPN2,UPLINK(QOS/TUN)], | |
| | | IP_PREFIX(HNP) ] | | | | | 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 19: Exemplary Message Sequence for Multi-DPN Agent
Figure 19 shows how the first 2 messages in Figure 17 are supported Figure 19 shows how the first 2 messages in Figure 17 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 donwnlink 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 "DPNS" list of the same Context. Message 1
shows the DPNS list with all entries. Each entry identifies the DPN shows the DPNS list with all entries. Each entry identifies the DPN
and direction (one of 'uplink', 'downlink' or 'both'). Generally, and direction (one of 'uplink', 'downlink' or 'both'). Generally,
the 'both' direction is not used for normal mobility session the 'both' direction is not used for normal mobility session
processing. It is commonly used for the instantaition of Policies on processing. It is commonly used for the instantiation of Policies on
a specific DPN (see Section 6.2.4). 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_NOTIFY_FOLLOWS while it simultaneoulsy
provisions both DPNs. Upon successful completion, the Agent responds provisions both DPNs. Upon successful completion, the Agent responds
to the Client with a CONFIG_RESULT_NOTIFY indicating the operation to the Client with a CONFIG_RESULT_NOTIFY indicating the operation
status. status.
6.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 Ports and Contexts in a The Client may add, modify or delete many Vports and Contexts in a
single FPC message. This includes linking Contexts to Actions and single FPC message. This includes linking Contexts to Actions and
Descriptors, i.e. a Rule. As example, a Rule which performs re- Descriptors, i.e. a Rule. As example, a Rule which performs re-
writing of an arriving packet's destination IP address from IP_A to writing of an arriving packet's destination IP address from IP_A to
IP_B matching an associated Descriptor, can be enforced in the Data- IP_B matching an associated Descriptor, can be enforced in the Data-
Plane via an Agent to implicitly consider matching arriving packet's Plane via an Agent to implicitly consider matching arriving packet's
source IP address against IP_B and re- write the source IP address to source IP address against IP_B and re- write the source IP address to
IP_A. IP_A.
Figure 20 illustrates the generic policy configuration model as used Figure 20 illustrates the generic policy configuration model as used
between a FPC Client and a FPC Agent. between a FPC Client and a FPC Agent.
skipping to change at page 38, line 18 skipping to change at page 38, line 18
+------+ +------+
/Order#/-------------+ /Order#/-------------+
+------+ | +------+ |
| |
Descriptor_3 -+ +- Action_3 +-<PolicyID> Descriptor_3 -+ +- Action_3 +-<PolicyID>
| | | ^ | | | ^
Descriptor_4 -+--<Rule>--+- Action_4 | | Descriptor_4 -+--<Rule>--+- Action_4 | |
+------+ | <PolicyGroupID> +------+ | <PolicyGroupID>
/Order#/-------------+ ^ /Order#/-------------+ ^
+------+ | +------+ |
<PortID> <VportID>
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| 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, | | a Policy, | | to a Policy, |
| Policy-Group and | | Policy-Group and | | Policy-Group and | | Policy-Group and |
| Port | | Port | | Vport | | Vport |
+-------------------+ +---------------------+ +-------------------+ +---------------------+
| | | |
+-------------- Data-Plane Rule ------------------+ +-------------- Data-Plane Rule ------------------+
Figure 20: Structure of Policies and Ports Figure 20: Structure of Policies and Vports
As depicted in Figure 20, the Port represents the anchor of Rules As depicted in Figure 20, the Vport represents the anchor of Rules
through the Policy-group, Policy, Rule hierarchy configured by any through the Policy-group, Policy, Rule hierarchy configured by any
mechanism including RPC or N. A Client and Agent use the identifier mechanism including RPC or N. A Client and Agent use the identifier
of the associated Policy to directly access the Rule and perform of the associated Policy to directly access the Rule and perform
modifications of traffic Descriptors or Action references. A Client modifications of traffic Descriptors or Action references. A Client
and Agent use the identifiers to access the Descriptors or Actions to and Agent use the identifiers to access the Descriptors or Actions to
perform modifications. From the viewpoint of packet processing, perform modifications. From the viewpoint of packet processing,
arriving packets are matched against traffic Descriptors and arriving packets are matched against traffic Descriptors and
processed according to the treatment Actions specified in the list of processed according to the treatment Actions specified in the list of
properties associated with the Port. properties associated with the Vport.
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 21 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
| |
skipping to change at page 39, line 45 skipping to change at page 39, line 45
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 MAY be inherited by its
descendants. This permits concise over the wire representation. descendants. This permits concise over the wire representation.
When a Client deletes a parent Context all children are also deleted. When a Client deletes a parent Context all children are also deleted.
6.2.3. Optimization for Current and Subsequent Messages 5.2.3. Optimization for Current and Subsequent Messages
6.2.3.1. Bulk Data in a Single Operation 5.2.3.1. Bulk Data in a Single Operation
A single operation MAY contain multiple entities. This permits A single operation MAY contain multiple entities. This permits
bundling of requests into a single operation. In the example below bundling of requests into a single operation. In the example below
two PMIP sessions are created via two PBU messages and sent to the two PMIP sessions are created via two PBU messages and sent to the
Agent in a single CONFIGURE message (1). Upon recieveing the Agent in a single CONFIG message (1). Upon recieveing the message,
message, the Agent responds back with an OK_NOTIFY_FOLLOWS (2), the Agent responds back with an OK_NOTIFY_FOLLOWS (2), completes work
completes work on the DPN to activate the associated sessions then on the DPN to activate the associated sessions then responds to the
responds to the Client with a CONFIG_RESULT_NOTIFY (3). Client with a CONFIG_RESULT_NOTIFY (3).
+-------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 |
+------+ +------+ +-----+-------+ +-------+ +---------+ +------+ +------+ +-----+-------+ +-------+ +---------+
[MN1 attach] | | | | [MN1 attach] | | | |
|-------------PBU----->| | | |-------------PBU----->| | |
| [MN2 attach] | | | | [MN2 attach] | | |
| |---PBU----->| | | | |---PBU----->| | |
| | | | | | | | | |
| | |---(1)--CONFIG(CREATE)--->| | | | |---(1)--CONFIG(CREATE)--->| |
|<------------PBA------| [ CONTEXT_ID 1, |--tun1 up->| |<------------PBA------| [ CONTEXT_ID 1, |--tun1 up->|
| | | DOWNLINK(QOS/TUN), | | | | | DOWNLINK(QOS/TUN), | |
| |<--PBA------| UPLINK(QOS/TUN), |--tc1 qos->| | |<--PBA------| UPLINK(QOS/TUN), |--tc1 qos->|
| | | IP_PREFIX(HNP) ] | | | | | IP_PREFIX(HNP) ] | |
| | | [ CONTEXT_ID 2, |-route1 | | | | [ CONTEXT_ID 2, |-route1 |
| | | DOWNLINK(QOS/TUN), | add> | | | | DOWNLINK(QOS/TUN), | add> |
| | | UPLINK(QOS/TUN), | | | | | UPLINK(QOS/TUN), | |
| | | IP_PREFIX(HNP) ] |--tun2 up->| | | | IP_PREFIX(HNP) ] |--tun2 up->|
| | |<-(2)- OK_NOTIFY_FOLLOWS--| | | | |<-(2)- OK_NOTIFY_FOLLOWS--| |
| | | |--tc2 qos->| | | | |--tc2 qos->|
|<------------PBA------| | | |<------------PBA------| | |
| | | |-route2 | | | | |-route2 |
| | |<(3) CONFIG_RESULT_NOTIFY | add> | | | |<(3) CONFIG_RESULT_NOTIFY | add> |
| | | [ Response Data ] | | | | | [ Response Data ] | |
| | | | | | | | | |
| | | | | | | | | |
Figure 22: Exemplary Bulk Entity with Asynchronous Notification Figure 22: Exemplary Bulk Entity with Asynchronous Notification
Sequence (focus on FPC reference point) Sequence (focus on FPC reference point)
6.2.3.2. Configuration Bundles 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 CONFIGURE_BUNDLES is preservation of dependency advantage of the CONF_BUNDLE is preservation of dependency orders in
orders in a single message as opposed to sending multiple CONFIGURE a single message as opposed to sending multiple CONFIG messages and
messages and awaiting results from the Agent. awaiting results from the Agent.
When a CONFIGURE_BUNDLES fails, any entities provisioned in the When a CONF_BUNDLE fails, any entities provisioned in the CURRENT
CURRENT operation are removed, however, any successful operations operation are removed, however, any successful operations completed
completed prior to the current operation are preserved in order to prior to the current operation are preserved in order to reduce
reduce system load. system load.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor | | FPC | | FPC | | Anchor |
| Client | | Agent | | DPN | | Client | | Agent | | DPN |
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
| | | | | |
|-CONFIG_BUNDLES(CREATE)-->| | |--CONF_BUNDLE(CREATE)---->| |
| [ OP 1, [PORT X ] | | | [ OP 1, [VPORT X ] | |
| [ CONTEXT_ID 1, | | | [ CONTEXT_ID 1, | |
| DOWNLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN), | |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | |
| IP_PREFIX(HNP) ] | | | IP_PREFIX(HNP) ] | |
| [ OP 2, | | | [ OP 2, | |
| [ CONTEXT_ID 2, | | | [ CONTEXT_ID 2, | |
| PARENT_CONTEXT_ID 1, | | | PARENT_CONTEXT_ID 1, | |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ] ] | | | DOWNLINK(QOS/TUN) ] ] | |
| | | | | |
Figure 23: Exemplary Bundle Message (focus on FPC reference point) Figure 23: Exemplary Bundle Message (focus on FPC reference point)
6.2.3.3. Cloning Feature (Optional) 5.2.3.3. Cloning Feature (Optional)
Cloning provides a high speed copy/paste mechanism. The example Cloning provides a high speed copy/paste mechanism. The example
below shows a single Context that will be copied two times. A below shows a single Context that will be copied two times. A
subsequent update then overrides the value. The avoid the accidental subsequent update will then override copied values. To avoid the
activation of the Contexts on the DPN, the CONFIGURE (1) message with accidental activation of the Contexts on the DPN, the CONFIG (1)
the cloning instruction has a SESSION_STATE with a value of message with the cloning instruction has a SESSION_STATE with a value
'incomplete' and OP_TYPE of 'CREATE'. A second CONFIGURE (2) is sent 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 with the SESSION_STATE of 'complete' and OP_TYPE of 'UPDATE'. The
second message includes any differences between the original (copied) second message includes any differences between the original (copied)
Context and its Clones. Context and its Clones.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor | | FPC | | FPC | | Anchor |
| Client | | Agent | | DPN | | Client | | Agent | | DPN |
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
| | | | | |
|-CONFIG_BUNDLES(CREATE)-->| | |--CONF_BUNDLE(CREATE)---->| |
| [ OP 1, | | | [ OP 1, | |
| [ SESSION_STATE | | | [ SESSION_STATE | |
| (incomplete) ], | | | (incomplete) ], | |
| [CLONE SRC=2, TARGET=3], | | | [CLONE SRC=2, TARGET=3], | |
| [CLONE SRC=2, TARGET=4], | | | [CLONE SRC=2, TARGET=4], | |
| [ CONTEXT_ID 2, | | | [ CONTEXT_ID 2, | |
| PARENT_CONTEXT_ID 1, | | | PARENT_CONTEXT_ID 1, | |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN), | |
| IP_PREFIX(HNP) ] ] | | | IP_PREFIX(HNP) ] ] | |
|<----- OK ----------------| | |<----- OK ----------------| |
| | | | | |
|-CONFIG_BUNDLES(UPDATE)-->| | |--CONF_BUNDLE(UPDATE)--->| |
| [ CONTEXT_ID 3, | | | [ CONTEXT_ID 3, | |
| PARENT_CONTEXT_ID(empty),| | | PARENT_CONTEXT_ID(empty),| |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ], | | | DOWNLINK(QOS/TUN) ], | |
| [ CONTEXT_ID 4, | | | [ CONTEXT_ID 4, | |
| PARENT_CONTEXT_ID(empty),| | | PARENT_CONTEXT_ID(empty),| |
| UPLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | |
| DOWNLINK(QOS/TUN) ] ] | | | DOWNLINK(QOS/TUN) ] ] | |
|<----- OK ----------------| | |<----- OK ----------------| |
| | | | | |
Figure 24: Exemplary Bundle Message (focus on FPC reference point) Figure 24: Exemplary Bundle Message (focus on FPC reference point)
Cloning has the added advantage of reducing the over the wire data Cloning has the added advantage of reducing the over the wire data
size required to create multiple entities. This can improve size required to create multiple entities. This can improve
performance if serialization / deserialization of multiple entities performance if serialization / deserialization of multiple entities
incurs some form of performance penalty. incurs some form of performance penalty.
6.2.3.4. Command Bitsets (Optional) 5.2.3.4. 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. CONTEXT, and specify which activities are expected
to be performed on the DPN. This has some advantages 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
skipping to change at page 43, line 32 skipping to change at page 43, line 32
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.
6.2.3.5. Reference Scope(Optional) 5.2.3.5. 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 Ports or Contexts, the Reference type, e.g. Contexts can refer to Vports or Contexts, the Reference
Scope gives the Agent an idea of where those references reside. They Scope gives the Agent an idea of where those references reside. They
may be in the same operation, an operation in the same CONFIG_BUNDLES may be in the same operation, an operation in the same CONF_BUNDLE
message or in storage. There may also be no references. This message or in storage. There may also be no references. This
permits the Agent to understand when it can stop searching for permits the Agent to understand when it can stop searching for
reference it cannot find. For example, if a CONFIG_BUNDLES message reference it cannot find. For example, if a CONF_BUNDLE message uses
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 CONFIG_BUNDLES 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 cache where each Cache where a increases. Figure 25 shows an example containment hierarchy provided
containment hierarchy is provided for all caches. for all caches.
+---------------+ +---------------+
| Global Cache | | Global Cache |
| (storage) | | (storage) |
+------+--------+ +------+--------+
| |
+----------------------+ +----------------------+
| | | |
+------+--------+ +------+--------+ +------+--------+ +------+--------+
| Bundle Cache | | Bundle Cache | | Bundle Cache | | Bundle Cache |
skipping to change at page 44, line 32 skipping to change at page 44, line 32
| | | | | |
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
| 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 25: Exemplary Hierarchical Cache
6.2.4. Pre-provisioning 5.2.4. Pre-provisioning
Although Contexts are used for Session based lifecycle elements, Although Contexts are used for Session based lifecycle elements,
Ports may exist outside of a specific lifecycle and represent more Vports may exist outside of a specific lifecycle and represent more
general policies that may affect multiple Contexts (sessions). The general policies that may affect multiple Contexts (sessions). The
use of pre-provisioning of Ports permits policy and administrative use of pre-provisioning of Vports permits policy and administrative
use cases to be executed. For example, creating tunnels to forward use cases to be executed. For example, creating tunnels to forward
traffic to a trouble management platform and dropping packets to a traffic to a trouble management platform and dropping packets to a
defective web server can be accomplished via provisioning of Ports. defective web server can be accomplished via provisioning of Vports.
The figure below shows a CONFIGURE (1) message used to install a The figure below shows a CONFIG (1) message used to install a Policy-
Policy-group, policy-group1, using a Context set aside for pre- group, policy-group1, using a Context set aside for pre-provisioning
provisioning on a DPN. on a DPN.
+-------Router--------+ +-------Router--------+
+-----------+ |+-------+ +---------+| +-----------+ |+-------+ +---------+|
| FPC | | FPC | | Anchor | | FPC | | FPC | | Anchor |
| Client | | Agent | | DPN | | Client | | Agent | | DPN |
+-----------+ +-------+ +---------+ +-----------+ +-------+ +---------+
| | | | | |
|------CONFIG(CREATE)----->| | |------CONFIG(CREATE)----->| |
| [ PORT_ID port1, | | | [ VPORT_ID port1, | |
| [ policy-group1 ] ] | | | [ policy-group1 ] ] | |
| [ CONTEXT_ID preprov, | | | [ CONTEXT_ID preprov, | |
| DPN_ID X, | | | DPN_ID X, | |
| [ port1 ] ] | | | [ port1 ] ] | |
| | | | | |
Figure 26: Exemplary Config Message for policy pre-provisioning Figure 26: Exemplary Config Message for policy pre-provisioning
6.2.4.1. Basename Registry Feature (Optional) 5.2.4.1. 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.
7. Protocol Message Details 6. Protocol Message Details
7.1. Data Structures And Type Assignment 6.1. Data Structures And Type Assignment
7.1.1. Policy Structures 6.1.1. Policy Structures
+--------------+-----------------+----------------------------+ +--------------+-----------------+----------------------------+
| Structure | Field | Type | | Structure | Field | Type |
+--------------+-----------------+----------------------------+ +--------------+-----------------+----------------------------+
| ACTION | ACTION_ID | FPC-Identity (Section 5.4) | | ACTION | ACTION_ID | FPC-Identity (Section 4.4) |
| | | | | | | |
| ACTION | TYPE | [32, unsigned integer] | | ACTION | TYPE | [32, unsigned integer] |
| | | | | | | |
| ACTION | VALUE | Type specific | | ACTION | VALUE | Type specific |
| | | | | | | |
| DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 5.4) | | DESCRIPTOR | DESCRIPTOR_ID | FPC-Identity (Section 4.4) |
| | | | | | | |
| DESCRIPTOR | TYPE | [32, unsigned integer] | | DESCRIPTOR | TYPE | [32, unsigned integer] |
| | | | | | | |
| DESCRIPTOR | VALUE | Type specific | | DESCRIPTOR | VALUE | Type specific |
| | | | | | | |
| POLICY | POLICY_ID | FPC-Identity (Section 5.4) | | POLICY | POLICY_ID | FPC-Identity (Section 4.4) |
| | | | | | | |
| POLICY | RULES | *[ RULE ] (See Table 4) | | POLICY | RULES | *[ RULE ] (See Table 4) |
| | | | | | | |
| POLICY-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 5.4) | | POLICY-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 4.4) |
| | | | | | | |
| POLICY-GROUP | POLICIES | *[ POLICY_ID ] | | 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.
skipping to change at page 46, line 46 skipping to change at page 46, line 46
+------------------+---------------+--------------------------------+ +------------------+---------------+--------------------------------+
| Field | Type | Sub-Fields | | Field | Type | Sub-Fields |
+------------------+---------------+--------------------------------+ +------------------+---------------+--------------------------------+
| ORDER | [16, INTEGER] | | | ORDER | [16, INTEGER] | |
| | | | | | | |
| RULE_DESCRIPTORS | *[ | DIRECTION [2, unsigned bits] | | RULE_DESCRIPTORS | *[ | DIRECTION [2, unsigned bits] |
| | DESCRIPTOR_ID | is an ENUMERATION (uplink, | | | DESCRIPTOR_ID | is an ENUMERATION (uplink, |
| | DIRECTION ] | downlink or both). | | | DIRECTION ] | downlink or both). |
| | | | | | | |
| RULE_ACTIONS | *[ ACTION_ID | ORDER [8, unsigned integer] | | RULE_ACTIONS | *[ ACTION_ID | ACTION-ORDER [8, unsigned |
| | ORDER ] | specifies action execution | | | ACTION-ORDER | integer] specifies action |
| | | order. | | | ] | execution order. |
+------------------+---------------+--------------------------------+ +------------------+---------------+--------------------------------+
Table 4: Rule Fields Table 4: Rule Fields
7.1.2. Mobilty Structures 6.1.2. Mobility Structures
+----------+----------------------------+ +----------+----------------------------+
| Field | Type | | Field | Type |
+----------+----------------------------+ +----------+----------------------------+
| PORT_ID | FPC-Identity (Section 5.4) | | VPORT_ID | FPC-Identity (Section 4.4) |
| | | | | |
| POLICIES | *[ POLICY_GROUP_ID ] | | POLICIES | *[ POLICY_GROUP_ID ] |
+----------+----------------------------+ +----------+----------------------------+
Table 5: Port Fields Table 5: Vport Fields
+------------------------+------------------------------------+ +-----------------------+--------------------------------------+
| Field | Type | | Field | Type |
+------------------------+------------------------------------+ +-----------------------+--------------------------------------+
| CONTEXT_ID | FPC-Identity (Section 5.4) | | CONTEXT_ID | FPC-Identity (Section 4.4) |
| | | | | |
| PORTS | *[ PORT_ID ] | | VPORTS | *[ VPORT_ID ] |
| | | | | |
| DPN_GROUP_ID | FPC-Identity (Section 5.4) | | DPN_GROUP_ID | FPC-Identity (Section 4.4) |
| | | | | |
| DELEGATING IP PREFIXES | *[ IP_PREFIX ] | | DELEGATED IP PREFIXES | *[ IP_PREFIX ] |
| | | | | |
| PARENT_CONTEXT_ID | FPC-Identity (Section 5.4) | | PARENT_CONTEXT_ID | FPC-Identity (Section 4.4) |
| | | | | |
| UPLINK [NOTE 1] | MOB_FIELDS | | UPLINK [NOTE 1] | MOB_FIELDS |
| | | | | |
| DOWNLINK [NOTE 1] | MOB_FIELDS | | DOWNLINK [NOTE 1] | MOB_FIELDS |
| | | | | |
| DPNS [NOTE 2] | *[ DPN_ID DPN_DIRECTION MOB_FIELDS | | DPNS [NOTE 2] | *[ DPN_ID DPN_DIRECTION MOB_FIELDS ] |
| | | | | |
| MOB_FIELDS | All parameters from Table 7 | | MOB_FIELDS | All parameters from Table 7 |
+------------------------+------------------------------------+ +-----------------------+--------------------------------------+
Table 6: Context Fields Table 6: Context Fields
NOTE 1 - These fields are present when the Agent supports only a NOTE 1 - These fields are present when the Agent supports only a
single DPN. single DPN.
NOTE 2 - This fields is present when the Agent supports multiple NOTE 2 - This field is present when the Agent supports multiple DPNs.
DPNs.
+---------------------------+---------------------+-----------------+ +---------------------------+---------------------+-----------------+
| Field | Type | Detail | | Field | Type | Detail |
+---------------------------+---------------------+-----------------+ +---------------------------+---------------------+-----------------+
| TUN_LOCAL_ADDRESS | IP Address | [NOTE 1] | | TUN_LOCAL_ADDRESS | IP Address | [NOTE 1] |
| | | | | | | |
| TUN_REMOTE_ADDRESS | IP Address | [NOTE 1] | | TUN_REMOTE_ADDRESS | IP Address | [NOTE 1] |
| | | | | | | |
| TUN_MTU | [32, unsigned | | | TUN_MTU | [32, unsigned | |
| | integer] | | | | integer] | |
skipping to change at page 49, line 7 skipping to change at page 49, line 7
| | | | | | | |
| VENDOR_SPECIFIC_PARAM | *[ Varies ] | [NOTE 1] | | VENDOR_SPECIFIC_PARAM | *[ Varies ] | [NOTE 1] |
+---------------------------+---------------------+-----------------+ +---------------------------+---------------------+-----------------+
NOTE 1 - These parameters are extensible. The Types may be extended NOTE 1 - These parameters are extensible. The Types may be extended
for Field value by future specifications or in the case of Vendor for Field value by future specifications or in the case of Vendor
Specific Attributes by enterprises. Specific Attributes by enterprises.
Table 7: Context Downlink/Uplink Field Definitions Table 7: Context Downlink/Uplink Field Definitions
7.1.3. Topology Structures 6.1.3. Topology Structures
+----------------+------------------------------------+ +----------------+------------------------------------+
| Field | Type | | Field | Type |
+----------------+------------------------------------+ +----------------+------------------------------------+
| DPN_ID | FPC-Identity. See Section 5.4 | | DPN_ID | FPC-Identity. See Section 4.4 |
| | | | | |
| DPN_NAME | [1024, OCTET STRING] | | DPN_NAME | [1024, OCTET STRING] |
| | | | | |
| DPN_GROUPS | * [ FPC-Identity ] See Section 5.4 | | DPN_GROUPS | * [ FPC-Identity ] See Section 4.4 |
| | | | | |
| NODE_REFERENCE | [1024, OCTET STRING] | | NODE_REFERENCE | [1024, OCTET STRING] |
+----------------+------------------------------------+ +----------------+------------------------------------+
Table 8: DPN Fields Table 8: DPN Fields
+-------------+----------------------+ +------------------+----------------------+
| Field | Type | | Field | Type |
+-------------+----------------------+ +------------------+----------------------+
| DOMAIN_ID | [1024, OCTET STRING] | | DOMAIN_ID | [1024, OCTET STRING] |
| | | | | |
| DOMAIN_NAME | [1024, OCTET STRING] | | DOMAIN_NAME | [1024, OCTET STRING] |
| | | | | |
| DOMAIN_TYPE | [1024, OCTET STRING] | | DOMAIN_TYPE | [1024, OCTET STRING] |
+-------------+----------------------+ | | |
| DOMAIN_REFERENCE | [1024, OCTET STRING] |
+------------------+----------------------+
Table 9: Domain Fields Table 9: Domain Fields
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Field | Type | | Field | Type |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| DPN_GROUP_ID | FPC-Identity. See Section 5.4 | | DPN_GROUP_ID | FPC-Identity. See Section 4.4 |
| | | | | |
| DATA_PLANE_ROLE | [4, ENUMERATION (data-plane, such as access- | | DATA_PLANE_ROLE | [4, ENUMERATION (data-plane, such as access- |
| | dpn, L2/L3 anchor-dpn.)] | | | dpn, L2/L3 anchor-dpn.)] |
| | | | | |
| ACCESS_TYPE | [4, ENUMERATION ()ethernet(802.3/11), 3gpp | | ACCESS_TYPE | [4, ENUMERATION ()ethernet(802.3/11), 3gpp |
| | cellular(S1,RAB)] | | | cellular(S1,RAB)] |
| | | | | |
| MOBILITY_PROFILE | [4, ENUMERATION (ietf-pmip, 3gpp, or new | | MOBILITY_PROFILE | [4, ENUMERATION (ietf-pmip, 3gpp, or new |
| | profile)] | | | profile)] |
| | | | | |
| PEER_DPN_GROUPS | * [ DPN_GROUP_ID MOBILITY_PROFILE | | PEER_DPN_GROUPS | * [ DPN_GROUP_ID MOBILITY_PROFILE |
| | REMOTE_ENDPOINT_ADDRESS LOCAL_ENDPOINT_ADDRESS | | | REMOTE_ENDPOINT_ADDRESS LOCAL_ENDPOINT_ADDRESS |
| | TUN_MTU DATA_PLANE_ROLE ] | | | TUN_MTU DATA_PLANE_ROLE ] |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 10: DPN Groups Fields Table 10: DPN Groups Fields
7.1.4. Monitors 6.1.4. Monitors
+------------------+----------------------+-------------------------+ +------------------+----------------------+-------------------------+
| Field | Type | Description | | Field | Type | Description |
+------------------+----------------------+-------------------------+ +------------------+----------------------+-------------------------+
| MONITOR | MONITOR_ID TARGET | | | MONITOR | MONITOR_ID TARGET | |
| | [REPORT_CONFIG] | | | | [REPORT_CONFIG] | |
| | | | | | | |
| MONITOR_ID | FPC-Identity. See | | | MONITOR_ID | FPC-Identity. See | |
| | Section 5.4 | | | | Section 4.4 | |
| | | | | | | |
| EVENT_TYPE_ID | [8, Event Type ID] | Event Type (unsigned | | EVENT_TYPE_ID | [8, Event Type ID] | Event Type (unsigned |
| | | integer). | | | | integer). |
| | | | | | | |
| TARGET | OCTET STRING (See | | | TARGET | OCTET STRING (See | |
| | Section 5.3.3) | | | | Section 4.3.3) | |
| | | | | | | |
| REPORT_CONFIG | [8, REPORT-TYPE] | | | REPORT_CONFIG | [8, REPORT-TYPE] | |
| | [TYPE_SPECIFIC_INFO] | | | | [TYPE_SPECIFIC_INFO] | |
| | | | | | | |
| PERIODIC_CONFIG | [32, period] | report interval (ms). | | PERIODIC_CONFIG | [32, period] | report interval (ms). |
| | | | | | | |
| THRESHOLD_CONFIG | [32, low] [32, hi] | thresholds (at least | | THRESHOLD_CONFIG | [32, low] [32, hi] | thresholds (at least |
| | | one value must be | | | | one value must be |
| | | present) | | | | present) |
| | | | | | | |
skipping to change at page 52, line 5 skipping to change at page 52, line 5
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
7.2. Message Attributes 6.2. Message Attributes
7.2.1. Header 6.2.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 (Section | All |
| | 5.4) | | | | 4.4) | |
| | | | | | | |
| DELAY | [32, unsigned integer] | All | | DELAY | [32, unsigned integer] | All |
| | | | | | | |
| OP_ID | [64, unsigned integer] | All | | OP_ID | [64, unsigned integer] | All |
| | | | | | | |
| ADMIN_STATE | [8, admin state] | CONF, CONF_BUNDLES and | | ADMIN_STATE | [8, admin state] | CONFIG, CONF_BUNDLE and |
| | | REG_MONITOR | | | | REG_MONITOR |
| | | | | | | |
| OP_TYPE | [8, op type] | CONF and CONF_BUNDLES | | OP_TYPE | [8, op type] | CONFIG and CONF_BUNDLE |
+-------------+------------------------+----------------------------+ +-------------+------------------------+----------------------------+
Table 12: Message Header Fields Table 12: Message Header Fields
7.2.2. CONF and CONF_BUNDLES Attributes and Notifications 6.2.2. CONFIG and CONF_BUNDLE Attributes and Notifications
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
| Field | Type | Operation Types Create(C), | | Field | Type | Operation Types Create(C), |
| | | Update(U), Query(Q) and | | | | Update(U), Query(Q) and |
| | | Delete(D) | | | | Delete(D) |
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
| SESSION_STATE | [8, session state] | C,U | | SESSION_STATE | [8, session state] | C,U |
| | | | | | | |
| COMMAND_SET | FPC Command Bitset. | C,U [NOTE 1] | | COMMAND_SET | FPC Command Bitset. | C,U [NOTE 1] |
| | See Section 6.1.1.4. | | | | See Section 5.1.1.4. | |
| | | | | | | |
| CLONES | *[ FPC-Identity FPC- | C,U [NOTE 1] | | CLONES | *[ FPC-Identity FPC- | C,U [NOTE 1] |
| | Identity ] (Section | | | | Identity ] (Section | |
| | 5.4) | | | | 4.4) | |
| | | | | | | |
| PORTS | *[ PORT ] | C,U | | VPORTS | *[ VPORT ] | C,U |
| | | | | | | |
| CONTEXTS | *[ CONTEXT [ | C,U | | CONTEXTS | *[ CONTEXT [ | C,U |
| | COMMAND_SET [NOTE 1] | | | | COMMAND_SET [NOTE 1] | |
| | ] ] | | | | ] ] | |
| | | | | | | |
| TARGETS | FPC-Identity | Q,D | | TARGETS | FPC-Identity | Q,D |
| | (Section 5.4) | | | | (Section 4.4) | |
| | *[DPN_ID] | | | | *[DPN_ID] | |
| | | | | | | |
| POLICY_GROUPS | *[ POLICY-GROUP ] | C,U [NOTE 1] | | POLICY_GROUPS | *[ POLICY-GROUP ] | C,U [NOTE 1] |
| | | | | | | |
| POLICIES | *[ POLICY ] | C,U [NOTE 1] | | POLICIES | *[ POLICY ] | C,U [NOTE 1] |
| | | | | | | |
| DESCRIPTORS | *[ DESCRIPTOR ] | C,U [NOTE 1] | | DESCRIPTORS | *[ DESCRIPTOR ] | C,U [NOTE 1] |
| | | | | | | |
| ACTIONS | *[ ACTION ] | C,U [NOTE 1] | | ACTIONS | *[ ACTION ] | C,U [NOTE 1] |
+---------------+----------------------+----------------------------+ +---------------+----------------------+----------------------------+
NOTE 1 - Only present if the corresponding feature is supported by NOTE 1 - Only present if the corresponding feature is supported by
the Agent. the Agent.
Table 13: CONF and CONF_BUNDLES OP_BODY Fields Table 13: 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) |
+-------------------+--------------------+--------------------------+ +-------------------+--------------------+--------------------------+
| PORTS | *[ PORT ] | C,U [NOTE 2] | | VPORTS | *[ VPORT ] | C,U [NOTE 2] |
| | | | | | | |
| CONTEXTS | *[ CONTEXT [ | C,U [NOTE 2] | | CONTEXTS | *[ CONTEXT [ | C,U [NOTE 2] |
| | COMMAND_SET [NOTE | | | | COMMAND_SET [NOTE | |
| | 1] ] ] | | | | 1] ] ] | |
| | | | | | | |
| TARGETS | *[ FPC-Identity | Q,D [NOTE 2] | | TARGETS | *[ FPC-Identity | Q,D [NOTE 2] |
| | (Section 5.4) | | | | (Section 4.4) | |
| | *[DPN_ID] ] | | | | *[DPN_ID] ] | |
| | | | | | | |
| ERROR_TYPE_ID | [32, unsigned | All [NOTE 3] | | ERROR_TYPE_ID | [32, unsigned | All [NOTE 3] |
| | integer] | | | | integer] | |
| | | | | | | |
| ERROR_INFORMATION | [1024, octet | All [NOTE 3] | | ERROR_INFORMATION | [1024, octet | All [NOTE 3] |
| | string] | | | | string] | |
+-------------------+--------------------+--------------------------+ +-------------------+--------------------+--------------------------+
Table 14: Immediate Response RESPONSE_BODY Fields Table 14: Immediate Response RESPONSE_BODY Fields
Notes: Notes:
NOTE 1 - Only present if the corresponding feature is supported by NOTE 1 - Only present if the corresponding feature is supported by
the Agent. the Agent.
NOTE 2 - Present in OK and OK_NOTIFY_FOLLOWS for both CONF and NOTE 2 - Present in OK and OK_NOTIFY_FOLLOWS for both CONFIG and
CONF_BUNDLES. MAY also be present in an CONF_BUNDLES Error CONF_BUNDLE. MAY also be present in an CONF_BUNDLE Error response
response (ERR) if one of the operations completed successfully. (ERR) if one of the operations completed successfully.
NOTE 3 - Present only for Error (ERR) responses. NOTE 3 - Present only for Error (ERR) responses.
+-----------------+--------------------+----------------------------+ +-----------------+--------------------+----------------------------+
| Field | Type | Description | | Field | Type | Description |
+-----------------+--------------------+----------------------------+ +-----------------+--------------------+----------------------------+
| AGENT_ID | FPC-Identity | | | AGENT_ID | FPC-Identity | |
| | (Section 5.4) | | | | (Section 4.4) | |
| | | | | | | |
| NOTIFICATION_ID | [32, unsigned | A Notification Identifier | | NOTIFICATION_ID | [32, unsigned | A Notification Identifier |
| | integer] | used to determine | | | integer] | used to determine |
| | | notification order. | | | | notification order. |
| | | | | | | |
| TIMESTAMP | [32, unsigned | The time that the | | TIMESTAMP | [32, unsigned | The time that the |
| | integer] | notification occurred. | | | integer] | notification occurred. |
| | | | | | | |
| DATA | *[ OP_ID | | | DATA | *[ OP_ID | |
| | RESPONSE_BODY | | | | RESPONSE_BODY | |
| | (Table 14) ] | | | | (Table 14) ] | |
+-----------------+--------------------+----------------------------+ +-----------------+--------------------+----------------------------+
Table 15: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields Table 15: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields
7.2.3. Monitors 6.2.3. Monitors
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
| Field | Type | Description | | Field | Type | Description |
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
| NOTIFICATION_ID | [32, unsiged | | | NOTIFICATION_ID | [32, unsiged | |
| | integer] | | | | integer] | |
| | | | | | | |
| TRIGGER | [32, unsigned | | | TRIGGER | [32, unsigned | |
| | integer] | | | | integer] | |
| | | | | | | |
| NOTIFY | NOTIFICATION_ID | Timestamp notes when the | | NOTIFY | NOTIFICATION_ID | Timestamp notes when the |
| | MONITOR_ID TRIGGER | event occurred. | | | MONITOR_ID TRIGGER | event occurred. |
| | [32, timestamp] | Notification Data is | | | [32, timestamp] | Notification Data is |
| | [NOTIFICATION_DATA] | TRIGGER and Monitor type | | | [NOTIFICATION_DATA] | TRIGGER and Monitor type |
| | | specific. | | | | specific. |
+-----------------+---------------------+---------------------------+ +-----------------+---------------------+---------------------------+
Table 16: Monitor Notifications Table 16: Monitor Notifications
8. Derived and Subtyped Attributes 7. Derived and Subtyped Attributes
This section notes derived attributes. This section notes derived attributes.
+------------------+-------+---------------+------------------------+ +------------------+-------+---------------+------------------------+
| Field | Type | Type | Description | | Field | Type | Type | Description |
| | Value | | | | | Value | | |
+------------------+-------+---------------+------------------------+ +------------------+-------+---------------+------------------------+
| TO_PREFIX | 0 | [IP Address] | Aggregated or per-host | | TO_PREFIX | 0 | [IP Address] | Aggregated or per-host |
| | | [ Prefix Len | destination IP | | | | [ Prefix Len | destination IP |
| | | ] | address/prefix | | | | ] | address/prefix |
skipping to change at page 56, line 43 skipping to change at page 56, line 43
| REWRITE | 1 | [in_src_ip] | Rewrite IP Address | | REWRITE | 1 | [in_src_ip] | Rewrite IP Address |
| | | [out_src_ip] | (NAT) or IP Address | | | | [out_src_ip] | (NAT) or IP Address |
| | | [in_dst_ip] | / Port (NAPT). | | | | [in_dst_ip] | / Port (NAPT). |
| | | [out_dst_ip] | | | | | [out_dst_ip] | |
| | | [in_src_port] | | | | | [in_src_port] | |
| | | [out_src_port] | | | | | [out_src_port] | |
| | | [in_dst_port] | | | | | [in_dst_port] | |
| | | [out_dst_port] | | | | | [out_dst_port] | |
| | | | | | | | | |
| COPY_FORWARD | 2 | FPC-Identity. See | Copy all packets and | | COPY_FORWARD | 2 | FPC-Identity. See | Copy all packets and |
| | | Section 5.4. | forward them to the | | | | Section 4.4. | forward them to the |
| | | | provided identity. | | | | | provided identity. |
| | | | The value of the | | | | | The value of the |
| | | | identity MUST be a | | | | | identity MUST be a |
| | | | port or context. | | | | | port or context. |
+--------------+-------+---------------------+----------------------+ +--------------+-------+---------------------+----------------------+
Table 18: Action Subtypes Table 18: Action Subtypes
+-----------------+-------+-------------------+---------------------+ +-----------------+-------+-------------------+---------------------+
| Field | Type | Type | Description | | Field | Type | Type | Description |
skipping to change at page 57, line 26 skipping to change at page 57, line 26
| MPLS_LABEL | 3 | [20, unsigned | MPLS Label | | MPLS_LABEL | 3 | [20, unsigned | MPLS Label |
| | | integer] | | | | | integer] | |
| | | | | | | | | |
| NSH | 4 | [SERVICE_PATH_ID] | Included NSH which | | NSH | 4 | [SERVICE_PATH_ID] | Included NSH which |
| | | [8, unsigned | is a SPI and | | | | [8, unsigned | is a SPI and |
| | | integer] | Service Index (8 | | | | integer] | Service Index (8 |
| | | | bits). | | | | | bits). |
| | | | | | | | | |
| INTERFACE_INDEX | 5 | [16, unsigned | Interface Index (an | | INTERFACE_INDEX | 5 | [16, unsigned | Interface Index (an |
| | | integer] | unsigned integer). | | | | integer] | unsigned integer). |
| | | | |
| SEGMENT_ID | 5 | [128, unsigned | Segement |
| | | integer] | Identifier. |
+-----------------+-------+-------------------+---------------------+ +-----------------+-------+-------------------+---------------------+
Table 19: Next Hop Subtypes Table 19: 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 |
skipping to change at page 58, line 31 skipping to change at page 58, line 31
o assign-ip - Assign the IP Address for the mobile session. o assign-ip - Assign the IP Address for the mobile session.
o assign-dpn - Assign the Dataplane Node. o assign-dpn - Assign the Dataplane Node.
o session - Assign values for the Session Level. o session - Assign values for the Session Level.
o uplink - Command applies to uplink. o uplink - Command applies to uplink.
o downlink - Command applies to downlink. o downlink - Command applies to downlink.
8.1. 3GPP Specific Extenstions 7.1. 3GPP Specific Extenstions
3GPP support is optional and detailed in this section. The following 3GPP support is optional and detailed in this section. The following
acronyms are used: acronyms are used:
APN-AMBR: Access Point Name Aggregate Maximum Bit Rate APN-AMBR: Access Point Name Aggregate Maximum Bit Rate
ARP: Allocation of Retention Priority ARP: Allocation of Retention Priority
EBI: EPS Bearer Identity EBI: EPS Bearer Identity
skipping to change at page 60, line 25 skipping to change at page 60, line 25
TEID. TEID.
o session - Assign values for the Session Level. When this involves o session - Assign values for the Session Level. When this involves
'assign-fteid-ip' and 'assign-fteid-teid' this implies the values 'assign-fteid-ip' and 'assign-fteid-teid' 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.
9. Implementation Status 8. Implementation Status
Two FPC Agent implementations have been made to date. The first was Two FPC Agent implementations have been made to date. The first was
based upon Version 03 of the draft and followed Model 1. The second based upon Version 03 of the draft and followed Model 1. The second
follows Version 04 of the document. Both implementations were 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'.
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
skipping to change at page 61, line 8 skipping to change at page 61, line 8
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 intended for open source Fpc is also an OpenDaylight project but is being prepared for open
release, if circumstances permit. It is also scoped to be a fully source release as the Opendaylight FpcAgent plugin
compliant FPC Agent that supports multiple DPNs including those that (https://wiki.opendaylight.org/view/Project_Proposals:FpcAgent).
communicate via OpenFlow. The following features present in this This project is scoped to be a fully compliant FPC Agent that
draft and others developed by the FPC development team have already supports multiple DPNs including those that communicate via OpenFlow.
lead to an order of magnitude improvement. The following features present in this draft and others developed by
the FPC development team have already lead to an order of magnitude
improvement.
Migration of non-realtime provisioning of entities such as Migration of non-realtime provisioning of entities such as
topology and policy allowed the implementation to focus only on topology and policy allowed the implementation to focus only on
the rpc. the rpc.
Using only 5 messages and 2 notifications has also reduced Using only 5 messages and 2 notifications has also reduced
implementation time. implementation time.
Command Sets, an optional feature in this specification, have Command Sets, an optional feature in this specification, have
eliminated 80% of the time spent determining what needs to be eliminated 80% of the time spent determining what needs to be
skipping to change at page 61, line 39 skipping to change at page 61, line 41
effectively act as a FPC protocol adapter remotely with multi-DPN effectively act as a FPC protocol adapter remotely with multi-DPN
support or colocated on the DPN in a single-DPN support model. support or colocated on the DPN in a single-DPN support model.
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 CONFIGURE_BUNDLES to be implemented as a simple CONFIGURE and CONF_BUNDLE to be implemented as a simple nested
nested FOR loops (see below). FOR loops (see below).
Current performance results without code optimizations or tuning Current 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.
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
CONFIGURE and CONFIGURE_BUNDLES (all CONFIG and CONF_BUNDLE (all operations)
operations)
DPN assignment, Tunnel allocations and IPv4 DPN assignment, Tunnel allocations and IPv4
address assignment by the Agent or Client. address assignment by the Agent or Client.
Immediate Response is always an Immediate Response is always an
OK_NOTIFY_FOLLOWS. OK_NOTIFY_FOLLOWS.
assignment system (receives rpc call): assignment system (receives rpc call):
perform basic operation integrity check perform basic operation integrity check
if CONFIGURE then if CONFIG then
goto assignments goto assignments
if assignments was ok then if assignments was ok then
send request to activation system send request to activation system
respond back to client with assignment data respond back to client with assignment data
else else
send back error send back error
end if end if
else if CONFIGURE_BUNDLES then else if CONF_BUNDLE then
for each operation in bundles for each operation in bundles
goto assignments goto assignments
if assignments was ok then if assignments was ok then
hold onto data hold onto data
else else
return error with the assignments that occurred in return error with the assignments that occurred in
prior operations (best effort) prior operations (best effort)
end if end if
end for end for
send bundles to activation systems send bundles to activation systems
end if end if
assignments: assignments:
assign DPN, IPv4 Address and/or tunnel info as required assign DPN, IPv4 Address and/or tunnel info as required
if an error occurs undo all assignments in this operation if an error occurs undo all assignments in this operation
return result return result
activation system: activation system:
build cache according to op-ref and operation type build cache according to op-ref and operation type
for each operation for each operation
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 (CONFIG_RESULT_NOTIFY) log transaction for tracking and notification
(CONFIG_RESULT_NOTIFY)
Figure 27: fpc pseudo code Figure 27: 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.
10. 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 protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure secure transport layer and the mandatory-to-implement secure
skipping to change at page 64, line 33 skipping to change at page 64, line 33
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.
These are the subtrees and data nodes and their sensitivity/ These are the subtrees and data nodes and their sensitivity/
vulnerability: vulnerability:
Nodes under the Policy tree provide generic policy enforcement and Nodes under the Policy tree provide generic policy enforcement and
traffic classification. The can be used to block or permit traffic classification. They can be used to block or permit
traffic. If this portion of the model was to be compromised it traffic. If this portion of the model was to be compromised it
may be used to block, identify or permit traffic that was not may be used to block, identify or permit traffic that was not
intended by the Tenant or FPC CLient. intended by the Tenant or FPC CLient.
Nodes under the Topology tree provide defintion of the Tenant's Nodes under the Topology tree provide defintion of the Tenant's
fowarding topology. Any compromise of this information will forwarding topology. Any compromise of this information will
provide topology information that could be used for subsequent provide topology information that could be used for subsequent
attack vectors. Removal of topology can limit services. attack vectors. Removal of topology can limit services.
Nodes under the Mobility Tree are runtime only and manipulated by Nodes under the Mobility Tree are runtime only and manipulated by
remote procedure calls. The unwanted deletion or removal of such remote procedure calls. The unwanted deletion or removal of such
information would deny users service or provide services ot information would deny users service or provide services to
unauthorized parties. unauthorized parties.
Some of the readable data nodes defined may be considered sensitive Some of the readable data nodes defined may be considered sensitive
or vulnerable in some network environments. It is thus important to or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to control read access (e.g., via get, get-config, or notification) to
these data nodes. These are the subtrees and data nodes and their these data nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability: sensitivity/vulnerability:
IP address assignments in the Context along with their associated IP address assignments in the Context along with their associated
tunnel configurations/identifiers (from the FPC base module) tunnel configurations/identifiers (from the FPC base module)
Internaional Mobile Subscriber Identity (IMSI) and bearer Internaional Mobile Subscriber Identity (IMSI) and bearer
identifiers in the Context when using the optional 3GPP module identifiers in the Context when using the optional 3GPP module
Some of the RPC operations defined may be considered sensitive or Some of the RPC operations defined may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control access to these operations. These are the operations and control access to these operations. These are the operations and
their sensitivity/vulnerability: their sensitivity/vulnerability:
CONF and CONF_BUNDLES send Context information which can include CONFIG and CONF_BUNDLE send Context information which can include
information of a sensitive or vulnerable nature in some network information of a sensitive or vulnerable nature in some network
environments as described above. environments as described above.
Monitor related RPC operations do not specicially provide Monitor related RPC operations do not specicially provide
sensitive or vulnerable informaiton but care must be taken by sensitive or vulnerable informaiton but care must be taken by
users to avoid identifier values that expose sensitive or users to avoid identifier values that expose sensitive or
vulnerable information. vulnerable information.
Notications MUST be treated with same level of protection and Notications MUST be treated with same level of protection and
scrutiny as the operations they correspond to. For example, a scrutiny as the operations they correspond to. For example, a
CONFIG_RESULT_NOTIFY notification provides the same information CONFIG_RESULT_NOTIFY notification provides the same information
that is sent as part of the input and output of the CONF and that is sent as part of the input and output of the CONFIG and
CONF_BUNDLES 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 5.4 permits arbirtrary string values but a FPC Naming Section 4.4 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 identificaiton 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.
11. 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 URI: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp
skipping to change at page 66, line 28 skipping to change at page 66, line 28
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-pmip 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 name: ietf-dmm-threegpp
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp
prefix: threegpp prefix: threegpp
reference: TBD1 reference: TBD1
name: ietf-dmm-pmip-qos name: ietf-dmm-pmip-qos
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos
prefix: qos-pmip prefix: qos-pmip
reference: TBD1 reference: TBD1
name: ietf-dmm-traffic-selector-types name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-traffic-selector-types namespace: urn:ietf:params:xml:ns:yang:
prefix: traffic-selectors ietf-dmm-traffic-selector-types
reference: TBD1 prefix: traffic-selectors
reference: TBD1
name: ietf-dmm-traffic-selector-types name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext
prefix: fpcpolicyext prefix: fpcpolicyext
reference: TBD1 reference: TBD1
name: ietf-dmm-traffic-selector-types name: ietf-dmm-traffic-selector-types
namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip
prefix: fpc-pmip prefix: fpc-pmip
reference: TBD1 reference: TBD1
The document registers the following YANG submodules in the "YANG The document registers the following YANG submodules in the "YANG
Module Names" registry [RFC6020]. Module Names" registry [RFC6020].
name: ietf-dmm-fpc-base name: ietf-dmm-fpc-base
parent: ietf-dmm-fpc parent: ietf-dmm-fpc
reference: TBD1 reference: TBD1
12. 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.
13. References 12. References
13.1. Normative References 12.1. Normative References
[I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-05 (work in progress), February
2017.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-07 (work in progress), February 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, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088, "Traffic Selectors for Flow Bindings", RFC 6088,
DOI 10.17487/RFC6088, January 2011, DOI 10.17487/RFC6088, January 2011,
<http://www.rfc-editor.org/info/rfc6088>. <http://www.rfc-editor.org/info/rfc6088>.
skipping to change at page 67, line 47 skipping to change at page 68, line 20
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089, Network Mobility (NEMO) Basic Support", RFC 6089,
DOI 10.17487/RFC6089, January 2011, DOI 10.17487/RFC6089, January 2011,
<http://www.rfc-editor.org/info/rfc6089>. <http://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,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
13.2. Informative References [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<http://www.rfc-editor.org/info/rfc7333>.
12.2. Informative References
[I-D.bertz-dime-policygroups] [I-D.bertz-dime-policygroups]
Bertz, L., "Diameter Policy Groups and Sets", draft-bertz- Bertz, L., "Diameter Policy Groups and Sets", draft-bertz-
dime-policygroups-01 (work in progress), July 2016. dime-policygroups-02 (work in progress), February 2017.
[I-D.ietf-dmm-deployment-models] [I-D.ietf-dmm-deployment-models]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-00 (work in progress), August 2016. models-01 (work in progress), February 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, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 68, line 38 skipping to change at page 69, line 19
[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,
<http://www.rfc-editor.org/info/rfc6242>. <http://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,
<http://www.rfc-editor.org/info/rfc7222>. <http://www.rfc-editor.org/info/rfc7222>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<http://www.rfc-editor.org/info/rfc7333>.
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. Seven 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
o ietf-dmm-fpc-base An FPC submodule that defines the information o ietf-dmm-fpc-base An FPC submodule that defines the information
model that is specified in this document model that is specified in this document
o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS
skipping to change at page 69, line 30 skipping to change at page 70, line 5
document. document.
A.1. FPC Agent YANG Model 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] and the fpc-base module defined in
this document. this document.
<CODE BEGINS> file "ietf-dmm-fpc@2016-08-03.yang" <CODE BEGINS> file "ietf-dmm-fpc@2017-03-08.yang"
module ietf-dmm-fpc { module 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;
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; include ietf-dmm-fpc-base;
organization "IETF Distributed Mobility Management (DMM) organization "IETF Distributed Mobility Management (DMM)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Dapeng Liu WG Chair: Dapeng Liu
<mailto:maxpassion@gmail.com> <mailto:maxpassion@gmail.com>
WG Chair: Jouni Korhonen WG Chair: Jouni Korhonen
<mailto:jouni.nospam@gmail.com> <mailto:jouni.nospam@gmail.com>
Editor: Satoru Matsushima Editor: Satoru Matsushima
<mailto:satoru.matsushima@g.softbank.co.jp> <mailto:satoru.matsushima@g.softbank.co.jp>
Editor: Lyle Bertz Editor: Lyle Bertz
<mailto:lyleb551144@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).
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 2016-08-03 { revision 2017-03-08 {
description "Initial Revision."; description "Version 06 updates.";
reference "draft-ietf-dmm-fpc-cpdp-05"; reference "draft-ietf-dmm-fpc-cpdp-06";
}
feature fpc-cloning {
description "An ability to support cloning in the RPC.";
}
feature fpc-basename-registry {
description "Ability to track Base Names already provisioned on the Agent";
}
feature fpc-bundles {
description "Ability for Client to send multiple bundles of actions to
an Agent";
}
feature fpc-client-binding {
description "Allows a FPC Client to bind a DPN to an Topology Object";
}
feature fpc-auto-binding {
description "Allows a FPC Agent to advertise Topology Objects that could be DPNs";
}
feature instruction-bitset {
description "Allows the expression of instructions (bit sets) over FPC.";
}
feature operation-ref-scope {
description "Provides the scope of refeneces in an operation. Used to optmize
the Agent processing.";
} }
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_BUNDLES operations.";
}
typedef agent-identifier { revision 2016-08-03 {
type fpc:fpc-identity; description "Initial Revision.";
description "Agent Identifier"; reference "draft-ietf-dmm-fpc-cpdp-05";
} }
feature fpc-cloning {
description "An ability to support cloning in the RPC.";
}
feature fpc-basename-registry {
description "Ability to track Base Names already provisioned
on the Agent";
}
feature fpc-bundles {
description "Ability for Client to send multiple bundles of
actions to an Agent";
}
feature fpc-client-binding {
description "Allows a FPC Client to bind a DPN to an Topology
Object";
}
feature fpc-auto-binding {
description "Allows a FPC Agent to advertise Topology Objects
that could be DPNs";
}
feature instruction-bitset {
description "Allows the expression of instructions (bit sets)
over FPC.";
}
feature operation-ref-scope {
description "Provides the scope of refeneces in an operation.
Used to optmize the Agent processing.";
}
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 client-identifier { typedef agent-identifier {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Client Identifier"; description "Agent Identifier";
} }
grouping basename-info { typedef client-identifier {
leaf basename { type fpc:fpc-identity;
if-feature fpc:fpc-basename-registry; description "Client Identifier";
type fpc:fpc-identity; }
description "Rules Basename"; grouping basename-info {
} leaf basename {
leaf base-state { if-feature fpc:fpc-basename-registry;
if-feature fpc:fpc-basename-registry; type fpc:fpc-identity;
type string; description "Rules Basename";
description "Current State"; }
} leaf base-state {
leaf base-checkpoint { if-feature fpc:fpc-basename-registry;
if-feature fpc:fpc-basename-registry; type string;
type string; description "Current State";
description "Checkpoint"; }
} leaf base-checkpoint {
description "Basename Information"; if-feature fpc:fpc-basename-registry;
} type string;
description "Checkpoint";
}
description "Basename Information";
}
// Top Level Structures // Top Level Structures
container tenants { container tenants {
list tenant { list tenant {
key "tenant-id"; key "tenant-id";
leaf tenant-id { leaf tenant-id {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Tenant ID"; description "Tenant ID";
} }
container fpc-policy { container fpc-policy {
list policy-groups { list policy-groups {
key "policy-group-id"; key "policy-group-id";
uses fpc:fpc-policy-group; uses fpc:fpc-policy-group;
description "Policy Groups"; description "Policy Groups";
} }
list policies { list policies {
key "policy-id"; key "policy-id";
uses fpc:fpc-policy; uses fpc:fpc-policy;
description "Policies"; description "Policies";
} }
list descriptors { list descriptors {
key descriptor-id; key descriptor-id;
uses fpc:fpc-descriptor; uses fpc:fpc-descriptor;
description "Descriptors"; description "Descriptors";
} }
list actions { list actions {
key action-id; key action-id;
uses fpc:fpc-action; uses fpc:fpc-action;
description "Actions"; description "Actions";
}
description "Policy";
}
container fpc-mobility { }
config false; description "Policy";
list contexts { }
key context-id;
uses fpc:fpc-context;
description "Contexts";
}
list ports {
key port-id;
uses fpc:fpc-port;
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 { container fpc-mobility {
if-feature fpc:fpc-basic-agent; config false;
type fpc:fpc-dpn-id; list contexts {
description "DPN ID"; key context-id;
} uses fpc:fpc-context;
leaf-list control-protocols { description "Contexts";
if-feature fpc:fpc-basic-agent; }
type identityref { list vports {
base "fpc:fpc-dpn-control-protocol"; key vport-id;
} uses fpc:fpc-vport;
description "Control Protocols"; 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";
}
list dpn-groups { leaf dpn-id {
if-feature fpc:fpc-multi-dpn; if-feature fpc:fpc-basic-agent;
key dpn-group-id; type fpc:fpc-dpn-id;
uses fpc:fpc-dpn-group; description "DPN ID";
list domains { }
key domain-id; leaf-list control-protocols {
uses fpc:fpc-domain; if-feature fpc:fpc-basic-agent;
uses fpc:basename-info; type identityref {
description "Domains"; base "fpc:fpc-dpn-control-protocol";
} }
description "DPN Groups"; description "Control Protocols";
} }
list dpns {
if-feature fpc:fpc-multi-dpn;
key dpn-id;
uses fpc:fpc-dpn;
description "DPNs";
}
description "Topology";
}
description "Tenant";
}
description "Tenant List";
}
container fpc-agent-info { list dpn-groups {
// General Agent Structures if-feature fpc:fpc-multi-dpn;
leaf-list supported-features { key dpn-group-id;
type string; uses fpc:fpc-dpn-group;
description "Agent Features"; 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";
}
// Common Agent Info container fpc-agent-info {
list supported-events { // General Agent Structures
key event; leaf-list supported-features {
leaf event { type string;
type identityref { description "Agent Features";
base "fpc:event-type"; }
}
description "Event Types";
}
leaf event-id {
type fpc:event-type-id;
description "Event ID";
}
description "Supported Events";
}
list supported-error-types { // Common Agent Info
key error-type; list supported-events {
leaf error-type { key event;
type identityref { leaf event {
base "fpc:error-type"; type identityref {
} base "fpc:event-type";
description "Error Type"; }
} description "Event Types";
leaf error-type-id { }
type fpc:error-type-id; leaf event-id {
description "Error Type ID"; type fpc:event-type-id;
} description "Event ID";
description "Supported Error Types"; }
} description "Supported Events";
description "General Agent Information"; }
}
// Multi-DPN Agent Structures list supported-error-types {
grouping fpc-dpn-group { key error-type;
leaf dpn-group-id { leaf error-type {
type fpc:fpc-dpn-group-id; type identityref {
description "DPN Group ID"; base "fpc:error-type";
} }
leaf data-plane-role { description "Error Type";
type identityref { }
base "fpc:fpc-forwaridingplane-role"; leaf error-type-id {
} type fpc:error-type-id;
description "Dataplane Role"; description "Error Type ID";
} }
leaf access-type { description "Supported Error Types";
type identityref { }
base "fpc:fpc-access-type"; description "General Agent Information";
} }
description "Access Type";
}
leaf mobility-profile {
type identityref {
base "fpc:fpc-mobility-profile-type";
}
description "Mobility Profile";
}
list dpn-group-peers {
key "remote-dpn-group-id";
uses fpc:fpc-dpn-peer-group;
description "Peer DPN Groups";
}
description "FPC DPN Group";
}
// RPC // Multi-DPN Agent Structures
// RPC Specific Structures grouping fpc-dpn-group {
//Input Structures leaf dpn-group-id {
typedef admin-status { type fpc:fpc-dpn-group-id;
type enumeration { description "DPN Group ID";
enum enabled { }
value 0; leaf data-plane-role {
description "enabled"; type identityref {
} base "fpc:fpc-data-plane-role";
enum disabled { }
value 1; description "Dataplane Role";
description "disabled"; }
} leaf access-type {
enum virtual { type identityref {
value 2; base "fpc:fpc-access-type";
description "virtual"; }
} description "Access Type";
} }
description "Adminstrative Status"; leaf mobility-profile {
} type identityref {
base "fpc:fpc-mobility-profile-type";
}
description "Mobility Profile";
}
list dpn-group-peers {
key "remote-dpn-group-id";
uses fpc:fpc-dpn-peer-group;
description "Peer DPN Groups";
}
description "FPC DPN Group";
}
typedef session-status { // RPC
type enumeration { // RPC Specific Structures
enum complete { //Input Structures
value 0; typedef admin-status {
description "complete"; type enumeration {
} enum enabled {
enum incomplete { value 0;
value 1; description "enabled";
description "incomplete"; }
} enum disabled {
enum outdated { value 1;
value 2; description "disabled";
description "outdated"; }
} enum virtual {
} value 2;
description "Session Status"; description "virtual";
} }
}
description "Adminstrative Status";
}
typedef op-delay { typedef session-status {
type uint32; type enumeration {
description "Operation Delay (ms)"; enum complete {
} value 0;
description "complete";
}
enum incomplete {
value 1;
description "incomplete";
}
enum outdated {
value 2;
description "outdated";
}
}
description "Session Status";
}
typedef op-identifier { typedef op-delay {
type uint64; type uint32;
description "Operation Identifier"; description "Operation Delay (ms)";
} }
typedef ref-scope { typedef op-identifier {
type enumeration { type uint64;
enum none { description "Operation Identifier";
value 0; }
description "no references"; typedef ref-scope {
} type enumeration {
enum op { enum none {
value 1; value 0;
description "op - All references are contained in the operation body (intra-op)"; description "no references";
} }
enum bundle { enum op {
value 2; value 1;
description "bundle - All references in exist in bundle (inter-operation/intra-bundle). description "op - All references are contained in the
NOTE - If this value comes in CONFIG call it is equivalen to 'op'."; operation body (intra-op)";
} }
enum storage { enum bundle {
value 3; value 2;
description "storage - One or more references exist outside of the operation and bundle. description "bundle - All references in exist in bundle
A lookup to a cache / storage is required."; (inter-operation/intra-bundle).
} NOTE - If this value comes in CONFIG call it is
enum unknown { equivalent to 'op'.";
value 4; }
description " unknown - the location of the references are unknown. This is treated as enum storage {
a 'storage' type."; value 3;
} description "storage - One or more references exist outside
} of the operation and bundle. A lookup to a cache /
description "Search scope for references in the operation."; storage is required.";
} }
enum unknown {
value 4;
description " unknown - the location of the references are
unknown. This is treated as a 'storage' type.";
}
}
description "Search scope for references in the operation.";
}
grouping instructions { grouping instructions {
container instructions { container instructions {
if-feature instruction-bitset; if-feature instruction-bitset;
choice instr-type { choice instr-type {
description "Instruction Value Choice"; description "Instruction Value Choice";
} }
description "Instructions"; description "Instructions";
} }
description "Instructions Value"; description "Instructions Value";
} }
grouping op-header { grouping op-header {
leaf client-id { leaf client-id {
type fpc:client-identifier; type fpc:client-identifier;
description "Client ID"; description "Client ID";
}
leaf delay {
type op-delay;
description "Delay";
}
leaf session-state {
type session-status;
description "Session State";
}
leaf admin-state {
type admin-status;
description "Admin State";
}
leaf op-type {
type enumeration {
enum create {
value 0;
description "create";
}
enum update {
value 1;
description "update";
}
enum query {
value 2;
description "query";
}
enum delete {
value 3;
description "delete";
}
}
description "Type";
}
leaf op-ref-scope {
if-feature operation-ref-scope;
type fpc:ref-scope;
description "Reference Scope";
}
uses fpc:instructions;
description "Operation Header";
}
grouping clone-ref { }
leaf entity { leaf delay {
type fpc:fpc-identity; type op-delay;
description "Clone ID"; description "Delay";
} }
leaf source { leaf session-state {
type fpc:fpc-identity; type session-status;
description "Source"; description "Session State";
} }
description "Clone Reference"; leaf admin-state {
} type admin-status;
description "Admin State";
}
leaf op-type {
type enumeration {
enum create {
value 0;
description "create";
}
enum update {
value 1;
description "update";
}
enum query {
value 2;
description "query";
}
enum delete {
value 3;
description "delete";
}
}
description "Type";
}
leaf op-ref-scope {
if-feature operation-ref-scope;
type fpc:ref-scope;
description "Reference Scope";
}
uses fpc:instructions;
description "Operation Header";
}
identity command-set { grouping clone-ref {
description "protocol specific commands"; leaf entity {
} type fpc:fpc-identity;
description "Clone ID";
}
leaf source {
type fpc:fpc-identity;
description "Source";
}
description "Clone Reference";
}
grouping context-operation { identity command-set {
uses fpc:fpc-context; description "protocol specific commands";
uses fpc:instructions; }
description "Context Operation";
}
// Output Structure grouping context-operation {
grouping payload { uses fpc:fpc-context;
list ports { uses fpc:instructions;
uses fpc:fpc-port; description "Context Operation";
description "Ports"; }
}
list contexts {
uses fpc:context-operation;
description "Contexts";
}
list policy-groups {
if-feature fpc:policy-rpc-provisioning;
key "policy-group-id";
uses fpc:fpc-policy-group;
description "Policy Groups";
}
list policies {
if-feature fpc:policy-rpc-provisioning;
key "policy-id";
uses fpc:fpc-policy;
description "Policies";
}
list descriptors {
if-feature fpc:policy-rpc-provisioning;
key descriptor-id;
uses fpc:fpc-descriptor;
description "Descriptors";
}
list actions {
if-feature fpc:policy-rpc-provisioning;
key action-id;
uses fpc:fpc-action;
description "Actions";
}
description "Payload";
}
grouping op-input { // Output Structure
uses fpc:op-header; grouping payload {
leaf op-id { list ports {
type op-identifier; uses fpc:fpc-vport;
description "Operation ID"; description "Ports";
} }
choice op_body { list contexts {
case create_or_update { uses fpc:context-operation;
list clones { description "Contexts";
if-feature fpc-cloning; }
key entity; list policy-groups {
uses fpc:clone-ref; if-feature fpc:policy-rpc-provisioning;
description "Clones"; key "policy-group-id";
} uses fpc:fpc-policy-group;
uses fpc:payload; description "Policy Groups";
description "Create/Update input"; }
} list policies {
case delete_or_query { if-feature fpc:policy-rpc-provisioning;
uses fpc:targets-value; key "policy-id";
description "Delete/Query input"; uses fpc:fpc-policy;
} description "Policies";
description "Opeartion Input value"; }
} list descriptors {
description "Operation Input"; if-feature fpc:policy-rpc-provisioning;
} key descriptor-id;
uses fpc:fpc-descriptor;
description "Descriptors";
}
list actions {
if-feature fpc:policy-rpc-provisioning;
key action-id;
uses fpc:fpc-action;
description "Actions";
}
description "Payload";
}
typedef result { grouping op-input {
type enumeration { uses fpc:op-header;
enum ok { leaf op-id {
value 0; type op-identifier;
description "OK"; description "Operation ID";
} }
enum err { choice op_body {
value 1; case create_or_update {
description "Error"; list clones {
} if-feature fpc-cloning;
enum ok-notify-follows { key entity;
value 2; uses fpc:clone-ref;
description "OK with NOTIFY following"; description "Clones";
} }
} uses fpc:payload;
description "Result Status"; description "Create/Update input";
} }
case delete_or_query {
uses fpc:targets-value;
description "Delete/Query input";
}
description "Opeartion Input value";
}
description "Operation Input";
}
identity error-type { typedef result {
description "Base Error Type"; type enumeration {
} enum ok {
identity name-already-exists { value 0;
description "Notification that an entity of the same name already exists"; description "OK";
} }
enum err {
value 1;
description "Error";
}
enum ok-notify-follows {
value 2;
description "OK with NOTIFY following";
}
}
description "Result Status";
typedef error-type-id { }
type uint32;
description "Integer form of the Error Type";
}
grouping op-status-value { identity error-type {
leaf op-status { description "Base Error Type";
type enumeration { }
enum ok { identity name-already-exists {
value 0; description "Notification that an entity of the same name
description "OK"; already exists";
} }
enum err {
value 1;
description "Error";
}
}
description "Operation Status";
}
description "Operation Status Value";
}
grouping error-info { typedef error-type-id {
leaf error-type-id { type uint32;
type fpc:error-type-id; description "Integer form of the Error Type";
description "Error ID"; }
}
leaf error-info {
type string {
length "1..1024";
}
description "Error Detail";
}
description "Error Information";
}
grouping result-body { grouping op-status-value {
leaf op-id { leaf op-status {
type op-identifier; type enumeration {
description "Operation Identifier"; enum ok {
} value 0;
choice result-type { description "OK";
case err { }
uses fpc:error-info; enum err {
description "Error Information"; value 1;
} description "Error";
case create-or-update-success { }
uses fpc:payload; }
description "Create/Update Success"; description "Operation Status";
} }
case delete_or_query-success { description "Operation Status Value";
uses fpc:targets-value; }
description "Delete/Query Success";
}
case empty-case {
description "Empty Case";
}
description "Result Value";
}
description "Result Body";
}
// Common RPCs grouping error-info {
rpc configure { leaf error-type-id {
description "CONF message"; type fpc:error-type-id;
input { description "Error ID";
uses fpc:op-input; }
} leaf error-info {
output { type string {
leaf result { length "1..1024";
type result; }
description "Result"; description "Error Detail";
} }
uses fpc:result-body; description "Error Information";
} }
} grouping result-body {
leaf op-id {
type op-identifier;
description "Operation Identifier";
}
choice result-type {
case err {
uses fpc:error-info;
description "Error Information";
}
case create-or-update-success {
uses fpc:payload;
description "Create/Update Success";
}
case delete_or_query-success {
uses fpc:targets-value;
description "Delete/Query Success";
}
case empty-case {
description "Empty Case";
}
description "Result Value";
}
description "Result Body";
}
rpc configure-bundles { // Common RPCs
if-feature fpc:fpc-bundles; rpc configure {
description "CONF_BUNDLES message"; description "CONF message";
input { input {
leaf highest-op-ref-scope { uses fpc:op-input;
if-feature operation-ref-scope; }
type fpc:ref-scope; output {
description "Highest Op-Ref used in the input"; leaf result {
} type result;
list bundles { description "Result";
key op-id; }
uses fpc:op-input; uses fpc:result-body;
description "List of operations"; }
} }
}
output {
list bundles {
key op-id;
uses fpc:result-body;
description "Operation Identifier";
}
}
}
// Notification Messages & Structures rpc configure-bundles {
typedef notification-id { if-feature fpc:fpc-bundles;
type uint32; description "CONF_BUNDLES message";
description "Notification Identifier"; input {
} leaf highest-op-ref-scope {
if-feature operation-ref-scope;
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 {
list bundles {
key op-id;
uses fpc:result-body;
description "Operation Identifier";
}
}
}
grouping notification-header { // Notification Messages & Structures
leaf notification-id { typedef notification-id {
type fpc:notification-id; type uint32;
description "Notification ID"; description "Notification Identifier";
} }
leaf timestamp {
type uint32;
description "timestamp";
}
description "Notification Header";
}
notification config-result-notification { grouping notification-header {
uses fpc:notification-header; leaf notification-id {
choice value { type fpc:notification-id;
case config-result { description "Notification ID";
uses fpc:op-status-value; }
uses fpc:result-body; leaf timestamp {
description "CONF Result"; type uint32;
} description "timestamp";
case config-bundle-result { }
list bundles { description "Notification Header";
uses fpc:op-status-value; }
uses fpc:result-body;
description "Operation Results";
}
description "CONF_BUNDLES Result";
}
description "Config Result value";
}
description "CONF/CONF_BUNDLES Async Result";
}
rpc event_register { notification config-result-notification {
description "Used to register monitoring of parameters/events"; uses fpc:notification-header;
input { choice value {
uses fpc:monitor-config; case config-result {
} uses fpc:op-status-value;
output { uses fpc:result-body;
leaf monitor-result { description "CONF Result";
type fpc:result; }
description "Result"; case config-bundle-result {
} list bundles {
uses fpc:error-info; uses fpc:op-status-value;
} uses fpc:result-body;
} description "Operation Results";
}
description "CONF_BUNDLES Result";
rpc event_deregister { }
description "Used to de-register monitoring of parameters/events"; description "Config Result value";
input { }
list monitors { description "CONF/CONF_BUNDLES Async Result";
uses fpc:monitor-id; }
description "Monitor ID";
}
}
output {
leaf monitor-result {
type fpc:result;
description "Result";
}
uses fpc:error-info;
}
} rpc event_register {
rpc probe { description "Used to register monitoring of parameters/events";
description "Probe the status of a registered monitor"; input {
input { uses fpc:monitor-config;
uses fpc:targets-value; }
} output {
output { leaf monitor-result {
leaf monitor-result { type fpc:result;
type fpc:result; description "Result";
description "Result"; }
} uses fpc:error-info;
uses fpc:error-info; }
} }
}
notification notify { rpc event_deregister {
uses fpc:notification-header; description "Used to de-register monitoring of
choice value { parameters/events";
case dpn-candidate-available { input {
if-feature fpc:fpc-auto-binding; list monitors {
leaf node-id { uses fpc:monitor-id;
type inet:uri; description "Monitor ID";
description "Topology URI"; }
} }
leaf-list access-types { output {
type identityref { leaf monitor-result {
base "fpc:fpc-access-type"; type fpc:result;
} description "Result";
description "Access Types"; }
} uses fpc:error-info;
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-forwaridingplane-role";
}
description "Forwarding Plane Role";
}
description "DPN Candidate Availability";
}
case monitor-notification {
choice monitor-notification-value {
case simple-monitor {
uses fpc:report;
description "Report";
} }
case bulk-monitors {
list reports { rpc probe {
uses fpc:report; description "Probe the status of a registered monitor";
description "Reports"; input {
} uses fpc:targets-value;
description "Bulk Monitor Response"; }
} output {
description "Monitor Notification value"; leaf monitor-result {
} type fpc:result;
description "Monitor Notification"; description "Result";
}
description "Notify Value"; }
} uses fpc:error-info;
description "Notify Message"; }
} }
}
<CODE ENDS> notification notify {
uses fpc:notification-header;
choice value {
case dpn-candidate-available {
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";
}
}
<CODE ENDS>
A.2. YANG Models A.2. YANG Models
A.2.1. FPC YANG Model A.2.1. FPC YANG Model
This module defines the base data elements specified in this This module defines the base data elements specified in this
document. document.
This module references [RFC6991]. This module references [RFC6991].
<CODE BEGINS> file "ietf-dmm-fpc-base@2016-08-03.yang" <CODE BEGINS> file "ietf-dmm-fpc-base@2017-03-08.yang"
submodule ietf-dmm-fpc-base { submodule ietf-dmm-fpc-base {
belongs-to ietf-dmm-fpc { belongs-to ietf-dmm-fpc {
prefix fpc; prefix fpc;
} }
import ietf-inet-types { prefix inet; revision-date 2013-07-15; }
organization "IETF Distributed Mobility Management (DMM) import ietf-inet-types { prefix inet; revision-date 2013-07-15; }
Working Group"; import ietf-yang-types { prefix ytypes;
revision-date 2013-07-15; }
contact organization "IETF Distributed Mobility Management (DMM)
"WG Web: <http://tools.ietf.org/wg/netmod/> Working Group";
WG List: <mailto:netmod@ietf.org>
WG Chair: Dapeng Liu contact
<mailto:maxpassion@gmail.com> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Jouni Korhonen WG Chair: Dapeng Liu
<mailto:jouni.nospam@gmail.com> <mailto:maxpassion@gmail.com>
Editor: Satoru Matsushima WG Chair: Jouni Korhonen
<mailto:satoru.matsushima@g.softbank.co.jp> <mailto:jouni.nospam@gmail.com>
Editor: Lyle Bertz Editor: Satoru Matsushima
<mailto:lyleb551144@gmail.com>"; <mailto:satoru.matsushima@g.softbank.co.jp>
description Editor: Lyle Bertz
"This module contains YANG definition for <mailto:lylebe551144@gmail.com>";
Forwarding Policy Configuration Protocol(FPCP).
Copyright (c) 2016 IETF Trust and the persons identified as the description
document authors. All rights reserved. "This module contains YANG definition for
Forwarding Policy Configuration Protocol(FPCP).
This document is subject to BCP 78 and the IETF Trust's Legal Copyright (c) 2016 IETF Trust and the persons identified as the
Provisions Relating to IETF Documents document authors. All rights reserved.
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.";
revision 2016-08-03 { This document is subject to BCP 78 and the IETF Trust's Legal
description "Initial Revision."; Provisions Relating to IETF Documents
reference "draft-ietf-dmm-fpc-cpdp-05"; (http://trustee.ietf.org/license-info) in effect on the date of
} publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.";
feature fpc-basic-agent { revision 2017-03-08 {
description "This is an agent co-located with a DPN. In this case description "Version 06 updates.";
only DPN Peer Groups, the DPN Id and Control Protocols are exposed reference "draft-ietf-dmm-fpc-cpdp-06";
along with the core structures."; }
}
feature fpc-multi-dpn {
description "The agent supports multiple DPNs.";
}
typedef fpc-identity { revision 2016-08-03 {
type union { description "Initial Revision.";
type uint32; reference "draft-ietf-dmm-fpc-cpdp-05";
type string; }
type instance-identifier;
}
description "FPC Identity";
}
grouping target-value { feature fpc-basic-agent {
leaf target { description "This is an agent co-located with a DPN. In this
type fpc-identity; case only DPN Peer Groups, the DPN Id and Control Protocols
description "Target Identity"; are exposed along with the core structures.";
} }
description "FPC Target Value"; feature fpc-multi-dpn {
} description "The agent supports multiple DPNs.";
}
grouping targets-value { typedef fpc-identity {
list targets { type union {
key "target"; type uint32;
leaf target { type string;
type fpc-identity; type instance-identifier;
description "Target Id"; }
} description "FPC Identity";
leaf dpn-id { }
type fpc:fpc-dpn-id;
description "DPN Id";
}
description "List of Targets";
}
description "Targets Value";
}
// Descriptor Structure grouping target-value {
typedef fpc-descriptor-id-type { leaf target {
type fpc:fpc-identity; type fpc-identity;
description "Descriptor-ID"; description "Target Identity";
} }
identity fpc-descriptor-type { description "FPC Target Value";
description "A traffic descriptor"; }
}
grouping fpc-descriptor-id {
leaf descriptor-id {
type fpc:fpc-identity;
description "Descriptor Id";
}
description "FPC Descriptor ID value";
}
grouping fpc-descriptor {
uses fpc:fpc-descriptor-id;
leaf descriptor-type {
type identityref {
base "fpc-descriptor-type";
}
mandatory true;
description "Descriptor Type";
}
choice descriptor-value {
case all-traffic {
leaf all-traffic {
type empty;
description "Empty Value";
}
}
description "Descriptor Value";
}
description "FPC Descriptor";
}
// Action Structure grouping targets-value {
typedef fpc-action-id-type { list targets {
type fpc:fpc-identity; key "target";
description "Action-ID"; leaf target {
} type fpc-identity;
identity fpc-action-type { description "Target Id";
description "Action Type"; }
} leaf dpn-id {
grouping fpc-action-id { type fpc:fpc-dpn-id;
leaf action-id { description "DPN Id";
type fpc:fpc-action-id-type; }
description "Action Identifier"; description "List of Targets";
} }
description "FPC Action ID"; description "Targets Value";
} }
grouping fpc-action {
uses fpc:fpc-action-id;
leaf action-type {
type identityref {
base "fpc-action-type";
}
mandatory true;
description "Action Type";
}
choice action-value {
case drop {
leaf drop {
type empty;
description "Empty Value";
}
}
description "FPC Action Value";
}
description "FPC Action";
}
// Rule Structure // Descriptor Structure
grouping fpc-rule { typedef fpc-descriptor-id-type {
list descriptors { type fpc:fpc-identity;
key descriptor-id; description "Descriptor-ID";
uses fpc:fpc-descriptor-id; }
leaf direction { identity fpc-descriptor-type {
type fpc:fpc-direction; description "A traffic descriptor";
description "Direction"; }
} grouping fpc-descriptor-id {
description "Descriptors"; leaf descriptor-id {
} type fpc:fpc-identity;
list actions { description "Descriptor Id";
key action-id; }
leaf order { description "FPC Descriptor ID value";
type uint32; }
description "Action Execution Order"; grouping fpc-descriptor {
} uses fpc:fpc-descriptor-id;
uses fpc:fpc-action-id; leaf descriptor-type {
description "Actions"; type identityref {
} base "fpc-descriptor-type";
description }
"FPC Rule. When no actions are present the action is DROP. mandatory true;
When no Descriptors are empty the default is 'all traffic'."; description "Descriptor Type";
} }
choice descriptor-value {
case all-traffic {
leaf all-traffic {
type empty;
description "Empty Value";
}
}
description "Descriptor Value";
}
description "FPC Descriptor";
}
// Policy Structures // Action Structure
typedef fpc-policy-id { typedef fpc-action-id-type {
type fpc:fpc-identity; type fpc:fpc-identity;
description "Policy Identifier"; description "Action-ID";
} }
grouping fpc-policy { identity fpc-action-type {
leaf policy-id { description "Action Type";
type fpc:fpc-policy-id; }
description "Policy Id"; grouping fpc-action-id {
} leaf action-id {
list rules { type fpc:fpc-action-id-type;
key order; description "Action Identifier";
leaf order { }
type uint32; description "FPC Action ID";
description "Rule Order"; }
} grouping fpc-action {
uses fpc:fpc-rule; uses fpc:fpc-action-id;
description "Rules"; leaf action-type {
} type identityref {
description "FPC Policy"; base "fpc-action-type";
}
// Policy Group }
typedef fpc-policy-group-id { mandatory true;
type fpc:fpc-identity; description "Action Type";
description "Policy Group Identifier"; }
} choice action-value {
grouping fpc-policy-group { case drop {
leaf policy-group-id { leaf drop {
type fpc:fpc-policy-group-id; type empty;
description "Policy Group ID"; description "Empty Value";
} }
leaf-list policies { }
type fpc:fpc-policy-id; description "FPC Action Value";
description "Policies"; }
} description "FPC Action";
description "FPC Policy Group"; }
}
// Mobility Structures // Rule Structure
// Port Group grouping fpc-rule {
typedef fpc-port-id { list descriptors {
type fpc:fpc-identity; key descriptor-id;
description "FPC Port Identifier"; uses fpc:fpc-descriptor-id;
} leaf direction {
grouping fpc-port { type fpc:fpc-direction;
leaf port-id { description "Direction";
type fpc:fpc-port-id; }
description "Port ID"; description "Descriptors";
} }
leaf-list policy-groups { list actions {
type fpc:fpc-policy-group-id; key action-id;
description "Policy Groups"; leaf action-order {
} type uint32;
description "FPC Port"; description "Action Execution Order";
} }
uses fpc:fpc-action-id;
description "Actions";
}
description
"FPC Rule. When no actions are present the action is DROP.
When no Descriptors are empty the default is
'all traffic'.";
}
// Context Group // Policy Structures
typedef fpc-context-id { typedef fpc-policy-id {
type fpc:fpc-identity; type fpc:fpc-identity;
description "FPC Context Identifier"; description "Policy Identifier";
} }
grouping fpc-context-profile { grouping fpc-policy {
leaf tunnel-local-address { leaf policy-id {
type inet:ip-address; type fpc:fpc-policy-id;
description "Uplink endpoint address of the DPN which agent exists."; description "Policy Id";
} }
leaf tunnel-remote-address { list rules {
type inet:ip-address; key order;
description "Uplink endpoint address of the DPN which agent exists."; leaf order {
} type uint32;
leaf mtu-size { description "Rule Order";
type uint32; }
description "MTU size"; uses fpc:fpc-rule;
} description "Rules";
container mobility-tunnel-parameters { }
uses fpc:mobility-info; description "FPC Policy";
description }
"Specifies profile specific uplink tunnel parameters to the DPN
which the agent exists. The profiles includes GTP/TEID for 3gpp profile,
GRE/Key for ietf-pmip profile, or new profile if anyone will define it.";
}
container nexthop {
uses fpc:fpc-nexthop;
description "Next Hop";
}
container qos-profile-parameters {
uses fpc:fpc-qos-profile;
description "QoS Parameters";
}
container dpn-parameters {
description "DPN Parameters";
}
list vendor-parameters {
key "vendor-id vendor-type";
uses fpc:vendor-attributes;
description "Vendor Parameters";
}
description "A profile that applies to a specific direction";
}
typedef fpc-direction { // Policy Group
type enumeration { typedef fpc-policy-group-id {
enum uplink { type fpc:fpc-identity;
description "Uplink"; description "Policy Group Identifier";
}
grouping fpc-policy-group {
leaf policy-group-id {
type fpc:fpc-policy-group-id;
description "Policy Group ID";
} }
enum downlink { leaf-list policies {
description "Downlink"; type fpc:fpc-policy-id;
description "Policies";
} }
enum both { description "FPC Policy Group";
description "Both";
}
} }
description "FPC Direction";
}
grouping fpc-context { // Mobility Structures
leaf context-id { // Port Group
type fpc:fpc-context-id; typedef fpc-vport-id {
description "Context ID"; type fpc:fpc-identity;
} description "FPC Port Identifier";
leaf-list ports { }
type fpc:fpc-port-id; grouping fpc-vport {
description "Ports"; leaf vport-id {
} type fpc:fpc-vport-id;
leaf dpn-group { description "Port ID";
type fpc:fpc-dpn-group-id; }
description "DPN Group"; leaf-list policy-groups {
} type fpc:fpc-policy-group-id;
leaf-list delegating-ip-prefixes { description "Policy Groups";
type inet:ip-prefix; }
description "Delegating Prefix(es)"; description "FPC Port";
} }
container ul {
if-feature fpc:fpc-basic-agent; // Context Group
uses fpc:fpc-context-profile; typedef fpc-context-id {
description "Uplink"; type fpc:fpc-identity;
} description "FPC Context Identifier";
container dl { }
if-feature fpc:fpc-basic-agent; grouping fpc-context-profile {
uses fpc:fpc-context-profile; leaf tunnel-local-address {
description "Downlink"; type inet:ip-address;
} description "endpoint address of the DPN which a
list dpns { gent exists.";
if-feature fpc:fpc-multi-dpn; }
key "dpn-id direction"; leaf tunnel-remote-address {
leaf dpn-id { type inet:ip-address;
type fpc:fpc-dpn-id; description "endpoint address of the DPN which
description "DPN"; agent exists.";
}
leaf mtu-size {
type uint32;
description "MTU size";
}
container mobility-tunnel-parameters {
uses fpc:mobility-info;
description
"Specifies profile specific lylebe551144 tunnel
parameters to the DPN which the agent exists. The
profiles includes GTP/TEID for 3gpp profile, GRE/Key for
ietf-pmip profile, or new profile if anyone will define
it.";
}
container nexthop {
uses fpc:fpc-nexthop;
description "Next Hop";
}
container qos-profile-parameters {
uses fpc:fpc-qos-profile;
description "QoS Parameters";
}
container dpn-parameters {
description "DPN Parameters";
}
list vendor-parameters {
key "vendor-id vendor-type";
uses fpc:vendor-attributes;
description "Vendor Parameters";
}
description "A profile that applies to a specific direction";
}
typedef fpc-direction {
type enumeration {
enum lylebe551144 {
description "lylebe551144";
} }
leaf direction { enum downlink {
type fpc:fpc-direction; description "Downlink";
mandatory true;
description "Direction";
} }
uses fpc:fpc-context-profile; enum both {
description "DPNs"; description "Both";
} }
leaf parent-context { }
type fpc:fpc-context-id; description "FPC Direction";
description "Parent Context"; }
}
description "FCP Context";
}
// Mobility (Tunnel) Information grouping fpc-context {
grouping mobility-info { leaf context-id {
choice profile-parameters { type fpc:fpc-context-id;
case nothing { description "Context ID";
leaf none { }
type empty; leaf-list vports {
description "Empty Value"; type fpc:fpc-vport-id;
} description "Vports";
description "No Parameters Case"; }
} leaf dpn-group {
description "Mobility Profile Parameters"; type fpc:fpc-dpn-group-id;
} description "DPN Group";
description "Mobility Information"; }
} leaf-list delegated-ip-prefixes {
type inet:ip-prefix;
description "Delegated Prefix(es)";
}
container ul {
if-feature fpc:fpc-basic-agent;
uses fpc:fpc-context-profile;
description "lylebe551144";
}
container dl {
if-feature fpc:fpc-basic-agent;
uses fpc:fpc-context-profile;
description "Downlink";
}
list dpns {
if-feature fpc:fpc-multi-dpn;
key "dpn-id direction";
leaf dpn-id {
type fpc:fpc-dpn-id;
description "DPN";
}
leaf direction {
type fpc:fpc-direction;
mandatory true;
description "Direction";
}
uses fpc:fpc-context-profile;
description "DPNs";
}
leaf parent-context {
type fpc:fpc-context-id;
description "Parent Context";
}
description "FCP Context";
}
// Next Hop Structures // Mobility (Tunnel) Information
typedef fpcp-service-path-id { grouping mobility-info {
type uint32 { choice profile-parameters {
range "0..33554431"; case nothing {
} leaf none {
description "SERVICE_PATH_ID"; type empty;
} description "Empty Value";
}
description "No Parameters Case";
}
description "Mobility Profile Parameters";
}
description "Mobility Information";
}
identity fpc-nexthop-type { // Next Hop Structures
description "Next Hop Type"; typedef fpc-service-path-id {
} type uint32 {
identity fpc-nexthop-ip { range "0..33554431";
base "fpc:fpc-nexthop-type"; }
description "Nexthop IP"; description "SERVICE_PATH_ID";
} }
identity fpc-nexthop-servicepath { typedef fpc-mpls-label {
base "fpc:fpc-nexthop-type"; type uint32 {
description "Nexthop Service Path"; range "0..1048575";
} }
grouping fpc-nexthop { description "MPLS label";
leaf nexthop-type { }
type identityref { identity fpc-nexthop-type {
base "fpc:fpc-nexthop-type"; description "Next Hop Type";
} }
description "Nexthop Type"; identity fpc-nexthop-ip {
} base "fpc:fpc-nexthop-type";
choice nexthop-value { description "Nexthop IP";
case ip { }
leaf ip { identity fpc-nexthop-servicepath {
type inet:ip-address; base "fpc:fpc-nexthop-type";
description "IP Value"; description "Nexthop Service Path";
} }
description "IP Case"; identity fpc-nexthop-mac {
} base "fpc:fpc-nexthop-type";
case servicepath { description "Nexthop MAC-Address";
leaf servicepath { }
type fpc:fpcp-service-path-id; identity fpc-nexthop-mpls {
description "Service Path Value"; base "fpc:fpc-nexthop-type";
} description "Nexthop MPLS";
description "Service Path Case"; }
} identity fpc-nexthop-if {
description "Value"; base "fpc:fpc-nexthop-type";
} description "Nexthop If index";
description "Nexthop Value"; }
} grouping fpc-nexthop {
leaf nexthop-type {
type identityref {
base "fpc:fpc-nexthop-type";
}
description "Nexthop Type";
}
choice nexthop-value {
case ip-nexthop {
leaf ip {
type inet:ip-address;
description "IP Value";
}
description "IP Case";
}
case macaddress-nexthop {
leaf macaddress {
type ytypes:mac-address;
description "MAC Address Value";
}
}
case servicepath-nexthop {
leaf servicepath {
type fpc:fpc-service-path-id;
description "Service Path Value";
// QoS Information }
identity fpc-qos-type { description "Service Path Case";
description "Base identity from which specific uses of QoS types are derived."; }
} case mplslabel-nexthop {
grouping fpc-qos-profile { leaf lsp {
leaf qos-type { type fpc:fpc-mpls-label;
type identityref { description "MPLS Value";
base fpc:fpc-qos-type; }
} description "Service Path Case";
description "the profile type"; }
} case if-nexthop {
choice value { leaf if-index {
description "QoS Value"; type uint16;
} description "If (interface) Value";
description "QoS Profile"; }
} description "Service Path Case";
}
description "Value";
}
description "Nexthop Value";
}
// Vendor Specific Attributes // QoS Information
identity vendor-specific-type { identity fpc-qos-type {
description "Vendor Specific Attribute Type"; description "Base identity from which specific uses of QoS
} types are derived.";
grouping vendor-attributes { }
leaf vendor-id { grouping fpc-qos-profile {
type fpc:fpc-identity; leaf qos-type {
description "Vendor ID"; type identityref {
} base fpc:fpc-qos-type;
leaf vendor-type { }
type identityref { description "the profile type";
base "fpc:vendor-specific-type"; }
} choice value {
description "Attribute Type"; description "QoS Value";
} }
choice value { description "QoS Profile";
case empty-type { }
leaf empty-type {
type empty;
description "Empty Value";
}
description "Empty Case";
} // Vendor Specific Attributes
description "Atttribute Value"; identity vendor-specific-type {
} description "Vendor Specific Attribute Type";
description "Vendor Specific Attributes"; }
} grouping vendor-attributes {
leaf vendor-id {
type fpc:fpc-identity;
description "Vendor ID";
// Topology }
typedef fpc-domain-id { leaf vendor-type {
type fpc:fpc-identity; type identityref {
description "Domain Identifier"; base "fpc:vendor-specific-type";
} }
grouping fpc-domain { description "Attribute Type";
leaf domain-id { }
type fpc:fpc-domain-id; choice value {
description "Domain ID"; case empty-type {
} leaf empty-type {
leaf domain-name { type empty;
type string; description "Empty Value";
description "Domain Name"; }
} description "Empty Case";
leaf domain-type { }
type string; description "Atttribute Value";
description "Domain Type"; }
} description "Vendor Specific Attributes";
description "FPC Domain"; }
}
typedef fpc-dpn-id { // Topology
type fpc:fpc-identity; typedef fpc-domain-id {
description "DPN Identifier"; type fpc:fpc-identity;
} description "Domain Identifier";
identity fpc-dpn-control-protocol { }
description "DPN Control Protocol"; grouping fpc-domain {
} leaf domain-id {
grouping fpc-dpn { type fpc:fpc-domain-id;
leaf dpn-id { description "Domain ID";
type fpc:fpc-dpn-id; }
description "DPN ID"; leaf domain-name {
} type string;
leaf dpn-name { description "Domain Name";
type string; }
description "DPN Name"; leaf domain-type {
} type string;
leaf-list dpn-groups { description "Domain Type";
type fpc:fpc-dpn-group-id; }
description "DPN Groups"; leaf domain-reference {
} type instance-identifier;
leaf node-reference { description "Indicates a set of resources for the domain";
type instance-identifier; }
description "DPN => Node (Topology) Mapping"; description "FPC Domain";
} }
description "FPC DPN";
}
typedef fpc-dpn-group-id { typedef fpc-dpn-id {
type fpc:fpc-identity; type fpc:fpc-identity;
description "DPN Group Identifier"; description "DPN Identifier";
}
identity fpc-forwaridingplane-role {
description "Role of DPN Group in the Forwarding Plane";
}
identity fpc-access-type {
description "Access Type of the DPN Group";
}
identity fpc-mobility-profile-type {
description "Mobility Profile Type";
}
grouping fpc-dpn-peer-group { }
leaf remote-dpn-group-id { identity fpc-dpn-control-protocol {
type fpc:fpc-dpn-group-id; description "DPN Control Protocol";
description "Remote DPN Group ID"; }
} grouping fpc-dpn {
leaf remote-mobility-profile { leaf dpn-id {
type identityref { type fpc:fpc-dpn-id;
base "fpc:fpc-mobility-profile-type"; description "DPN ID";
} }
description "Mobility Profile"; leaf dpn-name {
} type string;
leaf remote-data-plane-role { description "DPN Name";
type identityref { }
base "fpc:fpc-forwaridingplane-role"; leaf-list dpn-groups {
} type fpc:fpc-dpn-group-id;
description "Forwarding Plane Role"; description "DPN Groups";
} }
leaf remote-endpoint-address { leaf node-reference {
type inet:ip-address; type instance-identifier;
description "Remote Endpoint Address"; description "DPN => Node (Topology) Mapping";
} }
leaf local-endpoint-address { description "FPC DPN";
type inet:ip-address; }
description "Local Endpoint Address";
}
leaf mtu-size {
type uint32;
description "MTU Size";
} typedef fpc-dpn-group-id {
description "FPC DPN Peer Group"; type fpc:fpc-identity;
} description "DPN Group Identifier";
}
identity fpc-data-plane-role {
description "Role of DPN Group in the Forwarding Plane";
}
identity fpc-access-dpn-role {
base "fpc:fpc-data-plane-role";
description "Access DPN Role";
}
identity fpc-anchor-dpn-role {
base "fpc:fpc-data-plane-role";
description "Anchor DPN Role";
}
// Events, Probes & Notifications identity fpc-access-type {
identity event-type { description "Access Type of the DPN Group";
description "Base Event Type"; }
} identity fpc-mobility-profile-type {
typedef event-type-id { description "Mobility Profile Type";
type uint32; }
description "Event ID Type";
}
grouping monitor-id { grouping fpc-dpn-peer-group {
leaf monitor-id { leaf remote-dpn-group-id {
type fpc:fpc-identity; type fpc:fpc-dpn-group-id;
description "Monitor Identifier"; description "Remote DPN Group ID";
} }
description "Monitor ID"; leaf remote-mobility-profile {
} type identityref {
base "fpc:fpc-mobility-profile-type";
}
description "Mobility Profile";
}
leaf remote-data-plane-role {
type identityref {
base "fpc:fpc-data-plane-role";
}
description "Forwarding Plane Role";
}
leaf remote-endpoint-address {
type inet:ip-address;
description "Remote Endpoint Address";
}
leaf local-endpoint-address {
type inet:ip-address;
description "Local Endpoint Address";
}
leaf mtu-size {
type uint32;
description "MTU Size";
}
description "FPC DPN Peer Group";
}
identity report-type { // Events, Probes & Notifications
description "Type of Report"; identity event-type {
} description "Base Event Type";
identity periodic-report { }
base "fpc:report-type"; typedef event-type-id {
description "Periodic Report"; type uint32;
} description "Event ID Type";
identity threshold-report { }
base "fpc:report-type";
description "Threshold Report";
}
identity scheduled-report {
base "fpc:report-type";
description "Scheduled Report";
}
identity events-report {
base "fpc:report-type";
description "Events Report";
}
grouping report-config { grouping monitor-id {
choice event-config-value { leaf monitor-id {
case periodic-config { type fpc:fpc-identity;
leaf period { description "Monitor Identifier";
type uint32; }
description "Period"; description "Monitor ID";
} }
description "Periodic Config Case"; identity report-type {
} description "Type of Report";
case threshold-config { }
leaf lo-thresh { identity periodic-report {
type uint32; base "fpc:report-type";
description "lo threshold"; description "Periodic Report";
} }
leaf hi-thresh { identity threshold-report {
type uint32; base "fpc:report-type";
description "hi threshold"; description "Threshold Report";
} }
description "Threshold Config Case"; identity scheduled-report {
} base "fpc:report-type";
case scheduled-config { description "Scheduled Report";
leaf report-time { }
type uint32; identity events-report {
description "Reporting Time"; base "fpc:report-type";
} description "Events Report";
description "Scheduled Config Case"; }
}
case events-config-ident {
leaf-list event-identities {
type identityref {
base "fpc:event-type";
}
description "Event Identities";
}
description "Events Config Identities Case";
}
case events-config {
leaf-list event-ids {
type uint32;
description "Event IDs";
}
description "Events Config Case";
}
description "Event Config Value";
}
description "Report Configuration";
}
grouping monitor-config { grouping report-config {
uses fpc:monitor-id; choice event-config-value {
uses fpc:target-value; case periodic-config {
uses fpc:report-config; leaf period {
description "Monitor Configuration"; type uint32;
} description "Period";
grouping report { }
uses fpc:monitor-config; description "Periodic Config Case";
choice report-value { }
leaf trigger { case threshold-config {
type fpc:event-type-id; leaf lo-thresh {
description "Trigger Identifier"; type uint32;
} description "lo threshold";
case simple-empty { }
leaf nothing { leaf hi-thresh {
type empty; type uint32;
description "Empty Value"; description "hi threshold";
} }
description "Empty Case"; description "Threshold Config Case";
} }
case simple-val32 { case scheduled-config {
leaf val32 { leaf report-time {
type uint32; type uint32;
description "Unsigned 32 bit value"; description "Reporting Time";
} }
description "Simple Value Case"; description "Scheduled Config Case";
} }
description "Report Value"; case events-config-ident {
} leaf-list event-identities {
description "Monitor Report"; type identityref {
} base "fpc:event-type";
} }
<CODE ENDS> description "Event Identities";
}
description "Events Config Identities Case";
}
case events-config {
leaf-list event-ids {
type uint32;
description "Event IDs";
}
description "Events Config Case";
}
description "Event Config Value";
}
description "Report Configuration";
}
grouping monitor-config {
uses fpc:monitor-id;
uses fpc:target-value;
uses fpc:report-config;
description "Monitor Configuration";
}
grouping report {
uses fpc:monitor-config;
choice report-value {
leaf trigger {
type fpc:event-type-id;
description "Trigger Identifier";
}
case simple-empty {
leaf nothing {
type empty;
description "Empty Value";
}
description "Empty Case";
}
case simple-val32 {
leaf val32 {
type uint32;
description "Unsigned 32 bit value";
}
description "Simple Value Case";
}
description "Report Value";
}
description "Monitor Report";
}
}
<CODE ENDS>
A.2.2. PMIP QoS Model A.2.2. PMIP QoS Model
This module defines the base protocol elements specified in this This module defines the base protocol elements specified in this
document. document.
This module references [RFC6991] and the traffic-selector-types This module references [RFC6991] and the traffic-selector-types
module defined in this document. module defined in this document.
<CODE BEGINS> file "ietf-pmip-qos@2016-02-10.yang" <CODE BEGINS> file "ietf-pmip-qos@2016-02-10.yang"
skipping to change at page 100, line 25 skipping to change at page 102, line 51
WG Chair: Dapeng Liu WG Chair: Dapeng Liu
<mailto:maxpassion@gmail.com> <mailto:maxpassion@gmail.com>
WG Chair: Jouni Korhonen WG Chair: Jouni Korhonen
<mailto:jouni.nospam@gmail.com> <mailto:jouni.nospam@gmail.com>
Editor: Satoru Matsushima Editor: Satoru Matsushima
<mailto:satoru.matsushima@g.softbank.co.jp> <mailto:satoru.matsushima@g.softbank.co.jp>
Editor: Lyle Bertz Editor: Lyle Bertz
<mailto:lyleb551144@gmail.com>"; <mailto:lylebe551144@gmail.com>";
description description
"This module contains a collection of YANG definitions for "This module contains a collection of YANG definitions for
quality of service paramaters used in Proxy Mobile IPv6. quality of service paramaters used in Proxy Mobile IPv6.
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
skipping to change at page 101, line 4 skipping to change at page 103, line 31
revision 2016-02-10 { revision 2016-02-10 {
description "Initial revision"; description "Initial revision";
reference reference
"RFC 7222: Quality-of-Service Option for Proxy Mobile IPv6"; "RFC 7222: Quality-of-Service Option for Proxy Mobile IPv6";
} }
// Type Definitions // Type Definitions
// QoS Option Field Type Definitions // QoS Option Field Type Definitions
typedef sr-id { typedef sr-id {
type uint8; type uint8;
description description
"An 8-bit unsigned integer used "An 8-bit unsigned integer used]
for identifying the QoS Service Request. Its uniqueness is within for identifying the QoS Service Request. Its uniqueness is
the scope of a mobility session. The local mobility anchor always within the scope of a mobility session. The local mobility
allocates the Service Request Identifier. When a new QoS Service anchor always allocates the Service Request Identifier.
Request is initiated by a mobile access gateway, the Service When a new QoS Service Request is initiated by a mobile
Request Identifier in the initial request message is set to a access gateway, the Service Request Identifier in the initial
value of (0), and the local mobility anchor allocates a Service request message is set to a value of (0), and the local
Request Identifier and includes it in the response. For any new mobility anchor allocates a Service Request Identifier and
QoS Service Requests initiated by a local mobility anchor, the includes it in the response. For any new QoS Service
Service Request Identifier is set to the allocated value."; Requests initiated by a local mobility anchor, the
} Service Request Identifier is set to the allocated value.";
}
typedef traffic-class { typedef traffic-class {
type inet:dscp; type inet:dscp;
description description
"Traffic Class consists of a 6-bit DSCP field followed by a 2-bit "Traffic Class consists of a 6-bit DSCP field followed by a
reserved field."; 2-bit reserved field.";
reference reference
"RFC 3289: Management Information Base for the Differentiated "RFC 3289: Management Information Base for the Differentiated
Services Architecture Services Architecture
RFC 2474: Definition of the Differentiated Services Field RFC 2474: Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers (DS Field) in the IPv4 and IPv6 Headers
RFC 2780: IANA Allocation Guidelines For Values In RFC 2780: IANA Allocation Guidelines For Values In
the Internet Protocol and Related Headers"; the Internet Protocol and Related Headers";
} }
typedef operational-code { typedef operational-code {
type enumeration { type enumeration {
enum RESPONSE { enum RESPONSE {
value 0; value 0;
description "Response to a QoS request"; description "Response to a QoS request";
} }
enum ALLOCATE { enum ALLOCATE {
value 1; value 1;
description "Request to allocate QoS resources"; description "Request to allocate QoS resources";
} }
enum DE-ALLOCATE { enum DE-ALLOCATE {
value 2; value 2;
description "Request to de-Allocate QoS resources"; description "Request to de-Allocate QoS resources";
} }
enum MODIFY { enum MODIFY {
value 3; value 3;
description "Request to modify QoS parameters for a previously negotiated description "Request to modify QoS parameters for a
QoS Service Request"; previously negotiated QoS Service Request";
} }
enum QUERY { enum QUERY {
value 4; value 4;
description "Query to list the previously negotiated QoS Service Requests description "Query to list the previously negotiated QoS
that are still active"; Service Requests that are still active";
} }
enum NEGOTIATE { enum NEGOTIATE {
value 5; value 5;
description "Response to a QoS Service Request with a counter QoS proposal"; description "Response to a QoS Service Request with a
counter QoS proposal";
} }
} }
description description
"1-octet Operational code indicates the type of QoS request. "1-octet Operational code indicates the type of QoS request.
Reserved values: (6) to (255) Reserved values: (6) to (255)
Currently not used. Receiver MUST ignore the option received Currently not