ZENIC ONE Restful Service Provision Interface Specification

ZENIC ONE Restful Service Provision Interface Specification
ZENIC ONE Restful

Service Provision Interface Specification
Version: V16.20.20C2B7
Content
1 Service Provisioning............................................................................................................................................... 3
1.1 User Case........................................................................................................................................... 3
1.1.1 Use Case Features........................................................................................................................ 3
1.1.2 Use Case Operations.................................................................................................................... 3
1.2 L2VPN Service Provisioning.......................................................................................................... 4
1.2.1 Current L2VPNs Creation............................................................................................................4
1.2.2 Workflow for L2VPN Service Provisioning from OSS...............................................................4
1.2.3 Detailed modeling of L2VPN Use Cases..................................................................................... 9
1.3 L3VPN Service Provisioning........................................................................................................15
1.3.1 L3VPN Structure and Classification......................................................................................... 15
1.3.2 List of parameters to configure in the devices for L3VPNs....................................................16
1.3.3 Workflow for L3VPN Creation..................................................................................................16
1.3.4 L3VPN for 3G/4G Fusion Services........................................................................................... 21
1.3.5 L3VPN for Enterprises.............................................................................................................. 25
1.4 LXVPN Parameters Modification................................................................................................44
1.4.1 L3VPN Interface Params Modification.................................................................................... 44
1.4.2 L3VPN CE Routing Params Modification.................................................................................45
1.5 LxVPN Network Retrieval............................................................................................................ 47
1.5.1 Retrieve all L2VPNs...................................................................................................................47
1.5.2 Retrieve all L3VPNs...................................................................................................................48
1.5.3 L3VPN and L2VPN Retrieve Node/Endpoints........................................................................ 49
1.6 LxVPN Network Deletion............................................................................................................. 52
1.6.1 Workflow for L3VPN network deletion...................................................................................52
1.6.2 Workflow for L2VPN network deletion...................................................................................52
1.6.3 Delete a L3VPNs.........................................................................................................................53
1.6.4 Delete an Endpoint of the L3VPNs........................................................................................... 54
1.6.5 L2VPN Service Deletion............................................................................................................ 54
1.6.6 Delete a L2VPNs EndPoints...................................................................................................... 55
1.7 L3VPN Profiles Creation/Modification..................................................................................... 55
1.7.1 General parameter table........................................................................................................... 56
1.7.2 Creation and Modification of the Forwarding filter (IETF-ACCESS-CONTROL-LIST usage) 58
1.7.3 Creation and Modification of the Routing filter (IETF-ROUTING-POLICY & IETF-BGP-
POLICY usage)..................................................................................................................................... 59
1.7.4 RESTCONF: Use Case available interfaces............................................................................... 68
1.8 L2VPN Interface Params Modification......................................................................................69
2 Glossary...................................................................................................................................................................80
3 References.............................................................................................................................................................. 82
1 Service Provisioning
The VPN service defined in RFC 4364 provides a multipoint, routed service to the customer over an
IP/MPLS core. The L3VPNs are widely used to deploy 3G/4G, fixed and enterprise services principally
due to the fact that several traffic discrimination policies can be applied in the network to transport and
guarantee the right SLAs to the mobile customers.
1.1 User Case

1.1.1 Use Case Features
FEATURES
BASIC CREATION ADVANCE CREATION

• Service type • Multicast Support
• L3VPN • Service Binding/Mapping
• L2VPN
• NE-ID and NE-Interface
• CE-PE Routing protocol Selection
• CE-PE Access Encapsulation
• Underlay Transport Selection UPDATE
• RSVP-TE / SR-TE • Change Service Status (Up & Down)
• LDP • Change Service Parameters
1.1.2 Use Case Operations

OPERATIONS
CREATE READ
Create a LxVPN services, nodes and accesses Retrieve a LxVPN Services, Nodes and
using several topologies. Accesses Status
POST GET
Create a VPN node in a particular VPN Retrieve a VPN Node in a particular VPN
Service Service
Create an access to a particular VPN Node. Retrieve Accesses parameters
Create CE-PE routing parameters
Create accesses ethernet encapsulation,
requeriments.
Create QoS relationships of a service.
UPDATE DELETE
Update a LxVPN Services, Nodes and Delete all the LxVPN services, all nodes or all
Accesses Status accesses.
PATCH Update a VPN Node in a particular VPN DEL Delete specific LxVPN services, nodes or all
Service accesses.
Update accesses parameters such as IP Delete a VPN node in a particular VPN
routing and ethernet encapsulation. Service
Delete accesses parameters
1.2 L2VPN Service Provisioning

The lists of use cases identified at the time of writing for L2VPN are:
ID Use case Title Section
A.3.1 L2VPN/Dot1Q/None/Overwriting 1.2.3.2
A.3.2 L2VPN/MeshSDP/None/None 1.2.3.3
A.3.3 L2VPN for Enterprise (3) [VLL/[None|Dot1Q|QinQ]/None/None] 1.2.3.4
A.4.3 VPN for CDN (not included)
A.4.5 VPN for data center interconnection (not included)
B.9 L2VPN QoS Params Modification (not included)
1.2.1 Current L2VPNs Creation

In order to create a L2VPN in the IP network, today it is needed to configure the IP devices manually. To
instantiate, a L2VPN it is needed to create a virtual switching instance in each of the nodes involved in
service deployment. This switching instance allows the Ethernet information propagation between the
sites involved in the service.
The L2VPN parameters configured today in the HL5 are the following if the VPN does not exist:
+ Service Name (VPNID)
+ Operational status / Administrative status
+ VCID
+ Service-MTU
+ Interface
+ Encapsulation
+ VLAN ID
+ Administrative Status
+ Policies
+ Qos
+ Ingress / Egress Shaping
+ Topology (e.g. hub-spoke, in our case)
+ Topology-role
The same kind of validations must be done in the aggregation layer.
1.2.2 Workflow for L2VPN Service Provisioning from OSS

There will be an OSS from which the operator will trigger the provisioning of a L2VPN. In its most basic
form, the OSS could be just a GUI were the operator provides all the necessary parameters. More
complex OSS will automatically get the necessary information. The OSS design is out of scope of this
document.
The main assumption is that the interface between the OSS system and the SDN layer of the network
(OSS-SDTN) shall integrate only mandatory information that is held at the OSS layer or that is requested
by the customer service.
The SDN controller will expose via NBI a L2SM data model using RESTCONF. By using this data model,
the creation of an L2VPN can be automated.
First of all, the generic workflow to create a L2VPN from the OSS system is defined. Four steps are
considered:
 Create the L2VPN sites:
 Include new site-bearers to a Site.
 Create the L2 VPN service and add VPN common attributes.
 Add endpoints to the L2 VPN Service

The corresponding workflow is described in Figure 6
Figure 6. Workflow for L2VPN creation using the L2SM yang definition
While all the intermediate steps are described in the following subsections.
1.2.2.1 Create Site (VPN.L2.Site.Add)
A site is a customer location. For the SDN controller, the site is just an identification that can be used later
to belong to VPNs.
The first step is to create the site in the SDN controller if it has not been previously created. One site can
be used for multiple VPNs. A site can also have multiple connections to the network. With this step, the
SDN Controller will know that the site exists, but it does not know anything about its connectivity. Each
time a new client site that can potentially need VPNs is known; it should be created in the SDN Controller.
As it can be created prior to the activation of services. In the case of being necessary, a site ID and a
Location ID are necessary. This site creation may also include additional information as, for example, the
bearers (if already known and available), description, security or routing protocols for the entire site, etc.
SITE 1 SITE 2
1 2
Figure 7. VPN.L2.Site.Add
The set of parameters to add each of the sites and the responsibilities are the following:
Parameter Responsible Description
SITE ID (if necessary) OSS Identifier of the site.
LOCATION ID (if necessary) OSS Identifier for a particular location.
1.2.2.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

As described in the previous step, a site may exist prior to the service creation, while some of the
connections from that site to the transport network can be modified to cope with the demand or to support
new services or clients. In this sense, one or more bearers may be included during commissioning or
installation process. This process may require on-site manual process to find the appropriate port in the
PE router. This procedure will finish by having new bearers inventoried within the ietf-l2vpn-svc model
(and its augments).
After this first two steps, L2 VPN services can be requested.
SITE ID (if OSS Identifier of the site.
necessary)
Bearer ID OSS Unique identifier for a bearer. This identifies shall be mapped to the
bearer-reference on a site-network-access.
NE_ID (PE OSS Unique identifier for a network element. This identifier may be a
router) string, a UUID, an IP address, etc.
Port_ID OSS Port of the PE router for the given bearer.
1.2.2.3 Create VPN (VPN.L2.Add)

In this step, an L2VPN services is instantiated in the controller. Only the customer, the type of service and
common parameters is indicated. In this step, there are still endpoints attached. The table and figure
below describe the parameters required for the creation of the new VPN service in the SDN layer. This
request will not necessarily generate any direct configuration to be sent to the network elements, as it will
only serve as a notification for the controller to allocate resources for the new service. If information such
as VPN-nodes or import/export profiles is specified at the creation of the VPN service, the SDN layer can
use this information to push this configuration to the network elements. The information includes a VPN
ID, a customer ID and a VPN service topology.
SITE 1 SITE 2
1 VPN 2
Figure 8. VPN.L2.Add
The set of parameters and the responsibilities are the following:

VPN ID OSS Reference to an IP VPN.
VPN service OSS L2 service type. By default, the service type is ‘vpws’.
type
Customer OSS Name of the customer that actually uses the VPN service. In the case
Name that any intermediary (e.g., Tier-2 provider or partner) sells the VPN
service to their end user on behalf of the original service provider (e.g.,
Tier-1 provider), the original service provider may require the customer
name to provide smooth activation/commissioning and operation for the
service.
VPN service OSS VPN service topology.
topology
Description OSS Textual description of a VPN service.
CE VLAN OSS Preserves the CE-VLAN ID from ingress to egress, i.e., the CE-VLAN
preservation tag of the egress frame is identical to that of the ingress frame that
yielded this egress service frame. If all-to-one bundling within a site is
enabled, then preservation applies to all ingress service frames. If all-to-
one bundling is disabled, then preservation applies to tagged ingress
service frames having CE-VLAN IDs 1 through 4094.
CE VLAN OSS CE VLAN CoS preservation. The PCP bits in the CE-VLAN tag of the
COS egress frame are identical to those of the ingress frame that yielded this
preservation egress service frame.
1.2.2.4 Create Site Network Access (VPN.L2.Access.Add)

A site network access connection is an endpoint of the VPN Service. The activation of a new site network
access (e.g. new client port or sub-interface to be included in the VPN instance) requires some
parameters to be sent from the systems layer. These include the ID of the new access, description, the
bearer-reference (reference to the device and interface for the connection), encapsulation of the client
traffic, etc. This information will trigger configuration in the interface of the corresponding interface in the
PE router, but it will not yet be integrated in the VPN service.
SITE 1 SITE 2
1 ACCESS VPN ACCESS 2
Figure 9. VPN.L2.Access.Add

SITE-ID OSS Identifier of the site.
Site-network-access- OSS Identifier for the access.
id
Site-network-access- OSS Describes the type of connection, e.g., point-to-point or
type multipoint.
Status/administrative OSS True if the entity is administratively enabled.
Bearer/bearer- OSS This is an internal reference for the SP. In our case, mapped to
reference the PE router and client port.
Connection / OSS Encapsulation type. By default, the encapsulation type is set to
'ethernet'. Other information enclosed at this container, such as
Ethernet
dot1q, qinq, etc. parameters.
encapsulation
Service/Bandwidth OSS Input and output bandwidth for the service.
Service/MTU OSS SVC MTU. It is also known as the maximum transmission unit or
maximum frame size. When a frame is larger than the MTU, it is
broken down, or fragmented, into smaller pieces by the network
protocol to accommodate the MTU of the network. If CsC is
enabled, the requested svc-mtu leaf will refer to the MPLS MTU
and not to the link MTU.
Service/QoS OSS Reference to a standard profile for QoS, defined at the vpn-
[standard profile] profiles.
VPN attachment OSS Reference to the vpn-service where the new access is to be
attached.
MAC loop prevention OSS MAC loop prevention parameters.
Access control list OSS ACL related parameters
MAC address limit OSS MAC address limit configurations.
1.2.3 Detailed modeling of L2VPN Use Cases

The previous section described the general procedure. In this section, the details for each L2VPN use
case are described.
1.2.3.1 L2VPN for Enterprises
Number A.3
Name L2VPN for Enterprises
Technologies involved IP
Process/Areas Involved Planning and Service Activation
Brief description L2VPN
Devices involved HL5/HL4/HL3
Type Capacity and Services automated delivery
Country Validation COL X PER ARG CHI BRA
1.2.3.2 L2VPN for Enterprise (1) [L2VPN/Dot1Q/None/Overwriting]

Name A.3.1 L2VPN for Enterprises (11)
Service Type L2VPN
End Point Connection Type Dot1Q
Routing Protocol used to Connect the CE None
QoS policies applied in the service Overwriting
1.2.3.2.1 Description
This L2VPN services are part of the wholesale catalog of services deployed in the network in order to
provide Point-to-point (P2P) or Point-to-Multipoint (P2M) connections.
HL4 10.33.4.68/30 HL3
1/1/1
HL4 VAL_SIB 1/1/2

10/2/57:521
2/1/1
HL3
1/1/2
HL4
HL3
Figure 10. Service Diagram

1.2.3.2.2 Configuration example: SDTN NBI
1.2.3.2.2.1 Create Site (VPN.L2.Site.Add)

Parameter Responsible Example
SITE ID (if necessary) OSS VPLS_01_S211
LOCATION ID (if necessary) OSS S211
1.2.3.2.2.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

SITE ID (if necessary) OSS S211
Bearer ID OSS VPLS_01_S211_01
NE_ID (PE router) OSS 10.250.3.51
Port_ID OSS 10/2/57
1.2.3.2.2.3 Create VPN (VPN.L2.Add)

VPN ID OSS 100167463
VPN service type OSS ldp-l2tp-vpls
Customer Name OSS 16746
VPN service topology OSS hub-spoke
Description OSS AZTECA_VALDPARCL16_DS01265236
CE VLAN preservation OSS -
CE VLAN COS preservation OSS -
1.2.3.2.2.4 Create Site Network Access (VPN.L2.Access.Add)

SITE-ID OSS S211
Site-network-access-id OSS SNA_100167463_S211_01
Site-network-access-type OSS point-to-point
Status/administrative OSS UP
Bearer/bearer-reference OSS VPLS_01_S211_01
Connection / OSS Dot1Q
Ethernet encapsulation 521
Service/Bandwidth OSS 32768
32768
Service/MTU OSS -
Service/QoS [standard profile] OSS TELECOM
VPN attachment/VPN ID/Role OSS 100167463
hub
MAC loop prevention OSS -
Access control list OSS -
MAC address limit OSS -
For this specific use case, the calls and RESTCONF requests messages are described in detail with an
example of each parameter in the document RESTconf/l2_ent_4211_final.rc
1.2.3.3 L2VPN for Enterprise (2) [L2VPN/MeshSDP/None/None]

Service Type L2VPN
End Point Connection Type MeshSDP
This L2VPN services are part of the wholesale catalog of services deployed in the network in order to
provide Point-to-point (P2P) or Point-to-Multipoint (P2M) connections. The Mesh SDP supports the split
horizon rule to avoid loops in the L2.

SITE ID (if necessary) OSS VPLS_02_S211

Bearer ID OSS VPLS_02_S211_01
Port_ID OSS 3/1/5

VPN service type OSS ldp-l2tp-vpls
VPN service topology OSS hub-spoke
Description OSS SBC_BUC_La_Joya_Acceso_SIP_ALTAMIRA

SITE-ID OSS VPLS_02_S211
Site-network-access-id OSS SNA_200172420_S211_01
Bearer/bearer-reference OSS VPLS_02_S211_01
Service/Bandwidth OSS -
Service/MTU OSS -
VPN attachment OSS 200172420 spoke
example of each parameter.
1.2.3.4 L2VPN for Enterprise (3) [VLL/[None|Dot1Q|QinQ]/None/None]
Name A.3.3 L2VPN for Enterprise (3) [VLL/[None|Dot1Q|QinQ]/None/None]
Service Type PW
Routing Protocol used to Connect the None
CE
QoS policies applied in the service None
This use case is about provisioning a Single-Domain Ethernet pseudowire (PW). This L2VPN services
are part of the wholesale catalog of services deployed in the network in order to provide Point-to-point
(P2P).
HL4 10.33.4.68/30 HL3
1/1/1
HL4 VAL_SIB 1/1/2

10/2/57:521
2/1/1
HL3
1/1/2
HL4
HL3
Figure 8. Service Diagram

SITE ID (if necessary) OSS VLL_01_S211

Bearer ID OSS VLL_01_S211_01
Port_ID OSS 10/2/57


VPN service type OSS pwe3
VPN service topology OSS Any-to-any
Description OSS AZTECA_VALDPARCL16_DS01265236

SITE-ID OSS S211
Site-network-access-id OSS VLL_100167463_S211_01
Bearer/bearer-reference OSS VLL_01_S211_01
Ethernet encapsulation
521
32768
Service/MTU OSS -

VPN attachment/VPN ID/Role OSS 100167463
hub
For this specific use case the calls and RESTCONF requests messages are described in detail with an
example of each parameter: RESTconf/l2_ent_4211.docx
1.3 L3VPN Service Provisioning

The IP SDN Use cases consider the following categories are the ones described:
A.1 L3VPN for 3G/4G Fusion Services [L3VPN/Dot1Q/None/None] 1.3.4
A.2.1 L3VPN for Enterprise (1) /QinQ/BGP/Overwriting 1.3.5.1
A.2.2 L3VPN for Enterprise (2) /Dot1Q/BGP [multi-hop, 1.3.5.2
static]/Overwriting
A.2.3 L3VPN/Loopback/None/None 1.3.5.3
A.2.4 L3VPN/ipipe/BGP[i]/None 1.3.5.4
A.2.5 L3VPN/Dot1Q/OSPF/Overwriting 1.3.5.5
A.2.6 L2VPN/Dot1Q/None/Overwriting 1.3.5.6
A.2.7 L3VPN/null/null/null 1.3.5.7
A.2.8 L3VPN/Epipe/BGP[i]/None 1.3.5.8
A.2.9 L3VPN/[VPI/VCI]/BGP[import/export]/Overwriting -
A.2.10 L3VPN/[cem]/None/Overwriting -
1.3.1 L3VPN Structure and Classification

The VPN services can be classified using its operational characteristics, thus we have defined the
following structure to identify each possible variation of the VPN service. Additionally, we have included
an identifier of the Use case (Use case Definition) to map the relationship between the commercial offer
and the real deployment:
 Use case Definition: Type of services deployed in the network.
 Functional Parameters: Used to find common structures in the configured Services. This
classification has the following structure:
a. VPN Service Type: Type of service configured
i. L2VPN
ii. L3VPN
b. End Point Connection Type: Encapsulation details used in the CE-PE connection.
i. None
ii. Dot1q
iii. QinQ
iv. L2VPN (ipipe/epipe)
v. VPI/VCI
vi. CEM
vii. Loopback
c. Routing Protocol used to connect the CE: Routing details used in the CE-PE connection.
i. Direct
ii. Static
iii. BGP***
iv. OSPF*
v. ISIS*
vi. RIP*
d. QoS policies applied in the service:
i. None
ii. QoS Overwriting
iii. CIR / PIR policies
1.3.2 List of parameters to configure in the devices for L3VPNs

By definition the L3VPN creates a virtual routing network instance (VRF) in each of the nodes involved in
service deployment. This, routing instance allows the routing information propagation between the sites
involved in the service.
The L3VPN parameters configured in the HL5 are the following if the VPN does not exist:
+ Service Name (VPNID)
+ Autonomous system (if not already commissioned)
+ Router ID (usually is the loopback address)
+ Route Distinguisher
+ Import / Export Target
+ Operational status / Administrative status
+ End Points (1…n)
+ Interface
+ Encapsulation
+ VLAN ID
+ IP Address / mask
+ MTU
+ Administrative Status
+ Policies
+ Qos
+ Ingress / Egress Shaping
+ Policing
+ CE-Connectivity ()
+ Routing Protocols
+ Topology (e.g. hub-spoke, in our case)
+ Topology-role
The same kind of validations must be done in the aggregation layer.
1.3.3 Workflow for L3VPN Creation

The interface between systems and network (OSS-SDTN) shall integrate only mandatory information that
is held at the OSS layer or that is requested by the customer service. For this specific use case, the
parameters and request will have the following four steps:
1. Create/Identify the SITE to be assigned for each connection and the PE termination points.
2. Include new site-bearers to a Site.
3. Create VPN:
a. Add VPN common attributes.
b. Add Import/Export Profiles
c. Add VPN-Node.
4. Create each of the Site Network access connections and their bearers and attach the Site
Network access with the VPN-Node.
The corresponding workflow is as depicted in Figure 11 while all the intermediate steps are described in
the following subsections.
Figure 11. Workflow for L3VPN creation using the L3NM yang definition
1.3.3.1 Create Site (VPN.L3.Site.Add)

The site creation may or may not be necessary, as it can be created prior to the activation of services. In
the case of being necessary, a site ID and a Location ID are necessary. This site creation may also
include additional information as, for example, the bearers (if already known and available), description,
security or routing protocols for the entire site, etc.
SITE SITE
MME
Serving
GW
Figure 12. VPN.L3.Site.Add

The set of parameters to add each of the sites and the responsibilities are the following:
Parameter Responsible Type Description
SITE ID (if necessary) OSS svc-id Identifier of the site.
LOCATION ID (if necessary) OSS svc-id Identifier for a particular
location.
1.3.3.2 Create/add bearers to an existing Site (VPN.L3.Bearer.Add)

As described in the previous step, a site may exist prior to the service creation, while some of the
connections from that site to the transport network can be modified to cope with the demand or to support
new services or clients. In this sense, one or more bearers may be included during commissioning or
installation process. This process may require on-site manual process to find the appropriate port in the
PE router. This procedure will finish by having new bearers inventoried within the ietf-l3vpn-ntw model.
SITE ID (if OSS svc- Identifier of the site.
necessary) id
Bearer ID OSS string Unique identifier for a bearer. This identifies shall be mapped
to the bearer-reference on a site-network-access.
NE_ID (PE OSS string Unique identifier for a network element. This identifier may be
router) a string, a UUID, an IP address, etc.
Port_ID OSS string Port of the PE router for the given bearer.
1.3.3.3 Create VPN (VPN.L3.Add)

The table and figure below describe the parameters required for the creation of the new VPN service in
the SDN layer. This request will not necessarily generate any direct configuration to be sent to the
network elements, as it will only serve as a notification for the controller to allocate resources for the new
service. If information such as VPN-nodes or import/export profiles is specified at the creation of the VPN
service, the SDN layer can use this information to push this configuration to the network elements. The
information includes a VPN ID, a customer ID and a VPN service topology.
SITE SITE
VPN
MME
VPN-node VPN-node
Serving
GW
Figure 13. VPN.L3.Add
The set of parameters and the responsibilities are the following:

VPN ID OSS svc-id Reference to an IP VPN.
Customer OSS string Name of the customer that actually uses the VPN service. In
Name the case that any intermediary (e.g., Tier-2 provider or partner)
sells the VPN service to their end user on behalf of the original
service provider (e.g., Tier-1 provider), the original service
provider may require the customer name to provide smooth
activation/commissioning and operation for the service.
VPN service OSS identityref VPN service topology.
topology
Description OSS string Textual description of a VPN service.
Additionally, the import/export profiles that can be added when creating the VPN service, using the
following parameters:
Ie-profile-id OSS/NET string Unique identifier for an import/export profile
defined within a VPN node.
RD OSS/NET rt-types:route- Route distinguisher.
distinguisher
Vpn-target/route- OSS/NET rt-types:route- Set of route-targets to match for import and
target target export routes to/from VRF. Route target value
Vpn-target/route- OSS/NET rt-types:route- Set of route-targets to match for import and
target-type target-type export routes to/from VRF. Route target type
(import/export/both).
Furthermore, the VPN nodes can be included on VPN creation if the locations (PE routers) are known in
advance. To do so, the following parameters are configurable:
Vpn-node-ID OSS/NET string Identifier of the VPN node. It can be identified or
mapped as the VRF name. As it may not be globally
unique, the ne-id is also needed.
NE-ID OSS/NET string Unique identifier for a network element where to
instantiate the VRF. This identifier may be a string,
a UUID, an IP address, etc.
Description OSS/NET string Textual description of a VPN node.
Router-ID OSS inet:ipv4- In case of being necessary, it defines the IP
address address to identify the VRF. If not specified, the IP
of the loopback interface within the base routing
instance will be used.
ASnumber OSS uint32 AS number of the VRF, if different from the base
instance.
Node-role OSS identityref Role of the vpn-node in the IP VPN.
Status/administrative OSS boolean True if the entity is administratively enabled.
Maximum routes OSS/NET Defines 'maximum-routes' for the VRF.
Node’s IE-profile OSS/NET -> Reference to an import export profile defined within
a VPN service.
1.3.3.4 Create Site Network Access (VPN.L3.Access.Add)
The activation of a new site network access (e.g. new client port to be included in a VRF) requires some
parameters to be sent from the systems layer. These include the ID of the new access, description, the
bearer-reference (reference to the device and interface for the connection), encapsulation of the client
traffic, routing protocols, AS number (not necessary for our use case, with direct routing), IP addresses to
be configured for the PE-CE link. This information will trigger configuration in the interface of the
corresponding interface in the PE router, but it will not yet be integrated in the VPN service.
SITE SITE
VPN
ACCESS MME
ACCESS VPN-node VPN-node ACCESS

Serving
ACCESS ACCESS GW
Figure 14. VPN.L3.Access.Add

SITE-ID OSS svc-id Identifier of the site.
Site-network-access-id OSS svc-id Identifier for the access.
Site-network-access-type OSS identityref Describes the type of connection, e.g., point-to-
point or multipoint.
Status/administrative OSS boolean True if the entity is administratively enabled.
Bearer/bearer-reference OSS string This is an internal reference for the SP. In our
case, mapped to the PE router and client port.
Bearer/Connection/ OSS identityref Encapsulation type. By default, the
encapsulation type is set to 'ethernet'. Other
information enclosed at this container, such as
dot1q, qinq, etc. parameters.
Bearer/Connection/ OSS identityref If connection (site-network-access) is a
pseudowire, any necessary parameter will be
Pseudowire (if
enclosed here (e.g. Virtual circuit ID).
necessary)
Ip-connection/[ipv4/ipv6]/ OSS inet:ipv4- Protocol for IP allocation. Usually defined as
address static and IPs enclosed under the “address”
[dhcp/static]
container.
Service/Bandwidth OSS uint64 Input and output bandwidth for the service.
Service/QoS [standard OSS string Reference to a standard profile for QoS,
profile] defined at the vpn-profiles.
Routing-protocols/ospf OSS Configuration for routing protocol, when ospf is
chosen.
Address-family | Area-
address |
Metric | MTU | Security
Routing-protocols/bgp OSS Configuration for routing protocol, when bgp is
chosen.
ASnumber | address-
family |
Neighbor | Multihop |
Security
Routing- OSS Configuration for routing protocol, when static
protocols/static/ipvX- is chosen.
prefixes/
lan | next-hop | lan-tag
The site-network-accesses created in step 5.3.3.1 are not yet associated to a VPN service and, therefore,
not included into a VRF in the network element. During this step we must associate the already created
site-network-access (and, also, the specific bearer supporting the access) to a specific service. Within the
site network access the VPN-NODE and SERVICE-ID must be filled. With this attachment we are sure
that the following constrains are accomplished:
 One VPN node can have multiple Site Network Access
 One Site Network Access can be in just one VPN Node.
SITE SITE
VPN
ACCESS MME
ACCESS VPN-node VPN-node ACCESS

Serving
ACCESS ACCESS GW
Figure 15. VPN.L3.Access.Attach
The set of parameters to add each of the site network access and the responsibilities are the following:
Service-id OSS/NET -> Identifier of the service where the site-network-access is located.
Node-id OSS/NET -> Identifier of the vpn-node to be attached to the Site Network Access.
1.3.4 L3VPN for 3G/4G Fusion Services

1.3.4.1Use case Definition: L3VPN for 3G/4G Fusion Services
Number A.1
Name L3VPN for 3G/4G Fusion Services
Brief description L3VPN services are widely deployed in the IP/MPLS networks; These
services consume several logical resources (RD, RT, VLANs, IP Address,
etc.) to be deployed correctly. The maintenance is done in the network daily
and several areas get involved.
1.3.4.2 Use case Parameters: L3VPN for 3G/4G Fusion Services

Name A.1 L3VPN for 3G/4G Fusion Services
Service Type L3VPN
Routing Protocol used to Connect the CE Direct
1.3.4.3 Description
In the L3VPN for 3G/4G Fusion Services the nodeB are directly connected to the HL5 layer. The HL5
acts as a first aggregation layer, for nodes that shares the same geographical location. The connection
between HL3 and HL5 are made in a ring topology. The HL3 receives and aggregates traffic from the
rings of the same state (geographical location). In the HL5 a L3VPN is created to receive the interfaces
of each nodeB. Three interfaces are created in the HL5 each in a different IP Address and VLAN range:
 PKI interface: Used for PKI authentication.
 S1 Interface: Users Traffic
 Sync Interface: Clock signaling
The VPNID, targets and distinguisher are derived from standard naming conventions [5]. Additional
logical resources such VLANs, IP Addresses are defined by the network planning team during the service
design. The HL3 acts as a Route Reflector for all the HL5 of the region. For that reason, specific filtering
rules must be configured in the MP-BGP session.
Figure 16. Service topology diagram
To deploy this service several conditions must be evaluated, Figure 17 show the different scenarios:
Figure 17. Service provision options
1. Is the HL5 already deployed in the network?

o No. Some commissioning process may be done. This Includes Physical/Logical
activation of the device, interfaces, and protocols.
o Yes. Is the L3VPN already configured at the HL5 receiving the nodeB?
 No. Full configuration may be done.
 Yes. Just the interface parameters must be included in the configuration.
1.3.4.4 Configuration example: SDTN NBI
For this specific use case the set of parameters and RESTCONF request messages are described in
detail with an example of each parameter:
1.3.4.4.1 Create Site (VPN.L3.Site.Add)
Parameter Responsible Service Example
SITE ID (if necessary) OSS MLB0832-GUATEQUE-CENTRO
LOCATION ID (if necessary) OSS GUATEQUE-CENTRO
1.3.4.4.2 Create Bearer (VPN.L3.Bearer.Add)

SITE ID (if necessary) OSS MLB0832-GUATEQUE-CENTRO
Bearer ID OSS S1-MLB0832-GUATEQUE-CENTRO
Port_ID OSS 1/4/6
1.3.4.4.3 Create VPN (VPN.L3.Add)

Customer Name OSS 4G_Movistar
VPN service topology OSS any-to-any
Description OSS 4G _Movistar

Ie-profile-id OSS/NET ie_00
RD OSS/NET 65100:87400023
Vpn-target/route-target OSS/NET 65010:17400
Vpn-target/route-target-type OSS/NET both

Vpn-node-ID OSS/NET 550087400_10.226.0.23
NE-ID OSS/NET 10.226.0.23
Description OSS/NET 4G_MOVISTAR
Router-ID OSS 10.226.0.23
ASnumber OSS 65001
Node-role OSS any-to-any
Maximum routes OSS/NET -
Node’s IE-profile OSS/NET ie_00
1.3.4.4.4 Create Access (VPN.L3.Access.Add)

SITE-ID OSS MLB0832-GUATEQUE CENTRO
Site-network-access-id OSS PKI-MLB0832-550087400
Site-network-access-type OSS Point-to-point
Bearer/bearer-reference OSS S1-MLB0832-GUATEQUE CENTRO
Bearer/Connection/ OSS Vlan Dot1q 1017
Bearer/Connection/ OSS -
Pseudowire (if necessary)
Ip-connection/[ipv4/ipv6]/ OSS 10.99.84.69/30
[dhcp/static]
Service/QoS [standard profile] OSS -
Routing-protocols/ospf OSS -
Address-family | Area-address |
Routing-protocols/bgp OSS .
ASnumber | address-family |
Neighbor | Multihop | Security
Routing-protocols/static/ipvX-prefixes/ OSS None
Service-Id OSS/NET 550087400
VPN-Node OSS/NET 550087400_10.226.0.23
1.3.4.5 Device configuration via standard model

This part (SBI) is out of the scope of this document. It will be studied in later versions.
1.3.5 L3VPN for Enterprises

Number A.2
Name L3VPN for Enterprises
Brief description L3VPN for enterprises are customer fitted solutions able to fulfill
connectivity and SLAs compliancy between sites using a common
infrastructure. This kind of services support changes in topology as well as
in parameters configuration. In Colombia services is common to have just
one scheduler and QoS profile. These policies are overwritten in each of
the services configured in the network.
The generic service topology diagram for this kind of services is the following:
HL4
HL3
10.33.4.68/30
1/1/1
HL4 VAL_SIB 1/1/2
2/1/1
HL3
1/1/2
HL4
HL3
Figure 18. Service diagram
The list of services described are:

1.3.5.1 Use case Parameters: L3VPN for Enterprises (1)
Service Type L3VPN
End Point Connection Type QinQ
Routing Protocol used to Connect the CE BGP
This service has been widely deployed for wholesale customers. It uses BGP as the routing protocol
between the CE and the PE. This BGP connection does not has any special parameters or authentication.
In the HL4 the Router has an access list to export just the default route to the customer. Each customer
site has an access interface inside the VRF. In this interface the schedulers and QoS policies are
overwriting to fulfill the service characteristics. According to this practice has put a limit to the traffic that
can access the network in the connection border.
SITE ID (if necessary) OSS BCO_01_S8137

Bearer ID OSS BCO_01_S8137_01
Port_ID OSS 1/10/1

VPN service topology OSS HUB-SPOKE
Description OSS BANCO_XX

Ie-profile-id OSS/NET Ie_01
RD OSS/NET 3816:100090690
Vpn-target/route-target-type OSS/NET both

Description OSS/NET BANCO_XX
ASnumber OSS 3816
Node-role OSS SPOKE
Node’s IE-profile OSS/NET Ie_01

SITE-ID OSS BCO_01_S8137
Site-network-access-id OSS SNA_500100090_01
Site-network-access-type OSS POINT-TO-POINT
Description OSS
Bearer/bearer-reference OSS BCO_01_S8137_01
Bearer/Connection/ OSS QinQ
1514
Ip-connection/[ipv4/ipv6]/ OSS 10.91.243.65
[dhcp/static]
2048
Service/QoS [standard profile] OSS
Routing-protocols/bgp OSS BGP
ASnumber | address-family | 65009
Neighbor | Multihop | Security 10.91.243.64
none
none
Routing-protocols/static/ipvX-prefixes/ OSS -
Service-Id OSS/NET 500100090_10.250.3.38
VPN-Node OSS/NET SNA_500100090_01
1.3.5.1.7 Device configuration via standard model

Service Type L3VPN
Routing Protocol used to Connect the CE BGP [multi-hop, static]
This service has been widely deployed for wholesale customers. It uses BGP as the routing protocol
between the CE and the PE. This BGP connection has a multi-hop (peering routers are not directly
connected) connection for that reason a static route is configured to reach the CE-peering router. Define
the number of hops of this connection is vital inside the BGP connection because the TTL of the BGP
open messages is decreased during each jump. If the hop-count is not the same as the number of host’s
jumps the TTL expires and the session cannot be established.

Port_ID OSS 1/10/2
VPN service topology OSS OK HUB-SPOKE
Description OSS BANCO_XX_02

Ie-profile-id OSS/NET Ie_02
RD OSS/NET 3816:101322013

Vpn-target/route-target-type OSS/NET

Description OSS/NET BANCO_02
ASnumber OSS 3816
Node-role OSS SPOKE
Node’s IE-profile OSS/NET Ie_02

Description OSS BANCO_BELEN
Bearer/Connection/ OSS Dot1Q
[dhcp/static]
2048
Service/QoS [standard profile] OSS S-P TELECOM
multihop 5
none
Routing Profiles | ID | Type import "non-default-route"
export "To_CE_Datos_BGP"
Routing-protocols/static/ipvX-prefixes/ OSS Static 10.4.101.186 via 10.250.2.141
VPN-Node OSS/NET 500101323_10.250.3.38

Name A.2.3 L3VPN for Enterprises (3) – VRF Lite
Service Type L3VPN
End Point Connection Type Loopback
This use case has been designed to support the deployment of VRF Lite network Instances It is a way to
make multiple routing tables that are completely separate from each other. VRF lite is considered a way
of using VRF's to segment networks without MPLS. This use case also allows the creation of loopback
interfaces inside the VRFs so in this case the Bearer creation is not required.
SITE ID (if necessary) OSS TEST_04_S8137

The bearer creation is not necessary in this use case, because the site network access is using the
LOOPBACK type.
VPN ID OSS 134
Description OSS TEST

Ie-profile-id OSS/NET IE_03
RD OSS/NET 3816:134
Vpn-target/route-target OSS/NET -
Vpn-target/route-target-type OSS/NET -

Description OSS/NET TEST
ASnumber OSS 3816
Node-role OSS SPOKE
Node’s IE-profile OSS/NET IE_03

SITE-ID OSS TEST_04_S8137
Site-network-access-id OSS SNA_134_10.250.3.38_01
Site-network-access-type OSS LOOPBACK
Bearer/bearer-reference OSS -
[dhcp/static]
Routing-protocols/bgp OSS -
Routing-protocols/static/ipvX-prefixes/ OSS .
VPN-Node OSS/NET 134_10.250.3.38

Service Type L3VPN
End Point Connection Type Ipipe
This service has been deployed for wholesale customers. It uses a pseudowire to extend the customer’s
Ethernet information to the aggregation layer. In the HL3 the pseudowire finishes in an access interfaces
with an IP address assignment. The QoS and shaping constrains are applied in the access interface of
the HL5.

Port_ID OSS 1/3/1

Description OSS BANCO_RIOHACHA

RD OSS/NET 3816:100090690
Vpn-target/route-target-type OSS/NET BOTH

Description OSS/NET BANCO_RIOHACHA
ASnumber OSS 3816
Node-role OSS SPOKE

Site-network-access-type OSS PSEUDOWIRE
Bearer/Connection/ OSS PSEUDOWIRE
Pseudowire (if necessary) 300300501
[dhcp/static]
2048
none
none
VPN-Node OSS/NET 500100090_10.250.3.38

1.3.5.5 Use case Parameters: L3VPN for Enterprises
Service Type L3VPN
Routing Protocol used to Connect the CE OSPF
This service has been widely deployed for wholesale customers. It uses OSFP as the routing protocol
between the CE and the PE. This OSPF session creates a stub area to connect the CE site to the
network. Import/Export access lists can be applied into the connection to filter the routes received and
announced between the customer and the provider. MTU parameters can set under the interface
parameters.
detail with an example of each parameter.

SITE ID (if necessary) OSS IE_01_S8137

SITE ID (if necessary) OSS IE_01_S8137
Bearer ID OSS IE_01_S8137_01
Port_ID OSS 1/2/26

VPN service topology OSS OK HUB-SPOKE
Description OSS IE_FONSECA

RD OSS/NET 3816:100160380

Description OSS/NET IE_FONSECA
ASnumber OSS 3816
Node-role OSS SPOKE

Bearer/bearer-reference OSS IE_01_S8137_01
[dhcp/static]
4000
Routing-protocols/ospf OSS area 0.0.0.1
Address-family | Area-address | mtu 1500
Routing Profiles | ID | Type export "ce-valledupar"
Routing-protocols/static/ipvX-prefixes/ OSS
VPN-Node OSS/NET 500100160_10.250.3.38

Service Type L3VPN
Routing Protocol used to Connect the CE Null
This service has been widely deployed for wholesale customers. It does not use any routing protocol
between the CE and the PE. For that reason, just the directly connected interfaces are included in the
routing information of the VPN.
SITE ID (if necessary) OSS WH_01_S8137

SITE ID (if necessary) OSS WH_01_S8137
Bearer ID OSS WH_01_S8137_01
Port_ID OSS 1/2/13

Description OSS ETICOS_VALLEDUPAR

RD OSS/NET 3816:150000520

Description OSS/NET ETICOS_VALLEDUPAR
ASnumber OSS 3816
Node-role OSS SPOKE

SITE-ID OSS WH_01_S8137
Bearer/bearer-reference OSS WH_01_S8137_01
[dhcp/static]
VPN-Node OSS/NET 500150000_10.250.3.38

Service Type L3VPN
End Point Connection Type Null
Routing Protocol used to Connect the CE Null
QoS policies applied in the service Null
This service has been widely deployed for management services.
SITE ID (if necessary) OSS MG_01_S211

SITE ID (if necessary) OSS MG_01_ S211
Bearer ID OSS MG_01_ S211_01
Port_ID OSS 1/2/11

Description OSS "SAN-CEN"

RD OSS/NET 3816:60000147
Vpn-target/route-target-type OSS/NET import
Vpn-target/route-target-type OSS/NET export

Description OSS/NET GESTION
ASnumber OSS 3816
Node-role OSS SPOKE

SITE-ID OSS MG_01_ S211
Bearer/bearer-reference OSS MG_01_ S211_01
Bearer/Connection/ OSS None
Bearer/Connection/ OSS None
Ip-connection/[ipv4/ipv6]/ OSS 10.34.6.217/29
[dhcp/static]
VPN-Node OSS/NET 500006000_10.250.3.51

Service Type L3VPN
End Point Connection Type Epipe
This service has been deployed for wholesale customers. It uses a pseudowire to extend the customer’s
Ethernet information to the aggregation layer. In the HL3 the pseudowire finishes in an access interfaces
with an IP address assignment. The QoS and shaping constrains are applied in the access interface of
the HL5.

Port_ID OSS 1/3/1

Description OSS BANCO_RIOHACHA

RD OSS/NET 3816:100090690

Description OSS/NET BANCO_RIOHACHA
ASnumber OSS 3816
Node-role OSS SPOKE

Site-network-access-type OSS PSEUDOWIRE
Bearer/Connection/ OSS PSEUDOWIRE
Pseudowire (if necessary) 300300501
[dhcp/static]
2048
none
none
VPN-Node OSS/NET 500100090_10.250.3.38
1.4 LXVPN Parameters Modification

Modification of the network information is one of the main use cases for the SDN Controller. It is the base
to support inventory updates and planning possible applications. To achieve this, the IP SDNc acts an
aggregation point to expose all the information in a common way for its possible clients (SDTN, OSS,
APPs).
In order to be able to modify the content of a resource, the IP SDNc must support the PATCH operation
as is defined in the RFC 8040, in such a way that if the target resource instance does not exist, it MUST
NOT be created.
Based on the structure defined in the models, the set of use cases supported in the following section are:
B.5 L3VPN Interface Params Modification 1.4.1
B.6 L3VPN CE-Routing Params Modification 1.4.2
B.7 L3VPN QoS Params Modification Not included
B.8 L2VPN Interface Params Modification Not included
B.9 L2VPN QoS Params Modification Not included
1.4.1 L3VPN Interface Params Modification

Number B.5
Name L3VPN Interface Parameters Modification
Process/Areas Involved Service Provisioning
When a L3VPN interface is created, different parameters are configured,
such as the input/output service bandwidth limitation, description, status,
Brief description
VLAN identifier IP addressing, etc. The aim of this use case is to be able to
modify all these VPN interface related parameters.
Devices involved HL5/HL4/HL3/HL2/HL1
Type Service Provisioning
1.4.1.1 Model parameters

Although the L3NM yang model includes a wide number of variables related with the interface or site-
network-access, it has been selected a reduced set of those parameters which are mainly related with the
L3VPN creation use cases defined in previous sections.
The set of parameters that could be modified are summarized on the following table.
Attribute Format Responsible Mod
description string OSS rw
site-network-access-type Enum: {"point-to- OSS rw
point"|"multipoint"|"pseudowire"}
status/admin-enabled boolean OSS rw
bearer/bearer-reference string OSS rw
Bearer/connection/encapsulation- Emum: {“tagged-int” | “untagged- OSS rw
type int”}
Bearer/connection/tagged- Enum. {“dot1q” | ”priority-tagged” OSS rw
interface/type | “qinany” | “qinq” | “vxlan”}
Bearer/connection/tagged- Unit16 OSS rw
interface/dot1q-vlan-tagged/cvlan-
id
bearer/pseudowire/vcid Unit32 OSS rw
Bearer/ip- Enum: {"provider-dhcp"|"provider- OSS rw
connection/[ipv4/ipv6]/address- dhcp-relay"|"provider-dhcp-
allocation-type slaac"|"static-address"|"slaac"}
Bearer/ip-connection/ipv4/static- string OSS rw
address/address/address-id
Bearer/ip-connection/ipv4/static- inet:ipv4-address (string) OSS rw
address/address/provider-address
Bearer/ip-connection/ipv4/static- uint8 OSS rw
address/address/prefix-length
Service/svc-input-bandwidth unit64 OSS rw
Service/svc-output-bandwidth unit64 OSS rw
service/qos/qos- leafref OSS rw
profile/standard/profile
1.4.1.2 Workflow
Figure 19. Edit VPN PE-CE parameter interface workflow
1.4.1.3 Operation example
The following example shows how to modify the value of the IP addressing of a given PE-CE interface.
The HTTP request is the following:
PATCH /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/sites/site={site-
id}/site-network-accesses/site-network-access={site-network-access-
id }/ip-connection/ipv4/static-addresses HTTP/1.1
Host: example.com
Accept: application/yang-data+json
{
"provider-address": "10.0.0.1",
"prefix-length": "30"
}
The sample expected response if the parameter has been found and the value has been modified is the
following:
HTTP/1.1 204 No Content
1.4.2 L3VPN CE Routing Params Modification

Number B.6
Name L3VPN CE Routing Parameters modification
When a L3VPN is created, CE routes can be populated to the router PE in
several ways such as static routing or dynamic routing protocols such as
Brief description
BGP, OSPF, RIP, etc. The aim of this use case is to be able to modify the
VPN parameters related to CE routing.
1.4.2.1 Model parameters

Although the L3NM yang model includes a wide number of variables related with the routing protocols on
an interface or site-network-access, it has been selected a reduced set of those parameters which are
mainly related with the L3VPN creation use cases defined in previous sections.
The set of parameters that could be modified are summarized on the following table.
Attribute Format Responsible Mod
type Enum: {“direct” | “bgp” | OSS rw
“ospf” | “rip” | “vrrp” |
“static”}
[ospf/bgp/rip/vrrp]/address- address-family OSS rw
family
ospf/area-address dotted-quad (string) OSS rw
ospf/metric uint16 OSS rw
ospf/mtu uint16 OSS rw
Bgp/autonomous-system Uint32 OSS rw
Bgp/neighbor inet:ip-address OSS rw
Bgp/multihop1 uint8 OSS rw
Static/cascaded-lan- inet:ipv4-prefix OSS rw
prefixes/[ipv4/ipv6-lan-
prefixes]/lan
Static/cascaded-lan- inet:ipv4-prefix OSS rw
prefixes]/next-hop
Static/cascaded-lan- string OSS rw
prefixes]/lan-tag
1.4.2.2 Workflow
1
BGP multihop parameter success modification requires the existence of the corresponding static route.
Figure 20. Edit VPN CE routing protocol parameter workflow
1.4.2.3 Operation example
The following example shows how to modify the value of the neighbor of a given PE-CE BGP connection.
The HTTP request is the following:
PATCH /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/sites/site={site-
id}/site-network-accesses/site-network-access={site-network-access-
id }/routing-protocols/routing-protocol/bgp HTTP/1.1
Host: example.com
{
"neighbor": "192.168.1.2"
}
The sample expected response if the parameter has been found and the value has been modified is the
following:
HTTP/1.1 204 No Content
1.5 LxVPN Network Retrieval

Retrieval and expose the network information is one of the main use cases for the SDN Controller. It is
the base to support inventory, performance and planning possible applications. To achieve this, the IP
SDNc acts as an aggregation point to expose all the information in a common way for its possible clients
(SDTN, OSS, APPs).
Based on the structure defined in the models, the set of use cases supported in the following section are:
C.1 Retrieve all L3VPNs 1.5.2
C.2 Retrieve all L2VPNs 1.5.1
Query information of existing L3VPN and L2VPN (A.1, A2.X and
C.3 1.5.3
A3.X use cases)
1.5.1 Retrieve all L2VPNs

Number C.2
Name Retrieve all L2VPNs
Brief description This use case is used to get the entire set of VPN services of the IP
Network.
To retrieve all the L2VPNs the syntax, workflow and parameters are the following:
GET /restconf/data/ietf-l2vpn-svc:l2vpn-svc/vpn-
services HTTP/1.1
Host: example.com
Figure 21. Get All VPNs Workflow
1.5.2 Retrieve all L3VPNs

Number C.1
Name Retrieve all L3VPNs
Brief description This use case is used to get the entire set of VPN services of the IP
Network.
To retrieve all the L3VPNs the syntax, workflow and parameters are the following:
GET /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-
services HTTP/1.1
Host: example.com
Figure 22. Get All L3VPNs Workflow
1.5.3 L3VPN and L2VPN Retrieve Node/Endpoints

Number C.3
Name L3VPN and L2VPN Retrieve Node/Endpoints
Brief description This use case is used to get the node (in case of L3VPN) and access-point
parameters for a VPN service.
This use case is used to get the entire set of Nodes and Site Network Access deployed in the VPN
services.
 Get VPNs Nodes from the VPN service
 Get Site Network Access from Site
1.5.3.1 L3VPN Node/Endpoints of L3VPNs
To retrieve all the L3VPNs Nodes for a particular service the syntax, workflow and parameters are the
following:
GET /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-
services/vpn-service={VPN_ID}/vpn-nodes HTTP/1.1
Host: example.com
Figure 23. Get All Vpn Nodes from a selected VPN service Workflow
To retrieve all the L3VPNs EndPoints (Site Network Accesses) for a particular site the syntax, workflow
and parameters are the following:
GET /restconf/data/ietf-l3vpn-ntw:l3vpn-
ntw/sites/site={site-id}/site-network-accesses
HTTP/1.1
Host: example.com
Figure 24. Get the Site Network Access from a selected site
1.5.3.2 L2VPN Endpoints of L2VPNs

In the case of L2VPNs, vpn-node element does not exist on L2SM yang model. Because of that, it is not
needed to retrieve such as information.
To retrieve all the L3VPNs EndPoints (Site Network Accesses) for a particular site the syntax, workflow
and parameters are the following:
GET /restconf/data/ ietf-l2vpn-svc:l2vpn-svc/vpn-

services /sites/site={site-id}/site-network-accesses
HTTP/1.1
Host: example.com
Figure 25. Get the Site Network Access from a selected site
1.6 LxVPN Network Deletion

Deletion of the network information is one of the main use cases for the SDN Controller. It is the base to
support inventory updates and planning possible applications. To achieve this, the IP SDNc acts an
aggregation point to expose all the information in a common way for its possible clients (SDTN, OSS,
APPs).
Based, on the structure defined in the models. The set of use cases supported in the following section are:

B.1 L3VPN Service deletion 1.6.1
B.2 L3VPN Service endpoint deletion 1.6.4
B.3 L2VPN Service deletion 1.6.5
B.4 L2VPN Service endpoint deletion 1.6.6
1.6.1 Workflow for L3VPN network deletion

The general workflow of operations that have to be carried out to complete the deletion of a L3VPN
service is represented on the following figure.
Figure 26. Delete L3VPN workflow
1.6.2 Workflow for L2VPN network deletion

The general workflow of operations that have to be carried out to complete the deletion of a L2VPN
service is represented on the following figure.
Figure 25. Delete L2VPN workflow
1.6.3 Delete a L3VPNs

Number B.1
Name Delete a L3VPNs
Brief description This use case is used to delete the a L3VPN services of the IP Network.
1.6.3.1 Operations
Before deleting all L3VPN services, it is needed to erase all the nodes attached or created within that
service. For doing that, the following operation will be done:
DELETE /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-
services/service={{l3vpnservice}}/vpn-nodes HTTP/1.1
Host: example.com
Once the vpn-nodes have been erased, it can be executed the next step: to delete all L3VPNs. The
syntax, workflow and parameters are the following:
DELETE /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-
services HTTP/1.1
Host: example.com
The sample expected response for both operations if the elements have been found and have been
deleted is the following:
HTTP/1.1 200 OK
1.6.4 Delete an Endpoint of the L3VPNs

Number B.2
Brief description This use case is used to delete the a L3VPN services endpoints of the IP
Network.
To delete a Site Network Access if a particular L3VPNs the syntax, workflow and parameters are the
following:
DELETE /restconf/data/ietf-l3vpn-ntw:l3vpn-
ntw/sites/site={site-id}/site-network-accesses/site-
network-access={site-network-access-id} HTTP/1.1
Host: example.com
1.6.4.1 Examples
The sample response is the following:
HTTP/1.1 200 OK
1.6.5 L2VPN Service Deletion

Number B.3
Brief description This use case is used to delete the a L2VPN services of the IP Network.
1.6.5.1 Operations
Before deleting all L2VPN services, it is needed to erase all the endpoints attached or created within that
service (see section 5.6.6).
The syntax, workflow and parameters to delete L2VPN service are the following:
DELETE /restconf/data/ietf-l2vpn-svc:l2vpn-svc/vpn-
services HTTP/1.1
Host: example.com
The sample expected response for both operations if the elements have been found and have been
deleted is the following:
HTTP/1.1 200 OK
1.6.6 Delete a L2VPNs EndPoints

Number B.4
Name Delete a L2VPNs EndPoints
Brief description This use case is used to delete the a L2VPN services endpoints of the IP
Network.
To delete a Site Network Access of a particular L2VPN the syntax, workflow and parameters are the
following:
DELETE /restconf/data/ietf-l2vpn-svc:l2vpn-
svc/sites/site={site-id}/site-network-accesses/site-
network-access={site-network-access-id} HTTP/1.1
Host: example.com
1.6.6.1 Examples
The sample response is the following:
HTTP/1.1 200 OK
1.7 L3VPN Profiles Creation/Modification

Number B.7
Name L3VPN Profiles Creation/Modification
When a L3VPN a set of QoS, Encryption, Routing and Security profiles can
Brief description be added to the service. The Profile creation and modification Is part of the
following use case.
1.7.1 General parameter table
L3VPNs has a common container to enclose a set of profiles to be reused between VPN services and
VPN nodes. The set of available profiles are:
 Cloud Identifier: List of cloud Identifiers.
 Encryption Profile Identifier: Profile used for the CE-PE connectivity. It has only local meaning.
 QoS Profile Identifier: Profile used to control the QoS marking inside the L3VPN.
 BFD Profile Identifier: List for BFD Profile identifiers. Groups the same interval and multiplier for
several BFD sessions.
 Forwarding Profile Identifier: List for forwarding filters to be applied on the service. These kinds
of filters are firewall rules that can be applied over an interface or as part of the whole service.
NOTE: THIS MODULE IS AVAILABLE IN THE NEWEST VERSIONS OF THE L3NM.
 Routing Profile Identifier: List of Profiles used to control the routing actions based on L2/L3/L4
packet headers.
The conditions to deploy and relate a VPN service with the policy are the following:
 The profile-id is just a hook to attach the policy.
 The policy must be created before the service is created.
 The policy is created as an independent process from the service.
 The profile-id attachment inside the L3VPN is done using the leaf associated to each kind of
profile.
 The name must match between the id in the L3NM and the name of the Profile.
For example:
To attach a QoS Profile = QOS_ to the service.
The profile must be a valid entry in the Valid profile identifiers.
/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/qos-profile-
identifier/id = QOS_TELEFONICA
Then the QoS profile id must be in set in the QoS Profile leaf of the VPN Network Access in the
model:
/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-network-
accesses/vpn-network-access/service/qos/qos-profile/qos-
profile/profile = QOS_TELEFONICA
IETF-L3VPN-NTW
VALID PROFILES VPN SERVICE
VPN NODE
Cloud Encryption Routing

QoS Profile BFD Profile
Identifier Profile Profile VPN NETWORK ACCESS
Id
Service
QoS Profile
Reference
Id
Figure 27. Profiles Relationship

As described before, the creation of this profiles in the controller must be done prior to the assignation of
their usage as a reference inside a service. To create these profiles, the YANG modules selected are the
following:
 Cloud Identifier: PENDING, NOT MODELED YET.
 Encryption Profile Identifier: PENDING, NOT MODELED YET.
 QoS Profile Identifier: PENDING, NOT MODELED YET .
 BFD Profile Identifier: PENDING, NOT MODELED YET .
 Forwarding Profile Identifier: IETF-ACCESS-CONTOL-LIST
 Routing Profile Identifier: IETF-ROUITNG-POLICIES and IETF-BGP-POLICY.
In addition to the five profiles described previously, there is also VPN-POLICIES. The VPN-POLICIES
can contain specific rules to manipulate the prefixes and communities in a VPN-Node. This VPN-
POLICIES can also be created using the same models:
 Import-policy: IETF-ROUITNG-POLICIES and IETF-BGP-POLICY.
 Export-policy: IETF-ROUITNG-POLICIES and IETF-BGP-POLICY.
The relationship between models is the following:
<AUGMENT>
IETF-ACCESS-CONTROL-LIST IETF-ROUTING-POLICY IETF-BGP-POLICY

IETF-L3VPN-NTW
ACLs DEFINED SETs POLICY-DEFINITIONS

VALID PROFILES
ACL POLICY DEFINITION
Cloud Encryption Routing

FW Profile QoS Profile BFD Profile Name Name
Identifier Profile Profile
Id Id
Figure 28. Model relationship to create profiles
<AUGMENT>
IETF-L3VPN-NTW
IETF-ROUTING-POLICY IETF-BGP-POLICY
VPN-SERVICES
DEFINED SETs POLICY-DEFINITIONS
IE-PROFILE
POLICY DEFINITION
VPN-TARGETS
Name
VPN-POLICIES
Import-policy
Export-policy
Figure 29. Model relationship to create vpn-policies
1.7.2 Creation and Modification of the Forwarding filter (IETF-

ACCESS-CONTROL-LIST usage)
The set of parameters used for the creation of the ACCESS CONTOL LIST are the following:
 The access control list groups a set of entries.
 Each entry is an Access control node named (ACE).
 The ACEs are composed by matches and actions.
 Matches represents the conditions to be evaluated. Conditions include different source protocol
or layer properties.
 Forwarding or logging actions are accepted by the model.
Each parameter of the access-control-list is described as follows:

 Name [/acls/acl/name]: The name of the access-control-list. It must be a unique name for
the ACLs created under the same controller.
 ACE:Name [acls/acl/aces/ace/name]: The name of the access-control-node. It must be
a unique name for the ACE under the same ACL.
 ACE: Matches: Each ACE can have a unique possible condition to be matched. Source or
destination cannot be set in the ACE, those are explicit conditions of each specific layer. Logical
operations (AND, OR) between statements cannot be set.
o ACE:Matches:L2 [/acls/acl/aces/ace/matches]: Ethernet conditions to be
evaluated in the ACE. Includes the source and destination MAC address or MAC address
MASK and ethert-type.
o ACE:Matches:L3 [/acls/acl/aces/ace/matches]: IP conditions to be evaluated in
the ACE. Supports both IPv4 and IPv6 conditions.
o ACE:Matches:L4 [/acls/acl/aces/ace/matches]: TCP or UDP conditions to be
evaluated in the ACE.
 ACE:Actions: Two types of actions are permitted in the ACL: Forwarding and Logging. Both
operations can be set at as a result of and specific conditions.
o ACE:actions:forwarding [/acls/acl/aces/ace/actions/forwarding]: Accept
or reject the packet based on the condition previously evaluated.
o ACE:actions:forwarding [/acls/acl/aces/ace/actions/logging]: Specifies
the log action and destination for a matched packets. A syslog or other log can be
specified.
The set of parameters used for the creation of the ACL is summarized on the following table:
Parameter Yang type Default value Mandatory Provided Mode

by
name string No True OSS RW
type acl-type No False OSS RW
ace:name string No True OSS RW
ace:matches :L2 choice
destination-mac-address yang:mac-address No False OSS RW
source-mac-address yang:mac-address No False OSS RW
ethertype eth:ethertype No False OSS RW

source-ipv4-network inet:ipv4-prefix No False OSS RW
destination-ipv4-network inet:ipv4-prefix No False OSS RW

source-port container No False OSS RW
destination-port container No False OSS RW
ace:actions:forwarding identityref No True OSS RW
ace:actions:logging identityref log-none False OSS RW
Table 8. L3VPN Forwarding Filters Parameters
1.7.3 Creation and Modification of the Routing filter (IETF-ROUTING-

POLICY & IETF-BGP-POLICY usage)
The set of parameters used for the creation of the ROUTING POLICY are the following:
 The top level routing policy container, which can have two components: the defined sets and
policy-definitions.
 Defined Sets are groups of specific network attributes to use inside the policy-definitions. Each
set is a list of elements with a unique identifier (name). The types of defined sets available are:
o Prefix sets: List of ipv4/6 prefixes.
o Neighbor sets: Data definition for a list of IPv4 or IPv6 neighbors which can be matched
in a routing policy.
o Tag-sets: List of tag set definitions.
o BGP-defined-sets: This is an augmentation of the YANG IETF-BGP-POLICY module. It
covers additional sets, such as the communities and as-paths.
 Policy-definitions are composed by set of policy statements. Each statement evaluates a set of
conditions and takes a set of actions. Source criteria can be selected as a parameter of the policy
definition. Logical operations between the components of a set are allowed using the MATCH-
SET-OPTIONS.
o MATCH-SET-OPTIONS are optional parameters that governs the behavior of the match
operation. It allows to create logical operations to evaluate the items of a particular set.
 ANY: Is equivalent to create an OR operation of the terms in the set.
 ALL: Is equivalent to create an AND operation of the terms in the set.
 Conditions represents the rules to be evaluated. Conditions includes the possibility to evaluate
defined-sets, source protocols or bgp-specific parameters.
 Actions include decisions to take over the network, including complementary options such as: set
a tag, set a community or change the priority. Basic actions such as accept or reject traffic are
also included.
Each parameter of the access-control-list and its xpath is described as follows (each set of parameters
are grouped in their corresponding category):
1.7.3.1 Defined Sets [ietf-routing-policy/ietf-routing-policy/defined-sets]

This is a common container which have groups of specific network attributes (Prefix sets, Neighbor Sets,
Tag Sets and BGP Defined Sets.). These groups are created at controller level and can be re-used
between several match statements in different policy definitions. Once the routing policy is deployed on
the device, the sets must be translated to their corresponding prefix-list.
 name: [ietf-routing-policy/ietf-routing-policy/defined-sets/prefix-
sets/prefix-set*/name]
Unique name parameter to prefix sets.
 mode?: [ietf-routing-policy/ietf-routing-policy/defined-sets/prefix-sets/prefix-set*/mode?]
This parameter define the network address families mode (IPV4, IPV6 or Both) in the Prefix Set.
 prefixes [ietf-routing-policy/ietf-routing-policy/defined-
sets/prefix-sets/prefix-set*/prefixes]
Container of prefixes list with settings parameters (IP-Prefix and Mask-length range).
 ip-prefix: [ietf-routing-policy/ietf-routing-policy/defined-
sets/prefix-sets/prefix-set*/prefixes/prefix-list*/ip-prefix]
IP Address (IPV4/IPV6) which is used to match traffic on policies statement, those policies can be
applied in different types of routing protocols.
 masklength-lower: [ietf-routing-policy/ietf-routing-policy/defined-
sets/prefix-sets/prefix-set*/prefixes/prefix-list*/masklength-lower]
Define the lowest threshold of the mask.
 masklength-upper [ietf-routing-policy/ietf-routing-policy/defined-
sets/prefix-sets/prefix-set*/prefixes/prefix-list*/masklength-upper]
Define the upper threshold of the mask.
 masklength-range [ietf-routing-policy/ietf-routing-policy/defined-
sets/prefix-sets/prefix-set/prefixes/prefix/masklength-range]
Subnet mask parameter of the IP Address which determine the range of Network to match in
policy statement.
 neighbor-set* [ietf-routing-policy/ietf-routing-policy/defined-
sets/neighbor-sets/neighbor-set*]
List of IP Address (IPV4/IPV6) neighbors which matched in a policies statement that can be
applied to different purposes.
 name [ietf-routing-policy/ietf-routing-policy/defined-sets/neighbor-
sets/neighbor-set*/name]
Unique name to reference the list neighbor-set.
 address* [ietf-routing-policy/ietf-routing-policy/defined-
sets/neighbor-sets/neighbor-set*/address*]
IP Address (IPV4/IPV6) of neighbor which match with the policies statement.
 tag-set [ietf-routing-policy/ietf-routing-policy/defined-sets/tag-sets]
List of tag’s or flags to match and discriminate a type of traffic or a logical resource.
 Name [ietf-routing-policy/ietf-routing-policy/defined-sets/tag-
sets/tag-set*/name]
Unique name tag set, this is used to reference in policies statement.
 Tag-value* [ietf-routing-policy/ietf-routing-policy/defined-sets/tag-
sets/tag-set*/tag-value*]
Number or pattern value of the Tag created to discriminate specific traffic.
 bp-bgp-pol:bgp-defined-sets [ietf-routing-policy/ietf-routing-
policy/defined-sets/oc-bgp-pol:bgp-defined-sets]
Container in which has set definitions parameters related with BGP Protocol to reference in
policies statement.
 bp-bgp-pol:community-sets [ietf-routing-policy/ietf-routing-
policy/defined-sets/bp:bgp-defined-sets/oc-bgp-pol:community-sets]
Container in which there are community sets parameters defined for BGP Protocol.
 bp-bgp-pol:community-set [ietf-routing-policy/ietf-routing-
policy/defined-sets/bp:bgp-defined-sets/bp:community-sets/oc-bgp-
pol:community-sets]
List of communities sets defined to match with policies statement.
 bp:name [ietf-routing-policy/ietf-routing-policy/defined-
sets/bp:bgp-defined-sets/bp:community-sets/bp:community-set*/bp:name]
Unique name of community set defined, this is used to reference in policies statement.
 bp:member* [ietf-routing-policy/ietf-routing-policy/defined-
sets/bp:bgp-defined-sets/bp:community-sets/bp:community-set*/bp:member*]
Value of community set member composite by the Autonomous system (AS) number and unique
number entered 4-byte.
 bp:ext-community-sets [ietf-routing-policy/ietf-routing-
policy/defined-sets/bp:bgp-defined-sets/bp:ext-community-sets]
Container in which there are extended community sets parameters defined for BGP Protocol.
 bp:ext-community-set* [ietf-routing-policy/ietf-routing-policy/defined-sets/bp:bgp-
defined-sets/bp:ext-community-sets/bp:ext-community-set*]
List of extended communities sets defined to match with policies statement.
sets/bp:bgp-defined-sets/bp:ext-community-sets/bp:ext-community-
set*/bp:name]
Unique name of extended community set defined, this is used to reference in policies statement
 bp:member* [ietf-routing-policy/ietf-routing-policy/defined-sets/bp:bgp-defined-sets/bp:ext-
community-sets/bp:ext-community-set*/bp:member*]
Value of extended community set member composite by the Autonomous system (AS) number
and unique number entered 4-byte.
 bp:as-path-sets [ietf-routing-policy/ietf-routing-policy/defined-
sets/bp:bgp-defined-sets/bp:as-path-sets]
Container of list as-path-set’s defined with parameters settings name and member created.
 bp:as-path-set* [ietf-routing-policy/ietf-routing-policy/defined-
sets/bp:bgp-defined-sets/bp:as-path-sets/bp:as-path-set*]
List with the settings of as-path-sets that are matched with the policies statement and perform
any action in the BGP Protocols.
sets/bp:bgp-defined-sets/bp:as-path-sets/bp:as-path-set*/bp:name]
Name of the AS path set, this is used to reference the set-in match conditions
 bp: member* [ietf-routing-policy/ietf-routing-policy/defined-
sets/bp:bgp-defined-sets/bp:as-path-sets/bp:as-path-set*/bp:member*]
Autonomous system defined in the as-path-sets policies to match with de policies statement.
1.7.3.2 Policy Definition [ietf-routing-policy/ietf-routing-policy/policy-definitions/policy-

definition*]
List of the policy definitions. Relate parameters with conditions following the IF/THEN rules.
 name [ietf-routing-policy/ietf-routing-policy/policy-
definitions/policy-definition*/name]
Unique name of policies definition which are reference in the BGP policies import or export
depend of the actions that we have to perform.
 statements [ietf-routing-policy/ietf-routing-policy/policy-
definitions/policy-definition*/policy-statements]
Container for list of policy statement defined for any routing protocol.
 statement* [ietf-routing-policy/ietf-routing-policy/policy-
definitions/policy-definition*/policy-statements/statement*]
List of policies statement where defined any action of conditions and apply the defined-sets
created (Prefix-list or Communities) to match with parameters and perform any action.
 name [ietf-routing-policy/ietf-routing-policy/policy-
definitions/policy-definition*/policy-statements/statement*/name]
Name of the list of policies statement to reference and setting in routing protocols or other
settings.
1.7.3.3 Conditions [ietf-routing-policy/ietf-routing-policy/policy-definitions/policy-

definition*/policy-statements/statement*/conditions]
Condition statement for the current policy statement. Conditions defined to be evaluated. If it complies or
not, an action can be taken. The match can be done with any parameter related to routing protocols like a
BGP, ISIS, OSPF or match with another parameters of interface, prefix-set, neighbor or tag-set.
 Source-protocol [ietf-routing-policy/ietf-routing-policy/policy-
definitions/policy-definition*/policy-
statements/statement*/conditions/source-protocol?]
Condition to check the protocol, method used to install the route into the local routing table
 match-prefix-set [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-prefix-set]
Container with settings of prefix-set defined, matching and perform any action, this make an
example of conditions applied based on prefix-set.
 prefix-set? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-prefix-set/prefix-set?]
Name of prefix-set defined in the defined-sets section reference with parameters of IP and Mask
for apply any conditions and then any action.
 match-set-options? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-prefix-set/match-set-options?]
This is the selection of options and ways to match the parameters.(Any).
 match-neighbor-set [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-neighbor-set]
Container with settings of neighbor-set defined, matching and perform any action, this make an
example of conditions applied based on neighbor-set.
 neighbor-set? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-neighbor-set/neighbor-set?]
Name of neighbor-set defined in the defined-sets section reference with parameters of name of
neighbor for apply any conditions and then any action.
 match-tag-set [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-tag-set]
Container with settings of tag-set defined, matching and perform any action, this make an
example of conditions applied based on tag-set.
 tag-set? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-tag-set/tag-set?]
Name of tag-set defined in the defined-sets section reference with parameters of value of the tag
for apply any conditions and then any action.
 match-set-options? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/match-tag-set/match-set-options?]
 match-proto-route-type* [ietf-routing-policy/ietf-routing-
policy/policy-definitions/policy-definition*/policy-
statements/statement*/conditions/match-proto-route-type*]
 bp-bgp-conditions [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/]
Container related with only bgp conditions like a community-count, as-path-length, match-as-
path-set.
 bp:med-eq? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:med-eq?]
Condition to check if the received MED (Multi_Exit_Disc) value is equal to the specified value.
 bp:origin-eq? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:origin-eq?]
This parameter is to define the route origin that should be specify (IGP, EGP).
 bp:next-hop-in* [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:next-hop-in*]
This parameter can specific the next-hop address list to update route’s according to any event.
 bp:afi-safi-in* [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:afi-safi-in*]
List of address families which the NLRI (Network Layer Reachability Information) may be within.
 bp:local-pref-eq? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:local-pref-eq?]
Parameter to specify the local pref attribute like a condition for any action.
 bp:route-type? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:route-type?]
Condition to define is the route type in the route update is Internal or External learning.
 bp:community-count [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:community-count]
Value specified condition to compare the number of communities in the route updates.
 bp:as-path-length [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:as-path-length]
Value specified condition to compare the length of AS Path in the route updates and perform any
action.
 bp:match-community-set [ietf-routing-policy/ietf-routing-
statements/statement*/conditions/bp:bgp-conditions/bp:match-community-
set]
Name specified of match communities to reference in routing protocols configuration.
 bp:community-set? [ietf-routing-policy/ietf-routing-policy/policy-
set/bp:community-set?]
 bp:match-set-options? [ietf-routing-policy/ietf-routing-
set/bp:match-set-options?]
 bp:match-ext-community-set [ietf-routing-policy/ietf-routing-
statements/statement*/conditions/bp:bgp-conditions/bp:match-ext-
community-set]
 bp:ext-community-set? [ietf-routing-policy/ietf-routing-
community-set/bp:ext-community-set?]
community-set/bp:match-set-options?]
 bp:match-as-path-set [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:match-as-path-set]
Value and comparison operations for conditions based on the length of the AS path in the route
update
 bp:as-path-set? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/conditions/bp:bgp-conditions/bp:match-as-path-
set/bp:as-path-set?]
Name of as-path-set created in definition-set section to apply conditions and then any action.
statements/statement*/conditions/bp:bgp-conditions/bp:match-as-path-
set/bp:match-set-options?]
1.7.3.4 Actions [ietf-routing-policy/ietf-routing-policy/policy-definitions/policy-

definition*/policy-statements/statement*/actions]
Set of actions to be taken when a condition is triggered.
 policy-result? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/policy-result?]
Depends of the conditions statement defined, the actions would be accept or reject routes.
 set-metric [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-metric]
 metric-modification? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-metric/metric-codification?]
 metric? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-metric/metric?]
 set-metric-type [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-metric-type]
 metric-type? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-metric-type/metric-type?]
 set-import-level [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-import-level]
 import-level? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-import-level/import-level?]
 set-preference? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-preference?]
 set-tag? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-tag?]
 set-application-tag? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/set-application-tag?]
 bp:bgp-actions [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions]
Container of actions related with BGP protocols, actions (As-path-prepend, set-community, set-
ext-community).
 bp:set-route-origin? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-route-origin?]
This is a action parameter is to define the route origin that should be specify (IGP, EGP).
 bp:set-local-pref? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-local-pref?]
This is an action parameter to set a local pref attribute on the route update.
 bp:set-next-hop? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-next-hop?]
This is an action parameter setting to the next-hop address list to update route’s according to any
event.
 bp:set-med? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-med?]
Set action to define a preferred path. The med metric attribute in the route update.
 bp:set-as-path-prepend [ietf-routing-policy/ietf-routing-
statements/statement*/actions/bp:bgp-actions/bp:set-as-path-prepend]
Container with set action to define AS number prepend with parameters of number of times and
AS-path.
 bp:repeat-n? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-as-path-
prepend/bp:repeat-n?]
Number of times to prepend the value specified in the asn leaf to the AS path.
 bp:set-community [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-community]
Set action of community attributes defined, depends of BGP conditions established with different
options to modify the communities.
 bp:method? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-
community/bp:method?]
Set action of methods used to define the extended communities should be (Inline or Reference).
 bp:options? [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:options?]
Set actions to take with the communities attributes with the specified values, the options are (Add,
Remove or Replace).
 bp:inline [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-community/bp:inline]
Container with a list of communities values for action inline.
 bp:communities* [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:inline/bp:communities*]
Set action of change of community values to update inline.
 bp:reference [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:reference]
Provide a reference to a defined community set for the set-community action.
 bp:community-set-ref? [ietf-routing-policy/ietf-routing-
community/bp:reference/bp:community-set-ref?]
Set action to references a defined community set by name.
 bp:set-ext-community [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-ext-community]
Set action of extended community attributes defined, depends of BGP conditions established with
different options to modify the communities.
 bp:method? [ietf-routing-policy/ietf-routing-policy/policy-
statements/statement*/actions/bp:bgp-actions/bp:set-ext-
community/bp:method?]
Set action of methods used to define the extended communities should be (Inline or Reference).
 bp:options? [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:options?]
Set actions to take with the extended communities attributes with the specified values, the
options are (Add, Remove or Replace).
 bp:inline [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:inline]
Container with a list of extended community values for action inline.
 bp:communities* [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:inline/bp:communities*]
Set action of change of extended community values to update inline.
 bp:reference [ietf-routing-policy/ietf-routing-policy/policy-
community/bp:reference]
Set action to references a defined extended community set by name.
The set of parameters used for the creation of the ROUTING-POLICY is summarized on the following
table, where parameters in blue are part of the basic definition of the IETF-Routing-Policy module while
the green ones are part of the IETF-BGP-Policy (prefix: bp) definition.
Parameter Yang type Default value Mandatory Provided b Mode

Defined Sets container
prefix-sets list
mode enumerattion No False OSS RW
ip-prefix inet:ip-prefix No True OSS RW
masklength-lower uint8 No True OSS RW
masklength-upper uint8 No True OSS RW
neighbor-sets list
neighbor-sets list
bgp-defined-sets container
bp:community-sets list
bp:name string No True OSS RW
bp:member union No False OSS RW
bp: ext-community-sets list
bp:member union No False OSS RW
bp:as-path-sets list
bp:member string No False OSS RW
Policy-Definitions container
Policy-Definition list
Policy-Statements container
Policy-Statement list
Conditions container
source-protocol identityref No False OSS RW
prefix-set leafref No False OSS RW
neighbor-set leafref No False OSS RW
tag-set leafref No False OSS RW
match-set-options match-set-options-type No True OSS RW
bp:bgp-conditions container
bp:med-eq uint32 No False OSS RW
bp:origin-eq bt:bgp-origin-attr-type No False OSS RW
bp:next-hop-in inet:ip-address-no-zone No False OSS RW
bp:afi-safi-in identityref No False OSS RW
bp:local-pref-eq uint32 No False OSS RW
bp:route-type enumeration No False OSS RW
bp: match-community-set
bp:community-set leafref No False OSS RW
bp: match-ext-community-set
bp:ext-community-set leafref No False OSS RW
bp: match-as-path-set
bp:as-path-set leafref No False OSS RW
Actions container
policy-result? policy-result-type No False OSS RW
set-metric
metric-modification? metric-modification-type No False OSS RW
metric? uint32 No False OSS RW
set-metric-type No False OSS RW
metric-type? identityref No False OSS RW
set-import-level No False OSS RW
import-level? identityref No False OSS RW
set-preference? uint16 No False OSS RW
set-tag? tag-type No False OSS RW
set-application-tag? tag-type No False OSS RW
bp:bgp-actions
bp:set-route-origin? bt:bgp-origin-attr-type No False OSS RW
bp:set-local-pref? uint32 No False OSS RW
bp:set-next-hop? bgp-next-hop-type No False OSS RW
bp:set-med? bgp-set-med-type No False OSS RW
bp:set-as-path-prepend
bp:repeat-n? uint8 No False OSS RW
bp:set-community
bp:method? enumeration No False OSS RW
bp:options? bgp-set-community-option-
No False OSS RW
type
bp:inline
bp:communities* union No False OSS RW
bp:reference
bp:community-set-ref? /rpol:routing-policy/defined-
sets/bp:bgp-defined-
No False OSS RW
sets/community-
sets/community-set/name
bp:set-ext-community
bp:method? enumeration No False OSS RW
bp:options? bgp-set-community-option-
No False OSS RW
type
bp:inline
bp:communities* union No False OSS RW
bp:reference
bp:ext-community-set-ref? /rpol:routing-policy/defined-
sets/bp:bgp-defined-
sets/ext-community- No False OSS RW
sets/ext-community-
set/name
Table 9. L3VPN Routing Policy Parameters
1.7.4 RESTCONF: Use Case available interfaces

The following table contain the available API calls for the creation, modification and deletion of the ACL
and Routing Policies:
Type Path Description
get /restconf/data/ietf-routing-policy/ Obtain routing policy Configuration.
get /restconf/data/ietf-routing-policy/defined-sets/ Obtain defined-sets Configuration.
get /restconf/data/ietf-routing-policy/defined-sets/tag-sets/ Obtain defined-sets Configuration.
get /restconf/data/ietf-routing-policy/defined-sets/prefix-sets/ Obtain defined-sets Configuration.
get /restconf/data/ietf-routing-policy/defined-sets/neighbor-sets/ Obtain defined-sets Configuration.
post /restconf/data/ietf-routing-policy/defined-sets/tag-sets/tag-set/ Creation defined-set parameters.

/restconf/data/ietf-routing-policy/defined-sets/prefix-sets/prefix- Creation defined-set parameters.
post
set/
/restconf/data/ietf-routing-policy/defined-sets/neighbor- Creation defined-set parameters.
post
sets/neighbor-set/
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Obtain bgp-defined-sets Configuration.
get
sets/as-path-sets/
/restconf/data/ietf-routing-policy/policy-definitions/policy- Obtain policy-definitions Configuration.
get
definition={name}/
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Obtain communities in bgp-defined-sets
get
sets/community-sets/ Configuration.
/restconf/data/ietf-routing-policy/defined-sets/neighbor- Obtain neighbor-sets in bgp-defined-sets
get
sets/neighbor-set={name}/ Configuration.
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Creation ext-community-sets parameters.
post
sets/ext-community-sets/
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Delete ext-community-sets parameters.
delete
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Obtain ext-community-sets parameters.
get
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Creation as-path-sets parameters in bgp-
post
sets/as-path-sets/as-path-set/ defined-sets.
/restconf/data/ietf-routing-policy/policy-definitions/policy- Obtain statements policy-definitions
get
definition={name}/statements/ parameters.
/restconf/data/ietf-routing-policy/defined-sets/prefix-sets/prefix- Creation prefix-sets parameters in defined-
post
set={name},{mode}/prefixes/ sets.
/restconf/data/ietf-routing-policy/defined-sets/prefix-sets/prefix- Delete prefix-sets parameters in defined-
delete
set={name},{mode}/prefixes/ sets.
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Obtain as-path-sets parameters Obtain as-
get
sets/as-path-sets/as-path-set={name}/ path-sets parameters.
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Obtain community-sets parameters in bgp-
get
sets/community-sets/community-set={name}/ defined-sets.
/restconf/data/ietf-routing-policy/defined-sets/bgp-defined- Creation ext-community-sets parameters in
post
sets/ext-community-sets/ext-community-set/ bgp-defined-sets.
/restconf/data/ietf-routing-policy/defined-sets/prefix-sets/prefix- Creation prefix-sets parameters in defined-
post
set={name},{mode}/prefixes/prefix-list/ sets.
/restconf/data/ietf-routing-policy/policy-definitions/policy- Obtain statements parameters in policy-
get
definition={name}/statements/statement={statement-name}/ definitions.
/restconf/data/ietf-routing-policy/policy-definitions/policy- Creation set-metric-type parameter in
post definition={name}/statements/statement={statement- statements.
name}/actions/set-metric-type/
/restconf/data/ietf-routing-policy/policy-definitions/policy- Delete prefix-sets parameters in defined-
delete definition={name}/statements/statement={statement- sets.
name}/actions/set-metric-type/
/restconf/data/ietf-routing-policy/defined-sets/prefix-sets/prefix- Delete prefix-sets parameters (IP, Mask-
delete set={name},{mode}/prefixes/prefix-list={ip-prefix},{mask-length- length) in defined-sets.
lower},{mask-length-upper}/
/restconf/data/ietf-routing-policy/policy-definitions/policy- Delete reference parameter in set-
delete definition={name}/statements/statement={statement- community.
name}/actions/bgp-actions/set-community/reference/
1.8 L2VPN Interface Params Modification

Number B.9
Name L2VPN Profiles Creation/Modification
When a L2VPN a set of QoS, Encryption, Routing and Security profiles can
Brief description be added to the service. The Profile creation and modification Is part of the
following use case.
L2VPN parameters modification is done using the same models and parameters described in the
previous chapter.
1.9 QOS
1.9.1 CONFIG CLASS-MAP
功能描述 Create or Modify CLASSMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-classmap-rpc:create
/restconf/operations/{meUid}/singlenbi-classmap-rpc:modify
参数说明：
Parameter Description Value
meUid ME uuid or ID string
BODY CLASSMAP instance List List<CLASSMAP>
CLASSMAP instance :
classMapName Classmap name; Constraint：1-31 charcaters string
matchMode Match mode:”1”：match-all “2”：match-any string
matchConfigList CLASSMAP match configuration List List<MatchConfig>
MatchConfig instance :
matchType 1:dscp extended precedence level:”dscp-ex”, string
2:8021p outer:”out-8021p”
matchValue 1:dscp-ex values: string
“0”:default,”10”:af11,”12”:af12,”14”:af13,”18”:af21,”
20”:af22,”22”:af23,”26”:af31,”28”:af32,”30”:af33,”34
”:af41,”36”:af42,”28”:af43,”46”:af,”8”:cs1,”16”:cs2,”
24”:cs3,”32”:cs4,”40”:cs5,”48”:cs6,”56”:cs7
2:8021p outer values:valid integer value range 0-7
to string;such as,”0”,”1”,”2”,”3”,”4”,”5”,”6”,”7”
1.9.2 QUERY CLASS-MAP

功能描述 query CLASSMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-queryclassmap-rpc:query
参数说明：
1.9.3 DELETE CLASS-MAP
功能描述 delete CLASSMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-removeclassmap-rpc:delete
参数说明：
BODY CLASSMAP instance List List<CLASSMAP>
CLASSMAP instance :
classMapName CLASSMAP name; Constraint：1-31 charcaters string
1.9.4 CONFIG POLICY-MAP

功能描述 Create or Modify POLICYMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-policymap-rpc:create
/restconf/operations/{meUid}/singlenbi-policymap-rpc:modify
参数说明：
BODY POLICYMAP instance List List<POLICYMAP>
POLICYMAP instance :
policyMap Policymap name; Constraint:1-31 charcaters string
Name
policyMapT Policymap Type：“1”;default value string
ype
policyMap PolicyMapClassConfig instance List List<PolicyMapClass
ClassConfi Config>
gList
PolicyMapClassConfig instance :
policyMapId Policymap Id,Which is the same to string
policyMapName in policymap instance
classMapId Classmap id,Which is binded with CLASSMAP string
instance's classMapName in classmap in
classmap instance
dscpWsetval Dscp tagged value:valid integer value range 0-63 string
to string
dscpBinherit Dscp tagged type:“0”: not Inherited from,”1”: string
Inherited from
dscpUcinheritfro Dscp Inherited from: ”1”:precedence, string
m "2”:mplsExp, :”3”dot1p, “4”:dscp
mplsWsetval Mpls tagged value:valid integer value range 0-7 to string
string,such as “0”,’1”
mplsBinherit Mpls tagged type “0”: not Inherited from,”1”: string
Inherited from
mplsUcinheritfro Mpls Inherited from:”1”:precedence, string
m "2”:mplsExp, :”3”dot1p, “4”:dscp
mplsLabeltype Mpls heavy label type;:”0”:inner,”1”:topmost，“2”： string
imposition
cir Cir value:valid integer value range 8-400000000 to string
string,such as,”1000”
includePolicy policymap nested;1-31 charcaters,which is binded string
with policymap name
1.9.5 QUERY POLICY-MAP

功能描述 query POLICYMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-querypolicymap-rpc:query
参数说明：
1.9.6 DELETE POLICY-MAP

功能描述 delete POLICYMAP instance
URL路径 /restconf/operations/{meUid}/singlenbi-removepolicymap-rpc:delete
参数说明：
BODY POLICYMAP instance List List<POLICYMAP>
POLICYMAP instance :
policyMapNam POLICYMAP name; Constraint：1-31 charcaters string
e
1.9.7 CONFIG SERVICE SERVICEPOLICY

功能描述 Create or Modify SERVICEPOLICY instance
URL路径 /restconf/operations/{meUid}/singlenbi-servicepolicy-rpc:create
/restconf/operations/{meUid}/singlenbi-servicepolicy-rpc:modify
参数说明：
BODY SERVICEPOLICY instance List List<SERVICEPOLICY>
SERVICEPOLICY instance :
interfaceNa interface format;interface which is binded with string
me policymap in UME
direction directions:“input” or “output” string
policyNam POLICYMAP name is binded with PolicyMap string
e instance's policyMapName;1-31 charcaters
1.9.8 QUERY SERVICE SERVICEPOLICY

功能描述 query SERVICEPOLICY instance
URL路径 /restconf/operations/{meUid}/singlenbi-queryservicepolicy-rpc:query
参数说明：
me policymap in UME ,note:may be null to query
1.9.9 DELETE SERVICE SERVICEPOLICY

功能描述 delete SERVICEPOLICY instance
URL路径 /restconf/operations/{meUid}/singlenbi-removeservicepolicy-rpc:delete
参数说明：
me policymap in UME
direction directions:“input” or “output” string
policyNam POLICYMAP name is binded with PolicyMap string
e instance's policyMapName;1-31 charcaters
1.10 SQA
1.10.1 CONFIG UDP-JITTER SQA
Function: Create or Modify UDP-JITTER SQA instances
URL: POST /restconf/data/ietf-sqa/udpjitter:create
POST /restconf/data/ietf-sqa/udpjitter:modify
Parameters：
BODY UDP-JITTER SQA instance List List<SqaUDPJitterConfig>
UDP-JITTER SQA instance :

meUuid ME uuid string
serialNum Instance serial number [1-4000] integer
destinationIp Destination IP address string
destinationPort Destination port [1025-65535] integer
repeat Send packages repeat [1-1000] integer
interval Send packages interval(ms) [50-2000] integer
size Package size(byte) [50-1500] integer
tos ToS [0-255] integer
vrfName VRF name string
Response :
errorInfo Description when error string
List of created/modified successfully sqaIDs. list<string>
sqaIDList SqaID format: ‘meUuid’:’serialNum’.
1.10.2 QUERY UDP-JITTER SQA

Function: Query UDP-JITTER SQA instances
URL: GET /restconf/data/ietf-sqa/udpjitter
Parameters：
meUid ME uuid string
Response :
sqaUdpJitterConf List of queried UDP-JITTER SQA instances list<SqaUDPJitterCo
igList nfig>
1.10.3 DELETE UDP-JITTER SQA

Function: Delete UDP-JITTER SQA instances
URL: DELETE /restconf/data/ietf-sqa/udpjitter
Parameters：
BODY UDP-JITTER SQA instance List List<SqaUDPJitterConfig>
Response :
List of deleted successfully sqaIDs. SqaID format: list<string>
sqaIDList ‘meUuid’:’serialNum’.
1.11 INTEFACE
1.11.1 Config_Interface
Function: Modify Physical ports
URL: POST /restconf/operation/ltp:modifyPtps
Parameters：
BODY ptp List List<ptp>
neName ME uuid
ptp instance :
id Interface id(not uuid) string
description Destination ptp string
l2Mtu Value of l2Mtu string
trafficStat “0”means stop and “1” means start string
rateSelect “101” means auto-negotiation, string
“202” means 10mbs half duplex,
“203” means 10mbs full duplex,
“503” means 10GE full duplex,
“1603” means auto(1000m),
“1703” means module rate self matching.
adminStatus “0”means stop and “1” means start integer
Response :
200 if successful.
1.11.2 Config_Sub_Interface
Function: Modify Sub interface
URL: POST /restconf/operation/ltp:modifyl3Ltps
Parameters：
BODY l3LtpForMod List List<l3LtpForMod >
neName ME uuid
l3LtpForMod instance :
id Sub Interface id(not uuid) string
description Destination Sub Interface string
l2Mtu Value of l2Mtu string
ipv4Mtu Value of ipv4Mtu string
ipv6Mtu Value of ipv6Mtu string
adminStatus “0”means stop and “1” means start integer
Response :
200 if successful.
1.11.3 Delete_Sub_Interface
Function: Delete Sub interface
URL: POST /restconf/operation/ltp:deletel3Ltps
Parameters：
BODY Sub Interface id(not uuid) List<l3LtpForDel>
neName ME uuid
l3LtpForDel instance :
id Sub interface uuid for delete string
Response :
200 if successful.
1.12 Authentication
After the authentication function is enabled, all the interfaces whose URL with restconf/ must obtain
token first, and then accessToken: “xxxxx” is needed to fill in the message header to invoke the
anthentication interface normally.
A new user is needed to create on the UME and the admin user cannot be used directly.
For a new user, the account rule must be API access rule.
1.12.1 Obtain Token
Function description: obtain the token information according to the user-name and password. All
interfaces are needed to fill token in the message header.
URL: /restconf/operation/ietf-security:oauth_token
Input parameter description:
user-name Login user-name string
value Login password string
Return parameter description:
expires Token validity is 1800s. string
accessToken Access Token string
1.12.2 Exit Token

Function description: invoke this interface and exit the authentification login, then fill token in the message
header.
URL: /restconf/operation/ietf-security:oauth_token
Header
accessToken 1628713726_8e1d93b4133f472b98a7cff28f2b608e
Body
Null
NULL .
1.12.3 Renewal Token

Function description: Renewal token in the message header before the obtained token expires.
URL: /restconf/operation/ietf-security:oauth_handshake
Header
accessToken 1628713726_8e1d93b4133f472b98a7cff28f2b608e
Body
Null

NULL .
2 Glossary
ABNO Application-based network operations
ACL Access control list
API Application programming interface
ASBR Autonomous System Border Route
BGP-LS Border Gateway Protocol Link-Stat
BGP-LU BGP Labeled Unicast
BHM Backhaul Module
BRAS Broadband remote access server
BSS Business Support Systems
CDN Content Delivery Network
CE Customer Edge
CEM Circuit Emulation
CGNAT Carrier-grade NAT
CIR Committed information rate
CRUD Create, Read, Update and Delete
DWDM Dense Wavelength Division Multiplexing
GMPLS General Multi-Protocol Label Switching
GUI Graphical user interface
HTTP Hypertext Transfer Protocol
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
ISIS Intermediate System to intermediate System
L2SM L2VPN Service Model
L3NM L3VPN Network Model
LAG Link aggregation group
LDP Label Distribution Protocol
LLDP Link Layer Discovery Protocol
LSP Label Switch Path
LSR Label Switching Router
MP-BGP Multiprotocol Extensions for BGP
MPLS Multiprotocol Label Switching
NBI Northbound interface
NMDA Network Management Datastore Architecture
ONF Open Networking Foundation
OSPF Open Shortest Path First
OSS Operation Support Systems
P2M Point-to-Multipoint
P2P Point-to-point
PCE Path Computation Element
PCEP Path Computation Element Communication Protocol
PE Provider Edge
PIR Peak Information Rate
PKI Public Key Infrastructure
PW Pseudowire
QoS Quality of service
RD Route Distinguisher
RIP Routing Information Protocol
RPC Remote Procedure Call
RSVP Resource Reservation Protocol
RT Route Target
SBI South Bound Interface
SDN Software Defined Network
SDP Session Description Protocol
SecGW Security Gateway
SLA Service Level Agreement
SSE Server Sent Events
STP Spanning Tree Protocol
TAPI Transport API
TE Traffic engineering
TTL Time to live
UNI User-Network Interface
URI Uniform resource identifier
VCI Virtual Circuit Identifier
VLAN Virtual local area network
VPI Virtual Path Identifier
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
3 References
[1]. https://github.com/openconfig/public
[2]. https://datatracker.ietf.org/doc/rfc8466/
[3]. Layer 3 VPN Network Model draft-aguado-opsawg-l3sm-l3nm-01, https://tools.ietf.org/html/draft-
aguado-opsawg-l3sm-l3nm-01
[4]. https://github.com/YangModels/yang/tree/master/standard/ietf
[RFC 8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI
10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC 6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network
Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-
editor.org/info/rfc6241>.
[RFC 7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI
10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC 7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI
10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.
[OpenAPI] OpenAPI Specification Version 3.0.2, <https://swagger.io/specification/>
[RFC 6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455,
December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[W3C.REC-eventsource-20150203] Hickson, I., "Server-Sent Events", World Wide Web
Consortium Recommendation REC-eventsource-20150203, February 2015Considerations
<http://www.w3.org/TR/2015/REC-eventsource-20150203>.

ZENIC ONE Restful Service Provision Interface Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ZENIC ONE Restful Service Provision Interface Specification

Uploaded by

Copyright:

Available Formats

ZENIC ONE Restful Service Provision Interface Specification

ZENIC ONE Restful

1.1 User Case

BASIC CREATION ADVANCE CREATION

1.1.2 Use Case Operations

1.2 L2VPN Service Provisioning

1.2.1 Current L2VPNs Creation

The same kind of validations must be done in the aggregation layer.

1.2.2 Workflow for L2VPN Service Provisioning from OSS

 Add endpoints to the L2 VPN Service

1.2.2.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

1.2.2.3 Create VPN (VPN.L2.Add)

The set of parameters and the responsibilities are the following:

1.2.2.4 Create Site Network Access (VPN.L2.Access.Add)

1 ACCESS VPN ACCESS 2

Parameter Responsible Description

1.2.3 Detailed modeling of L2VPN Use Cases

1.2.3.2 L2VPN for Enterprise (1) [L2VPN/Dot1Q/None/Overwriting]

HL4 10.33.4.68/30 HL3

HL4 VAL_SIB 1/1/2

Figure 10. Service Diagram

1.2.3.2.2.1 Create Site (VPN.L2.Site.Add)

1.2.3.2.2.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

1.2.3.2.2.3 Create VPN (VPN.L2.Add)

1.2.3.2.2.4 Create Site Network Access (VPN.L2.Access.Add)

1.2.3.3 L2VPN for Enterprise (2) [L2VPN/MeshSDP/None/None]

1.2.3.3.1.1 Create Site (VPN.L2.Site.Add)

1.2.3.3.1.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

1.2.3.3.1.3 Create VPN (VPN.L2.Add)

1.2.3.3.1.4 Create Site Network Access (VPN.L2.Access.Add)

HL4 VAL_SIB 1/1/2

Figure 8. Service Diagram

1.2.3.4.2 Configuration example: SDTN NBI

1.2.3.4.2.1 Create Site (VPN.L2.Site.Add)

1.2.3.4.2.2 Create/add bearers to an existing Site (VPN.L2.Bearer.Add)

1.2.3.4.2.3 Create VPN (VPN.L2.Add)

VPN ID OSS 100167463

CE VLAN preservation OSS -

CE VLAN COS preservation OSS -

1.2.3.4.2.4 Create Site Network Access (VPN.L2.Access.Add)

Service/QoS [standard profile] OSS TELECOM

1.3 L3VPN Service Provisioning

1.3.1 L3VPN Structure and Classification

1.3.2 List of parameters to configure in the devices for L3VPNs

The same kind of validations must be done in the aggregation layer.

1.3.3 Workflow for L3VPN Creation

1.3.3.1 Create Site (VPN.L3.Site.Add)

Figure 12. VPN.L3.Site.Add

1.3.3.2 Create/add bearers to an existing Site (VPN.L3.Bearer.Add)

1.3.3.3 Create VPN (VPN.L3.Add)

Figure 13. VPN.L3.Add

The set of parameters and the responsibilities are the following:

ACCESS VPN-node VPN-node ACCESS

Figure 14. VPN.L3.Access.Add

Parameter Responsible Type Description

ACCESS VPN-node VPN-node ACCESS

Figure 15. VPN.L3.Access.Attach

1.3.4 L3VPN for 3G/4G Fusion Services

1.3.4.2 Use case Parameters: L3VPN for 3G/4G Fusion Services

Figure 16. Service topology diagram

Figure 17. Service provision options

1. Is the HL5 already deployed in the network?

1.3.4.4.2 Create Bearer (VPN.L3.Bearer.Add)