--- 1/draft-ietf-dmm-fpc-cpdp-05.txt 2017-03-13 03:14:27.438383683 -0700 +++ 2/draft-ietf-dmm-fpc-cpdp-06.txt 2017-03-13 03:14:27.734390635 -0700 @@ -1,197 +1,198 @@ DMM Working Group S. Matsushima Internet-Draft SoftBank Intended status: Standards Track L. Bertz -Expires: May 4, 2017 Sprint +Expires: September 14, 2017 Sprint M. Liebsch NEC S. Gundavelli Cisco D. Moses Intel Corporation - October 31, 2016 + C. Perkins + Futurewei + March 13, 2017 Protocol for Forwarding Policy Configuration (FPC) in DMM - draft-ietf-dmm-fpc-cpdp-05.txt + draft-ietf-dmm-fpc-cpdp-06.txt Abstract - This document describes the solution of data-plane separation from - control-plane which enables a flexible mobility management system - using agent and client functions. To configure data-plane nodes and - functions, the data-plane is abstracted by an agent interface to the - client. The data-plane abstraction model is extensible in order to - support many different type of mobility management systems and data- - plane functions. + This document describes a way, called Forwarding Policy Configuration + (FPC) to manage the separation of data-plane and control-plane. FPC + defines a flexible mobility management system using FPC agent and FPC + client functions. An FPC agent provides an abstract interface to the + data-plane. The FPC client configures data-plane nodes by using the + functions and abstractions provided by the FPC agent for that data- + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 4, 2017. + This Internet-Draft will expire on September 14, 2017. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 5 - 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1.1. Domains . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 9 - 5.1.3. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 12 - 5.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 14 - 5.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 16 - 5.3. FPC-Mobility . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3.1. Port . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 22 - 5.4. Namespace and Format . . . . . . . . . . . . . . . . . . 23 - 5.5. Attribute Application . . . . . . . . . . . . . . . . . . 24 - 5.6. Policy and Runtime Data . . . . . . . . . . . . . . . . . 25 - 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.1. Protocol Messages and Semantics . . . . . . . . . . . . . 25 - 6.1.1. CONF and CONF_BUNDLES Messages . . . . . . . . . . . 28 - 6.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 31 - 6.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 32 - 6.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 32 - 6.2.2. Policy And Mobility on the Agent . . . . . . . . . . 37 - 6.2.3. Optimization for Current and Subsequent Messages . . 39 - 6.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 44 - 7. Protocol Message Details . . . . . . . . . . . . . . . . . . 45 - 7.1. Data Structures And Type Assignment . . . . . . . . . . . 45 - 7.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 45 - 7.1.2. Mobilty Structures . . . . . . . . . . . . . . . . . 47 - 7.1.3. Topology Structures . . . . . . . . . . . . . . . . . 49 - 7.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 50 - - 7.2. Message Attributes . . . . . . . . . . . . . . . . . . . 52 - 7.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 52 - 7.2.2. CONF and CONF_BUNDLES Attributes and Notifications . 52 - 7.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 55 - 8. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 55 - 8.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 58 - 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 60 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 - 12. Work Team Participants . . . . . . . . . . . . . . . . . . . 67 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 67 - 13.2. Informative References . . . . . . . . . . . . . . . . . 67 - Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 68 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. FPC Architecture . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Information Model for FPC . . . . . . . . . . . . . . . . . . 8 + 4.1. FPC-Topology . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. DPNs . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.2. DPN-groups . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.3. Domains . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. FPC-Policy . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2.1. Descriptors . . . . . . . . . . . . . . . . . . . . . 13 + 4.2.2. Actions . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2.3. Policies . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.4. Policy-groups . . . . . . . . . . . . . . . . . . . . 16 + 4.3. FPC for Mobility Management . . . . . . . . . . . . . . . 16 + 4.3.1. Vport . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.3.2. Context . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.3.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 22 + 4.4. Namespace and Format . . . . . . . . . . . . . . . . . . 23 + 4.5. Attribute Application . . . . . . . . . . . . . . . . . . 24 + 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 5.1. Protocol Messages and Semantics . . . . . . . . . . . . . 25 + 5.1.1. CONFIG and CONF_BUNDLE Messages . . . . . . . . . . . 28 + 5.1.2. Monitors . . . . . . . . . . . . . . . . . . . . . . 31 + 5.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 32 + 5.2.1. Simple RPC Operation . . . . . . . . . . . . . . . . 32 + 5.2.2. Policy And Mobility on the Agent . . . . . . . . . . 37 + 5.2.3. Optimization for Current and Subsequent Messages . . 39 + 5.2.4. Pre-provisioning . . . . . . . . . . . . . . . . . . 44 + 6. Protocol Message Details . . . . . . . . . . . . . . . . . . 45 + 6.1. Data Structures And Type Assignment . . . . . . . . . . . 45 + 6.1.1. Policy Structures . . . . . . . . . . . . . . . . . . 45 + 6.1.2. Mobility Structures . . . . . . . . . . . . . . . . . 47 + 6.1.3. Topology Structures . . . . . . . . . . . . . . . . . 49 + 6.1.4. Monitors . . . . . . . . . . . . . . . . . . . . . . 50 + 6.2. Message Attributes . . . . . . . . . . . . . . . . . . . 52 + 6.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 52 + 6.2.2. CONFIG and CONF_BUNDLE Attributes and Notifications . 52 + 6.2.3. Monitors . . . . . . . . . . . . . . . . . . . . . . 55 + 7. Derived and Subtyped Attributes . . . . . . . . . . . . . . . 55 + 7.1. 3GPP Specific Extenstions . . . . . . . . . . . . . . . . 58 + 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 60 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 64 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 + 11. Work Team Participants . . . . . . . . . . . . . . . . . . . 67 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 67 + 12.2. Informative References . . . . . . . . . . . . . . . . . 68 + Appendix A. YANG Data Model for the FPC protocol . . . . . . . . 69 A.1. FPC Agent YANG Model . . . . . . . . . . . . . . . . . . 69 - A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 85 - A.2.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . 85 - A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 99 - A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 112 - A.2.4. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 123 - A.2.5. FPC / PMIP Integration YANG Model . . . . . . . . . . 138 - A.2.6. FPC Policy Extension YANG Model . . . . . . . . . . . 145 - A.3. FPC nformation Model YANG Tree . . . . . . . . . . . . . 148 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 152 + A.2. YANG Models . . . . . . . . . . . . . . . . . . . . . . . 86 + A.2.1. FPC YANG Model . . . . . . . . . . . . . . . . . . . 86 + A.2.2. PMIP QoS Model . . . . . . . . . . . . . . . . . . . 102 + A.2.3. Traffic Selectors YANG Model . . . . . . . . . . . . 115 + A.2.4. FPC 3GPP Mobility YANG Model . . . . . . . . . . . . 127 + A.2.5. FPC / PMIP Integration YANG Model . . . . . . . . . . 144 + A.2.6. FPC Policy Extension YANG Model . . . . . . . . . . . 151 + A.3. FPC YANG Data Model Structure . . . . . . . . . . . . . . 155 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 1. Introduction - This document describes Forwarding Policy Configuration (FPC), the - solution of data-plane separation from control-plane which enables - flexible mobility management systems using agent and client - functions. To configure data-plane nodes and functions, the data- - plane is abstracted in the agent which provides an interface to the - client. + This document describes Forwarding Policy Configuration (FPC), a + system for managing the separation of data-plane and control-plane. + FPC enables flexible mobility management using FPC agent and FPC + client functions. An FPC agent exports an abstract interface to the + data-plane. To configure data-plane nodes and functions, the FPC + client uses the interface to the data-plane offered by the FPC agent. - Control planes of mobility management systems, and/or any - applications which require data-plane control, can utilize the FPC - Client in flexible granularities of operation. The configuration - operations are capable of configuring not only single Data-Plane Node - (DPN) directly, but also multiple DPNs from abstracted data-plane - models on the FPC agent. + Control planes of mobility management systems, or other applications + which require data-plane control, can utilize the FPC client at + various granularities of operation. The operations are capable of + configuring a single Data-Plane Node (DPN) directly, as well as + multiple DPNs as determined by abstracted data-plane models on the + FPC agent. - FPC agent provides the data-plane abstraction models in the following - three areas: + A FPC agent provides data-plane abstraction in the following three + areas: - Topology: DPNs are grouped and abstracted in terms of roles of - mobility management such as access, anchors and domains. FPC - Agent abstracts DPN-groups and consists of forwarding plane - topology, such as access nodes assigned to a DPN-group which peers - to a DPN-group of anchor nodes. + Topology: DPNs are grouped and abstracted according to well-known + concepts of mobility management such as access networks, anchors + and domains. A FPC agent provides an interface to the abstract + DPN-groups that enables definition of a topology for the + forwarding plane. For example, access nodes may be assigned to a + DPN-group which peers to a DPN-group of anchor nodes. - Policy: Policy abstracts policies which handle specific traffic - flows or packets such as QoS, packet processing to rewrite - headers, etc. A policy consists of one or multiple rules which - are composed of Descriptors and Actions. Descriptors in a rule - identify traffic flows and Actions apply treatments to packets - matched to the Descriptors in the rule. An arbitrary set of - policies is abstracted as a Policy-group which is applied to - Ports. + Policy: A Policy embodies the mechanisms for processing specific + traffic flows or packets. This is needed for QoS, for packet + processing to rewrite headers, etc. A Policy consists of one or + more rules. Each rule is composed of Descriptors and Actions. + Descriptors in a rule identify traffic flows, and Actions apply + treatments to packets that match the Descriptors in the rule. An + arbitrary set of policies can be abstracted as a Policy-group to + 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 - Context with its associated runtime concrete attributes, such as - tunnel endpoints, tunnel identifiers, delegated prefix(es), - routing information, etc. Contexts are attached to DPN-groups - along with consequence of the control plane. One or multiple - Contexts which have same sets of policies are assigned Ports which - abstract those policy sets. A Context can belong to multiple - Ports which serve different kinds of purpose and policy. Monitors - provide a mechanism to produce reports when events regarding - Ports, Sessions, DPNs or the Agent occurs. + Mobility: A mobility session which is active on a mobile node is + abstracted as a Context with associated runtime concrete + attributes, such as tunnel endpoints, tunnel identifiers, + delegated prefix(es), routing information, etc. Contexts are + attached to DPN-groups along with consequence of the control + plane. One or multiple Contexts which have same sets of policies + are assigned Vports which abstract those policy sets. A Context + can belong to multiple Vports which serve various kinds of purpose + and policy. Monitors provide a mechanism to produce reports when + 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 policies into specific configurations for each DPN to which the - sessions attached. Specific protocols and configurations to - configure DPN from FPC Agent are out of scope of this document. + sessions attached. The specific protocols and configurations to + configure DPN from a FPC Agent are outside the scope of this + document. - The data-plane abstraction model is extensible in order to support - many different types of mobility management systems and data-plane - functions. The architecture and protocol design of FPC intends not - to tie to specific types of access technologies and mobility - protocols. + The data-plane abstractions may be extended to support many different + mobility management systems and data-plane functions. The + architecture and protocol design of FPC is not tied to specific types + of access technologies and mobility protocols. -2. Conventions +2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -3. Terminology - DPN: A data-plane node (DPN) is capable of deploying data-plane features. DPNs may be switches or routers regardless of their realiziation, i.e. whether they are hardware or software based. FPC Agent: A functional entity in FPC that manages DPNs and provides abstracted data-plane networks to mobility management systems and/or applications through FPC Clients. @@ -203,397 +204,424 @@ Tenant: An operational entity that manages mobility management systems or applications which require data-plane functions. Domain: One or more DPNs that form a data-plane network. A mobility management system or an application in a tenant may utilize a single 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 - associated with runtime attributes. Ports + associated with runtime attributes. Vports may apply to Context which instantiates those forwarding policies on a DPN. -4. FPC Architecture +3. FPC Architecture - In accordance with the requirements of flexible data-plane functions - deployment described in [RFC7333], FPC provides a means for mobility - control-plane and applications to handle DPNs that must be configured - with various roles of the mobility management aspect described in + To fulfill the requirements described in [RFC7333], FPC enables + mobility control-planes and applications to configure DPNs with + various roles of the mobility management as described in [I-D.ietf-dmm-deployment-models]. - FPC uses building blocks of Agent, Client and data-plane abstraction - models as the interface between the agent and the client. + FPC defines building blocks of FPC Agent and FPC Client, as well as + data models for the necessary data-plane abstractions. The + attributes defining those data models serve as protocol elements for + the interface between the FPC Agent and the FPC Client. - Mobility control-plane and applications integrate the FPC Client - function and connect to FPC Agent functions. The Client and the - Agent communicate based on data-plane abstraction models described in - Section 5. Along with models, the control-plane and the applications - put forwarding policies for their mobility sessions on the Agent. + Mobility control-planes and applications integrate the FPC Client + function. The FPC Client connects to FPC Agent functions. The + Client and the Agent communicate based on information models for the + data-plane abstractions described in Section 4. The data models + 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 - configurations are rendered from the forwarding policies by the - Agent. FPC Agent may be implemented in a network controller that - handles multiple DPNs or it also may be integrated into a DPN. + The FPC Agent carries out the required configuration and management + of the DPN(s). The Agent determines DPN configurations according to + the forwarding policies requested by the FPC Client. The 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 - data-plane supports multiple tenants of mobile operator networks and/ - or applications. DPNs on the data-plane run in multiple data-plane - roles which are defined per session, domain and tenant. + Once the Topology of DPN(s) and domains are defined for a data plane + on an Agent, the data-plane nodes (DPNs) are available for further + configuration. The FPC Agent connects those DPNs to manage their + configurations. - This architecture is illustrated in Figure 1. This document does not - adopt a specific protocol for the FPC envelope protocol and it is out - of scope. However it must be capable of supporting FPC protocol - messages and transactions described in Section 6. + This architecture is illustrated in Figure 1. An FPC Agent may be + implemented in a network controller that handles multiple DPNs, or + there is a simple case where another FPC Agent may itself be + 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 | | and | | Applications | |+-----------------------+| || FPC Client || |+----------^------------+| +-----------|-------------+ - FPC envelope protocol | + FPC interface protocol | +---------------+-----------------+ | | Network | | Controller | DPN | +-----------|-------------+ +----------|---------+ |+----------v------------+| |+---------v--------+| || [Data-plane model] || ||[Data-plane model]|| || FPC Agent || || FPC Agent || |+-----------------------+| |+------------------+| |+------------+----------+| | | ||SB Protocols|FPC Client|| | DPN Configuration | || Modules | Module || +--------------------+ |+------^-----+----^-----+| +-------|----------|------+ | | - Other | | FPC envelope + Other | | FPC interface Southband | | Protocol Protocols | | | +-----------------+ | | DPN | DPN | +----------|---------+ +----------|---------+ |+---------v--------+| |+---------v--------+| || Configuration || ||[Data-plane model]|| || Protocol module || || FPC Agent || |+------------------+| |+------------------+| | | | | | DPN Configuration | | DPN Configuration | +--------------------+ +--------------------+ Figure 1: Reference Forwarding Policy Configuration (FPC) Architecture - Note that the FPC envelope protocol is only required to handle - runtime data in the Mobility model. The rest of the FPC models, - namely Topology and Policy, are pre-configured, therefore real-time - data handling capabilities are not required for them. Operators that - are tenants in the FPC data-plane can configure Topology and Policy - on the Agent through other means, such as Restconf + The FPC architecture supports multi-tenancy; an FPC enabled data- + plane supports tenants of multiple mobile operator networks and/or + applications. It means that the FPC Client of each tenant connects + to the FPC Agent and it MUST partition namespace and data for their + data-planes. DPNs on the data-plane may fulfill multiple data-plane + roles which are defined per session, domain and tenant. + + 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]. -5. Information Model +4. Information Model for FPC - This section describes information model that represents the concept - of FPC which is language and protocol neutral. Figure 2 is an - overview of FPC data-plane abstraction model. + This section presents an information model representing the abstract + concepts of FPC, which are language and protocol neutral. Figure 2 + shows an overview of the FPC data-plane information model. (Mobile operator tenant that abstracted data-plane is used) | +---FPC-Topology | | - | +---Domains + | +---DPNs | | | +---DPN-groups | | - | +---DPNs + | +---Domains | +---FPC-Policy | | | +---Descriptors | | | +---Actions | | | +---Policies | | | +---Policy-groups | +---FPC-Mobility | - +---Ports + +---Vports | +---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 - multiple mobile operator's topologies of their data-plane. The FPC- - Topology consists of DPNs, DPN-groups and Domains which abstract - data-plane topologies for the Client's mobility control-planes and - applications. + Topology abstraction enables a physical data-plane network to support + multiple overlay topologies. An FPC-Topology consists of DPNs, DPN- + groups and Domains which abstract data-plane topologies for the + Client's mobility control-planes and applications. - A mobile operator who utilizes a FPC enabled data-plane network can - virtually create their DPNs along with their data-plane design on the - Agent. The operator also creates a DPN-group of which the DPNs are - attributed roles of mobility management such as access, anchors and - domains. + Utilizing a FPC Agent, a mobile operator can create virtual DPNs in + an overlay network. Those such virtual DPNs are treated the same as + physical forwarding DPNs in this document. -5.1.1. Domains +4.1.1. DPNs - A domain is defined by the operators to attribute DPN-groups to the - domain. Domains may represent services or applications within the - operator. + The DPNs define all available nodes to a tenant of the FPC data-plane + network. FPC Agent defines DPN binding to actual nodes. The role of + a DPN in the data-plane is determined at the time the DPN is assigned + to a DPN-group. (FPC-Topology) | - +---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 - Section 5.4. + DPN-id: The identifier for the DPN. The ID format MUST conform to + Section 4.4. - Domain-name: Defines Domain name. + DPN-name: The name of the DPN. - Domain-type: Specifies which type of communication allowed within - the domain, such as ipv4, ipv6, ipv4v6 or ieee802. + DPN-groups: The list of DPN-groups to which the DPN belongs. -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 - attributes. DPN-groups consist data-plane topology that consists of - a DPN-group of access nodes connecting to an anchor nodes DPN-group. +4.1.2. DPN-groups - 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 - domain. + domain. A DPN may be assigned to multiple DPN-groups in different + data-plane roles or different domains. (FPC-Topology) | +---DPN-groups | +---DPN-group-id | +---Data-plane-role | +---Domains | +---Access-type | +---Mobility-profile | +---DPN-group-peers Figure 4: DPN-groups Model Structure - DPN-group-id: Defines identifier of DPN-group. The ID format SHOULD - refer to Section 5.4. + DPN-group-id: The identifier of the DPN-group. The ID format MUST + conform to Section 4.4. - Data-plane-role: Defines data-plane role of the DPN-group, such as - access-dpn, L2/L3 or anchor-dpn. + Data-plane-role: The data-plane role of the DPN-group, such as + 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 - as ethernet(802.3/11), 3gpp cellular(S1, RAB), if any. + Access-type: The access type supported by the DPN-group such as + ethernet(802.3/11), 3gpp cellular(S1, RAB), if any. - Mobility-profile: Defines supported mobility profile, such as ietf- - pmip, 3gpp, or new profiles defined as extensions of this - specification. When those profiles are correctly defined, some - or all data-plane parameters of contexts can be automatically - derived from this profile by FPC Agent. + Mobility-profile: Identifies a supported mobility profile, such as + ietf-pmip, or 3gpp. New profiles may be defined as extensions of + this specification. Mobility profiles are defined so that some + or all data-plane parameters of the mobility contexts that are + part of the profile can be automatically determined by the FPC + Agent. - DPN-group-peers: Defines remote peers of DPN-group with parameters - described in Section 5.1.2.1. + DPN-group-peers: The remote peers of the DPN-group with parameters + 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 - in Figure 5. + DPN-group-peers lists relevant parameters of remote peer DPNs as + illustrated in Figure 5. (DPN-groups) | +---DPN-group-peers | +---Remote-DPN-group-id | +---Remote-mobility-profile | +---Remote-data-plane-role | +---Remote-endpoint-address | +---Local-endpoint-address | +---MTU-size Figure 5: DPN-groups Peer Model Structure - 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 - peer, currently defined profiles are ietf-pmip, 3gpp, or new - profiles defined as extensions of this specification. + Remote-mobility-profile: The mobility-profile for the peering DPN- + group. Currently defined profiles are ietf-pmip, or 3gpp. New + profiles may be defined as extensions of this specification. - Remote-data-plane-role: Defines forwarding-plane role of peering - DPN-group. + Remote-data-plane-role: The data-plane role of the peering DPN- + group. Remote-endpoint-address: Defines Endpoint address of the peering DPN-group. Local-endpoint-address: Defines Endpoint address of its own DPN- group to peer the remote DPN-group. MTU-size: Defines MTU size of traffic between the DPN-Group and this DPN-group-peer. -5.1.3. DPNs - - 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. +4.1.3. Domains - A DPN may have multiple DPN-groups which are in different data-plane - roles or domains. Mobility sessions of that DPN-groups are installed - into actual data-plane nodes. The Agent defines DPN binding to - actual nodes. + A domain is defined by an operator to refer to a particular network, + considered as a system of cooperating DPN-groups. Domains may + represent services or applications that are resident within an + operator's network. (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 - Section 5.4. + Domain-id: Identifier of Domain. The ID format MUST conform to + 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 - the DPN. The Agent SHOULD maintain that nodes information - including IP address of management and control protocol to - connect them. + Domain-reference: Indicates a set of resources for the domain which + consists a topology of physical nodes, platforms of + virtualization and physical/virtual links with certain bandwidth, + etc,. -5.2. FPC-Policy +4.2. FPC-Policy The FPC-Policy consists of Descriptors, Actions, Policies and Policy- - groups, which can be viewed as configuration data while Contexts and - Ports are akin to structures that are instantiated on the Agent. The - Descriptors and Actions in a Policy referenced by a Port are active - when the Port is in a active Context, i.e. they can be applied to - traffic on a DPN. + groups. These can be viewed as configuration data, in contrast to + Contexts and Vports, which are structures that are instantiated on + the Agent. The Descriptors and Actions in a Policy referenced by a + Vport are active when the Vport is in an active Context, i.e. they + 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 - flow, such as those based on source and destination addresses, - protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet. Note - that Descriptors are extensibly defined by specific profiles which - 3gpp, ietf or other SDOs produce. Many specifications also use the - terms Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A - packet that meets the criteria of a Descriptor is said to satisfy, - pass or is consumed by the Descriptor. Descriptors are assigned an + Descriptors defines classifiers of specific traffic flows, such as + those based on source and destination addresses, protocols, port + numbers of TCP/UDP/SCTP/DCCP, or any way of classifying packets. + Descriptors are defined by specific profiles that may be produced by + 3gpp, ietf or other SDOs. Many specifications also use the terms + Filter, Traffic Descriptor or Traffic Selector [RFC6088]. A packet + that meets the criteria of a Descriptor is said to satisfy, pass or + be consumed by the Descriptor. Descriptors are assigned an identifier and contain a type and value. (FPC-Policy) | +---Descriptors | +---Descriptor-id | +---Descriptor-type | +---Descriptor-value Figure 7: Descriptor Model Structure - Descriptor-id: Identifier of Descriptor. The ID format SHOULD refer - to Section 5.4. + Descriptor-id: Identifier of Descriptor. The ID format MUST conform + to Section 4.4. - Descriptor-type: Defines descriptor type, which classifies specific - traffic flow, such as source and destination addresses, - protocols, port numbers of TCP/UDP/SCTP/DCCP or any packet. + Descriptor-type: The descriptor type, which determines the + classification of a specific traffic flows, such as source and + 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 - prefix/address, protocol number, port number, etc. + Descriptor-value: The value of Descriptor such as IP prefix/address, + protocol number, port number, etc. -5.2.2. Actions +4.2.2. Actions - List of Actions which defines treatment/actions to apply to - classified traffic meeting the criteria defined by Descriptors. - Actions include traffic management related activity such as shaping, - policing based on given bandwidth, and connectivity management - actions such as pass, drop, forward to given nexthop. Note that - Actions are extensibly defined by specific profiles which 3gpp, ietf - or other SDOs produce. + A Policy defines a list of Actions that are to be applied to traffic + meeting the criteria defined by the Descriptors. Actions include + traffic management such as shaping, policing based on given + bandwidth, and connectivity actions such as pass, drop, forward to + given nexthop. Actions may be defined as part of specific profiles + which are produced by 3gpp, ietf or other SDOs. (FPC-Policy) | +---Actions | +---Action-id | +---Action-type | +---Action-value Figure 8: Action Model Structure - Action-id: Identifier of Action. The ID format SHOULD refer to - Section 5.4. + Action-id: Identifier for the Action. The ID format MUST conform to + Section 4.4. - Action-type: Defines action type, i.e. how to treat the specified - traffic flow, e.g. pass, drop, forward to given nexthop value and - shape, police based on given bandwidth value, etc. + Action-type: The type of the action -- i.e. how to treat the + specified traffic flows. Examples include pass, drop, forward to + a given nexthop value, shape or police based on given bandwidth + value, etc. - Action-value: Specifies value of Action, such as bandwidth, nexthop - address or drop explicitly, etc. + Action-value: Specifies a value for the Action-type, such as + bandwidth, nexthop address or drop, etc. -5.2.3. Policies +4.2.3. Policies Policies are collections of Rules. Each Policy has a Policy Identifier and a list of Rule/Order pairs. The Order and Rule values MUST be unique in the Policy. Unlike the AND filter matching of each Rule the Policy uses an OR matching to find the first Rule whose Descriptors are satisfied by the packet. The search for a Rule to apply to packet is executed according to the unique Order values of the Rules. This is an ascending order search, i.e. the Rule with the lowest Order value is tested first and if its Descriptors are not satisfied by the packet the Rule with the next lowest Order value is tested. If a Rule is not found then the Policy does not apply. - Policies contain Rules as opposed to references to Rules. + Policies contain Rules (not references to Rules). (FPC-Policy) | +---Policies | +---Policy-id | +---Rules | +---Order @@ -601,165 +629,165 @@ +---Descriptors | | | +---Descriptor-id | | | +---Direction | +---Actions | +---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 - Section 5.4. + Policy-id: Identifier of Policy. The ID format MUST conform to + Section 4.4. Rules: List of Rules which are a collection of Descriptors and Actions. All Descriptors MUST be satisfied before the Actions are taken. This is known as an AND Descriptor list, i.e. - Descriptor 1 AND Descriptor 2 AND ... Descriptor X MUST be - satisfied for the Rule to apply. These are internal structure to - the Policy, i.e. it is not a first class, visible object at the - top level of an Agent. + Descriptor 1 AND Descriptor 2 AND ... Descriptor X all MUST be + satisfied for the Rule to apply. Order: Specifies ordering if the Rule has multiple Descriptors and - 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, - downstream or both. + Direction: Specifies which direction applies, such as uplink, + downlink or both. Actions: List of Actions. 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 applications include aggregating Policies that are defined by different functions, e.g. Network Address Translation, Security, etc. The structure has an Identifier and references the Policies via their Identifiers. (FPC-Policy) | +---Policy-groups | +---Policy-group-id | +---Policies Figure 10: Policy-group Model Structure - Policy-group-id: Identifier of Policy-group. The ID format SHOULD - refer to Section 5.4. + Policy-group-id: The identifier of the Policy-group. The ID format + MUST conform to Section 4.4. 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 - abstracted as a Context with its associated runtime concrete + The FPC-Mobility consists of Vports and Contexts. A mobility session + is abstracted as a Context with its associated runtime concrete attributes, such as tunnel endpoints, tunnel identifiers, delegated - prefix(es) and routing information, etc. A Port abstracts a set of + prefix(es) and routing information, etc. A Vport abstracts a set of 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 - that can exist independent of the mobility/session lifecycle. - Mobility control-plane or applications create, modify and delete - Ports on FPC Agent through the FPC Client. + A Vport represents a collection of policy groups, that is, a group of + rules that can exist independently of the mobility/session lifecycle. + Mobility control-plane applications create, modify and delete Vports + on FPC Agent through the FPC Client. - When a Port is indicated in a Context, the set of Descriptors and - Actions in the Policies of the Port are collected and applied to the + When a Vport is indicated in a Context, the set of Descriptors and + Actions in the Policies of the Vport are collected and applied to the Context. They must be instantiated on the DPN as forwarding related actions such as QoS differentiations, packet processing of encap/ decap, header rewrite, route selection, etc. (FPC-Mobility) | - +---Ports + +---Vports | - +---Port-id + +---Vport-id | +---Policy-groups - Figure 11: Port Model Structure + Figure 11: Vport Model Structure - Port-id: Identifier of Port. The ID format SHOULD refer to - Section 5.4. + Vport-id: The identifier of Vport. The ID format MUST conform to + Section 4.4. 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- - groups is abstracted as a Context with its associated runtime - concrete attributes, such as tunnel endpoints, tunnel identifiers, - delegated prefix(es) and routing information, etc. Mobility control- - plane or applications create, modify and delete contexts on FPC Agent - through the FPC Client. + An endpoint of a mobility session is abstracted as a Context with its + associated runtime concrete attributes, such as tunnel endpoints, + tunnel identifiers, delegated prefix(es) and routing information, + etc. A mobility control-plane, or other applications, can create, + modify and delete contexts on an FPC Agent by using the FPC Client. - A Context directly describes traffic treatment policies in QoS - profile and Mobility profiles or indirectly via Ports. Parameters in - these profiles may be set by the FPC Client directly or indirectly - derived from the set of Descriptors and Actions when the Ports - indicate Policies which specify those descriptors and actions. If a - Context doesn't have any Port, all parameters of the Context must be - set by the Client. + FPC Agent SHOULD determine runtime attributes of a Context from the + Vport's policies and the attached DPN's attributes. A mobility + control-plane, or other applications, MAY set some of the runtime + attributes directly when they create data-plane related attributes. + In the case of that a mobility control-plane assigns tunnel + identifiers, for instance. (FPC-Mobility) | +---Contexts | +---Context-id | - +---Ports + +---Vports | +---DPN-group | - +---Delegating-ip-prefixes + +---Delegated-ip-prefixes | +---Parent-context Figure 12: Common Context Model Structure - Context-id: Identifier of Context. The ID format SHOULD refer to - Section 5.4. + Context-id: Identifier of the Context. The ID format MUST conform + to Section 4.4. - Ports: List of Ports. When a Context is applied to Port(s), the - context is configured by policies of those Port(s). Port-id - references indicate Ports which apply to the Context. Context - can be a part of multiple Ports which have different policies. + Vports: List of Vports. When a Context is applied to a Vport, the + context is configured by policies at each such Vport. Vport-id + references indicate Vports which apply to the Context. Context + can be a spread over multiple Vports which have different + policies. DPN-group: The DPN-group assigned to the Context. - Delegating-ip-prefixes: List of IP prefixes to be delegated to the - mobile node of the context. + Delegated-ip-prefixes: List of IP prefixes to be delegated to the + 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 - maintain context data just for the DPN. The Agent does not need to - maintain a Topology model. The Context in single DPN case consists - of following parameters for both direction of uplink and downlink. + maintain Context data just for the DPN. The Agent does not need to + maintain a Topology model. Contexts in single DPN case consists of + following parameters for both direction of uplink and downlink. (Contexts) | +---UL-Tunnel-local-address | +---UL-Tunnel-remote-address | +---UL-MTU-size | +---UL-Mobility-specific-tunnel-parameters @@ -773,43 +801,44 @@ +---UL-Vendor-specific-parameters Figure 13: Uplink Context Model of Single DPN Structure UL-Tunnel-local-address: Specifies uplink endpoint address of the DPN. UL-Tunnel-remote-address: Specifies uplink endpoint address of the 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 - 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 profiles defined by extensions of this - specification. + uplink tunnel parameters to the DPN which the agent exists. This + may, for example, include GTP/TEID for 3gpp profile, or GRE/Key + for ietf-pmip profile. - 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 - 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 - parameter of uplink, such as QCI/TFT for 3gpp profile, - [RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by - extensions of this specification. + parameters of uplink, such as QCI/TFT for 3gpp profile, + [RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles + defined by extensions of this specification. UL-DPN-specific-parameters: Specifies optional node specific - 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. UL-Vendor-specific-parameters: Specifies a vendor specific parameter - space for uplink. + space for the uplink. (Contexts) | +---DL-Tunnel-local-address | +---DL-Tunnel-remote-address | +---DL-MTU-size | +---DL-Mobility-specific-tunnel-parameters @@ -823,51 +852,52 @@ +---DL-Vendor-specific-parameters Figure 14: Downlink Context Model of Single DPN Structure DL-Tunnel-local-address: Specifies downlink endpoint address of the DPN. DL-Tunnel-remote-address: Specifies downlink endpoint address of the 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 downlink 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 profiles defined by extensions of this - specification. + This may, for example, include GTP/TEID for 3gpp profile, or GRE/ + Key for ietf-pmip profile. - 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 - 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 - parameter of downlink, such as QCI/TFT for 3gpp profile, - [RFC6089]/[RFC7222] for ietf-pmip, or new profiles defined by - extensions of this specification. + parameters of downlink, such as QCI/TFT for 3gpp profile, + [RFC6089]/[RFC7222] for ietf-pmip, or parameters of new profiles + defined by extensions of this specification. 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. 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 - Agent 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 + Alternatively, a FPC Agent may connect to multiple DPNs. The Agent + MUST maintain a set of Context data for each DPN. The Context + 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 - 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'. (Contexts) | +---DPNs | +---DPN-id | +---Direction | @@ -882,456 +912,448 @@ +---Nexthop | +---QoS-profile-specific-parameters | +---DPN-specific-parameters | +---Vendor-specific-parameters 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, - "uplink", "downlink" or "both". + Direction: Specifies which side of connection at the DPN indicated - + uplink, downlink or both. Tunnel-local-address: Specifies endpoint address of the DPN at the uplink or downlink. Tunnel-remote-address: Specifies endpoint address of remote DPN at the uplink or downlink. MTU-size: Specifies the packet MTU size on uplink or downlink. Mobility-specific-tunnel-parameters: Specifies profile specific - tunnel parameters for uplink or downlink of the DPN. The - profiles includes GTP/TEID for 3gpp profile, GRE/Key for ietf- - pmip profile, or new profiles defined by extensions of this - specification. + tunnel parameters for uplink or downlink to the DPN. This may, + for example, include GTP/TEID for 3gpp profile, or GRE/Key for + ietf-pmip profile. - Nexthop: Indicates nexthop information for uplink or downlink in - external network of the DPN such as IP address, MAC address, SPI - of service function chain, SID of segment routing, etc. + Nexthop: Indicates next-hop information for uplink or downlink in + external network such as IP address, MAC address, SPI of service + 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 - parameter for uplink or downlink of the DPN, such as QCI/TFT for - 3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or new profiles - defined by extensions of this specification. + parameters for uplink or downlink to the DPN, such as QCI/TFT for + 3gpp profile, [RFC6089]/[RFC7222] for ietf-pmip, or parameters of + new profiles defined by extensions of this specification. DPN-specific-parameters: Specifies optional node specific parameters - for uplink or downlink of the DPN in need, such like if-index, + needed by uplink or downlink to the DPN such like if-index, tunnel-if-number that must be unique in the DPN. Vendor-specific-parameters: Specifies a vendor specific parameter space for the DPN. - 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 - both the Single Agent DPN model Section 5.3.2.1 and the multi-DPN - Agent Context described here. However, Agent feature support MUST be - discoverable by the FPC Client in order to determine which option(s) - an Agent supports. + both the Single Agent DPN model Section 4.3.2.1 and the multi-DPN + Agent Context described here. -5.3.3. Monitors +4.3.3. Monitors Monitors provide a mechanism to produce reports when events occur. A Monitor will have a target that specifies what is to be watched. When a Monitor is specified, the configuration MUST be applicable to - the attribute/entity monitored, e.g. a Monitor using a Threshold - configuration cannot be applied to a context but it can be applied to - a numeric property. + the attribute/entity monitored. For example, a Monitor using a + Threshold configuration cannot be applied to a Context, because + Contexts do not have thresholds. But such a monitor could be applied + to a numeric threshold property of a Context. (FPC-Mobility) | +---Monitors | +---Monitor-id | +---Target | +---Configuration Figure 16: Common Monitor Model Structure - Monitor-id: Name of the Monitor. The ID format SHOULD refer to - Section 5.4. + Monitor-id: Name of the Monitor. The ID format MUST conform to + Section 4.4. Target: Target to be monitored. This may be an event, a Context, a - Port or attribute(s) of Contexts. When the type is an + Vport or attribute(s) of Contexts. When the type is an attribute(s) of a Context, the target name is a concatenation of the Context-Id and the relative path (separated by '/') to the attribute(s)to be monitored. Configuration: Determined by the Monitor subtype. Four report types are defined: * Periodic reporting specifies an interval by which a notification is sent to the Client. - * Event reporting specifies a list of even types that, if they + * Event reporting specifies a list of event types that, if they 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 1, 1970) when a notification for the monitor should be sent to the Client. Once this Monitor's notification is completed the Monitor is automatically de-registered. * Threshold reporting specifies one or both of a low and high threshold. When these values are crossed a corresponding notification is sent to the Client. -5.4. Namespace and Format +4.4. Namespace and Format The identifiers and names in FPC models which reside in the same namespace must be unique. That uniqueness must be kept in agent or data-plane tenant namespace on an Agent. The tenant namespace uniqueness MUST be applied to all elements of the tenant model, i.e. Topology, Policy and Mobility models. When a Policy needs to be applied to Contexts in all tenants on an 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. The format of identifiers can utilize any format with agreement between data-plane agent and client operators. The formats include but are not limited to Globally Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs), Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names ( FQPNs) and Uniform Resource Identifiers (URIs). - The FPC model MUST NOT limit the types of format that dictate the - choice of FPC protocol. It is noted that the choice of identifiers - which are used in Mobility model should be suitable to handle runtime + The FPC model does not limit the types of format that dictate the + choice of FPC protocol. However the choice of identifiers which are + used in Mobility model need to be considered to handle runtime 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 - Agent prior to Contexts and Ports. Those pre-configured attributes - SHOULD NOT be instantiated on DPN(s) until the Contexts and Ports - indicate them. + Attributes in FPC Topology and Policy SHOULD be pre-configured in a + FPC Agent prior to Contexts and Vports. The FPC Agent requires those + pre-configured attributes to be able to derive a Context's detailed + runtime attributes. - This is intentional as it provides FPC Clients ability to reuse - attributes that helps to minimize over the wire exchanges and reduce - system errors by exchanging less information. + When a FPC Client creates a Context, the FPC Client is then able to + indicate specific DPN-group(s) instead of all endpoint addresses of + the DPN(s) and MTU-size of the tunnels for example. This is because + that the FPC Agent can derive data for those details from the pre- + configured DPN-group information in the FPC Topology. - When an Client creates Context, the Client would be able to indicate - just DPN-group(s) instead of all endpoint addresses of the DPN(s) and - MTU-size of the tunnels for example. This is because that the Agent - can derive data for those details from pre-configured DPN-group - information in the Topology. + Similarly when a Vport is created for the Context, the FPC Agent can + derive detailed forwarding policies from the pre-configured Policy + information in the FPC Policy. The FPC Client thereby has no need to + indicate those specific policies to all of the Contexts which share + the same set of Policy-groups. + + This is intentional as it provides FPC Clients the ability to reuse + 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 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 consequently instantiates forwarding policies on DPN(s) based - on that attributes. + Agent case) or directly under the Context (single-DPN Agent case). + The Agent consequently instantiates forwarding policies on DPN(s) + based on those attributes. - When the attribute is a direct value of the Context, e.g. IMSI - defined in the 3GPP extension, only missing values can be provided by - the Parent Context. + When a Context inherits another Context as its parent, missing + attributes in the child Context are provided by the Parent Context + (for example, IMSI defined in the 3GPP extension) . It is noted that the Agent SHOULD update the Context's attributes which are instantiated on DPN(s) when the applied attributes of Topology and Policy are changed. -5.6. Policy and Runtime Data - - Contexts and Ports that are supporting runtime, realtime mobility - sessions which are produced in the mobility control plane. These - could be installed using any number of protocols, but in case of they - 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. + In the case of FPC Client modifying an existing runtime attribute of + a Context which the FPC Agent derived, the FPC Agent MUST overwrite + that attribute with the value which the Client brings to the Agent. + However risks exist, for example, the attributes could be outside of + allowable range of DPNs which the FPC Agent managed. -6. Protocol +5. Protocol -6.1. Protocol Messages and Semantics +5.1. Protocol Messages and Semantics Five message types are supported: +---------------+----------------+----------------------------------+ | Message | Type | Description | +---------------+----------------+----------------------------------+ | CONF | HEADER | Configure processes a single | | | ADMIN_STATE | operation. | | | SESSION_STATE | | | | OP_TYPE BODY | | | | | | - | CONF_BUNDLES | 1*[HEADER | Configure-bundles takes multiple | + | CONF_BUNDLE | 1*[HEADER | A Conf-bundle takes multiple | | | ADMIN_STATE | operations that are to be | | | SESSION_STATE | executed as a group with partial | | | TRANS_STRATEGY | failures allowed. They are | | | OP_TYPE BODY] | executed according to the OP_ID | | | | value in the OP_BODY in | | | | ascending order. If a | - | | | CONFIGURE_BUNDLES fails, any | - | | | entities provisioned in the | - | | | CURRENT operation are removed, | - | | | however, any successful | - | | | operations completed prior to | - | | | the current operation are | - | | | preserved in order to reduce | - | | | system load. | + | | | CONF_BUNDLE fails, any entities | + | | | provisioned in the CURRENT | + | | | operation are removed. However, | + | | | any successful operations | + | | | completed prior to the current | + | | | operation are preserved in order | + | | | to reduce system load. | | | | | - | REG_MONITOR | HEADER | Install a monitor at an Agent. | + | REG_MONITOR | HEADER | Register a monitor at an Agent. | | | ADMIN_STATE *[ | The message includes information | | | MONITOR ] | about the attribute to monitor | | | | and the reporting method. Note | | | | that a MONITOR_CONFIG is | | | | required for this operation. | | | | | - | DEREG_MONITOR | HEADER *[ | Remove monitors from an Agent. | - | | MONITOR_ID ] [ | Monitor IDs are provided. | + | DEREG_MONITOR | HEADER *[ | Deregister monitors from an | + | | MONITOR_ID ] [ | Agent. Monitor IDs are provided. | | | boolean ] | Boolean (optional) indicates if | | | | a successful DEREG triggers a | | | | NOTIFY with final data. | | | | | | PROBE | HEADER | Probe the status of a registered | | | MONITOR_ID | monitor. | +---------------+----------------+----------------------------------+ Table 1: Client to Agent Messages Each message contains a header with the Client Identifier, an execution delay timer and an operation identifier. The delay, in ms, is processed as the delay for operation execution from the time the operation is received by the Agent. The Client Identifier is used by the Agent to associate specific configuration characteristics, e.g. options used by the Client when communicating with the Agent, as well as the association of the Client and tenant in the information model. - Messages that create or update Monitors and Entities, i.e. CONF, - CONF_BUNDLES and REG_MONITOR, specify an Administrative State which + Messages that create or update Monitors and Entities, i.e. CONFIG, + CONF_BUNDLE and REG_MONITOR, specify an Administrative State which specifies the Administrative state of the message subject(s) after the successful completion of the operation. If the status is set to virtual, any existing data on the DPN is removed. If the value is - set to disabled, then an operation to disable the associated entity - will occur on the DPN IF that entity exists on the DPN. If set to - 'active' the DPN will be provisioned. Values are 'enabled', - 'disabled' or 'virtual'. + set to disabled, and if that entity exists on the DPN, then an + operation to disable the associated entity will occur on the DPN . If + set to 'active' the DPN will be provisioned. Values are 'enabled', + 'disabled', and 'virtual'. - CONF_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 - operation fails while prodessing a CONF_BUNDLES message. The value - of 'default' uses the default strategy defined for the message. The + operation fails while processing a CONF_BUNDLE message. The value of + 'default' uses the default strategy defined for the message. The value 'all_or_nothing' will roll back all successfully executed operations within the bundle as well as the operation that failed. - It is important to note that an envelope protocol used to support - this specification may not need to support CONF_BUNDLES messages or - specific TRANS_STRATEGY types beyond 'default' when the protocol - provides similar semantics. However, this MUST be clearly defined in - the specification that defines how the envelope protocol supports - this specificaiton. + An FPC interface protocol used to support this specification may not + need to support CONF_BUNDLE messages or specific TRANS_STRATEGY types + beyond 'default' when the protocol provides similar semantics. + However, this MUST be clearly defined in the specification that + defines the interface protocol. - An Agent will respond with an error, ok, or an ok with indication + An Agent will respond with an ERROR, OK, or an OK WITH INDICATION 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. Two Agent notifications are supported: +----------------------+----------+---------------------------------+ | Message | Type | Description | +----------------------+----------+---------------------------------+ | CONFIG_RESULT_NOTIFY | See | An asynchronous notification | | | Table 15 | from Agent to Client based upon | | | | a previous CONFIG or | - | | | CONFIG_BUNDLES request. | + | | | CONF_BUNDLE request. | | | | | | NOTIFY | See | An asynchronous notification | | | Table 16 | from Agent to Client based upon | | | | a registered MONITOR. | +----------------------+----------+---------------------------------+ 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: SESSION_STATE: sets the expected state of the entities embedded in the operation body after successful completion of the operation. Values can be 'complete', 'incomplete' or 'outdated'. Any operation that is 'incomplete' MAY NOT result in communication between the Agent and DPN. If the result is 'outdated' any new operations on these entities or new references to these entities have unpredictable results. OP_TYPE: specifies the type of operation. Valid values are 'create' (0), 'update' (1), 'query' (2) or 'delete' (3). - COMMAND_SET: specifies the Command Set IF the feature is supported - (see Section 6.1.1.4). + COMMAND_SET: If the feature is supported, specifies the Command Set + (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 - Targets for 'query' or 'deletion'. See Section 7.2.2 for + Targets for 'query' or 'deletion'. See Section 6.2.2 for 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 following order: 1. Clone Instructions, if the feature is supported - 2. Ports + 2. Vports 3. Contexts according to COMMAND_SET order processing The following Order Processing occurs when COMMAND Sets are present - 1. The Entity specific COMMAND_SET is processed according to its bit + 1. The Entity-specific COMMAND_SET is processed according to its bit order unless otherwise specified by the technology specific COMMAND_SET definition. 2. Operation specific COMMAND_SET is processed upon all applicable - entities (even if they had Entity specific COMMAND_SET values + entities (even if they had Entity-specific COMMAND_SET values present) according to its bit order unless otherwise specified by the technology specific COMMAND_SET definition. 3. Operation OP_TYPE is processed for all entities. When deleting objects only their name needs to be provided. However, attributes MAY be provided if the Client wishes to avoid requiring the Agent cache lookups. When deleting an attribute, a leaf reference should be provided. This is a path to the attributes. -6.1.1.2. Policy RPC Support +5.1.1.2. Policy RPC Support 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. -6.1.1.3. Cloning +5.1.1.3. Cloning Cloning is an optional feature that allows a Client to copy one structure to another in an operation. Cloning is always done first within the operation (see Operation Order of Execution for more detail). If a Client wants to build an object then Clone it, use - CONFIG_BUNDLES with the first operation being the entities to be - copied and a second operation with the Cloning instructions. A CLONE + CONF_BUNDLE with the first operation being the entities to be copied + and a second operation with the Cloning instructions. A CLONE operation takes two arguments, the first is the name of the target to clone and the second is the name of the newly created entity. - Individual attributes are not clonable; only Ports and Contexts can + Individual attributes are not clonable; only Vports and Contexts can 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 single entity to be sent in an operation with requested sub- transactions to be completed. For example, a Context could have the Home Network Prefix absent but it is unclear if the Client would like the address to be assigned by the Agent or if this is an error. Rather than creating a specific command for assigning the IP a bit position in a COMMAND_SET is reserved for Agent based IP assignment. Alternatively, an entity could be sent in an update operation that would be considered incomplete, e.g. missing some required data in for the entity, but has sufficient data to complete the instructions provided in the COMMAND_SET. -6.1.1.5. Reference Scope +5.1.1.5. Reference Scope The Reference Scope is an optional feature that provides the scope of references used in a configuration command, i.e. CONFIG or - CONFIG_BUNDLES. These scopes are defined as + CONF_BUNDLE. These scopes are defined as o none - all entities have no references to other entities. This - implies only Contexts are present Ports MUST have references to + implies only Contexts are present. Vports MUST have references to Policy-Groups. o op - All references are contained in the operation body, i.e. only - intra-operaion references exist. + intra-operation references exist. - o bundle - All references in exist in bundle (inter-operation/intra- - bundle). NOTE - If this value comes in CONFIG call it is - equivalent to 'op'. + o bundle - All references exist in bundle (inter-operation/intra- + bundle). NOTE - If this value is present in a CONFIG message it + is equivalent to 'op'. o storage - One or more references exist outside of the operation and bundle. A lookup to a cache / storage is required. o unknown - the location of the references are unknown. This is treated as a 'storage' type. If supported by the Agent, when cloning instructions are present, the - scope MUST NOT be 'none'. When Ports are present the scope MUST be + scope MUST NOT be 'none'. When Vports are present the scope MUST be 'storage' or 'unknown'. An agent that only accepts 'op' or 'bundle' reference scope messages is referred to as 'stateless' as it has no direct memory of references outside messages themselves. This permits low memory footprint Agents. Even when an Agent supports all message types an 'op' or 'bundle' scoped message can be processed quickly by the Agent as it does not require storage access. -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 the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS values are: - OK - SUCCESS + OK - Success ERR - An Error has occurred OK_NOTIFY_FOLLOWS - The Operation has been accepted by the Agent but further processing is required. A CONFIG_RESULT_NOTIFY will be sent once the processing has succeeded or failed. - Any result MAY contain nothing or a entities created or partially + Any result MAY contain nothing or entities created or partially fulfilled as part of the operation as specified in Table 14. For Clients that need attributes back quickly for call processing, the AGENT MUST respond back with an OK_NOTIFY_FOLLOWS and minimally the attributes assigned by the Agent in the response. These situations MUST be determined through the use of Command Sets (see - Section 6.1.1.4). + Section 5.1.1.4). If an error occurs the following information is returned. ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error type ERROR_INFORMATION - An OPTIONAL string of no more than 1024 characters. -6.1.1.6.2. Asynchronous Notification +5.1.1.6.2. Asynchronous Notification A CONFIG_RESULT_NOTIFY occurs after the Agent has completed - processing related to a CONFIG or CONFIG_BUNDLES request. It is an + processing related to a CONFIG or CONF_BUNDLE request. It is an asynchronous communication from the Agent to the Client. 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 automatically de-registered after the NOTIFY occurs. An Agent or DPN may temporarily suspend monitoring if insufficient resources exist. In such a case the Agent MUST notify the Client. All monitored data can be requested by the Client at any time using the PROBE message. Thus, reporting configuration is optional and when not present only PROBE messages may be used for monitoring. If a SCHEDULED or PERIODIC configuration is provided during registration @@ -1342,69 +1364,69 @@ needs and lets the Agent realize the Client has no further need for the monitor to be registered. An Agent may reject a registration if it or the DPN has insufficient resources. PROBE messages are also used by a Client to retrieve information about a previously installed monitor. The PROBE message SHOULD identify one or more monitors by means of including the associated monitor identifier. An Agent receiving a PROBE message sends the requested information in a single or multiple NOTIFY messages. -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 the RESULT_STATUS and OP_ID that it corresponds to. RESULT_STATUS values are: - OK - SUCCESS + OK - Success ERR - An Error has occurred Any OK result will contain no more information. If an error occurs the following information is returned. ERROR_TYPE_ID (Unsigned 32) - The identifier of a specific error type ERROR_INFORMATION - An OPTIONAL string of no more than 1024 characters. -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 - Monitor Configuration or a PROBE. A NOTIFY is comprised of unique + A NOTIFY can be sent as part of de-registraiton, a trigger based upon + a Monitor Configuration or a PROBE. A NOTIFY is comprised of unique Notification Identifier from the Agent, the Monitor ID the notification applies to, the Trigger for the notification, a timestamp of when the notification's associated event occurs and data 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 AGT_ID respectively to ensure that for all transactions a recipient of an FPC message can unambiguously identify the sender of the FPC message. A Client MAY direct the Agent to enforce a rule in a particular DPN by including a DPN_ID value in a Context. Otherwise the Agent selects a suitable DPN to enforce a Context and notifies the Client about the selected DPN using the DPN_ID. All messages sent from a Client to an Agent MUST be acknowledged by the Agent. The response must include all entities as well as status information, which indicates the result of processing the message, using the RESPONSE_BODY property. In case the processing of the message results in a failure, the Agent sets the ERROR_TYPE_ID and - ERROR_INFORMATION accordingly and MAY clear the Context or Port, + ERROR_INFORMATION accordingly and MAY clear the Context or Vport, which caused the failure, in the response. If based upon Agent configuration or the processing of the request possibly taking a significant amount of time the Agent MAY respond with an OK_NOTIFY_FOLLOWS with an optional RESPONSE_BODY containing the partially completed entities. When an OK_NOTIFY_FOLLOWS is sent, the Agent will, upon completion or failure of the operation, respond with an asynchronous CONFIG_RESULT_NOTIFY to the Client. A Client MAY add a property to a Context without providing all @@ -1467,46 +1489,46 @@ | | |Edge| |<---(4)- OK --------------| | | | |DPN2| | | | | | +----+ | | | | | | | | | | | |-============================================-| | | | | | Figure 17: Exemplary Message Sequence (focus on FPC reference point) 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 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 the associated DPN identifier. The LMA-C adds properties during the creation of the new Context. One property is added to specify the forwarding tunnel type and endpoints (Anchor DPN, Edge DPN1) in each direction (as required). Another property is added to specify the QoS differentiation, which the MN's traffic should experience. At reception of the Context, the FPC Agent utilizes local configuration commands to create the tunnel (tun1) as well as the traffic control (tc) to enable QoS differentiation. After configuration has been completed, the Agent 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 interface (tun1). 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) 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 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). +-------Router--------+ +-----------+ |+-------+ +---------+| +------+ +------+ +-----+ FPC | | FPC | | Anchor | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | +------+ +------+ +-----+-------+ +-------+ +---------+ [MN attach] | | | | |-------------PBU----->| | | | | |---(1)--CONFIG(MODIFY)--->| | @@ -1521,30 +1543,30 @@ | | |---(3)--CONFIG(DELETE)--->|-- tun1 -->| | | | | delete | | | |<-(4)- OK ----------------| | | | | |-- route ->| | | | | remove | | | | | | 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 - lifetime value of zero. The LMA-C sends a CONFIGURE message (1) to - the Agent to modify the existing tunnel property of the existing - Context to delete the tunnel information.) Upon reception of the - CONFIGURE message, the Agent removes the tunnel configuration and - responds to the Client (2). Per [RFC5213], the PBA is sent back - immediately after the PBA is received. + lifetime value of zero. The LMA-C sends a CONFIG message (1) to the + Agent to modify the existing tunnel property of the existing Context + to delete the tunnel information.) Upon reception of the CONFIG + message, the Agent removes the tunnel configuration and responds to + the Client (2). Per [RFC5213], the PBA is sent back immediately + after the PBA is received. If no valid PBA is received after the expiration of the MinDelayBeforeBCEDelete timer (see [RFC5213]), the LMA-C will send a - CONFIGURE (3) message with a deletion request for the Context. Upon + CONFIG (3) message with a deletion request for the Context. Upon reception of the message, the Agent deletes the tunnel and route on the DPN and responds to the Client (4). When a multi-DPN Agent is used the DPN list permits several DPNs to be provisioned in a single message. +-----------+ +-------+ +---------+ +------+ +------+ +-----+ FPC | | FPC | | Anchor | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN1 | +------+ +------+ +-----+-------+ +-------+ +---------+ @@ -1570,41 +1592,41 @@ | |<---------------------- route add -----------| | | | | | | | | |<(3) CONFIG_RESULT_NOTIFY | | | | | [ Response Data ] | | | | | | | Figure 19: Exemplary Message Sequence for Multi-DPN Agent 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 - 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 shows the DPNS list with all entries. Each entry identifies the DPN and direction (one of 'uplink', 'downlink' or 'both'). Generally, the 'both' direction is not used for normal mobility session - processing. It is commonly used for the instantaition of Policies on - a specific DPN (see Section 6.2.4). + processing. It is commonly used for the instantiation of Policies on + a specific DPN (see Section 5.2.4). The Agent responds with an OK_NOTIFY_FOLLOWS while it simultaneoulsy provisions both DPNs. Upon successful completion, the Agent responds to the Client with a CONFIG_RESULT_NOTIFY indicating the operation 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 Agent. Such entities are not always required to be constructed in realtime and, therefore, there are no specific messages defined for them in this specification. - The Client may add, modify or delete many 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 Descriptors, i.e. a Rule. As example, a Rule which performs re- writing of an arriving packet's destination IP address from IP_A to IP_B matching an associated Descriptor, can be enforced in the Data- Plane via an Agent to implicitly consider matching arriving packet's source IP address against IP_B and re- write the source IP address to IP_A. Figure 20 illustrates the generic policy configuration model as used between a FPC Client and a FPC Agent. @@ -1615,45 +1637,45 @@ +------+ /Order#/-------------+ +------+ | | Descriptor_3 -+ +- Action_3 +- | | | ^ Descriptor_4 -+----+- Action_4 | | +------+ | /Order#/-------------+ ^ +------+ | - + +-------------------+ +---------------------+ | Bind 1..M traffic | | Bind 1..N traffic | | Descriptors to | --> | treatment actions | | a Policy, | | to a Policy, | | Policy-Group and | | Policy-Group and | - | Port | | Port | + | Vport | | Vport | +-------------------+ +---------------------+ | | +-------------- 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 mechanism including RPC or N. A Client and Agent use the identifier of the associated Policy to directly access the Rule and perform modifications of traffic Descriptors or Action references. A Client and Agent use the identifiers to access the Descriptors or Actions to perform modifications. From the viewpoint of packet processing, arriving packets are matched against traffic Descriptors and processed according to the treatment Actions specified in the list of - properties associated with the Port. + properties associated with the Vport. A Client complements a rule's Descriptors with a Rule's Order (priority) value to allow unambiguous traffic matching on the Data- Plane. Figure 21 illustrates the generic context configuration model as used between a FPC Client and a FPC Agent. TrafficSelector_1 | @@ -1688,31 +1710,31 @@ Descriptors and processed according to the qos or other mobility profile related Actions specified in the Context's properties. If present, the final action is to use a Context's tunnel information to encapsulate and forward the packet. A second Context also references context1 in the figure. Based upon the technology a property in a parent context MAY be inherited by its descendants. This permits concise over the wire representation. When a Client deletes a parent Context all children are also deleted. -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 bundling of requests into a single operation. In the example below two PMIP sessions are created via two PBU messages and sent to the - Agent in a single CONFIGURE message (1). Upon recieveing the - message, the Agent responds back with an OK_NOTIFY_FOLLOWS (2), - completes work on the DPN to activate the associated sessions then - responds to the Client with a CONFIG_RESULT_NOTIFY (3). + Agent in a single CONFIG message (1). Upon recieveing the message, + the Agent responds back with an OK_NOTIFY_FOLLOWS (2), completes work + on the DPN to activate the associated sessions then responds to the + Client with a CONFIG_RESULT_NOTIFY (3). +-------Router--------+ +-----------+ |+-------+ +---------+| +------+ +------+ +-----+ FPC | | FPC | | Anchor | |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | +------+ +------+ +-----+-------+ +-------+ +---------+ [MN1 attach] | | | | |-------------PBU----->| | | | [MN2 attach] | | | | |---PBU----->| | | @@ -1731,111 +1753,111 @@ |<------------PBA------| | | | | | |-route2 | | | |<(3) CONFIG_RESULT_NOTIFY | add> | | | | [ Response Data ] | | | | | | | | | | | | Figure 22: Exemplary Bulk Entity with Asynchronous Notification 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 message. Operations in a bundle MUST be successfully executed in the order specified. This allows references created in one operation to be used in a subsequent operation in the bundle. The example bundle shows in Operation 1 (OP 1) the creation of a Context 1 which is then referenced in Operation 2 (OP 2) by CONTEXT_ID 2. If OP 1 fails then OP 2 will not be executed. The - advantage of the CONFIGURE_BUNDLES is preservation of dependency - orders in a single message as opposed to sending multiple CONFIGURE - messages and awaiting results from the Agent. + advantage of the CONF_BUNDLE is preservation of dependency orders in + a single message as opposed to sending multiple CONFIG messages and + awaiting results from the Agent. - When a CONFIGURE_BUNDLES fails, any entities provisioned in the - CURRENT operation are removed, however, any successful operations - completed prior to the current operation are preserved in order to - reduce system load. + When a CONF_BUNDLE fails, any entities provisioned in the CURRENT + operation are removed, however, any successful operations completed + prior to the current operation are preserved in order to reduce + system load. +-------Router--------+ +-----------+ |+-------+ +---------+| | FPC | | FPC | | Anchor | | Client | | Agent | | DPN | +-----------+ +-------+ +---------+ | | | - |-CONFIG_BUNDLES(CREATE)-->| | - | [ OP 1, [PORT X ] | | + |--CONF_BUNDLE(CREATE)---->| | + | [ OP 1, [VPORT X ] | | | [ CONTEXT_ID 1, | | | DOWNLINK(QOS/TUN), | | | UPLINK(QOS/TUN), | | | IP_PREFIX(HNP) ] | | | [ OP 2, | | | [ CONTEXT_ID 2, | | | PARENT_CONTEXT_ID 1, | | | UPLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN) ] ] | | | | | Figure 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 below shows a single Context that will be copied two times. A - subsequent update then overrides the value. The avoid the accidental - activation of the Contexts on the DPN, the CONFIGURE (1) message with - the cloning instruction has a SESSION_STATE with a value of - 'incomplete' and OP_TYPE of 'CREATE'. A second CONFIGURE (2) is sent + subsequent update will then override copied values. To avoid the + accidental activation of the Contexts on the DPN, the CONFIG (1) + message with the cloning instruction has a SESSION_STATE with a value + of 'incomplete' and OP_TYPE of 'CREATE'. A second CONFIG (2) is sent with the SESSION_STATE of 'complete' and OP_TYPE of 'UPDATE'. The second message includes any differences between the original (copied) Context and its Clones. +-------Router--------+ +-----------+ |+-------+ +---------+| | FPC | | FPC | | Anchor | | Client | | Agent | | DPN | +-----------+ +-------+ +---------+ | | | - |-CONFIG_BUNDLES(CREATE)-->| | + |--CONF_BUNDLE(CREATE)---->| | | [ OP 1, | | | [ SESSION_STATE | | | (incomplete) ], | | | [CLONE SRC=2, TARGET=3], | | | [CLONE SRC=2, TARGET=4], | | | [ CONTEXT_ID 2, | | | PARENT_CONTEXT_ID 1, | | | UPLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN), | | | IP_PREFIX(HNP) ] ] | | |<----- OK ----------------| | | | | - |-CONFIG_BUNDLES(UPDATE)-->| | + |--CONF_BUNDLE(UPDATE)--->| | | [ CONTEXT_ID 3, | | | PARENT_CONTEXT_ID(empty),| | | UPLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN) ], | | | [ CONTEXT_ID 4, | | | PARENT_CONTEXT_ID(empty),| | | UPLINK(QOS/TUN), | | | DOWNLINK(QOS/TUN) ] ] | | |<----- OK ----------------| | | | | Figure 24: Exemplary Bundle Message (focus on FPC reference point) Cloning has the added advantage of reducing the over the wire data size required to create multiple entities. This can improve performance if serialization / deserialization of multiple entities incurs some form of performance penalty. -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 structure, e.g. CONTEXT, and specify which activities are expected to be performed on the DPN. This has some advantages o Rather than sending N messages with a single operation performed on the DPN a single message can be used with a Command Set that specifies the N DPN operations to be executed. o Errors become more obvious. For example, if the HNP is NOT @@ -1858,43 +1880,43 @@ As Command Bitsets are technology specific, e.g. PMIP or 3GPP Mobility, the type of work varies on the DPN and the amount of data present in a Context or Port will vary. Using the technology specific instructions allows the Client to serve multiple technologies and MAY result in a more stateless Client as the instructions are transferred the Agent which will match the desired, technology specific instructions with the capabilities and over the wire protocol of the DPN more efficiently. -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 - 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 - 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 permits the Agent to understand when it can stop searching for - reference it cannot find. For example, if a CONFIG_BUNDLES message - uses a Reference Scope of type 'op' then it merely needs to keep an + reference it cannot find. For example, if a CONF_BUNDLE message uses + a Reference Scope of type 'op' then it merely needs to keep an operation level cache and consume no memory or resources searching - across the many operations in the CONFIG_BUNDLES message or the data + across the many operations in the CONF_BUNDLE message or the data store. Agents can also be stateless by only supporting the 'none', 'op' and 'bundle' reference scopes. This does not imply they lack storage but merely the search space they use when looking up references for an entity. The figure below shows the caching hierarchy provided by the Reference Scope Caches are temporarily created at each level and as the scope includes more caches the amount of entities that are searched - increases. Figure 25 shows an example cache where each Cache where a - containment hierarchy is provided for all caches. + increases. Figure 25 shows an example containment hierarchy provided + for all caches. +---------------+ | Global Cache | | (storage) | +------+--------+ | +----------------------+ | | +------+--------+ +------+--------+ | Bundle Cache | | Bundle Cache | @@ -1905,87 +1927,87 @@ | | | +--------+---------+ +--------+---------+ +--------+---------+ | Operation Cache | | Operation Cache | | Operation Cache | | (op) | | (op) | | (op) | +------------------+ +------------------+ +------------------+ (no 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, - 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 - 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 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 - Policy-group, policy-group1, using a Context set aside for pre- - provisioning on a DPN. + The figure below shows a CONFIG (1) message used to install a Policy- + group, policy-group1, using a Context set aside for pre-provisioning + on a DPN. +-------Router--------+ +-----------+ |+-------+ +---------+| | FPC | | FPC | | Anchor | | Client | | Agent | | DPN | +-----------+ +-------+ +---------+ | | | |------CONFIG(CREATE)----->| | - | [ PORT_ID port1, | | + | [ VPORT_ID port1, | | | [ policy-group1 ] ] | | | [ CONTEXT_ID preprov, | | | DPN_ID X, | | | [ port1 ] ] | | | | | 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 Clients and tenants with common scopes, referred to in this specification as BaseNames, to track the state of provisioned policy information on an Agent. The registry records the BaseName and Checkpoint set by a Client. If a new Client attaches to the Agent it can query the Registry to determine the amount of work that must be executed to configure the Agent to a BaseName / checkpoint revision. A State value is also provided in the registry to help Clients coordinate work on common BaseNames. -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 | +--------------+-----------------+----------------------------+ - | ACTION | ACTION_ID | FPC-Identity (Section 5.4) | + | ACTION | ACTION_ID | FPC-Identity (Section 4.4) | | | | | | ACTION | TYPE | [32, unsigned integer] | | | | | | 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 | 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-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 5.4) | + | POLICY-GROUP | POLICY_GROUP_ID | FPC-Identity (Section 4.4) | | | | | | POLICY-GROUP | POLICIES | *[ POLICY_ID ] | +--------------+-----------------+----------------------------+ Table 3: Action Fields Policies contain a list of Rules by their order value. Each Rule contains Descriptors with optional directionality and Actions with order values that specifies action execution ordering if the Rule has multiple actions. @@ -1994,68 +2016,67 @@ +------------------+---------------+--------------------------------+ | Field | Type | Sub-Fields | +------------------+---------------+--------------------------------+ | ORDER | [16, INTEGER] | | | | | | | RULE_DESCRIPTORS | *[ | DIRECTION [2, unsigned bits] | | | DESCRIPTOR_ID | is an ENUMERATION (uplink, | | | DIRECTION ] | downlink or both). | | | | | - | RULE_ACTIONS | *[ ACTION_ID | ORDER [8, unsigned integer] | - | | ORDER ] | specifies action execution | - | | | order. | + | RULE_ACTIONS | *[ ACTION_ID | ACTION-ORDER [8, unsigned | + | | ACTION-ORDER | integer] specifies action | + | | ] | execution order. | +------------------+---------------+--------------------------------+ Table 4: Rule Fields -7.1.2. Mobilty Structures +6.1.2. Mobility Structures +----------+----------------------------+ | Field | Type | +----------+----------------------------+ - | PORT_ID | FPC-Identity (Section 5.4) | + | VPORT_ID | FPC-Identity (Section 4.4) | | | | | POLICIES | *[ POLICY_GROUP_ID ] | +----------+----------------------------+ - Table 5: Port Fields + Table 5: Vport Fields - +------------------------+------------------------------------+ + +-----------------------+--------------------------------------+ | 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 | | | | | 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 | - +------------------------+------------------------------------+ + +-----------------------+--------------------------------------+ Table 6: Context Fields NOTE 1 - These fields are present when the Agent supports only a single DPN. - NOTE 2 - This fields is present when the Agent supports multiple - DPNs. + NOTE 2 - This field is present when the Agent supports multiple DPNs. +---------------------------+---------------------+-----------------+ | Field | Type | Detail | +---------------------------+---------------------+-----------------+ | TUN_LOCAL_ADDRESS | IP Address | [NOTE 1] | | | | | | TUN_REMOTE_ADDRESS | IP Address | [NOTE 1] | | | | | | TUN_MTU | [32, unsigned | | | | integer] | | @@ -2100,84 +2121,86 @@ | | | | | VENDOR_SPECIFIC_PARAM | *[ Varies ] | [NOTE 1] | +---------------------------+---------------------+-----------------+ NOTE 1 - These parameters are extensible. The Types may be extended for Field value by future specifications or in the case of Vendor Specific Attributes by enterprises. Table 7: Context Downlink/Uplink Field Definitions -7.1.3. Topology Structures +6.1.3. Topology Structures +----------------+------------------------------------+ | Field | Type | +----------------+------------------------------------+ - | DPN_ID | FPC-Identity. See Section 5.4 | + | DPN_ID | FPC-Identity. See Section 4.4 | | | | | 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] | +----------------+------------------------------------+ Table 8: DPN Fields - +-------------+----------------------+ + +------------------+----------------------+ | Field | Type | - +-------------+----------------------+ + +------------------+----------------------+ | DOMAIN_ID | [1024, OCTET STRING] | | | | | DOMAIN_NAME | [1024, OCTET STRING] | | | | | DOMAIN_TYPE | [1024, OCTET STRING] | - +-------------+----------------------+ + | | | + | DOMAIN_REFERENCE | [1024, OCTET STRING] | + +------------------+----------------------+ Table 9: Domain Fields +------------------+------------------------------------------------+ | 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- | | | dpn, L2/L3 anchor-dpn.)] | | | | | ACCESS_TYPE | [4, ENUMERATION ()ethernet(802.3/11), 3gpp | | | cellular(S1,RAB)] | | | | | MOBILITY_PROFILE | [4, ENUMERATION (ietf-pmip, 3gpp, or new | | | profile)] | | | | | PEER_DPN_GROUPS | * [ DPN_GROUP_ID MOBILITY_PROFILE | | | REMOTE_ENDPOINT_ADDRESS LOCAL_ENDPOINT_ADDRESS | | | TUN_MTU DATA_PLANE_ROLE ] | +------------------+------------------------------------------------+ Table 10: DPN Groups Fields -7.1.4. Monitors +6.1.4. Monitors +------------------+----------------------+-------------------------+ | Field | Type | Description | +------------------+----------------------+-------------------------+ | MONITOR | MONITOR_ID TARGET | | | | [REPORT_CONFIG] | | | | | | | MONITOR_ID | FPC-Identity. See | | - | | Section 5.4 | | + | | Section 4.4 | | | | | | | EVENT_TYPE_ID | [8, Event Type ID] | Event Type (unsigned | | | | integer). | | | | | | TARGET | OCTET STRING (See | | - | | Section 5.3.3) | | + | | Section 4.3.3) | | | | | | | REPORT_CONFIG | [8, REPORT-TYPE] | | | | [TYPE_SPECIFIC_INFO] | | | | | | | PERIODIC_CONFIG | [32, period] | report interval (ms). | | | | | | THRESHOLD_CONFIG | [32, low] [32, hi] | thresholds (at least | | | | one value must be | | | | present) | | | | | @@ -2197,159 +2220,159 @@ o HIGH_THRESHOLD_CROSSED o PERIODIC_REPORT o SCHEDULED_REPORT o PROBED 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: +-------------+------------------------+----------------------------+ | Field | Type | Messages | +-------------+------------------------+----------------------------+ | CLIENT_ID | FPC-Identity (Section | All | - | | 5.4) | | + | | 4.4) | | | | | | | DELAY | [32, 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 | | | | | - | OP_TYPE | [8, op type] | CONF and CONF_BUNDLES | + | OP_TYPE | [8, op type] | CONFIG and CONF_BUNDLE | +-------------+------------------------+----------------------------+ 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), | | | | Update(U), Query(Q) and | | | | Delete(D) | +---------------+----------------------+----------------------------+ | SESSION_STATE | [8, session state] | C,U | | | | | | COMMAND_SET | FPC Command Bitset. | C,U [NOTE 1] | - | | See Section 6.1.1.4. | | + | | See Section 5.1.1.4. | | | | | | | CLONES | *[ FPC-Identity FPC- | C,U [NOTE 1] | | | Identity ] (Section | | - | | 5.4) | | + | | 4.4) | | | | | | - | PORTS | *[ PORT ] | C,U | + | VPORTS | *[ VPORT ] | C,U | | | | | | CONTEXTS | *[ CONTEXT [ | C,U | | | COMMAND_SET [NOTE 1] | | | | ] ] | | | | | | | TARGETS | FPC-Identity | Q,D | - | | (Section 5.4) | | + | | (Section 4.4) | | | | *[DPN_ID] | | | | | | | POLICY_GROUPS | *[ POLICY-GROUP ] | C,U [NOTE 1] | | | | | | POLICIES | *[ POLICY ] | C,U [NOTE 1] | | | | | | DESCRIPTORS | *[ DESCRIPTOR ] | C,U [NOTE 1] | | | | | | ACTIONS | *[ ACTION ] | C,U [NOTE 1] | +---------------+----------------------+----------------------------+ NOTE 1 - Only present if the corresponding feature is supported by the Agent. - Table 13: CONF and CONF_BUNDLES OP_BODY Fields + Table 13: CONFIG and CONF_BUNDLE OP_BODY Fields +-------------------+--------------------+--------------------------+ | Field | Type | Operation Types | | | | Create(C), Update(U), | | | | Query(Q) and Delete(D) | +-------------------+--------------------+--------------------------+ - | PORTS | *[ PORT ] | C,U [NOTE 2] | + | VPORTS | *[ VPORT ] | C,U [NOTE 2] | | | | | | CONTEXTS | *[ CONTEXT [ | C,U [NOTE 2] | | | COMMAND_SET [NOTE | | | | 1] ] ] | | | | | | | TARGETS | *[ FPC-Identity | Q,D [NOTE 2] | - | | (Section 5.4) | | + | | (Section 4.4) | | | | *[DPN_ID] ] | | | | | | | ERROR_TYPE_ID | [32, unsigned | All [NOTE 3] | | | integer] | | | | | | | ERROR_INFORMATION | [1024, octet | All [NOTE 3] | | | string] | | +-------------------+--------------------+--------------------------+ Table 14: Immediate Response RESPONSE_BODY Fields Notes: NOTE 1 - Only present if the corresponding feature is supported by the Agent. - NOTE 2 - Present in OK and OK_NOTIFY_FOLLOWS for both CONF and - CONF_BUNDLES. MAY also be present in an CONF_BUNDLES Error - response (ERR) if one of the operations completed successfully. + NOTE 2 - Present in OK and OK_NOTIFY_FOLLOWS for both CONFIG and + CONF_BUNDLE. MAY also be present in an CONF_BUNDLE Error response + (ERR) if one of the operations completed successfully. NOTE 3 - Present only for Error (ERR) responses. +-----------------+--------------------+----------------------------+ | Field | Type | Description | +-----------------+--------------------+----------------------------+ | AGENT_ID | FPC-Identity | | - | | (Section 5.4) | | + | | (Section 4.4) | | | | | | | NOTIFICATION_ID | [32, unsigned | A Notification Identifier | | | integer] | used to determine | | | | notification order. | | | | | | TIMESTAMP | [32, unsigned | The time that the | | | integer] | notification occurred. | | | | | | DATA | *[ OP_ID | | | | RESPONSE_BODY | | | | (Table 14) ] | | +-----------------+--------------------+----------------------------+ Table 15: CONFIG_RESULT_NOTIFY Asynchronous Notification Fields -7.2.3. Monitors +6.2.3. Monitors +-----------------+---------------------+---------------------------+ | Field | Type | Description | +-----------------+---------------------+---------------------------+ | NOTIFICATION_ID | [32, unsiged | | | | integer] | | | | | | | TRIGGER | [32, unsigned | | | | integer] | | | | | | | NOTIFY | NOTIFICATION_ID | Timestamp notes when the | | | MONITOR_ID TRIGGER | event occurred. | | | [32, timestamp] | Notification Data is | | | [NOTIFICATION_DATA] | TRIGGER and Monitor type | | | | specific. | +-----------------+---------------------+---------------------------+ Table 16: Monitor Notifications -8. Derived and Subtyped Attributes +7. Derived and Subtyped Attributes This section notes derived attributes. +------------------+-------+---------------+------------------------+ | Field | Type | Type | Description | | | Value | | | +------------------+-------+---------------+------------------------+ | TO_PREFIX | 0 | [IP Address] | Aggregated or per-host | | | | [ Prefix Len | destination IP | | | | ] | address/prefix | @@ -2377,21 +2400,21 @@ | REWRITE | 1 | [in_src_ip] | Rewrite IP Address | | | | [out_src_ip] | (NAT) or IP Address | | | | [in_dst_ip] | / Port (NAPT). | | | | [out_dst_ip] | | | | | [in_src_port] | | | | | [out_src_port] | | | | | [in_dst_port] | | | | | [out_dst_port] | | | | | | | | COPY_FORWARD | 2 | FPC-Identity. See | Copy all packets and | - | | | Section 5.4. | forward them to the | + | | | Section 4.4. | forward them to the | | | | | provided identity. | | | | | The value of the | | | | | identity MUST be a | | | | | port or context. | +--------------+-------+---------------------+----------------------+ Table 18: Action Subtypes +-----------------+-------+-------------------+---------------------+ | Field | Type | Type | Description | @@ -2407,20 +2430,23 @@ | MPLS_LABEL | 3 | [20, unsigned | MPLS Label | | | | integer] | | | | | | | | NSH | 4 | [SERVICE_PATH_ID] | Included NSH which | | | | [8, unsigned | is a SPI and | | | | integer] | Service Index (8 | | | | | bits). | | | | | | | INTERFACE_INDEX | 5 | [16, unsigned | Interface Index (an | | | | integer] | unsigned integer). | + | | | | | + | SEGMENT_ID | 5 | [128, unsigned | Segement | + | | | integer] | Identifier. | +-----------------+-------+-------------------+---------------------+ Table 19: Next Hop Subtypes +----------+-------+------------------+-----------------------------+ | Field | Type | Type | Description | | | Value | | | +----------+-------+------------------+-----------------------------+ | QOS | 0 | [qos index type] | Refers to a single index | | | | [index] [DSCP] | and DSCP to write to the | @@ -2457,21 +2483,21 @@ o assign-ip - Assign the IP Address for the mobile session. o assign-dpn - Assign the Dataplane Node. o session - Assign values for the Session Level. o uplink - Command applies to uplink. o downlink - Command applies to downlink. -8.1. 3GPP Specific Extenstions +7.1. 3GPP Specific Extenstions 3GPP support is optional and detailed in this section. The following acronyms are used: APN-AMBR: Access Point Name Aggregate Maximum Bit Rate ARP: Allocation of Retention Priority EBI: EPS Bearer Identity @@ -2548,21 +2574,21 @@ TEID. o session - Assign values for the Session Level. When this involves 'assign-fteid-ip' and 'assign-fteid-teid' this implies the values are part of the default bearer. o uplink - Command applies to uplink. o downlink - Command applies to downlink. -9. Implementation Status +8. Implementation Status Two FPC Agent implementations have been made to date. The first was based upon Version 03 of the draft and followed Model 1. The second follows Version 04 of the document. Both implementations were OpenDaylight plug-ins developed in Java by Sprint. Version 03 was known as fpcagent and version 04's implementation is simply referred to as 'fpc'. fpcagent's intent was to provide a proof of concept for FPC Version 03 Model 1 in January 2016 and research various errors, corrections @@ -2579,26 +2605,28 @@ A throughput performance of tens per second using various NetConf based solutions in OpenDaylight made fpcagent undesirable for call processing. The RPC implementation improved throughput by an order of magnitude but was not useful based upon FPC's Version 03 design using two information models. During this time the features of version 04 and its converged model became attractive and the fpcagent project was closed in August 2016. fpcagent will no longer be developed and will remain a proprietary implementation. The learnings of fpcagent has influenced the second project, fpc. - Fpc is also an OpenDaylight project but is intended for open source - release, if circumstances permit. It is also scoped to be a fully - compliant FPC Agent that supports multiple DPNs including those that - communicate via OpenFlow. The following features present in this - draft and others developed by the FPC development team have already - lead to an order of magnitude improvement. + Fpc is also an OpenDaylight project but is being prepared for open + source release as the Opendaylight FpcAgent plugin + (https://wiki.opendaylight.org/view/Project_Proposals:FpcAgent). + This project is scoped to be a fully compliant FPC Agent that + supports multiple DPNs including those that communicate via OpenFlow. + The following features present in this draft and others developed by + the FPC development team have already lead to an order of magnitude + improvement. Migration of non-realtime provisioning of entities such as topology and policy allowed the implementation to focus only on the rpc. Using only 5 messages and 2 notifications has also reduced implementation time. Command Sets, an optional feature in this specification, have eliminated 80% of the time spent determining what needs to be @@ -2610,55 +2638,54 @@ effectively act as a FPC protocol adapter remotely with multi-DPN support or colocated on the DPN in a single-DPN support model. Multi-tenant support allows for Cache searches to be partitioned for clustering and performance improvements. This has not been capitalized upon by the current implementation but is part of the development roadmap. Use of Contexts to pre-provision policy has also eliminated any processing of Ports for DPNs which permitted the code for - CONFIGURE and CONFIGURE_BUNDLES to be implemented as a simple - nested FOR loops (see below). + CONFIGURE and CONF_BUNDLE to be implemented as a simple nested + FOR loops (see below). Current performance results without code optimizations or tuning allow 2-5K FPC Contexts processed per second on a 2013 Mac laptop. This results in 2x the number of transactions on the southbound interface to a proprietary DPN API on the same machine. fpc currently supports the following: 1 proprietary DPN API Policy and Topology as defined in this specification using OpenDaylight North Bound Interfaces such as NetConf and RestConf - CONFIGURE and CONFIGURE_BUNDLES (all - operations) + CONFIG and CONF_BUNDLE (all operations) DPN assignment, Tunnel allocations and IPv4 address assignment by the Agent or Client. Immediate Response is always an OK_NOTIFY_FOLLOWS. assignment system (receives rpc call): perform basic operation integrity check - if CONFIGURE then + if CONFIG then goto assignments if assignments was ok then send request to activation system respond back to client with assignment data else send back error end if - else if CONFIGURE_BUNDLES then + else if CONF_BUNDLE then for each operation in bundles goto assignments if assignments was ok then hold onto data else return error with the assignments that occurred in prior operations (best effort) end if end for send bundles to activation systems @@ -2672,33 +2699,34 @@ activation system: build cache according to op-ref and operation type for each operation for each Context for each DPN / direction in Context perform actions on DPN according to Command Set end for end for end for commit changes to in memory cache - log transaction for tracking and notification (CONFIG_RESULT_NOTIFY) + log transaction for tracking and notification + (CONFIG_RESULT_NOTIFY) Figure 27: fpc pseudo code For further information please contact Lyle Bertz who is also a co- author of this document. NOTE: Tenant support requires binding a Client ID to a Tenant ID (it is a one to many relation) but that is outside of the scope of this specification. Otherwise, the specification is complete in terms of providing sufficient information to implement an Agent. -10. Security Considerations +9. Security Considerations Detailed protocol implementations for DMM Forwarding Policy Configuration must ensure integrity of the information exchanged between an FPC Client and an FPC Agent. Required Security Associations may be derived from co-located functions, which utilize the FPC Client and FPC Agent respectively. The YANG modules defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure @@ -2710,77 +2738,77 @@ There are a number of data nodes defined which are writable/creatable/deletable. These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., a NETCONF edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/ vulnerability: 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 may be used to block, identify or permit traffic that was not intended by the Tenant or FPC CLient. 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 attack vectors. Removal of topology can limit services. Nodes under the Mobility Tree are runtime only and manipulated by 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. Some of the readable data nodes defined may be considered sensitive or vulnerable in some network environments. It is thus important 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 sensitivity/vulnerability: IP address assignments in the Context along with their associated tunnel configurations/identifiers (from the FPC base module) Internaional Mobile Subscriber Identity (IMSI) and bearer identifiers in the Context when using the optional 3GPP module Some of the RPC operations defined may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and 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 environments as described above. Monitor related RPC operations do not specicially provide sensitive or vulnerable informaiton but care must be taken by users to avoid identifier values that expose sensitive or vulnerable information. Notications MUST be treated with same level of protection and scrutiny as the operations they correspond to. For example, a CONFIG_RESULT_NOTIFY notification provides the same information - that is sent as part of the input and output of the CONF and - CONF_BUNDLES RPC operations. + that is sent as part of the input and output of the CONFIG and + CONF_BUNDLE RPC operations. 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 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. -11. IANA Considerations +10. IANA Considerations This document registers six URIs in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registrations have been made. URI: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc Registrant Contact: The DMM WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp @@ -2815,50 +2843,69 @@ namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp prefix: threegpp reference: TBD1 name: ietf-dmm-pmip-qos namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-pmip-qos prefix: qos-pmip reference: TBD1 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: + ietf-dmm-traffic-selector-types prefix: traffic-selectors reference: TBD1 name: ietf-dmm-traffic-selector-types namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext prefix: fpcpolicyext reference: TBD1 name: ietf-dmm-traffic-selector-types namespace: urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip prefix: fpc-pmip reference: TBD1 The document registers the following YANG submodules in the "YANG Module Names" registry [RFC6020]. name: ietf-dmm-fpc-base parent: ietf-dmm-fpc reference: TBD1 -12. Work Team Participants +11. Work Team Participants Participants in the FPSM work team discussion include Satoru Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred Templin. -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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011, . @@ -2866,30 +2913,35 @@ [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, DOI 10.17487/RFC6089, January 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . -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, + . + +12.2. Informative References [I-D.bertz-dime-policygroups] Bertz, L., "Diameter Policy Groups and Sets", draft-bertz- - dime-policygroups-01 (work in progress), July 2016. + dime-policygroups-02 (work in progress), February 2017. [I-D.ietf-dmm-deployment-models] Gundavelli, S. and S. Jeon, "DMM Deployment Models and 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] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -2905,25 +2957,20 @@ [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, . - [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, - . - Appendix A. YANG Data Model for the FPC protocol 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-base An FPC submodule that defines the information model that is specified in this document o ietf-pmip-qos (pmip-qos) - Defines proxy mobile IPv6 QoS @@ -2944,21 +2991,21 @@ document. A.1. FPC Agent YANG Model This module defines the information model and protocol elements specified in this document. This module references [RFC6991] and the fpc-base module defined in this document. - file "ietf-dmm-fpc@2016-08-03.yang" + file "ietf-dmm-fpc@2017-03-08.yang" module ietf-dmm-fpc { namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc"; prefix fpc; import ietf-inet-types { prefix inet; revision-date 2013-07-15; } include ietf-dmm-fpc-base; organization "IETF Distributed Mobility Management (DMM) Working Group"; @@ -2970,70 +3017,80 @@ WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains YANG definition for Forwarding Policy Configuration Protocol (FPCP). Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 2017-03-08 { + description "Version 06 updates."; + reference "draft-ietf-dmm-fpc-cpdp-06"; + + } + revision 2016-08-03 { description "Initial Revision."; 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"; + 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"; + 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"; + 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"; + 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."; + 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."; - + 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."; + description "Enables the ability to send policy elements + (Policy Groups, Policies, Descriptors and Actions) to be sent + in CONF or CONF_BUNDLE operations."; } typedef agent-identifier { type fpc:fpc-identity; description "Agent Identifier"; } typedef client-identifier { type fpc:fpc-identity; description "Client Identifier"; @@ -3091,23 +3148,23 @@ description "Policy"; } container fpc-mobility { config false; list contexts { key context-id; uses fpc:fpc-context; description "Contexts"; } - list ports { - key port-id; - uses fpc:fpc-port; + list vports { + key vport-id; + uses fpc:fpc-vport; description "Ports"; } list monitors { uses fpc:monitor-config; description "Monitors"; } description "Mobility"; } container fpc-topology { // Basic Agent Topology Structures @@ -3197,21 +3254,21 @@ } // Multi-DPN Agent Structures grouping fpc-dpn-group { leaf dpn-group-id { type fpc:fpc-dpn-group-id; description "DPN Group ID"; } leaf data-plane-role { type identityref { - base "fpc:fpc-forwaridingplane-role"; + base "fpc:fpc-data-plane-role"; } description "Dataplane Role"; } leaf access-type { type identityref { base "fpc:fpc-access-type"; } description "Access Type"; } leaf mobility-profile { @@ -3269,45 +3326,48 @@ typedef op-delay { type uint32; description "Operation Delay (ms)"; } typedef op-identifier { type uint64; description "Operation Identifier"; } - typedef ref-scope { type enumeration { enum none { value 0; description "no references"; } enum op { value 1; - description "op - All references are contained in the operation body (intra-op)"; + description "op - All references are contained in the + operation body (intra-op)"; } enum bundle { value 2; - description "bundle - All references in exist in bundle (inter-operation/intra-bundle). - NOTE - If this value comes in CONFIG call it is equivalen to 'op'."; + description "bundle - All references in exist in bundle + (inter-operation/intra-bundle). + NOTE - If this value comes in CONFIG call it is + equivalent to 'op'."; } enum storage { value 3; - description "storage - One or more references exist outside of the operation and bundle. - A lookup to a cache / storage is required."; + description "storage - One or more references exist outside + of the operation and bundle. A lookup to a cache / + storage is required."; } enum unknown { value 4; - description " unknown - the location of the references are unknown. This is treated as - a 'storage' type."; + 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 { container instructions { if-feature instruction-bitset; choice instr-type { description "Instruction Value Choice"; @@ -3382,21 +3443,21 @@ grouping context-operation { uses fpc:fpc-context; uses fpc:instructions; description "Context Operation"; } // Output Structure grouping payload { list ports { - uses fpc:fpc-port; + uses fpc:fpc-vport; 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; @@ -3458,27 +3519,29 @@ enum err { value 1; description "Error"; } enum ok-notify-follows { value 2; description "OK with NOTIFY following"; } } description "Result Status"; + } identity error-type { description "Base Error Type"; } identity name-already-exists { - description "Notification that an entity of the same name already exists"; + description "Notification that an entity of the same name + already exists"; } typedef error-type-id { type uint32; description "Integer form of the Error Type"; } grouping op-status-value { leaf op-status { type enumeration { @@ -3623,21 +3686,22 @@ output { leaf monitor-result { type fpc:result; description "Result"; } uses fpc:error-info; } } rpc event_deregister { - description "Used to de-register monitoring of parameters/events"; + description "Used to de-register monitoring of + parameters/events"; input { list monitors { uses fpc:monitor-id; description "Monitor ID"; } } output { leaf monitor-result { type fpc:result; description "Result"; @@ -3676,32 +3742,50 @@ 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-forwaridingplane-role"; + 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"; } @@ -3716,73 +3800,80 @@ A.2. YANG Models A.2.1. FPC YANG Model This module defines the base data elements specified in this document. This module references [RFC6991]. - file "ietf-dmm-fpc-base@2016-08-03.yang" + file "ietf-dmm-fpc-base@2017-03-08.yang" submodule ietf-dmm-fpc-base { belongs-to ietf-dmm-fpc { prefix fpc; } import ietf-inet-types { prefix inet; revision-date 2013-07-15; } + import ietf-yang-types { prefix ytypes; + revision-date 2013-07-15; } organization "IETF Distributed Mobility Management (DMM) Working Group"; contact "WG Web: WG List: WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains YANG definition for Forwarding Policy Configuration Protocol(FPCP). Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 2017-03-08 { + description "Version 06 updates."; + reference "draft-ietf-dmm-fpc-cpdp-06"; + } + revision 2016-08-03 { description "Initial Revision."; reference "draft-ietf-dmm-fpc-cpdp-05"; } feature fpc-basic-agent { - description "This is an agent co-located with a DPN. In this case - only DPN Peer Groups, the DPN Id and Control Protocols are exposed - along with the core structures."; + description "This is an agent co-located with a DPN. In this + case only DPN Peer Groups, the DPN Id and Control Protocols + are exposed along with the core structures."; } feature fpc-multi-dpn { description "The agent supports multiple DPNs."; } typedef fpc-identity { type union { type uint32; type string; type instance-identifier; @@ -3892,30 +3984,31 @@ key descriptor-id; uses fpc:fpc-descriptor-id; leaf direction { type fpc:fpc-direction; description "Direction"; } description "Descriptors"; } list actions { key action-id; - leaf order { + leaf action-order { type uint32; 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'."; + When no Descriptors are empty the default is + 'all traffic'."; } // Policy Structures typedef fpc-policy-id { type fpc:fpc-identity; description "Policy Identifier"; } grouping fpc-policy { leaf policy-id { type fpc:fpc-policy-id; @@ -3945,60 +4038,64 @@ } leaf-list policies { type fpc:fpc-policy-id; description "Policies"; } description "FPC Policy Group"; } // Mobility Structures // Port Group - typedef fpc-port-id { + typedef fpc-vport-id { type fpc:fpc-identity; description "FPC Port Identifier"; } - grouping fpc-port { - leaf port-id { - type fpc:fpc-port-id; + grouping fpc-vport { + leaf vport-id { + type fpc:fpc-vport-id; description "Port ID"; } leaf-list policy-groups { type fpc:fpc-policy-group-id; description "Policy Groups"; } description "FPC Port"; } // Context Group typedef fpc-context-id { type fpc:fpc-identity; description "FPC Context Identifier"; } grouping fpc-context-profile { leaf tunnel-local-address { type inet:ip-address; - description "Uplink endpoint address of the DPN which agent exists."; + description "endpoint address of the DPN which a + gent exists."; } leaf tunnel-remote-address { type inet:ip-address; - description "Uplink endpoint address of the DPN which agent exists."; + description "endpoint address of the DPN which + agent exists."; } leaf mtu-size { type uint32; description "MTU size"; } container mobility-tunnel-parameters { uses fpc:mobility-info; 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."; + "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 { @@ -4007,54 +4104,54 @@ 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 uplink { - description "Uplink"; + enum lylebe551144 { + description "lylebe551144"; } enum downlink { description "Downlink"; } enum both { description "Both"; } } description "FPC Direction"; } grouping fpc-context { leaf context-id { type fpc:fpc-context-id; description "Context ID"; } - leaf-list ports { - type fpc:fpc-port-id; - description "Ports"; + leaf-list vports { + type fpc:fpc-vport-id; + description "Vports"; } leaf dpn-group { type fpc:fpc-dpn-group-id; description "DPN Group"; } - leaf-list delegating-ip-prefixes { + leaf-list delegated-ip-prefixes { type inet:ip-prefix; - description "Delegating Prefix(es)"; + description "Delegated Prefix(es)"; } container ul { if-feature fpc:fpc-basic-agent; uses fpc:fpc-context-profile; - description "Uplink"; + 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 { @@ -4085,68 +4182,107 @@ description "Empty Value"; } description "No Parameters Case"; } description "Mobility Profile Parameters"; } description "Mobility Information"; } // Next Hop Structures - typedef fpcp-service-path-id { + typedef fpc-service-path-id { type uint32 { range "0..33554431"; } description "SERVICE_PATH_ID"; } - + typedef fpc-mpls-label { + type uint32 { + range "0..1048575"; + } + description "MPLS label"; + } identity fpc-nexthop-type { description "Next Hop Type"; } identity fpc-nexthop-ip { base "fpc:fpc-nexthop-type"; description "Nexthop IP"; } identity fpc-nexthop-servicepath { base "fpc:fpc-nexthop-type"; description "Nexthop Service Path"; } + identity fpc-nexthop-mac { + base "fpc:fpc-nexthop-type"; + description "Nexthop MAC-Address"; + } + identity fpc-nexthop-mpls { + base "fpc:fpc-nexthop-type"; + description "Nexthop MPLS"; + } + identity fpc-nexthop-if { + base "fpc:fpc-nexthop-type"; + description "Nexthop If index"; + } grouping fpc-nexthop { leaf nexthop-type { type identityref { base "fpc:fpc-nexthop-type"; } description "Nexthop Type"; } choice nexthop-value { - case ip { + case ip-nexthop { leaf ip { type inet:ip-address; description "IP Value"; } description "IP Case"; } - case servicepath { + case macaddress-nexthop { + leaf macaddress { + type ytypes:mac-address; + description "MAC Address Value"; + } + } + case servicepath-nexthop { leaf servicepath { - type fpc:fpcp-service-path-id; + type fpc:fpc-service-path-id; description "Service Path Value"; + + } + description "Service Path Case"; + } + case mplslabel-nexthop { + leaf lsp { + type fpc:fpc-mpls-label; + description "MPLS Value"; + } + description "Service Path Case"; + } + case if-nexthop { + leaf if-index { + type uint16; + description "If (interface) Value"; } description "Service Path Case"; } description "Value"; } description "Nexthop Value"; } // QoS Information identity fpc-qos-type { - description "Base identity from which specific uses of QoS types are derived."; + description "Base identity from which specific uses of QoS + types are derived."; } grouping fpc-qos-profile { leaf qos-type { type identityref { base fpc:fpc-qos-type; } description "the profile type"; } choice value { description "QoS Value"; @@ -4194,26 +4330,31 @@ description "Domain ID"; } leaf domain-name { type string; description "Domain Name"; } leaf domain-type { type string; description "Domain Type"; } + leaf domain-reference { + type instance-identifier; + description "Indicates a set of resources for the domain"; + } description "FPC Domain"; } typedef fpc-dpn-id { type fpc:fpc-identity; description "DPN Identifier"; + } identity fpc-dpn-control-protocol { description "DPN Control Protocol"; } grouping fpc-dpn { leaf dpn-id { type fpc:fpc-dpn-id; description "DPN ID"; } leaf dpn-name { @@ -4228,44 +4369,53 @@ type instance-identifier; description "DPN => Node (Topology) Mapping"; } description "FPC DPN"; } typedef fpc-dpn-group-id { type fpc:fpc-identity; description "DPN Group Identifier"; } - identity fpc-forwaridingplane-role { + 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"; + } + 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 { type fpc:fpc-dpn-group-id; description "Remote DPN Group 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-forwaridingplane-role"; + 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"; @@ -4431,21 +4579,21 @@ WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains a collection of YANG definitions for quality of service paramaters used in Proxy Mobile IPv6. Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents @@ -4462,37 +4610,38 @@ reference "RFC 7222: Quality-of-Service Option for Proxy Mobile IPv6"; } // Type Definitions // QoS Option Field Type Definitions typedef sr-id { type uint8; description - "An 8-bit unsigned integer used - for identifying the QoS Service Request. Its uniqueness is within - the scope of a mobility session. The local mobility anchor always - allocates the Service Request Identifier. When a new QoS Service - Request is initiated by a mobile access gateway, the Service - Request Identifier in the initial request message is set to a - value of (0), and the local mobility anchor allocates a Service - Request Identifier and includes it in the response. For any new - QoS Service Requests initiated by a local mobility anchor, the + "An 8-bit unsigned integer used] + for identifying the QoS Service Request. Its uniqueness is + within the scope of a mobility session. The local mobility + anchor always allocates the Service Request Identifier. + When a new QoS Service Request is initiated by a mobile + access gateway, the Service Request Identifier in the initial + request message is set to a value of (0), and the local + mobility anchor allocates a Service Request Identifier and + includes it in the response. For any new QoS Service + Requests initiated by a local mobility anchor, the Service Request Identifier is set to the allocated value."; } typedef traffic-class { type inet:dscp; description - "Traffic Class consists of a 6-bit DSCP field followed by a 2-bit - reserved field."; + "Traffic Class consists of a 6-bit DSCP field followed by a + 2-bit reserved field."; reference "RFC 3289: Management Information Base for the Differentiated Services Architecture RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2780: IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers"; } typedef operational-code { @@ -4504,64 +4653,70 @@ enum ALLOCATE { value 1; description "Request to allocate QoS resources"; } enum DE-ALLOCATE { value 2; description "Request to de-Allocate QoS resources"; } enum MODIFY { value 3; - description "Request to modify QoS parameters for a previously negotiated - QoS Service Request"; + description "Request to modify QoS parameters for a + previously negotiated QoS Service Request"; } enum QUERY { value 4; - description "Query to list the previously negotiated QoS Service Requests - that are still active"; + description "Query to list the previously negotiated QoS + Service Requests that are still active"; } enum NEGOTIATE { 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 "1-octet Operational code indicates the type of QoS request. Reserved values: (6) to (255) - Currently not used. Receiver MUST ignore the option received - with any value in this range."; + Currently not used. Receiver MUST ignore the option + received with any value in this range."; } // QoS Attribute Types - //The enumeration value for mapping - don't confuse with the identities + //The enumeration value for mapping - don't confuse with the + // identities typedef qos-attrubite-type-enum { type enumeration { enum Reserved { value 0; description "This value is reserved and cannot be used"; } enum Per-MN-Agg-Max-DL-Bit-Rate { value 1; - description "Per-Mobile-Node Aggregate Maximum Downlink Bit Rate."; + description "Per-Mobile-Node Aggregate Maximum Downlink + Bit Rate."; } enum Per-MN-Agg-Max-UL-Bit-Rate { value 2; - description "Per-Mobile-Node Aggregate Maximum Uplink Bit Rate."; + description "Per-Mobile-Node Aggregate Maximum Uplink Bit + Rate."; } enum Per-Session-Agg-Max-DL-Bit-Rate { value 3; - description "Per-Mobility-Session Aggregate Maximum Downlink Bit Rate."; + description "Per-Mobility-Session Aggregate Maximum + Downlink Bit Rate."; } enum Per-Session-Agg-Max-UL-Bit-Rate { value 4; - description "Per-Mobility-Session Aggregate Maximum Uplink Bit Rate."; + description "Per-Mobility-Session Aggregate Maximum + Uplink Bit Rate."; } enum Allocation-Retention-Priority { value 5; description "Allocation and Retention Priority."; } enum Aggregate-Max-DL-Bit-Rate { value 6; description "Aggregate Maximum Downlink Bit Rate."; } enum Aggregate-Max-UL-Bit-Rate { @@ -4580,30 +4735,32 @@ value 10; description "QoS Traffic Selector."; } enum QoS-Vendor-Specific-Attribute { value 11; description "QoS Vendor-Specific Attribute."; } } description "8-bit unsigned integer indicating the type of the QoS - attribute. This specification reserves the following reserved values. + attribute. This specification reserves the following + reserved values. (12) to (254) - Reserved These values are reserved for future allocation. (255) Reserved This value is reserved and cannot be used."; } // Attribute Type as Identities - // Added for convenience of inclusion and extension in other YANG modules. + // Added for convenience of inclusion and extension in + // other YANG modules. identity qos-attribute-type { description "Base type for Quality of Service Attributes"; } identity Per-MN-Agg-Max-DL-Bit-Rate-type { base qos-attribute-type; description "Per-Mobile-Node Aggregate Maximum Downlink Bit Rate."; } @@ -4661,121 +4819,130 @@ base qos-attribute-type; description "QoS Vendor-Specific Attribute."; } //value definitions typedef Per-MN-Agg-Max-DL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that indicates the aggregate maximum downlink bit rate that is - requested/allocated for all the mobile node's IP flows. The - measurement units for Per-MN-Agg-Max-DL-Bit-Rate are bits per - second."; + requested/allocated for all the mobile node's IP flows. + The measurement units for Per-MN-Agg-Max-DL-Bit-Rate are + bits per second."; + } typedef Per-MN-Agg-Max-UL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that - indicates the aggregate maximum uplink bit rate that is requested/ - allocated for the mobile node's IP flows. The measurement units - for Per-MN-Agg-Max-UL-Bit-Rate are bits per second."; + indicates the aggregate maximum uplink bit rate that is + requested/allocated for the mobile node's IP flows. The + measurement units for Per-MN-Agg-Max-UL-Bit-Rate are bits + per second."; } // Generic Structure for the uplink and downlink grouping Per-Session-Agg-Max-Bit-Rate-Value { leaf max-rate { type uint32; mandatory true; description "This is a 32-bit unsigned integer - that indicates the aggregate maximum bit rate that is requested/allocated - for all the IP flows associated with that mobility session. The measurement - units for Per-Session-Agg-Max-UL/DL-Bit-Rate are bits per second."; + that indicates the aggregate maximum bit rate that is + requested/allocated for all the IP flows associated with + that mobility session. The measurement units for + Per-Session-Agg-Max-UL/DL-Bit-Rate are bits per second."; } leaf service-flag { type boolean; mandatory true; description "This flag is used for extending the scope of the - target flows for Per-Session-Agg-Max-UL/DL-Bit-Rate from(UL)/to(DL) the mobile - node's other mobility sessions sharing the same Service - Identifier. 3GPP Access Point Name (APN) is an example of a - Service Identifier, and that identifier is carried using the - Service Selection mobility option [RFC5149]. + target flows for Per-Session-Agg-Max-UL/DL-Bit-Rate + from(UL)/to(DL) the mobile node's other mobility sessions + sharing the same Service Identifier. 3GPP Access Point Name + (APN) is an example of a Service Identifier, and that + identifier is carried using the Service Selection mobility + option [RFC5149]. - * When the (S) flag is set to a value of (1), then the Per- - Session-Agg-Max-Bit-Rate is measured as an aggregate across - all the mobile node's other mobility sessions sharing the same - Service Identifier associated with this mobility session. + - When the (S) flag is set to a value of (1), then the + Per-Session-Agg-Max-Bit-Rate is measured as an + aggregate across all the mobile node's other mobility + sessions sharing the same Service Identifier associated + with this mobility session. - * When the (S) flag is set to a value of (0), then the target - flows are limited to the current mobility session. + - When the (S) flag is set to a value of (0), then the + target flows are limited to the current mobility + session. - * The (S) flag MUST NOT be set to a value of (1) when there is no - Service Identifier associated with the mobility session."; + - The (S) flag MUST NOT be set to a value of (1) when there + is no Service Identifier associated with the mobility + session."; reference "RFC 5149 - Service Selection mobility option"; } leaf exclude-flag { type boolean; mandatory true; description "This flag is used to request that the uplink/downlink - flows for which the network is providing Guaranteed-Bit-Rate - service be excluded from the target IP flows for which Per- - Session-Agg-Max-UL/DL-Bit-Rate is measured. + flows for which the network is providing + Guaranteed-Bit-Rate service be excluded from the + target IP flows for which + Per-Session-Agg-Max-UL/DL-Bit-Rate is measured. - * When the (E) flag is set to a value of (1), then the request is - to exclude the IP flows for which Guaranteed-UL/DL-Bit-Rate - is negotiated from the flows for which Per-Session-Agg-Max-UL/DL-Bit-Rate + - When the (E) flag is set to a value of (1), then the + request is to exclude the IP flows for which + Guaranteed-UL/DL-Bit-Rate is negotiated from the flows + for which Per-Session-Agg-Max-UL/DL-Bit-Rate is measured. - * When the (E) flag is set to a value of (0), then the request is - not to exclude any IP flows from the target IP flows for which - Per-Session-Agg-Max-UL/DL-Bit-Rate is measured. + - When the (E) flag is set to a value of (0), then the + request is not to exclude any IP flows from the target + IP flows for which Per-Session-Agg-Max-UL/DL-Bit-Rate + is measured. - * When the (S) flag and (E) flag are both set to a value of (1), - then the request is to exclude all the IP flows sharing the - Service Identifier associated with this mobility session from - the target flows for which Per-Session-Agg-Max-UL/DL-Bit-Rate is - measured."; + - When the (S) flag and (E) flag are both set to a value + of (1), then the request is to exclude all the IP flows + sharing the Service Identifier associated with this + mobility session from the target flows for which + Per-Session-Agg-Max-UL/DL-Bit-Rate is measured."; } description "Per-Session-Agg-Max-Bit-Rate Value"; } grouping Allocation-Retention-Priority-Value { leaf prioirty-level { type uint8 { range "0..15"; } mandatory true; description - "This is a 4-bit unsigned integer value. It - is used to decide whether a mobility session establishment or - modification request can be accepted; this is typically used for + "This is a 4-bit unsigned integer value. It is used to decide + whether a mobility session establishment or modification + request can be accepted; this is typically used for admission control of Guaranteed Bit Rate traffic in case of resource limitations. The priority level can also be used to + decide which existing mobility session to preempt during + resource limitations. The priority level defines the + relative timeliness of a resource request. - decide which existing mobility session to preempt during resource - limitations. The priority level defines the relative timeliness - of a resource request. - - Values 1 to 15 are defined, with value 1 as the highest level of - priority. + Values 1 to 15 are defined, with value 1 as the highest level + of priority. Values 1 to 8 should only be assigned for services that are - authorized to receive prioritized treatment within an operator - domain. Values 9 to 15 may be assigned to resources that are - authorized by the home network and thus applicable when a mobile - node is roaming."; + authorized to receive prioritized treatment within an + operator domain. Values 9 to 15 may be assigned to resources + that are authorized by the home network and thus applicable + when a mobile node is roaming."; } leaf premption-capability { type enumeration { enum enabled { value 0; description "enabled"; } enum disabled { value 1; description "disabled"; @@ -4784,28 +4951,28 @@ value 2; description "reserved1"; } enum reserved2 { value 3; description "reserved2"; } } mandatory true; description - "This is a 2-bit unsigned integer - value. It defines whether a service data flow can get resources - that were already assigned to another service data flow with a - lower priority level. The following values are defined: + "This is a 2-bit unsigned integer value. It defines whether a + service data flow can get resources that were already + assigned to another service data flow with a lower priority + level. The following values are defined: - Enabled (0): This value indicates that the service data flow is - allowed to get resources that were already assigned to another - IP data flow with a lower priority level. + Enabled (0): This value indicates that the service data flow + is allowed to get resources that were already assigned to + another IP data flow with a lower priority level. Disabled (1): This value indicates that the service data flow is not allowed to get resources that were already assigned to another IP data flow with a lower priority level. The values (2) and (3) are reserved."; } leaf premption-vulnerability { type enumeration { enum enabled { value 0; @@ -4819,160 +4986,170 @@ value 2; description "reserved1"; } enum reserved2 { value 3; description "reserved2"; } } mandatory true; description - "This is a 2-bit unsigned integer - value. It defines whether a service data flow can lose the - resources assigned to it in order to admit a service data flow - with a higher priority level. The following values are defined: + "This is a 2-bit unsigned integer value. It defines whether a + service data flow can lose the resources assigned to it in + order to admit a service data flow with a higher priority + level. The following values are defined: - Enabled (0): This value indicates that the resources assigned - to the IP data flow can be preempted and allocated to a service - data flow with a higher priority level. + Enabled (0): This value indicates that the resources + assigned to the IP data flow can be preempted and + allocated to a service data flow with a higher + priority level. - Disabled (1): This value indicates that the resources assigned - to the IP data flow shall not be preempted and allocated to a - service data flow with a higher priority level. The values (2) - and (3) are reserved."; + Disabled (1): This value indicates that the resources + assigned to the IP data flow shall not be preempted and + allocated to a service data flow with a higher priority + level. The values (2) and (3) are reserved."; } description "Allocation-Retention-Priority Value"; } typedef Aggregate-Max-DL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that indicates the aggregate maximum downlink bit rate that is - requested/allocated for downlink IP flows. The measurement units - for Aggregate-Max-DL-Bit-Rate are bits per second."; - + requested/allocated for downlink IP flows. The measurement + units for Aggregate-Max-DL-Bit-Rate are bits per second."; } typedef Aggregate-Max-UL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that indicates the aggregate maximum downlink bit rate that is - requested/allocated for downlink IP flows. The measurement units - for Aggregate-Max-DL-Bit-Rate are bits per second."; + requested/allocated for downlink IP flows. The measurement + units for Aggregate-Max-DL-Bit-Rate are bits per second."; } typedef Guaranteed-DL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that - indicates the guaranteed bandwidth in bits per second for downlink - IP flows. The measurement units for Guaranteed-DL-Bit-Rate are - bits per second."; + indicates the guaranteed bandwidth in bits per second for + downlink IP flows. The measurement units for + Guaranteed-DL-Bit-Rate are bits per second."; } typedef Guaranteed-UL-Bit-Rate-Value { type uint32; description "This is a 32-bit unsigned integer that - indicates the guaranteed bandwidth in bits per second for uplink - IP flows. The measurement units for Guaranteed-UL-Bit-Rate are - bits per second."; + indicates the guaranteed bandwidth in bits per second + for uplink IP flows. The measurement units for + Guaranteed-UL-Bit-Rate are bits per second."; } grouping QoS-Vendor-Specific-Attribute-Value-Base { leaf vendorid { type uint32; mandatory true; description "The Vendor ID is the SMI (Structure of Management - Information) Network Management Private Enterprise Code of the - IANA-maintained 'Private Enterprise Numbers' registry [SMI]."; + Information) Network Management Private Enterprise Code of + the IANA-maintained 'Private Enterprise Numbers' + registry."; reference "'PRIVATE ENTERPRISE NUMBERS', SMI Network Management Private Enterprise Codes, April 2014, "; } leaf subtype { type uint8; mandatory true; description "An 8-bit field indicating the type of vendor-specific - information carried in the option. The namespace for this sub- - type is managed by the vendor identified by the Vendor ID field."; + information carried in the option. The namespace for this + sub-type is managed by the vendor identified by the + Vendor ID field."; } description "QoS Vendor-Specific Attribute."; } - //NOTE - We do NOT add the Status Codes or other changes in PMIP in this module + //NOTE - We do NOT add the Status Codes or other changes in + // PMIP in this module //Primary Structures (groupings) grouping qosattribute { leaf attributetype { type identityref { base qos-attribute-type; } mandatory true; description "the attribute type"; } //All of the sub-types by constraint choice attribute-choice { case per-mn-agg-max-dl-case { - when "../attributetype = 'Per-MN-Agg-Max-DL-Bit-Rate-type'"; + when "../attributetype = " + + "'Per-MN-Agg-Max-DL-Bit-Rate-type'"; leaf per-mn-agg-max-dl { type qos-pmip:Per-MN-Agg-Max-DL-Bit-Rate-Value; description "Per-MN-Agg-Max-DL-Bit-Rate Value"; } description "Per-MN-Agg-Max-DL-Bit-Rate Case"; } case per-mn-agg-max-ul-case { - when "../attributetype = 'Per-MN-Agg-Max-UL-Bit-Rate-type'"; + when "../attributetype = " + + "'Per-MN-Agg-Max-UL-Bit-Rate-type'"; leaf per-mn-agg-max-ul { type qos-pmip:Per-MN-Agg-Max-UL-Bit-Rate-Value; description "Per-MN-Agg-Max-UL-Bit-Rate Value"; } description "Per-MN-Agg-Max-UL-Bit-Rate Case"; } case per-session-agg-max-dl-case { - when "../attributetype = 'Per-Session-Agg-Max-DL-Bit-Rate-type'"; + when "../attributetype = " + + "'Per-Session-Agg-Max-DL-Bit-Rate-type'"; container per-session-agg-max-dl { uses qos-pmip:Per-Session-Agg-Max-Bit-Rate-Value; description "Per-Session-Agg-Max-Bit-Rate Value"; } description "Per-Session-Agg-Max-Bit-Rate Case"; } case per-session-agg-max-ul-case { - when "../attributetype = 'Per-Session-Agg-Max-UL-Bit-Rate-type'"; + when "../attributetype = " + + "'Per-Session-Agg-Max-UL-Bit-Rate-type'"; container per-session-agg-max-ul { uses qos-pmip:Per-Session-Agg-Max-Bit-Rate-Value; description "Per-Session-Agg-Max-Bit-Rate Value"; } description "Per-Session-Agg-Max-Bit-Rate Case"; } case allocation-retention-priority-case { - when "../attributetype = 'Allocation-Retention-Priority-type'"; + when "../attributetype = " + + "'Allocation-Retention-Priority-type'"; uses qos-pmip:Allocation-Retention-Priority-Value; description "Allocation-Retention-Priority Case"; } case agg-max-dl-case { - when "../attributetype = 'Aggregate-Max-DL-Bit-Rate-type'"; + when "../attributetype = " + + "'Aggregate-Max-DL-Bit-Rate-type'"; leaf agg-max-dl { type qos-pmip:Aggregate-Max-DL-Bit-Rate-Value; description "Aggregate-Max-DL-Bit-Rate Value"; } description "Aggregate-Max-DL-Bit-Rate Case"; } case agg-max-ul-case { - when "../attributetype = 'Aggregate-Max-UL-Bit-Rate-type'"; + when "../attributetype = " + + "'Aggregate-Max-UL-Bit-Rate-type'"; leaf agg-max-ul { type qos-pmip:Aggregate-Max-UL-Bit-Rate-Value; description "Aggregate-Max-UL-Bit-Rate Value"; } description "Aggregate-Max-UL-Bit-Rate Case"; } case gbr-dl-case { when "../attributetype = 'Guaranteed-DL-Bit-Rate-type'"; leaf gbr-dl { type qos-pmip:Guaranteed-DL-Bit-Rate-Value; @@ -5059,21 +5237,21 @@ WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains a collection of YANG definitions for traffic selectors for flow bindings. Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents @@ -5092,534 +5269,585 @@ } revision 2016-01-12 { description "Initial revision"; reference "RFC 6088: Traffic Selectors for Flow Bindings"; } // Identities identity traffic-selector-format { - description "The base type for Traffic-Selector Formats"; + description + "The base type for Traffic-Selector Formats"; } identity ipv4-binary-selector-format { base traffic-selector-format; description "IPv4 Binary Traffic Selector Format"; } identity ipv6-binary-selector-format { base traffic-selector-format; description "IPv6 Binary Traffic Selector Format"; } // Type definitions and groupings typedef ipsec-spi { type uint32; - description "This type defines the first 32-bit IPsec Security Parameter - Index (SPI) value on data packets sent from a corresponding - node to the mobile node as seen by the home agent. This field + description + "This type defines the first 32-bit IPsec + Security Parameter Index (SPI) value on data + packets sent from a corresponding node to the + mobile node as seen by the home agent. This field is defined in [RFC4303]."; reference - "RFC 4303: IP Encapsulating Security Payload (ESP)"; + "RFC 4303: IP Encapsulating Security + Payload (ESP)"; } grouping traffic-selector-base { - description "A grouping of the commen leaves between the v4 and v6 Traffic Selectors"; + description "A grouping of the commen leaves between the + v4 and v6 Traffic Selectors"; container ipsec-spi-range { presence "Enables setting ipsec spi range"; description - "Inclusive range representing IPSec Security Parameter Indices to be used. - When only start-spi is present, it represents a single spi."; + "Inclusive range representing IPSec Security Parameter + Indices to be used. When only start-spi is present, it + represents a single spi."; leaf start-spi { type ipsec-spi; mandatory true; description - "This field identifies the first 32-bit IPsec SPI value, from the - range of SPI values to be matched, on data packets sent from a - corresponding node to the mobile node as seen by the home agent. + "This field identifies the first 32-bit IPsec SPI value, + from the range of SPI values to be matched, on data + packets sent from a corresponding node to the mobile + node as seen by the home agent. This field is defined in [RFC4303]."; - } leaf end-spi { type ipsec-spi; must ". >= ../start-spi" { error-message - "The end-spi must be greater than or equal to start-spi"; + "The end-spi must be greater than or equal + to start-spi"; } description - "If more than one contiguous SPI value needs to be matched, then - this field can be used to indicate the end value of a range - starting from the value of the Start SPI field. This field - MUST NOT be included unless the Start SPI field is included - and has a value less than or equal to this field. + "If more than one contiguous SPI value needs to be matched, + then this field can be used to indicate the end value of + a range starting from the value of the Start SPI field. + This field MUST NOT be included unless the Start SPI + field is included and has a value less than or equal to + this field. - When this field is included, the receiver will match all of the - SPI values between fields start-spi and end-spi, + When this field is included, the receiver will match all + of the SPI values between fields start-spi and end-spi, inclusive of start-spi and end-spi."; } } container source-port-range { presence "Enables setting source port range"; description "Inclusive range representing source ports to be used. - When only start-port is present, it represents a single port."; + When only start-port is present, it represents a single + port."; leaf start-port { type inet:port-number; mandatory true; description - "This field identifies the first 16-bit source port number, from - the range of port numbers to be matched, on data packets sent from - a corresponding node to the mobile node as seen by the home agent. + "This field identifies the first 16-bit source port number, + from the range of port numbers to be matched, on data + packets sent from a corresponding node to the mobile node + as seen by the home agent. This is from the range of port numbers defined by IANA (http://www.iana.org)."; } leaf end-port { type inet:port-number; must ". >= ../start-port" { error-message "The end-port must be greater than or equal to start-port"; } description "If more than one contiguous source port number needs to be - matched, then this field can be used to indicate the end value of - a range starting from the value of the Start Port field. - This field MUST NOT be included unless the Start Port field - is included and has a value less than or equal to this field. + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start + Port field. This field MUST NOT be included unless the + Start Port field is included and has a value less than + or equal to this field. When this field is included, the receiver will match - all of the port numbers between fields start-port and end-port, inclusive of start-port and end-port."; } } container destination-port-range { presence "Enables setting destination port range"; description - "Inclusive range representing destination ports to be used. When - only start-port is present, it represents a single port."; + "Inclusive range representing destination ports to be used. + When only start-port is present, it represents a single + port."; leaf start-port { type inet:port-number; mandatory true; description - "This field identifies the first 16-bit destination port number, - from the range of port numbers to be matched, on data packets sent - from a corresponding node to the mobile node as seen by the home - agent."; + "This field identifies the first 16-bit destination port + number, from the range of port numbers to be matched, on + data packets sent from a corresponding node to the mobile + node as seen by the home agent."; } leaf end-port { type inet:port-number; must ". >= ../start-port" { error-message - "The end-port must be greater than or equal to start-port"; + "The end-port must be greater than or equal to + start-port"; } description - "If more than one contiguous destination port number needs to be - matched, then this field can be used to indicate the end value of - a range starting from the value of the Start Destination Port - field. This field MUST NOT be included unless the Start - Port field is included and has a value less than or equal to this - field. + "If more than one contiguous destination port number needs + to be matched, then this field can be used to indicate + the end value of a range starting from the value of the + Start Destination Port field. This field MUST NOT be + included unless the Start Port field is included and has + a value less than or equal to this field. - When this field is included, the receiver will match all of the - port numbers between fields start-port and end-port, inclusive of - start-port and end-port."; + When this field is included, the receiver will match + all of the port numbers between fields start-port and + end-port, inclusive of start-port and end-port."; } } } grouping ipv4-binary-traffic-selector { container source-address-range-v4 { presence "Enables setting source IPv4 address range"; description "Inclusive range representing IPv4 addresses to be used. When - only start-address is present, it represents a single address."; + only start-address is present, it represents a single + address."; leaf start-address { type inet:ipv4-address; mandatory true; description - "This field identifies the first source address, from the range of - 32-bit IPv4 addresses to be matched, on data packets sent from a - corresponding node to the mobile node as seen by the home agent. - In other words, this is one of the addresses of the correspondent - node."; + "This field identifies the first source address, from the range + of 32-bit IPv4 addresses to be matched, on data packets sent + from a corresponding node to the mobile node as seen by the + home agent. In other words, this is one of the addresses of + the correspondent node."; } leaf end-address { type inet:ipv4-address; description - "If more than one contiguous source address needs to be matched, - then this field can be used to indicate the end value of a range - starting from the value of the Start Address field. This - field MUST NOT be included unless the Start Address field - is included. When this field is included, the receiver will match - all of the addresses between fields start-address and - end-address, inclusive of start-address and end-address."; + "If more than one contiguous source address needs to be + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start + Address field. This field MUST NOT be included unless the + Start Address field is included. When this field is + included, the receiver will match all of the addresses + between fields start-address and end-address, inclusive of + start-address and end-address."; } } container destination-address-range-v4 { presence "Enables setting destination IPv4 address range"; description - "Inclusive range representing IPv4 addresses to be used. When - only start-address is present, it represents a single address."; + "Inclusive range representing IPv4 addresses to be used. + When only start-address is present, it represents a + single address."; leaf start-address { type inet:ipv4-address; mandatory true; description "This field identifies the first destination address, from the - range of 32-bit IPv4 addresses to be matched, on data packets sent - from a corresponding node to the mobile node as seen by the home - agent. In other words, this is one of the registered home - addresses of the mobile node."; + range of 32-bit IPv4 addresses to be matched, on data packets + sent from a corresponding node to the mobile node as seen by + the home agent. In other words, this is one of the registered + home addresses of the mobile node."; } leaf end-address { type inet:ipv4-address; description "If more than one contiguous destination address needs to be - matched, then this field can be used to indicate the end value of - a range starting from the value of the Start Destination Address - field. This field MUST NOT be included unless the Start - Address field is included. When this field is included, the receiver - will match all of the addresses between fields start-address and - end-address, inclusive of start-address and end-address."; + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start + Destination Address field. This field MUST NOT be included + unless the Start Address field is included. When this field + is included, the receiver will match all of the addresses + between fields start-address and end-address, inclusive of + start-address and end-address."; } } container ds-range { presence "Enables setting dscp range"; description - "Inclusive range representing DiffServ Codepoints to be used. When - only start-ds is present, it represents a single Codepoint."; + "Inclusive range representing DiffServ Codepoints to be used. + When only start-ds is present, it represents a single + Codepoint."; leaf start-ds { type inet:dscp; mandatory true; description - "This field identifies the first differential services value, from - the range of differential services values to be matched, on data - packets sent from a corresponding node to the mobile node as seen - by the home agent. Note that this field is called a 'Type of - Service field' in [RFC0791]. [RFC3260] then clarified that the - field has been redefined as a 6-bit DS field with 2 bits reserved, - later claimed by Explicit Congestion Notification (ECN) [RFC3168]. - For the purpose of this specification, the Start DS field is 8 - bits long, where the 6 most significant bits indicate the DS field + "This field identifies the first differential service value, + from the range of differential services values to be + matched, on data packets sent from a corresponding node to + the mobile node as seen by the home agent. Note that this + field is called a 'Type of Service field' in [RFC0791]. + [RFC3260] then clarified that the field has been redefined + as a 6-bit DS field with 2 bits reserved, later claimed by + Explicit Congestion Notification (ECN) [RFC3168]. For the + purpose of this specification, the Start DS field is 8 bits + long, where the 6 most significant bits indicate the DS field to be matched and the 2 least significant bits' values MUST be ignored in any comparison."; } leaf end-ds { type inet:dscp; must ". >= ../start-ds" { error-message "The end-ds must be greater than or equal to start-ds"; } description "If more than one contiguous DS value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start DS field. This field MUST NOT be included unless the Start DS field is included. When this field is included, it MUST be coded the same way as defined for - start-ds. When this field is included, the receiver will match all of - the values between fields start-ds and end-ds, inclusive of start-ds - and end-ds."; + start-ds. When this field is included, the receiver will match + all of the values between fields start-ds and end-ds, inclusive + of start-ds and end-ds."; } } container protocol-range { presence "Enables setting protocol range"; description "Inclusive range representing IP protocol(s) to be used. When - only start-protocol is present, it represents a single protocol."; + only start-protocol is present, it represents a single + protocol."; leaf start-protocol { type uint8; mandatory true; description "This field identifies the first 8-bit protocol value, from the - range of protocol values to be matched, on data packets sent from - a corresponding node to the mobile node as seen by the home agent."; - + range of protocol values to be matched, on data packets sent + from a corresponding node to the mobile node as seen by the + home agent."; } leaf end-protocol { type uint8; must ". >= ../start-protocol" { error-message - "The end-protocol must be greater than or equal to start-protocol"; + "The end-protocol must be greater than or equal to + start-protocol"; } description "If more than one contiguous protocol value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Protocol field. This field - MUST NOT be included unless the Start Protocol field is included. - When this field is included, the receiver will match all of the - values between fields start-protocol and end-protocol, inclusive - of start-protocol and end-protocol."; + MUST NOT be included unless the Start Protocol field is + included. When this field is included, the receiver will match + all of the values between fields start-protocol and + end-protocol, inclusive of start-protocol and end-protocol."; } } description "ipv4 binary traffic selector"; + } grouping ipv6-binary-traffic-selector { container source-address-range-v6 { presence "Enables setting source IPv6 address range"; description - "Inclusive range representing IPv6 addresses to be used. When - only start-address is present, it represents a single address."; + "Inclusive range representing IPv6 addresses to be used. + When only start-address is present, it represents a + single address."; leaf start-address { type inet:ipv6-address; mandatory true; description - "This field identifies the first source address, from the range of - 128-bit IPv6 addresses to be matched, on data packets sent from a - corresponding node to the mobile node as seen by the home agent. - In other words, this is one of the addresses of the correspondent - node."; + "This field identifies the first source address, from the + range of 128-bit IPv6 addresses to be matched, on data + packets sent from a corresponding node to the mobile node as + seen by the home agent. In other words, this is one of the + addresses of the correspondent node."; } leaf end-address { type inet:ipv6-address; description - "If more than one contiguous source address needs to be matched, - then this field can be used to indicate the end value of a range - starting from the value of the Start Address field. This - field MUST NOT be included unless the Start Address field is included. - When this field is included, the receiver will match all of the addresses - between fields start-address and end-address, inclusive of start-address - and end-address ."; + "If more than one contiguous source address needs to be + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start + Address field. This field MUST NOT be included unless the + Start Address field is included. When this field is + included, the receiver will match all of the addresses + between fields start-address and end-address, inclusive of + start-address and end-address ."; } } container destination-address-range-v6 { presence "Enables setting destination IPv6 address range"; description - "Inclusive range representing IPv6 addresses to be used. When - only start-address is present, it represents a single address."; + "Inclusive range representing IPv6 addresses to be used. + When only start-address is present, it represents a + single address."; leaf start-address { type inet:ipv6-address; mandatory true; description - "This field identifies the first destination address, from the - range of 128-bit IPv6 addresses to be matched, on data packets - sent from a corresponding node to the mobile node as seen by the - home agent. In other words, this is one of the registered home - addresses of the mobile node."; + "This field identifies the first destination address, from + the range of 128-bit IPv6 addresses to be matched, on data + packets sent from a corresponding node to the mobile node as + seen by the home agent. In other words, this is one of the + registered home addresses of the mobile node."; } leaf end-address { type inet:ipv6-address; description "If more than one contiguous destination address needs to be - matched, then this field can be used to indicate the end value of - a range starting from the value of the Start Address field. This - field MUST NOT be included unless the Start Address field is included. - When this field is included, the receiver will match all of the - addresses between fields start-address and end-address, inclusive of + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start + Address field. This field MUST NOT be included unless the + Start Address field is included. When this field is + included, the receiver will match all of the addresses + between fields start-address and end-address, inclusive of start-address and end-address."; } } container flow-label-range { presence "Enables setting Flow Label range"; description "Inclusive range representing IPv4 addresses to be used. When - only start-flow-label is present, it represents a single flow label."; + only start-flow-label is present, it represents a single + flow label."; leaf start-flow-label { type inet:ipv6-flow-label; description - "This field identifies the first flow label value, from the range - of flow label values to be matched, on data packets sent from a - corresponding node to the mobile node as seen by the home agent. - According to [RFC2460], the flow label is 24 bits long. For the - purpose of this specification, the sender of this option MUST - prefix the flow label value with 8 bits of '0' before inserting it - in the start-flow-label field. The receiver SHOULD ignore the - first 8 bits of this field before using it in comparisons with - flow labels in packets."; + "This field identifies the first flow label value, from the + range of flow label values to be matched, on data packets + sent from a corresponding node to the mobile node as seen + by the home agent. According to [RFC2460], the flow label + is 24 bits long. For the purpose of this specification, the + sender of this option MUST prefix the flow label value with + 8 bits of '0' before inserting it in the start-flow-label + field. The receiver SHOULD ignore the first 8 bits of this + field before using it in comparisons with flow labels in + packets."; } leaf end-flow-label { type inet:ipv6-flow-label; must ". >= ../start-flow-label" { error-message - "The end-flow-lable must be greater than or equal to start-flow-label"; + "The end-flow-lable must be greater than or equal to + start-flow-label"; } description - "If more than one contiguous flow label value needs to be matched, - then this field can be used to indicate the end value of a range - starting from the value of the Start Flow Label field. This field - MUST NOT be included unless the Start Flow Label field is - included. When this field is included, the receiver will match - all of the flow label values between fields start-flow-label - and end-flow-label, inclusive of start-flow-label and end-flow-label. - When this field is included, it MUST be coded the same way as defined + "If more than one contiguous flow label value needs to be + matched, then this field can be used to indicate the end + value of a range starting from the value of the Start Flow + Label field. This field MUST NOT be included unless the + Start Flow Label field is included. When this field is + included, the receiver will match all of the flow label + values between fields start-flow-label and end-flow-label, + inclusive of start-flow-label and end-flow-label. When this + field is included, it MUST be coded the same way as defined for end-flow-label."; } } container traffic-class-range { presence "Enables setting the traffic class range"; description "Inclusive range representing IPv4 addresses to be used. When - only start-traffic-class is present, it represents a single traffic class."; + only start-traffic-class is present, it represents a single + traffic class."; leaf start-traffic-class { type inet:dscp; description "This field identifies the first traffic class value, from the - range of traffic class values to be matched, on data packets sent - from a corresponding node to the mobile node as seen by the home - agent. This field is equivalent to the Start DS field in the IPv4 - traffic selector in Figure 1. As per RFC 3260, the field is - defined as a 6-bit DS field with 2 bits reserved, later claimed by - Explicit Congestion Notification (ECN) RFC 3168. For the purpose - of this specification, the start-traffic-class field is 8 bits long, where - the 6 most significant bits indicate the DS field to be matched - and the 2 least significant bits' values MUST be ignored in any + range of traffic class values to be matched, on data packets + sent from a corresponding node to the mobile node as seen by + the home agent. This field is equivalent to the Start DS field + in the IPv4 traffic selector in Figure 1. As per RFC 3260, the + field is defined as a 6-bit DS field with 2 bits reserved, + later claimed by Explicit Congestion Notification (ECN) + RFC 3168. For the purpose of this specification, the + start-traffic-class field is 8 bits long, where the 6 most + significant bits indicate the DS field to be matched and the 2 + least significant bits' values MUST be ignored in any comparison."; reference "RFC 3260: New Terminology and Clarifications for Diffserv - RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP"; + RFC 3168: The Addition of Explicit Congestion Notification + (ECN) to IP"; } leaf end-traffic-class { type inet:dscp; must ". >= ../start-traffic-class" { error-message - "The end-traffic-class must be greater than or equal to start-traffic-class"; + "The end-traffic-class must be greater than or equal to + start-traffic-class"; } description - "If more than one contiguous TC value needs to be matched, then - this field can be used to indicate the end value of a range - starting from the value of the Start TC field. This field MUST - NOT be included unless the Start TC field is included. When this - field is included, it MUST be coded the same way as defined for - start-traffic-class. When this field is included, the receiver - will match all of the values between fields start-traffic-class - and end-traffic-class, inclusive of start-traffic-class and - end-traffic-class."; + "If more than one contiguous TC value needs to be matched, + then this field can be used to indicate the end value of a + range starting from the value of the Start TC field. This + field MUST NOT be included unless the Start TC field is + included. When this field is included, it MUST be coded the + same way as defined for start-traffic-class. When this field + is included, the receiver will match all of the values + between fields start-traffic-class and end-traffic-class, + inclusive of start-traffic-class and end-traffic-class."; + } } container next-header-range { presence "Enables setting Next Header range"; description "Inclusive range representing Next Headers to be used. When - only start-next-header is present, it represents a single Next Header."; + only start-next-header is present, it represents a + single Next Header."; leaf start-next-header { type uint8; description - "This field identifies the first 8-bit next header value, from the - range of next header values to be matched, on data packets sent - from a corresponding node to the mobile node as seen by the home - agent."; + "This field identifies the first 8-bit next header value, from + the range of next header values to be matched, on data packets + sent from a corresponding node to the mobile node as seen by + the home agent."; } leaf end-next-header { type uint8; must ". >= ../start-next-header" { error-message - "The end-next-header must be greater than or equal to start-next-header"; + "The end-next-header must be greater than or equal to + start-next-header"; } description - "If more than one contiguous next header value needs to be matched, - then this field can be used to indicate the end value of a range - starting from the value of the Start NH field. This field MUST - NOT be included unless the Start next header field is included. - When this field is included, the receiver will match all of the - values between fields start-next-header and end-next-header, - inclusive of start-next-header and end-next-header."; + "If more than one contiguous next header value needs to be + matched, then this field can be used to indicate the end value + of a range starting from the value of the Start NH field. This + field MUST NOT be included unless the Start next header field + is included. When this field is included, the receiver will + match all of the values between fields start-next-header and + end-next-header, inclusive of start-next-header and + end-next-header."; } } description "ipv6 binary traffic selector"; } grouping traffic-selector { leaf ts-format { type identityref { base traffic-selector-format; } description "Traffic Selector Format"; } uses traffic-selector-base { - when "boolean(../ts-format/text() = 'ipv6-binary-selector-format') | boolean(../ts-format/text() = 'ipv4-binary-selector-format')"; + when "boolean(../ts-format/text() =" + + "'ipv6-binary-selector-format') |" + + " boolean(../ts-format/text() =" + + " 'ipv4-binary-selector-format')"; } uses ipv4-binary-traffic-selector { - when "boolean(../ts-format/text() = 'ipv4-binary-selector-format')"; + when "boolean(../ts-format/text() =" + + " 'ipv4-binary-selector-format')"; } uses ipv6-binary-traffic-selector { - when "boolean(../ts-format/text() = 'ipv6-binary-selector-format')"; + when "boolean(../ts-format/text() = " + + "'ipv6-binary-selector-format')"; } description "The traffic selector includes the parameters used to match packets for a specific flow binding."; reference - "RFC 6089: Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"; + "RFC 6089: Flow Bindings in Mobile IPv6 and Network + Mobility (NEMO) Basic Support"; } grouping ts-list { list selectors { key index; leaf index { type uint64; description "index"; } uses traffic-selector; description "traffic selectors"; } description "traffic selector list"; } } A.2.4. FPC 3GPP Mobility YANG Model - This module defines the base protocol elements of 3GPP mobility. + This module defines the base protocol elements of 3GPP mobility.. This module references [RFC6991], the fpc-base, fpc-agent, ietf- traffic-selector and pmip-qos modules defined in this document. - file "ietf-dmm-threegpp@2016-08-03.yang" + file "ietf-dmm-threegpp@2017-03-08.yang" module ietf-dmm-threegpp { namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-threegpp"; prefix threegpp; import ietf-inet-types { prefix inet; revision-date 2013-07-15; } - import ietf-dmm-fpc { prefix fpc; revision-date 2016-08-03; } - import ietf-traffic-selector-types { prefix traffic-selectors; revision-date 2016-01-14; } - import ietf-pmip-qos { prefix pmipqos; revision-date 2016-02-10; } + import ietf-dmm-fpc { prefix fpc; revision-date 2017-03-08; } + import ietf-traffic-selector-types { prefix traffic-selectors; + revision-date 2016-01-14; } + import ietf-pmip-qos { prefix pmipqos; + revision-date 2016-02-10; } organization "IETF Distributed Mobility Management (DMM) Working Group"; contact "WG Web: WG List: WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains YANG definition for 3GPP Related Mobility Structures. Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 2017-03-08 { + description "Version 06 updates."; + reference "draft-ietf-dmm-fpc-cpdp-06"; + } + revision 2016-08-03 { description "Initial"; reference "draft-ietf-dmm-fpc-cpdp-04"; + } identity threeGPP-access-type { base "fpc:fpc-access-type"; description "3GPP Access Type"; } // Profile Type identity threeGPP-mobility { base "fpc:fpc-mobility-profile-type"; @@ -5727,21 +5954,22 @@ enum ipv6RemoteAddressPrefix { value 33; description "IPv6 Remote Address Prefix"; } enum ipv6LocalAddressPrefix { value 35; description "IPv6 Local Address Prefix"; } enum protocolNextHeader { value 48; - description "Protocol (IPv4) or NextHeader (IPv6) value"; + description "Protocol (IPv4) or NextHeader (IPv6) + value"; } enum localPort { value 64; description "Local Port"; } enum localPortRange { value 65; description "Local Port Range"; } enum reomotePort { @@ -5784,21 +6013,22 @@ enum bidirectional { value 3; description "bi-direcitonal"; } } description "Packet Filter Direction"; } typedef component-type-id { type uint8 { - range "16 | 17 | 32 | 33 | 35 | 48 | 64 | 65 | 80 | 81 | 96 | 112 | 128"; + range "16 | 17 | 32 | 33 | 35 | 48 | 64 | 65 |" + + " 80 | 81 | 96 | 112 | 128"; } description "Specifies the Component Type"; } grouping packet-filter { leaf direction { type threegpp:packet-filter-direction; description "Filter Direction"; } leaf identifier { @@ -5921,21 +6149,23 @@ list packet-filters { key identifier; uses threegpp:packet-filter; description "List of Packet Filters"; } description "Packet Filter List"; } typedef imsi-type { type uint64; - description "International Mobile Subscriber Identity (IMSI) Value Type"; + description + "International Mobile Subscriber Identity (IMSI) + Value Type"; } typedef threegpp-instr { type bits { bit assign-ip { position 0; description "Assign IP Address/Prefix"; } bit assign-fteid-ip { position 1; @@ -5954,232 +6184,283 @@ description "Commands apply to the Uplink"; } bit downlink { position 5; description "Commands apply to the Downlink"; } bit assign-dpn { position 6; description "Assign DPN"; } - } description "Instruction Set for 3GPP R11"; } - // Descriptors update - goes to Entities, Configure and Configure Bundles - augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:descriptors/fpc:descriptor-value" { + // Descriptors update - goes to Entities, Configure + // and Configure Bundles + augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:" + + "descriptors/fpc:descriptor-value" { case threegpp-tft { uses threegpp:tft; description "3GPP TFT"; } description "3GPP TFT Descriptor"; } - // Contexts Update - Contexts / UL / mob-profile - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { - case threegpp-tunnel { + grouping threegpp-tunnel-info { uses threegpp:threeGPP-tunnel; + choice tft-or-ref { + case defined-tft { uses threegpp:tft; + } + case predefined-tft { + leaf tft-reference { + type fpc:fpc-identity; + description "Pre-configured TFT"; + } + } + description "TFT Value"; + } description "3GPP TFT and Tunnel Information"; } + + // Contexts Update - Contexts / UL / mob-profile + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { + case threegpp-tunnel { + uses threegpp:threegpp-tunnel-info; + } description "Context UL Tunnel"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:ul/fpc:" + + "mobility-tunnel-parameters/fpc:profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Create Context UL Tunnel"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "ul/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Bundles Create Context UL Tunnel"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:" + + "ul/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Create Context UL Tunnel Response"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:contexts/fpc:" + + "ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Bundles Create Context UL Tunnel Response"; } // Contexts Update - Contexts / DL / mob-profile - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; + } description "Context DL Tunnel"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dl/fpc:" + + "mobility-tunnel-parameters/fpc:profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Bundles Create Context DL Tunnel"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:" + + "mobility-tunnel-parameters/fpc:profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Bundles Create Context DL Tunnel"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:dl/fpc:" + + "mobility-tunnel-parameters/fpc:profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Create Context DL Tunnel Response"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Bundles Create Context DL Tunnel Response"; } - // Contexts Update - Contexts / dpns / mobility-tunnel-parameters - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + + // Contexts Update - Contexts / dpns / + // mobility-tunnel-parameters + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Context 3GPP TFT and Tunnel Information"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dpns/fpc:" + + "mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } description "Configure 3GPP TFT and Tunnel Information"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } - description "Configure Bundles 3GPP TFT and Tunnel Information"; + description "Configure Bundles 3GPP TFT and Tunnel + Information"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:" + + "dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } - description "Configure 3GPP TFT and Tunnel Information Response"; + description "Configure 3GPP TFT and Tunnel Information + Response"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case threegpp-tunnel { - uses threegpp:threeGPP-tunnel; - uses threegpp:tft; - description "3GPP TFT and Tunnel Information"; + uses threegpp:threegpp-tunnel-info; } - description "Configure Bundles 3GPP TFT and Tunnel Information Response"; + description "Configure Bundles 3GPP TFT and Tunnel Information + Response"; } // QoS Updates - Context / UL / qosprofile - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; - } description "Context UL 3GPP QoS Values"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:ul/fpc:" + + "qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Context UL 3GPP QoS Values"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "ul/fpc:qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Bundles Context UL 3GPP QoS Values"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:ul/fpc:" + + "qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Context UL 3GPP QoS Values Response"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } - description "Configure Bundles Context UL 3GPP QoS Values Response"; + description "Configure Bundles Context UL 3GPP QoS Values + Response"; } // QoS Updates - Context / DL / QoS Profile - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Context DL 3GPP QoS Values"; + } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dl/fpc:" + + "qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Context DL 3GPP QoS Values"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:" + + "qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Bundles Context DL 3GPP QoS Values"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:dl/fpc:" + + "qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } description "Configure Context DL 3GPP QoS Values Response"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { case threegpp-qos { uses threegpp:threeGPP-QoS; description "3GPP QoS Values"; } - description "Configure Bundles Context DL 3GPP QoS Values Response"; + description "Configure Bundles Context DL 3GPP QoS Values + Response"; } grouping threegpp-properties { leaf imsi { type threegpp:imsi-type; description "IMSI"; } leaf ebi { type threegpp:ebi-type; description "EUTRAN Bearere Identifier (EBI)"; @@ -6188,144 +6469,163 @@ type threegpp:ebi-type; description "Linked Bearer Identifier (LBI)"; } description "3GPP Mobility Session Properties"; } augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts" { uses threegpp:threegpp-properties; description "3GPP Mobility Session Properties"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts" { uses threegpp:threegpp-properties; description "3GPP Mobility Session Properties"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:op_body/fpc:create_or_update/fpc:contexts" { uses threegpp:threegpp-properties; description "3GPP Mobility Session Properties"; - } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts" { uses threegpp:threegpp-properties; description "3GPP Mobility Session Properties"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:contexts" { uses threegpp:threegpp-properties; description "3GPP Mobility Session Properties"; } grouping threegpp-commandset { leaf instr-3gpp-mob { type threegpp:threegpp-instr; description "3GPP Specific Command Set"; } description "3GPP Instructions"; } - augment "/fpc:configure/fpc:input/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:input/fpc:instructions/fpc:" + + "instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } description "Configure 3GPP Instructions"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:instructions/fpc:" + + "instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } description "Configure 3GPP Context Instructions"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:" + + "instructions/fpc:instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } description "Configure 3GPP Context Instructions Response"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "instructions/fpc:instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } description "Configure Bundles 3GPP Instructions"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "instructions/fpc:instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } description "Configure Bundles 3GPP Context Instructions"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:" + + "result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:instructions/fpc:instr-type" { case instr-3gpp-mob { uses threegpp:threegpp-commandset; description "3GPP Instructions"; } - description "Configure Bundles 3GPP Context Instructions Response"; + description "Configure Bundles 3GPP Context Instructions + Response"; } } A.2.5. FPC / PMIP Integration YANG Model This module defines the integration between FPC and PMIP models. This module references the fpc-base, fpc-agent, pmip-qos and traffic- selector-types module defined in this document. - file "ietf-dmm-fpc-pmip@2016-01-19.yang" + file "ietf-dmm-fpc-pmip@2017-03-08.yang" module ietf-dmm-fpc-pmip { namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-pmip"; prefix fpc-pmip; - import ietf-dmm-fpc { prefix fpc; } + import ietf-dmm-fpc { prefix fpc; revision-date 2017-03-08; } import ietf-pmip-qos { prefix qos-pmip; } import ietf-traffic-selector-types { prefix traffic-selectors; } organization "IETF Distributed Mobility Management (DMM) Working Group"; contact "WG Web: WG List: WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains YANG definition for Forwarding Policy Configuration Protocol (FPCP). Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 2017-03-08 { + description "Version 06 update. Adds predfined selector."; + reference "draft-ietf-dmm-fpc-cpdp-06"; + } + revision 2016-01-19 { description "Changes based on -01 version of FPCP draft."; reference "draft-ietf-dmm-fpc-cpdp-01"; } identity ietf-pmip-access-type { base "fpc:fpc-access-type"; description "PMIP Access"; } @@ -6396,144 +6697,180 @@ description "Uplink"; } bit downlink { position 4; description "Downlink"; } } description "Instruction Set for PMIP"; } - // Descriptors update - goes to Entities, Configure and Configure Bundles - augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:descriptors/fpc:descriptor-value" { + // Descriptors update - goes to Entities, Configure and + // Configure Bundles + augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/" + + "fpc:descriptors/fpc:descriptor-value" { case pmip-selector { uses traffic-selectors:traffic-selector; description "PMIP Selector"; } description "Policy Descriptor"; } - // Contexts Update - Contexts / UL / mob-profile, Contexts / DL / mob-profile and Contexts / dpns / mobility-tunnel-parameters - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { - case pmip-tunnel { + grouping pmip-tunnel-info { uses fpc-pmip:pmip-mobility; + choice pmiptunnel-or-ref { + case defined-selector { uses traffic-selectors:traffic-selector; + } + case predefined-selector { + leaf selector-reference { + type fpc:fpc-identity; + description "Pre-configured selector"; + } + } + description "Traffic Selector Value"; + } description "PMIP Tunnel Information"; } + + // Contexts Update - Contexts/UL/mob-profile, Contexts/DL/ + // mob-profile and Contexts/dpns/mobility-tunnel-parameters + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { + case pmip-tunnel { + uses fpc-pmip:pmip-tunnel-info; + } description "Context UL Mobility"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:ul/fpc:" + + "mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "CONF Context UL Mobility"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "ul/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "CONF_BUNDLES Context UL Mobility"; } - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; - + uses fpc-pmip:pmip-tunnel-info; } description "Context DL Mobility"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dl/fpc:" + + "mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "CONF Context DL Mobility"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:op_body/fpc:create_or_update/fpc:" + + "contexts/fpc:dl/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "CONF_BUNDLES Context DL Mobility"; } - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "Context DPN Mobility"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dpns/fpc:" + + "mobility-tunnel-parameters/fpc:profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; + } description "CONF Context DPN Mobility"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:profile-parameters" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:op_body/fpc:create_or_update/fpc:" + + "contexts/fpc:dpns/fpc:mobility-tunnel-parameters/fpc:" + + "profile-parameters" { case pmip-tunnel { - uses fpc-pmip:pmip-mobility; - uses traffic-selectors:traffic-selector; - description "PMIP Tunnel Information"; + uses fpc-pmip:pmip-tunnel-info; } description "CONF_BUNDLES Context DPN Mobility"; } - // QoS Updates - Context / UL / qosprofile, Context / DL / QoS Profile - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + // QoS Updates - Context / UL / qosprofile, Context / DL / + // QoS Profile + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "Context UL QoS"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:ul/fpc:" + + "qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "CONF Context UL QoS"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:op_body/fpc:create_or_update/fpc:" + + "contexts/fpc:ul/fpc:qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "CONF_BUNDLES Context UL QoS"; } - augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-mobility/fpc:" + + "contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "Context DL QoS"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:dl/fpc:" + + "qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "CONF Context DL QoS"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:op_body/fpc:create_or_update/fpc:" + + "contexts/fpc:dl/fpc:qos-profile-parameters/fpc:value" { case qos-pmip { uses qos-pmip:qosattribute; description "PMIP QoS Information"; } description "CONF_BUNDLES Context DL QoS"; } grouping pmip-commandset { leaf instr-pmip { type fpc-pmip:pmip-instr; @@ -6533,121 +6870,136 @@ } description "CONF_BUNDLES Context DL QoS"; } grouping pmip-commandset { leaf instr-pmip { type fpc-pmip:pmip-instr; description "PMIP Instructions"; } description "PMIP Commandset"; - } // Instructions Update - OP BODY, Context, Port - augment "/fpc:configure/fpc:input/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:input/fpc:instructions/fpc:" + + "instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF Instructions"; } - augment "/fpc:configure/fpc:input/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:input/fpc:op_body/fpc:" + + "create_or_update/fpc:contexts/fpc:instructions/fpc:" + + "instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF Context Instructions"; } - augment "/fpc:configure/fpc:output/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure/fpc:output/fpc:result-type/fpc:" + + "create-or-update-success/fpc:contexts/fpc:" + + "instructions/fpc:instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF Result Context Instructions"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:input/fpc:" + + "bundles/fpc:instructions/fpc:instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF_BUNDLES Instructions"; } - augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:op_body/fpc:create_or_update/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:input/fpc:bundles/fpc:" + + "op_body/fpc:create_or_update/fpc:contexts/fpc:" + + "instructions/fpc:instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF_BUNDLES Context Instructions"; } - augment "/fpc:configure-bundles/fpc:output/fpc:bundles/fpc:result-type/fpc:create-or-update-success/fpc:contexts/fpc:instructions/fpc:instr-type" { + augment "/fpc:configure-bundles/fpc:output/fpc:" + + "bundles/fpc:result-type/fpc:create-or-update-success/fpc:" + + "contexts/fpc:instructions/fpc:instr-type" { case pmip-instr { uses fpc-pmip:pmip-commandset; description "PMIP Commandset"; } description "CONF_BUNDLES Result Context Instructions"; } } + A.2.6. FPC Policy Extension YANG Model This module defines extensions to FPC policy structures. This module references [RFC6991], the fpc-base and fpcagent module defined in this document. - file "ietf-dmm-fpc-policyext@2016-08-03.yang" + file "ietf-dmm-fpc-policyext@2017-03-08.yang" module ietf-dmm-fpc-policyext { namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpc-policyext"; prefix fpcpolicyext; - import ietf-dmm-fpc { prefix fpc; revision-date 2016-08-03; } + import ietf-dmm-fpc { prefix fpc; revision-date 2017-03-08; } import ietf-inet-types { prefix inet; revision-date 2013-07-15; } organization "IETF Distributed Mobility Management (DMM) Working Group"; contact "WG Web: WG List: WG Chair: Dapeng Liu WG Chair: Jouni Korhonen Editor: Satoru Matsushima Editor: Lyle Bertz - "; + "; description "This module contains YANG definition for Forwarding Policy Configuration Protocol (FPCP) common Policy Action and Descriptor extensions. Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 2017-03-08 { + description "Version 06 update."; + reference "draft-ietf-dmm-fpc-cpdp-06"; + } + revision 2016-08-03 { description "Changes based on -04 version of FPC draft."; reference "draft-ietf-dmm-fpc-cpdp-04"; } identity service-function { base "fpc:fpc-descriptor-type"; description "Base Identifier for Service Functions."; } identity napt-service { @@ -6677,48 +7029,49 @@ } leaf destination-port { type inet:port-number; description "Destination Port"; } description "Simple NAPT Configuration"; } identity copy-forward { base "fpc:fpc-descriptor-type"; - description "Copies a packet then forwards to a specific destination"; - + description "Copies a packet then forwards to a specific + destination"; } grouping copy-forward { container destination { choice value { case port-ref { leaf port-ref { - type fpc:fpc-port-id; + type fpc:fpc-vport-id; description "Port"; } description "Port Forward Case"; } case context-ref { leaf context-ref { type fpc:fpc-context-id; description "Context"; } description "Context Forward Case"; } description "Copy Forward Value"; } description "destination"; } description "Copy Then Forward to Port/Context Action"; } - augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:actions/fpc:action-value" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:actions/fpc:" + + "action-value" { case simple-nat { uses fpcpolicyext:simple-nat; description "Simple NAT value"; } case simple-napt { uses fpcpolicyext:simple-napt; description "Simple NAPT Value"; } case copy-forward { uses fpcpolicyext:copy-forward; @@ -6735,86 +7088,92 @@ leaf source-ip { type inet:ip-prefix; description "Rule of source IP"; } description "Traffic descriptor group collects parameters to identify target traffic flow. It represents source/destination as IP prefixes"; } - augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:descriptors/fpc:descriptor-value" { + augment "/fpc:tenants/fpc:tenant/fpc:fpc-policy/fpc:" + + "descriptors/fpc:descriptor-value" { case prefix-descriptor { uses fpcpolicyext:prefix-traffic-descriptor; description "traffic descriptor value"; } description "Descriptor Augments"; } } -A.3. FPC nformation Model YANG Tree +A.3. FPC YANG Data Model Structure - This section only shows the YANG tree for the information model. + This section only shows the structure for FPC YANG model. module: ietf-dmm-fpc -module: ietf-dmm-fpc +--rw tenants | +--rw tenant* [tenant-id] | +--rw tenant-id fpc:fpc-identity | +--rw fpc-policy | | +--rw policy-groups* [policy-group-id] | | | +--rw policy-group-id fpc:fpc-policy-group-id | | | +--rw policies* fpc:fpc-policy-id | | +--rw policies* [policy-id] | | | +--rw policy-id fpc:fpc-policy-id | | | +--rw rules* [order] | | | +--rw order uint32 | | | +--rw descriptors* [descriptor-id] | | | | +--rw descriptor-id fpc:fpc-identity | | | | +--rw direction? fpc:fpc-direction | | | +--rw actions* [action-id] - | | | +--rw order? uint32 + | | | +--rw action-order? uint32 | | | +--rw action-id fpc:fpc-action-id-type | | +--rw descriptors* [descriptor-id] | | | +--rw descriptor-id fpc:fpc-identity | | | +--rw descriptor-type identityref | | | +--rw (descriptor-value)? | | | +--:(all-traffic) | | | +--rw all-traffic? empty | | +--rw actions* [action-id] | | +--rw action-id fpc:fpc-action-id-type | | +--rw action-type identityref | | +--rw (action-value)? | | +--:(drop) | | +--rw drop? empty | +--ro fpc-mobility | | +--ro contexts* [context-id] | | | +--ro context-id fpc:fpc-context-id - | | | +--ro ports* fpc:fpc-port-id + | | | +--ro vports* fpc:fpc-vport-id | | | +--ro dpn-group? fpc:fpc-dpn-group-id - | | | +--ro delegating-ip-prefixes* inet:ip-prefix + | | | +--ro delegated-ip-prefixes* inet:ip-prefix | | | +--ro ul {fpc:fpc-basic-agent}? | | | | +--ro tunnel-local-address? inet:ip-address | | | | +--ro tunnel-remote-address? inet:ip-address | | | | +--ro mtu-size? uint32 | | | | +--ro mobility-tunnel-parameters | | | | | +--ro (profile-parameters)? | | | | | +--:(nothing) | | | | | +--ro none? empty | | | | +--ro nexthop | | | | | +--ro nexthop-type? identityref | | | | | +--ro (nexthop-value)? - | | | | | +--:(ip) + | | | | | +--:(ip-nexthop) | | | | | | +--ro ip? inet:ip-address - | | | | | +--:(servicepath) - | | | | | +--ro servicepath? fpc:fpcp-service-path-id + | | | | | +--:(macaddress-nexthop) + | | | | | | +--ro macaddress? ytypes:mac-address + | | | | | +--:(servicepath-nexthop) + | | | | | | +--ro servicepath? fpc:fpc-service-path-id + | | | | | +--:(mplslabel-nexthop) + | | | | | | +--ro lsp? fpc:fpc-mpls-label + | | | | | +--:(if-nexthop) + | | | | | +--ro if-index? uint16 | | | | +--ro qos-profile-parameters | | | | | +--ro qos-type? identityref | | | | | +--ro (value)? | | | | +--ro dpn-parameters | | | | +--ro vendor-parameters* [vendor-id vendor-type] | | | | +--ro vendor-id fpc:fpc-identity | | | | +--ro vendor-type identityref | | | | +--ro (value)? | | | | +--:(empty-type) | | | | +--ro empty-type? empty @@ -6822,24 +7181,30 @@ | | | | +--ro tunnel-local-address? inet:ip-address | | | | +--ro tunnel-remote-address? inet:ip-address | | | | +--ro mtu-size? uint32 | | | | +--ro mobility-tunnel-parameters | | | | | +--ro (profile-parameters)? | | | | | +--:(nothing) | | | | | +--ro none? empty | | | | +--ro nexthop | | | | | +--ro nexthop-type? identityref | | | | | +--ro (nexthop-value)? - | | | | | +--:(ip) + | | | | | +--:(ip-nexthop) | | | | | | +--ro ip? inet:ip-address - | | | | | +--:(servicepath) - | | | | | +--ro servicepath? fpc:fpcp-service-path-id + | | | | | +--:(macaddress-nexthop) + | | | | | | +--ro macaddress? ytypes:mac-address + | | | | | +--:(servicepath-nexthop) + | | | | | | +--ro servicepath? fpc:fpc-service-path-id + | | | | | +--:(mplslabel-nexthop) + | | | | | | +--ro lsp? fpc:fpc-mpls-label + | | | | | +--:(if-nexthop) + | | | | | +--ro if-index? uint16 | | | | +--ro qos-profile-parameters | | | | | +--ro qos-type? identityref | | | | | +--ro (value)? | | | | +--ro dpn-parameters | | | | +--ro vendor-parameters* [vendor-id vendor-type] | | | | +--ro vendor-id fpc:fpc-identity | | | | +--ro vendor-type identityref | | | | +--ro (value)? | | | | +--:(empty-type) | | | | +--ro empty-type? empty @@ -6849,37 +7214,43 @@ | | | | +--ro tunnel-local-address? inet:ip-address | | | | +--ro tunnel-remote-address? inet:ip-address | | | | +--ro mtu-size? uint32 | | | | +--ro mobility-tunnel-parameters | | | | | +--ro (profile-parameters)? | | | | | +--:(nothing) | | | | | +--ro none? empty | | | | +--ro nexthop | | | | | +--ro nexthop-type? identityref | | | | | +--ro (nexthop-value)? - | | | | | +--:(ip) + | | | | | +--:(ip-nexthop) | | | | | | +--ro ip? inet:ip-address - | | | | | +--:(servicepath) - | | | | | +--ro servicepath? fpc:fpcp-service-path-id + | | | | | +--:(macaddress-nexthop) + | | | | | | +--ro macaddress? ytypes:mac-address + | | | | | +--:(servicepath-nexthop) + | | | | | | +--ro servicepath? fpc:fpc-service-path-id + | | | | | +--:(mplslabel-nexthop) + | | | | | | +--ro lsp? fpc:fpc-mpls-label + | | | | | +--:(if-nexthop) + | | | | | +--ro if-index? uint16 | | | | +--ro qos-profile-parameters | | | | | +--ro qos-type? identityref | | | | | +--ro (value)? | | | | +--ro dpn-parameters | | | | +--ro vendor-parameters* [vendor-id vendor-type] | | | | +--ro vendor-id fpc:fpc-identity | | | | +--ro vendor-type identityref | | | | +--ro (value)? | | | | +--:(empty-type) | | | | +--ro empty-type? empty | | | +--ro parent-context? fpc:fpc-context-id - | | +--ro ports* [port-id] - | | | +--ro port-id fpc:fpc-port-id + | | +--ro vports* [vport-id] + | | | +--ro vport-id fpc:fpc-vport-id | | | +--ro policy-groups* fpc:fpc-policy-group-id | | +--ro monitors* | | +--ro monitor-id? fpc:fpc-identity | | +--ro target? fpc-identity | | +--ro (event-config-value)? | | +--:(periodic-config) | | | +--ro period? uint32 | | +--:(threshold-config) | | | +--ro lo-thresh? uint32 | | | +--ro hi-thresh? uint32 @@ -6887,65 +7258,67 @@ | | | +--ro report-time? uint32 | | +--:(events-config-ident) | | | +--ro event-identities* identityref | | +--:(events-config) | | +--ro event-ids* uint32 | +--rw fpc-topology | +--rw domains* [domain-id] | | +--rw domain-id fpc:fpc-domain-id | | +--rw domain-name? string | | +--rw domain-type? string - | | +--rw basename? fpc:fpc-identity {fpc:fpc-basename-registry}? - | | +--rw base-state? string {fpc:fpc-basename-registry}? - | | +--rw base-checkpoint? string {fpc:fpc-basename-registry}? - | +--rw dpn-group-peers* [remote-dpn-group-id] {fpc:fpc-basic-agent}? - | | +--rw remote-dpn-group-id fpc:fpc-dpn-group-id - | | +--rw remote-mobility-profile? identityref - | | +--rw remote-data-plane-role? identityref - | | +--rw remote-endpoint-address? inet:ip-address - | | +--rw local-endpoint-address? inet:ip-address - | | +--rw mtu-size? uint32 - | +--rw dpn-id? fpc:fpc-dpn-id {fpc:fpc-basic-agent}? - | +--rw control-protocols* identityref {fpc:fpc-basic-agent}? + | | +--rw domain-reference? instance-identifier + | | +--rw basename? fpc:fpc-identity + | | | {fpc:fpc-basename-registry}? + | | +--rw base-state? string + | | | {fpc:fpc-basename-registry}? + | | +--rw base-checkpoint? string + | | {fpc:fpc-basename-registry}? + | +--rw dpn-id? fpc:fpc-dpn-id + | | {fpc:fpc-basic-agent}? + | +--rw control-protocols* identityref + | | {fpc:fpc-basic-agent}? | +--rw dpn-groups* [dpn-group-id] {fpc:fpc-multi-dpn}? | | +--rw dpn-group-id fpc:fpc-dpn-group-id | | +--rw data-plane-role? identityref | | +--rw access-type? identityref | | +--rw mobility-profile? identityref | | +--rw dpn-group-peers* [remote-dpn-group-id] | | | +--rw remote-dpn-group-id fpc:fpc-dpn-group-id | | | +--rw remote-mobility-profile? identityref | | | +--rw remote-data-plane-role? identityref | | | +--rw remote-endpoint-address? inet:ip-address | | | +--rw local-endpoint-address? inet:ip-address | | | +--rw mtu-size? uint32 | | +--rw domains* [domain-id] | | +--rw domain-id fpc:fpc-domain-id | | +--rw domain-name? string | | +--rw domain-type? string - | | +--rw basename? fpc:fpc-identity {fpc:fpc-basename-registry}? - | | +--rw base-state? string {fpc:fpc-basename-registry}? - | | +--rw base-checkpoint? string {fpc:fpc-basename-registry}? + | | +--rw domain-reference? instance-identifier + | | +--rw basename? fpc:fpc-identity + | | | {fpc:fpc-basename-registry}? + | | +--rw base-state? string + | | | {fpc:fpc-basename-registry}? + | | +--rw base-checkpoint? string + | | {fpc:fpc-basename-registry}? | +--rw dpns* [dpn-id] {fpc:fpc-multi-dpn}? | +--rw dpn-id fpc:fpc-dpn-id | +--rw dpn-name? string | +--rw dpn-groups* fpc:fpc-dpn-group-id | +--rw node-reference? instance-identifier +--rw fpc-agent-info +--rw supported-features* string +--rw supported-events* [event] | +--rw event identityref | +--rw event-id? fpc:event-type-id +--rw supported-error-types* [error-type] +--rw error-type identityref +--rw error-type-id? fpc:error-type-id -rpcs: ... Figure 28: YANG FPC Agent Tree Authors' Addresses Satoru Matsushima SoftBank 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan @@ -6944,27 +7317,26 @@ Authors' Addresses Satoru Matsushima SoftBank 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan Email: satoru.matsushima@g.softbank.co.jp - Lyle Bertz 6220 Sprint Parkway Overland Park KS, 66251 USA - Email: lyleb551144@gmail.com + Email: lylebe551144@gmail.com Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg Germany Phone: +49 6221 4342146 Email: liebsch@neclab.eu @@ -6972,10 +7345,19 @@ Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Danny Moses Email: danny.moses@intel.com + + Charles E. Perkins + Futurewei Inc. + 2330 Central Expressway + Santa Clara, CA 95050 + USA + + Phone: +1-408-330-4586 + Email: charliep@computer.org