SIST ES 201 915-10 V1.4.1:2005

• Abstract:

  Maintenance update of ES 201 915-10 v.1.3.1. Updated document will also be known as Parlay 3.3. Only those parts requiring modification will be updated ( most parts require maintenance fixes )

• Status: Published
• Publication Date: 31-Dec-2004
• ICS: 33.040.01 - Telecommunication systems in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Jan-2005
• Due Date: 01-Jan-2005
• Completion Date: 01-Jan-2005
• Ref Project: ETSI ES 201 915-10 V1.4.1 (2003-07) - Open Service Access (OSA); Application Programming Interface (API); Part 10: Connectivity Manager SCF (Parlay 3)

SIST ES 201 915-10 V1.4.1:2005 is the Slovene version of ETSI ES 201 915-10 V1.4.1 for the Open Service Access (OSA) Application Programming Interface (API). It specifies the Connectivity Manager Service Capability Feature (SCF) used by an enterprise operator to discover provider QoS templates, inspect enterprise network information, and create or manage Virtual Provisioned Pipes (VPrP) in the provider network.

What does SIST ES 201 915-10 V1.4.1:2005 specify?

SIST ES 201 915-10 V1.4.1:2005 specifies the OSA API part for Connectivity Manager SCF. The document defines how an enterprise operator works with provider network QoS services, including template selection, VPrP creation, and retrieval of existing VPrN and site information.

The scope is operational and interface-focused. It covers the interfaces, sequence diagrams, class diagrams, method details, state-related information, data definitions, and OMG IDL representation needed to use the service. The provider network applies the Provisioned QoS service, while the QoS mechanisms used inside the enterprise network itself are outside the service scope.

The document is organized as follows:

• Clause 4 introduces the Connectivity Manager SCF.
• Clause 5 gives sequence diagrams for common operator flows.
• Clause 6 presents the class diagrams.
• Clause 7 defines the service interface specification format and callback model.
• Clause 8 describes the interface classes and their methods.
• Clause 10 defines the data types used by the service.
• Clause 11 lists the exception classes.

Annex	What it covers
Annex A	Normative OMG IDL description of Connectivity Manager SCF
Annex B	Informative record of changes

What are the key requirements of SIST ES 201 915-10 V1.4.1:2005?

SIST ES 201 915-10 V1.4.1:2005 requires the client to use the Connectivity Manager as the entry point after authentication and authorization by the Framework service. In practice, this means the operator first gets references to the QoS menu and the enterprise network, and then uses those references to browse or provision services.

Service access and read-only browsing

Clause 8.1 defines IpConnectivityManager, which returns the QoS menu and the enterprise network interface. Clause 8.2 defines IpEnterpriseNetwork, which allows the operator to retrieve site IDs, a VPrN reference, and a site reference, but not to modify stored enterprise network data. Clause 8.3 extends this to IpEnterpriseNetworkSite, which provides site location, description, SAP list, and IP subnet information.

In practice, this separates browsing from provisioning. An operator can inspect the current enterprise VPN-related inventory, but changes to those records remain under provider control.

QoS templates and operator-controlled parameters

Clause 8.4 defines IpQoSMenu, which lists the QoS templates offered by the provider and creates a temporary template reference for editing. Clause 8.5 defines IpQoSTemplate, where the operator can read template defaults and fill in the values allowed by the template tags.

The template tags matter operationally:

• Provider specified values stay fixed.
• Operator specified values may be changed.
• Unspecified values are not used for that template.

This is what turns a provider offer into a usable VPrP request. The operator can only change the fields the provider has exposed for that template.

Provisioned QoS, pipe QoS, and validity

Clause 8.5 separates TpProvisionedQoSInfo, TpPipeQoSInfo, and TpValidityInfo. TpProvisionedQoSInfo covers delay, loss, jitter, and excess load action. TpPipeQoSInfo covers endpoint selection, traffic direction, and load parameters. TpValidityInfo defines when the VPrP is valid, using date/time, period, time-of-day, day-of-week, and month components.

In practice, the operator is not just naming a service - the operator is choosing what traffic it applies to, how excess traffic is treated, and when the service is active. Clause 10 explains the underlying tagged data types, so the same structure can be used whether the provider or operator supplies a value.

VPrP lifecycle and status

Clause 8.6 defines IpVPrN, which creates and deletes VPrPs and lists existing VPrPs. Clause 8.7 defines IpVPrP, which reports the VPrP ID, SLA ID, status, QoS information, validity, and DS Codepoint.

The status values are ACTIVE, PENDING, and DISALLOWED. That status is important in practice because a request can be submitted before provider approval, and the operator needs to know whether packets may already be carried, are still awaiting decision, or have been denied.

Packet marking and network behavior

The service uses TpDsCodepoint to identify traffic in the provider network. The document states that packets entering the provider network must be marked with the appropriate DS Codepoint so they can be directed to the correct VPrP.

This is the operational link between application provisioning and packet handling. Without the marking, the provider network cannot match the packet to the provisioned pipe.

Interfaces, methods, and errors

Clause 7 explains the interface style: get methods return handles or values, set methods update template fields, and asynchronous requests use Req, Res, and Err forms where applicable. Clause 11 lists the exceptions used for invalid IDs, illegal values, unknown references, and missing data.

In practice, implementers need to handle invalid site IDs, unknown templates, illegal references, and inconsistent QoS requests in a controlled way.

What terms does SIST ES 201 915-10 V1.4.1:2005 define?

SIST ES 201 915-10 V1.4.1:2005 defines the key service terms used to describe enterprise-network connectivity and QoS control.

• Open Service Access (OSA) - an architecture that lets application developers use network functionality through standardized APIs.
• Service Capability Feature (SCF) - a service part of the OSA API, here focused on connectivity management.
• Virtual Provisioned Pipe (VPrP) - a provider service for a specific enterprise traffic flow, with pre-specified QoS.
• Virtual Provisioned Network (VPrN) - the collection of VPrPs delivered to one enterprise network.
• Service Access Point (SAP) - the enterprise network point that connects to the provider network.
• Quality of Service (QoS) - the service levels delivered by the provider network, such as delay and loss behavior.
• DiffServ Codepoint (DS Codepoint) - the marking used to identify which VPrP should carry a packet.
• Service Level Agreement (SLA) - the agreement context used to validate or constrain a VPrP request.

Who uses SIST ES 201 915-10 V1.4.1:2005?

SIST ES 201 915-10 V1.4.1:2005 is used by enterprise operators, provider-network administrators, and application developers building OSA client software. It is also relevant to architects and integrators who need to expose or consume connectivity-management functions through telecom APIs.

In practice, users apply it to browse VPN sites and SAPs, review provider QoS templates, create new VPrPs, monitor VPrP status, and check how requested service parameters relate to an SLA. Buyers or technical reviewers use it to confirm that a system supports standardized provisioning of enterprise connectivity services rather than proprietary control logic.

What changed in SIST ES 201 915-10 V1.4.1:2005 from the previous edition?

SIST ES 201 915-10 V1.4.1:2005 is a maintenance update of ES 201 915-10 v1.3.1 and the updated document is also known as Parlay 3.3. The update applies only to the parts that required modification.

The change log states one explicit data-definition update:

• TpNameDescrpTagMonth - the order of elements in the IDL was changed to match the document.

Which standards are used with SIST ES 201 915-10 V1.4.1:2005?

SIST ES 201 915-10 V1.4.1:2005 uses the following companion parts and references:

• ETSI ES 201 915-1, Part 1: Overview (Parlay 3) - supplies the referenced provisions for clause 2 and provides the shared terms and abbreviations used by this part.
• ETSI ES 201 915-2 - provides the common data definitions referenced by this part when a type is not defined locally.

What does the SIST ES 201 915-10 V1.4.1:2005 document contain?

SIST ES 201 915-10 V1.4.1:2005 contains three operator sequence diagrams, class diagrams for the Connectivity Manager interfaces, detailed method descriptions, data type definitions, and an exception catalogue. It also includes a normative OMG IDL file for the interface description in Annex A.

The technical body shows how to browse enterprise sites and SAPs, how to inspect QoS templates, and how to create and manage VPrPs. The data definitions describe the tagged QoS structures, endpoint and load parameters, validity windows, and status values used by the methods.

Annex B provides a structured change record for interfaces, methods, data definitions, service properties, exceptions, and other items. That makes the document useful both for implementation work and for checking what changed between releases.

SLOVENSKI STANDARD
01-januar-2005
Odprti dostop do storitve (OSA) – Vmesnik za aplikacijsko programiranje (API) –
10. del: Upravljalnik povezljivosti SCF
Open Service Access (OSA); Application Programming Interface (API); Part 10:
Connectivity Manager SCF
Ta slovenski standard je istoveten z: ES 201 915-10 Version 1.4.1
ICS:
33.040.01 Telekomunikacijski sistemi Telecommunication systems
na splošno in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 10: Connectivity Manager SCF
(Parlay 3)
�
2 ETSI ES 201 915-10 V1.4.1 (2003-07)

Reference
RES/SPAN-120095-10
Keywords
API, OSA, IDL, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
© The Parlay Group 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 201 915-10 V1.4.1 (2003-07)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.7
4 Connectivity Manager SCF.8
5 Sequence Diagrams.11
5.1 Operator Selects Service Components and creates a new VPrP.11
5.2 Operator Browses Virtual Provisioned Pipe.12
5.3 Operator Browses SAPs and Sites.13
6 Class Diagrams.14
7 The Service Interface Specifications.20
7.1 Interface Specification Format .20
7.1.1 Interface Class.20
7.1.2 Method descriptions.20
7.1.3 Parameter descriptions.21
7.1.4 State Model.21
7.2 Base Interface.21
7.2.1 Interface Class IpInterface .21
7.3 Service Interfaces.21
7.3.1 Overview.21
7.4 Generic Service Interface .21
7.4.1 Interface Class IpService .21
8 Connectivity Manager Interface Classes.22
8.1 Interface Class IpConnectivityManager .22
8.2 Interface Class IpEnterpriseNetwork.24
8.3 Interface Class IpEnterpriseNetworkSite .26
8.4 Interface Class IpQoSMenu .28
8.5 Interface Class IpQoSTemplate.30
8.6 Interface Class IpVPrN .35
8.7 Interface Class IpVPrP .38
9 State Transition Diagrams.42
10 Data Definitions.42
10.1 Connectivity Manager Data Types.43
10.1.1 TpStringList.43
10.1.2 TpIPSubnet.43
10.1.3 TpIPv4AddType.43
10.1.4 TpIPVersion.43
10.1.5 TpVprpStatus.44
10.1.6 TpDsCodepoint.44
10.1.7 TpProvisionedQoSInfo.44
10.1.8 TpDelayDescriptor.44
10.1.9 TpLossDescriptor.45
10.1.10 TpJitterDescriptor.45
10.1.11 TpNameDescrpTagInt.45
10.1.12 TpNameDescrpTagString.45
10.1.13 TpTagValue.46
10.1.14 TpNameDescrpTagExcessLoadAction.46
ETSI
4 ETSI ES 201 915-10 V1.4.1 (2003-07)
10.1.15 TpAction.46
10.1.16 TpPipeQoSInfo.46
10.1.17 TpNameDescrpTagDir.47
10.1.18 TpTrafficDirection.47
10.1.19 TpEndpoint.47
10.1.20 TpSiteOrSap.47
10.1.21 TpLoadDescriptor.47
10.1.22 TpValidityInfo.48
10.1.23 TpNameDescrpTagDateTime.48
10.1.24 TpNameDescrpTagTimePeriod.48
10.1.25 TpNameDescrpTagTimeOfDay.48
10.1.26 TpNameDescrpTagDayOfWeek.49
10.1.27 TpNameDescrpTagMonth.49
11 Exception Classes.51
Annex A (normative): OMG IDL Description of Connectivity Manager SCF.52
Annex B (informative): Record of changes .53
B.1 Interfaces.53
B.1.1 New.53
B.1.2 Deprecated.53
B.1.3 Removed.53
B.2 Methods.53
B.2.1 New.53
B.2.2 Deprecated.53
B.2.3 Modified.54
B.2.4 Removed.54
B.3 Data Definitions.54
B.3.1 New.54
B.3.2 Modified.54
B.3.3 Removed.54
B.4 Service Properties.54
B.4.1 New.54
B.4.2 Deprecated.55
B.4.3 Modified.55
B.4.4 Removed.55
B.5 Exceptions.55
B.5.1 New.55
B.5.2 Modified.55
B.5.3 Removed.55
B.6 Others.55
History .56

ETSI
5 ETSI ES 201 915-10 V1.4.1 (2003-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Services and Protocols for Advanced
Networks (SPAN).
The present document is part 10 of a multi-part deliverable covering Open Service Access (OSA); Application
Programming Interface (API), as identified below. The API specification (ES 201 915) is structured in the following
parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF".
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 3.3 set of specifications.
ETSI
6 ETSI ES 201 915-10 V1.4.1 (2003-07)
1 Scope
The present document is part 10 of the Stage 3 specification for an Application Programming Interface (API) for Open
Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Connectivity Manager Service Capability Feature (SCF) aspects of the interface. All
aspects of the Connectivity Manager SCF are defined here, these being:
• Sequence Diagrams
• Class Diagrams
• Interface specification plus detailed method descriptions
• State Transition diagrams
• Data Definitions
• IDL Description of the interfaces
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 201 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 201 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 201 915-1 and the following apply:
best effort traffic: traffic that is not carried by a VPrN established for the enterprise network by the provider
differentiated services: effort in the Internet Engineering Task Force (IETF) to provide quality of service in networks
employing small well defined building blocks from which variety of service may be built
DS Codepoint: marking associated with a specific VPrP
enterprise operator: administrator of the enterprise network/user of APIs also referred to as operator
operator: enterprise operator
provider network: provides a VPN and VPrP service to the enterprise network, and offers APIs for connectivity
manager to the enterprise operator also referred to as network service provider
provider: entity that offers the VPN and VPrP services, and implements the APIs in the provider network
ETSI
7 ETSI ES 201 915-10 V1.4.1 (2003-07)
Quality of Service (QoS): collection of service levels delivered by a provider network to an enterprise network
NOTE: QoS can be characterised by various performance attributes such as: packet loss, packet delay; traffic
policing measures such as maximum bandwidth and burst rate for traffic entering the providers network.
Service Access Point (SAP): enterprise network is connected to the provider network through the enterprise network
service access points
NOTE: A SAP is typically the egress router from the enterprise network that connects to the provider network.
TOS bits: value held in the TOS field
NOTE: IETF defined the use the TOS field in the IPv4 packet header as a signalling mechanism aimed at
providing definitions of aggregation of flows, where each aggregate is supported by the same level of
QoS.
Virtual Private Network (VPN): network that uses a provider network infrastructure to connect geographically
separated sites of an enterprise
NOTE: Such a network looks like a private network to the enterprise as the sites are connected using tunnelling
and security technologies. With no QoS measures, VPN passes all packets among the sites with a best
effort approach.
Virtual Leased Line (VLL): network that uses a provider network infrastructure to connect two geographically
separated sites of an enterprise
Virtual Provisioned Network (VPrN): collection of VPrP delivered as a service to a single enterprise network
Virtual Provisioned Pipe (VPrP): service provided by the provider network to the enterprise network, which is a type
of virtual leased line (VLL) provisioned with QoS levels
NOTE: VPrP carries enterprise network traffic whose packets are marked with the specific DS Codepoint that is
associated with this VPrP. The enterprise operator using APIs can create on-line a VPrP.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in ES 201 915-1 and the following apply:
CIM Common Information Model
CM Connectivity Manager
DiffServ Differentiated Services
DMTF Distributed Management Task Force
DS Differentiated Services
QoS Quality of Service
SAP Service Access Point
SLA Service Level Agreement terms
TOS Type Of Service
VLL Virtual Leased Line
VPN Virtual Private Network
VPrN Virtual Provisioned Network
VPrP Virtual Provisioned Pipe
ETSI
8 ETSI ES 201 915-10 V1.4.1 (2003-07)
4 Connectivity Manager SCF
Connectivity Manager includes the APIs between the enterprise operator and the provider network for the two parties to
establish QoS parameters for enterprise network packets travelling through the provider network.
The Connectivity Manager service provides tools for the enterprise operator to set up a Provisioned QoS service in the
provider network. The QoS measures used in the enterprise network are outside the scope of the service. The API does
not require any specific QoS method to be used in the enterprise network, nor in the provider network. However, in
order for Provisioned QoS service to be applied to packets arriving from the enterprise network into the provider
network, the packets have to be marked using DS Codepoint marking. Once the packets are so marked, they can enjoy
the QoS service provisioned in the provider network.
APIs provide the enterprise network operator on-line access to provision quality of service measures that control the
enterprise's own traffic passing through the provider network. Using APIs the operator can create virtual provisioned
pipes (VPrPs) in the provider network to carry the enterprise traffic and support it with pre-specified quality of service
attributes. A VPrP can be thought of as a Virtual Leased Line (VLL) provisioned to deliver pre-specified QoS. The
provider may offer to the enterprise operator a set of templates that are used by the operator to specify a VPrP. For
instance, the provider may offer templates for video conferencing, audio conferencing, Gold Service, Silver Service,
etc. Using these templates the operator can select and provision a VPrP that specifies the quality of service attributes for
this VPrP.
Elements that can be specified for a VPrP include attributes such as packet delay and packet loss. Characteristics of
traffic that enters the VPrP at its access point to the provider network can be also specified with attributes such as
maximum rate and burst rate.
The following is an example of a possible scenario:
• The provider prepares a template with operator-specified attributes, provider-specified attributes, and
unspecified attributes, one for each QoS level.
• The provider generates for the enterprise network a list of all the current sites and their access points to the
provider network.
• Enterprise operator logs into connectivity manager after being authenticated and authorised by the Framework
service.
• Operator gets the list of the sites and service access points of the enterprise virtual private network (VPN)
already provided to the enterprise by the provider.
• Enterprise operator retrieves the set of templates available to the enterprise (as supported by the SLA), selects
one, and requests a template for constructing a new VPrP based upon the selected QoS.
• Enterprise operator completes the VPrP template: i.e. selects a value for delay, loss, jitter and excess traffic
treatment action, enters the SLA ID against which the template could be validated, selects endpoints, load
parameters and traffic flow direction, and selects the time requirements desired. The enterprise operator can
choose or modify those attributes that are operator-specified attributes in the template. Provider-specified
attributes cannot be modified and are inherently part of the service.
• Enterprise operator submits the completed VPrP template for validation by the CM service. Operator creates a
new VPrP with pending-status that holds these selections.
• The provider responds after validating the requests, which may be an approval or a denial (e.g. the requested
service is not available at this access point, or at the specified time).
• If the provider approves service, the operator may send packets marked with the templates DiffServ
Codepoint, which identifies together with the endpoints the VPrP that carries these packets.
ETSI
9 ETSI ES 201 915-10 V1.4.1 (2003-07)
Some additional clarification points:
• A VPrN is associated with a single network provider.
• A VPrP defines QoS parameters for traffic flowing through this provider network, between two specified
enterprise endpoints, optionally during specified date/time period(s).
• The enterprise operator may be (provider's choice) constrained to selecting QoS parameter values from a
pre-defined set of values, and selecting endpoints from a predefined set of enterprise sites; where these sets
were negotiated off-line between the enterprise and the network provider and possibly documented in a
Service Level Agreement (SLA).
• The CM service validates each VPrP request submitted by the enterprise operator. The validation process is
not specified here. Validation against the SLA is an example of such possible validation.
• If the CM service accepts the VPrP request, it adds it to the VPrN. The DiffServ Codepoint provided by the
enterprise operator is then used by the enterprise for marking all packets belonging to any traffic flow
associated with the VPrP.
The following is a summary of interfaces and methods supported by connectivity manager. The syntax method
(interface) is used for this description.
There are Passive CM interface functions (CM1, CM2, CM4) that are used to retrieve information (read) relative to
VPN, VPrN, and QoS templates provided by the service provider, and active (CM3) functions (read/write) used to
provision new services.
CM1: Retrieve information on a Virtual Private Network, its sites and their service access points:
getEnterpriseNetwork(IpConnectivityManager)
getSiteList(IpEterpriseNetwork)
getSite(IpEterpriseNetwork)
getSAPList(IpEnterpriseNetworkSite)
getSiteID(IpEnterpriseNetworkSite)
getSiteLocation(IpEnterpriseNetworkSite)
getSiteDescription(IpEnterpriseNetworkSite)
getSAPIPSubnet(IpEnterpriseNetworkSite)
getSiteIPSubnet(IpEnterpriseNetworkSite)

CM2: Retrieve QoS services offered by provider, stored in QoS templates:
getQoSMenu(IpConnectivityManager)
getTemplateList(IpQoSMenu)
getTemplate(IpQoSMenu)
getTemplateType(IpQoSTemplate)
getDescription(IpQoSTemplate)
getPipeQoSInfo(IpQoSTemplate)
getValidityInfo(IpQoSTemplate)
getProvisionedQoSInfo(IpQoSTemplate)
getDsCodepoint(IpQoSTemplate)
CM3: Set up a new Virtual Provisioned Pipe:
createVPrP(IpVPrN)
deleteVPrP(IpVPrN)
setSlaID(IpQoSTemplate)
setPipeQoSInfo(IpQoSTemplate)
setValidityInfo(IpQoSTemplate)
setProvisionedQoSInfo(IpQoSTemplate)

ETSI
10 ETSI ES 201 915-10 V1.4.1 (2003-07)
CM4: Retrieve information on a Virtual Provisioned Network and its Virtual Provisioned Pipes:
getVPrN(IpEterpriseNetwork)
getVPrPList(IpVPrN)
getVPrP(IpVPrN)
getVPrPID(IpVPrP)
getSlaID(IpVPrP)
getStatus(IpVPrP)
getProvisionedQoSInfo(IpVPrP)
getPipeQoSInfo(IpVPrP)
getDsCodepoint(IpVPrP)
Two typical scenarios:
1) To set up a new VPrP:
- The enterprise operator retrieves information regarding enterprise's existing VPN (sites and SAPs), using
as needed the methods listed in CM1 above.
- Enterprise operator retrieves information on provider's offered QoS services, using methods listed in
CM2 above as needed.
- Enterprise operator submits a request to set up a new VPrP, using methods listed in CM3 above as
needed.
- Enterprise operator checks the status of the request using the methods listed in CM4 above as needed.
- If the request was approved by the network provider, the VPrP is put in an active mode, and packets that
are marked in the enterprise network with appropriate marking in their packet header will travel the
providers network through the new Virtual Provisioned Pipe that supports the requested QoS levels.
2) Retrieve information on current enterprise network services delivered to the enterprise by the provider
network:
- Enterprise operator retrieves information on current QoS services delivered to the enterprise network
using CM4 methods listed above as needed.
- Enterprise operator checks if the provider offers new QoS services using CM2 listed above as needed.
The following clauses describe each aspect of the Connectivity Manager Service Capability Feature (SCF).
The order is as follows:
• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
• The Class relationships clause show how each of the interfaces applicable to the SCF, relate to one another.
• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram
part.
• The State Transition Diagrams (STD) show the transition between states in the SCF. The states and transitions
are well-defined; either methods specified in the Interface specification or events occurring in the underlying
networks cause state transitions.
• The Data Definitions clause show a detailed expansion of each of the data types associated with the methods
within the classes. Note that some data types are used in other methods and classes and are therefore defined
within the Common Data types part of this specification.
ETSI
11 ETSI ES 201 915-10 V1.4.1 (2003-07)
5 Sequence Diagrams
5.1 Operator Selects Service Components and creates a new
VPrP
The following sequence diagram shows how an enterprise operator client collects the information required to select a
service, and then selects the service parameters, and finally submits it to the connectivity manager.
: : IpQoSMenu : : IpVPrN
OperatorClient IpConnectivityManager IpQoSTemplate
1: getQoSMenu( )
2: getTemplateList( )
3: getTemplate( )
4: getPipeQoSInfo( )
5: setPipeQoSInfo( )
6: getProvisionedQoSInfo( )
7: setProvisionedQoSInfo( )
8: getValidityInfo( )
9: setValidityInfo( )
10: createVPrP( )
ETSI
12 ETSI ES 201 915-10 V1.4.1 (2003-07)
5.2 Operator Browses Virtual Provisioned Pipe
The following shows an enterprise operator client browses and collect information pertinent to an existing virtual
provisioned pipe, including all the QoS parameters that have been set for this pipe.
: : : IpVPrN : IpVPrP
OperatorClient IpConnectivityManager IpEnterpriseNetwork
1: getEnterpriseNetwork( )
2: getVPrN( )
3: getVPrPList( )
4: getVPrP( )
5: getVPrPID( )
6: getSlaID( )
7: getProvisionedQoSInfo( )
8: getValidityInfo( )
9: getPipeQoSInfo( )
10: getDsCodepoint( )
11: getStatus( )
ETSI
13 ETSI ES 201 915-10 V1.4.1 (2003-07)
5.3 Operator Browses SAPs and Sites
The following sequence diagram shows how an enterprise operator browses service access points and sites to retrieve
information regarding a site and its SAP(s).
: : :
OperatorClient IpConnectivityManager IpEnterpriseNetwork IpEnterpriseNetworkSite
1: getEnterpriseNetwork( )
2: getSiteList( )
3: getSite( )
4: getSAPList( )
5: getSiteID( )
6: getSiteLocation( )
7: getSiteDescription( )
8: getSAPIPSubnet( )
9: getIPSubnet( )
ETSI
14 ETSI ES 201 915-10 V1.4.1 (2003-07)
6 Class Diagrams
The class diagram below shows the connectivity manager interfaces. The connectivity manager interface is the entry
point to this service. From this interface a reference to the enterprise network and to the Quality of Service (QoS) menu
interfaces can be retrieved. The QoS menu interface provides a list of templates, each of which specifies the QoS
service parameters that are offered by the service provider. The service is composed of components that are associated
with a Provisioned QoS. The template interface is used to specify the service parameters that are offered by the service
provider, and also, for temporary storage of parameters that the operator selects. The enterprise network interface is
associated with two components: enterprise network sites, and the Virtual Provisioned Network that has been already
provisioned in the provider network. The Virtual Provisioned Network interface contains references to all the Virtual
Provisioned Pipes (VPrPs) already established. The QoS Menu contains references to all the QoS templates offered by
the provider. Each template specifies the QoS parameters that can be set in order to create a new VPrP. Once the
operator selects the QoS parameters provided in the QoS template, and submits the request to create a new VPrP, the
provider validates the information submitted and if the request is approved, the new VPrP is set to an active mode.
<>
IpConnectivityManager
(from cm)
<>
IpQoSMenu
<>
(from cm)
IpEnterpriseNetwork
(from cm)
11 11
<>
IpVPrN
(from cm)
00.n.n
11.n.n
<>
<>
IpQoSTemplate
IpEnterpriseNetworkSite
(from cm)
(from cm)
00.n.n
<>
IpVPrP
(from cm)
Figure 1: Connectivity Management High level class diagram
ETSI
15 ETSI ES 201 915-10 V1.4.1 (2003-07)
The connectivity manager class is associated with the QoS menu class and the enterprise network class as shown in the
figure below. From the CM class the QoS Menu and Enterprise Network reference can be retrieved. The QoS menu
provides a method (getTemplateList()), to get the list of all the QoS offered services, each of which is stored as a
template (e.g., Gold template, Silver template). The QoS menu provides a method (getTemplate()) that instantiates a
temporary template to retrieve the default parameters for a specific template, and store the parameters selected by the
operator for a new service (VPrP). The Enterprise Network class is used to retrieve the list of sites that the operator has
established for a Virtual Private Network (VPN) service with the service provider, and to get a reference to a specific
site. This class also provides a reference to the Virtual Provisioned Network class that holds the information regarding
the already established QoS network with the provider.
<>
IpConnectivityManager
(f ro m c m)
getQoSMenu()
getEnterpriseNetwork()
<> <>
IpQoSMenu IpEnterpriseNetwork
(from cm) (from cm)
getTemplate() getSiteList()
getTemplateList()
getVPrN()
getSite()
Figure 2: QoS Menu and Enterprise Network class diagram
ETSI
16 ETSI ES 201 915-10 V1.4.1 (2003-07)
The figure below shows QoS templates class that is used to retrieve the QoS parameters offered by the provider and
select the parameters for a new VPrP and store them in this template. Most of these parameters are tagged using the
TPNameDescrpTag class to indicate whether the parameter is set by the provider and cannot be changed by the
operator, or is a parameter that can be set by the operator. A third option associated with each QoS parameter is the
unspecified tag, that means that the operator does not offer this parameter as an option for this template. All the QoS
parameters that constitute a VPrP are stored in the template class, including the source and destination site/SAP, the
direction of the traffic, the provisioned QoS parameters, such as packet loss, delay, jitter, the Pipe QoS parameters, such
as load conditioning.
<>
IpQoSMenu
(from cm)
<>
getTemplate()
TpPipeQoSInf o
getTemplateList()
(from cm_data)
0.0.nn
<>
IpQoSTemplate
<>
(from cm)
TpProv isionedQoSInf o
(from cm_data)
getTemplateTy pe()
getDescription()
setSlaID()
getPipeQoSInf o()
setPipeQoSInf o()
getValidity Inf o()
<>
setValidity Inf o()
TpValidity Inf o
setProv isionedQoSInf o()
(from cm_data)
getProv isionedQoSInf o()
getDsCodepoint()
<>
TpDsCodepoint
(from cm_data)
Figure 3: QoS Template class diagram
ETSI
17 ETSI ES 201 915-10 V1.4.1 (2003-07)
The figure below shows the data types that specify the Provisioned QoS information: as packet loss, packet delay,
packet jitter. All use the Name Description Tag class to indicate whether each parameter is specified by the provider,
the operator, or unspecified for this template. The value used for each of individual parameters is either an integer, or a
string. For the excess load condition, one of the four actions can be applied: drop, transmit, reshape, and remark. The
DS Codepoint used by this template is also shown below.
<>
<>
TpJitterDescriptor
TpProv isionedQoSInf o
( from cm_data)
(from cm_data)
M
M
M
TpNameDescrpTag
<>
M
M TpDelay Descriptor
M
(from cm_data)
M
M
M
<>
TpTagValue
<>
(from cm_data)
TpLossDesc riptor
OPERATOR_SPECIFIED
(from cm_data)
PROVIDER_SPECIFIED
<>
UNSPECIFIED
TpNameDescrpTagExcessLoadAction
( from cm_data)
+v alue
<>
TpAction
(from cm_data)
<>
<>
DROP
TpNameDescrpTagInt
TpNameDescrpTagString
TRANSMIT
(from cm_data)
(from cm_data)
RESHAPE
REMARK
Figure 4: Provisioned QoS Data Types Classes
ETSI
18 ETSI ES 201 915-10 V1.4.1 (2003-07)
The figure below shows the Pipe QoS information data type classes. They include the load parameters, and the endpoint
termination of the pipe. The individual values are integer, and for the directional type, either uni-directional traffic or
bi-directional traffic is specified for the Pipe.
<>
<>
TpLoadDescriptor TpPipeQoSInfo
(from cm_data) (from cm_data)
+serviceOrigin
M M
<>
+serviceDestination
TpTagValue
(from cm_data)
<>
OPERATOR_SPECIFIED
TpEndpoint
PROVIDER_SPECIFIED
(from cm_data)
UNSPECIFIED
+type
<>
M TpSiteOrSap
(from cm_data)
M
TpNameDescrpTag
SITE
SAP
M
M
M
<>
TpTrafficDirection
(from cm_data)
<>
UNIDIRECTIONAL
TpNameDescrpTagInt
BIDIRECTIONAL
(from cm_data)
+val ue
<>
TpNameDescrpTagDir
<>
(from cm_data)
TpNameDescrpTagString
(from cm_data)
Figure 5: Pipe QoS Data Types
ETSI
19 ETSI ES 201 915-10 V1.4.1 (2003-07)
The figure below shows the classes that store information regarding the existing services already established between
the provider and the enterprise. This includes the Virtual Private Network that is contained in the Enterprise Network
Site class, and the Virtual Provisioned Network Class, and the associated Virtual Provisioned Pipe class. Also shown
here is the information included for Pipe QoS, and the IP subnet information stored in these classes. However, the class
that shows the information collected for Provisioned QoS is not shown here but in another class diagram below.
<>
IpEnterpriseNetwork
(f rom cm)
getSiteList()
getVPrN()
getSite()
1.1.nn
<>
<>
<>
IpEnterpriseNetworkSite
IpVPrN
TpStringList
(f rom cm )
(f r om c m)
getSAPList()
getVPrPList()
getSiteID()
<>
getVPrP()
getSiteLocation()
TpVprpStatus
createVPrP()
getSiteDescription()
deleteVPrP() (from cm_data)
getIPSubnet()
ACTIVE
11 getSAPIPSubnet()
PENDING
DISALLOWED
00.n.n
<>
IpVPrP
<>
TpPipeQoSInfo
(f r om c m)
<>
TpIPSubnet
getVPrPID()
<>
(from cm_data)
getSlaID()
TpProvisionedQoSInfo
getStatus()
(from cm_data)
getProvisionedQoSInfo()
getValidityInfo()
getPipeQoSInfo()
<>
getDsCodepoint()
TpValidityInfo
+addressT ype
+IPVersionSupport
(f rom cm_data)
<>
<>
TpIPv4AddType
TpIPVersion
(f rom cm_data)
(f rom cm_data)
IPV4_ADD_CLASS_A
VERSION_UNKNOWN
<>
IPV4_ADD_CLASS_B
VERSION_IPV4
TpDsCodepoint
IPV4_ADD_CLASS_C
VERSION_IPV6
(from cm_data)
IPV4_ADD_CLASS_D
IPV4_ADD_CLASS_E
Figure 6: Existing VPN and VPrN services class diagram
ETSI
...