GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Deliverable
Contractual Date:
Actual Date:
Grant Agreement No.:
Activity:
Task Item:
Nature of Deliverable:
Dissemination Level:
Lead Partner:
Document Code:
Authors:
dd-mm-yyyy
dd-mm-yyyy
238875
<Insert activity code – e.g. JRA1, SA3>
<Insert task item number>
<R (Report), P (Prototype), D (Demonstrator), O (Other)>
<PU (Public), PP (Project Participants), RE (Restricted), CO (Confidential – Consortium members and
Commission)>
<Insert name of lead partner>
Document Revision History
Version
Date
Description of change
Person
1.0
11062010
Rearranged the content
Brian Bach Mortensen
1.1
11062010
Further Editing
Brian Bach Mortensen
1.2
14062010
Correcting and clarifying stuff
Brian Bach Mortensen
28072010
Architecture description changes (after
output from NREN)
PSNC team
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
BoD Joint Infrastructure and OLA
Document Revision History
1.3
28032012
1.4
Project:
GN3
Deliverable Number:
Date of Issue:
28/07/17
EC Contract No.:
511082
Document Code:
General Review for Alpha service lunch
Tasos Karaliotas (T2/GRNET)
Lukas Grzesiak (T2/PSNC)
General review and changes to reflect
latest status of the service
Darren Ingless
Table of Contents
Abstract
5
Use of this Document
5
1
The Bandwidth-on-Demand Service
6
1.1
Prerequisites
6
1.2
Introduction
6
1.3
BoD service outline
6
2
Service Architecture
7
2.1
Local resources and services
9
2.1.1
Network Infrastructure
9
2.1.2
Path Provisioning
9
2.1.3
Monitoring
14
2.1.4
Authentication and Authorization Infrastructure (AAI)
14
2.1.5
Service Support Desk
15
2.1.6
Infrastructure support service
17
2.1.7
Support Teams
17
2.2
3
Joint infrastructure “blocks”
18
2.2.1
Joint Network Infrastructure
18
2.2.2
Automatic E2E Path Provisioning
18
2.2.3
E2E Monitoring
18
2.2.4
Authentication and Authorization Infrastructure
19
2.2.5
Joint Accounting
20
2.2.6
Service Support Desk
20
2.2.7
MDSD
20
Service deployment checklist
21
3.1
Network Infrastructure
21
3.2
Path provisioning
22
3.3
Monitoring
22
3.4
AAI
23
3.5
Accounting
23
3.6
Service desk
23
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
iii
3.7
Support teams
23
Service Management Procedures
24
A.1
Participation of a domain in the BoD Service Area (Initialization)
24
A.2
Service functions procedures
24
A.2.1
Service setup
24
A.2.2
Service modification
27
A.2.3
Service termination
29
A.2.4
Monitoring of an implemented service
31
A.2.5
Service problems indication
31
A.2.6
Schedule maintenance for a dynamic E2E link
33
Appendix A
Appendix B
B.1
B.2
Related GÉANT Tools
36
AutoBAHN
36
B.1.1
AutoBAHN for Intra-Domain Transport provisioning
36
B.1.2
AutoBAHN for Inter-Domain Topology Distribution
37
B.1.3
AutoBAHN for Inter-Domain Pathfinding service
37
B.1.4
AutoBAHN for service Inter-Domain Connectivity
37
B.1.5
AutoBAHN for Access Interface
38
cNIS
B.2.1
B.3
B.4
38
cNIS for Intra-Domain Transport topology discovery
38
PerfSONAR
38
B.3.1
PerfSONAR for Monitoring service
38
B.3.2
PerfSONAR for Access Interface
39
EduGAIN
39
B.4.1
39
EduGAIN for authorization and authentication service
Appendix C
Indicative Functions of the Access Interfaces
References
47
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
40
iv
Abstract
This document describes service architecture for the Bandwidth on Demand service offered jointly by networks
in the GÉANT service area.
Use of this Document
This document is written for usage within the GN3 consortium in order to make sure that the functionality and
quality specified in the service descriptions and the service level specification of the bandwidth on demand
service are met. It describes the infrastructure and the supporting services that are needed to run the service.
The infrastructure and supporting services are put either in a joined service provider category or in an individual
provider category to make it very clear what the responsibilities of the different participants are. The
infrastructure and supporting service blocks are further decomposed into smaller component where needed.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
5
1
The Bandwidth-on-Demand Service
1.1
Prerequisites
The Bandwidth-on-Demand (BoD) service architecture is based on the “Multi-Domain Connectivity Services
Architecture Document”, Deliverable 2.1.1. The reader should reference to the service architecture document
for key concepts and definition of terms.
The service description and service level parameters are described in the BoD service Specification.
1.2
Introduction
The BoD service is provided as a joint service. It is specified in a service specification document that will be
used as a part of the service catalogue for connectivity services in the GÉANT service area. The service
specification document describes what the service offers to the end users (for a complete understanding of this
document read the BoD service specification first).
This document describes how the BoD service is designed from a service management point of view. This
includes a description of the necessary infrastructure for building the service, any supporting services that need
to be defined (federated or individual) and a number of Operational Level Agreements (OLAs) for the
supporting services. Obviously there should be a strong relation between the service description with its
Service Level Specification and this document and its OLA’s. this document is therefore only meaningful
together with the service specification.
1.3
BoD service outline
Figure 1 presents the data plane for the end-to-end transport of the Ethernet frames by the BoD service. The
two End-Users are connected on their respective End-User domains. The BoD Service area comprises several
participating domains. The BoD Service receives, transports and delivers Ethernet Frames between Service
Demarcation Points (SDPs) “A” and “Z”, where the End-User sites are connected. The end-to-end transport
service is implemented through several intra domain transport services, stitched together at the Service
Stitching Points (SSPs) between the domains. Both SDPs are connected using infrastructure provided by the
federated domains. The domains that participate in the joint BoD service offering are connected together at
SSPs (for a detailed description of the service offerings read the BoD Service Description)
The end-to-end service transporting Ethernet frames are provisioned over a number of interconnected
domains, each delivering a small part of the data plane. The data plane functionality that needs to be delivered
by the participating domains at the SDPs and SSPs is described in 2.1.2.2. For exchange of topology
information between the participating domains see 2.1.2.1. Signalling and reservation request requirements are
described in section 2.1.2.3. The authentication and authorisation requirements are described in 2.1.4. The
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
6
requirements towards local service desks and the interaction with the consortium service desk are explained in
2.1.5.
Transit Domain
Desti
Source Domain
“A”
SDP
SSP
SDP
End User/Facility
E
Figure 1 End to end path of BoD instance in multi-domain infrastructure
Please note that the delivery of the Ethernet frames between the actual end users and the SDPs is outside of
the BoD Service Area and hence not within the scope of the BoD Service definition. The end user needs to
make the appropriate arrangements with their local network domains for the handoff of data at the specific
SDP.
2
Service Architecture
The BoD service relies on a set of infrastructure tools and supporting services that enable end-to-end dynamic
allocation of bandwidth; see figure 2 below:
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
7
End-user A
End-user B
End-user C
Request
Request
Request
Bandwidth on Demand Service (BoD)
Joint Infrastructure and
supporting services offered
by the consortium
Joint Network
infrastructure
Automatic E2E
path provisioning
E2E
Weathermap
Monitoring
SLS
Joint Authentication
and Authorization
Joint Accounting
Multi-Domain
Service Desk
(MDSD)
NREN
NREN
NREN
Network
infrastructure
Intradomain path
provisioning
Monitoring
AAI
Accounting
Service Desk
OLA’s
Infrastructure, OLA’s, Supporting
services and Support Teams operated
by each individual network operator
(NREN or Dante)
Infrastructure
support service
Support Team(s)
Figure 2 Dependencies between service, infrastructure and supporting services
Figure 2 depicts the dependencies between the service and the infrastructure and supporting services
(including support teams and OLAs). The figure does NOT illustrate any data or control plane communication.
Furthermore, it should be noted that the figure may not capture all dependencies between the blocks, but rather
the most significant ones. However, the intention is to describe each of the blocks in figure 2, in more detail
than what can be pictorially displayed.
The top part of figure 2 depicts the relationships that exist between end users, their requirements and the actual
specification of the service in terms of textual descriptions and the SLS. This part of the figure is described in
the previously mentioned document [BoD Service Specification] and will not be covered here. Underneath
these “blocks”, two main “areas” exists. One area contains the entire infrastructure, supporting services, OLAs
and support teams that are managed and operated by the consortium jointly. The other division describes the
supporting services and OLAs that need to be established for each network to participate in the service. In this
area a support team is mentioned for completeness, but how the individual network decides to operate or
provide the supporting services are not part of any OLA as long as core functionality is provided. In the
following we will describe each of the areas and blocks shown in the figure. First we will describe the “blocks”
that are necessary to be supplied by the individual networks in order to take part in the joint service offering.
Thereafter a description of the “blocks” that is required by the joint service provider to deliver the specified
service is given. Some of the blocks will be further divided into description as they typically “hide” a number of
underlying components. Furthermore, each supporting service described below will be accomplished by a
textual OLA when needed, even if this is not shown in
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
8
Local resources and services
2.1
Local resources are all the elements that any domain needs to provide in order to participate in the BoD
Service Area. Those elements reside under the administration and operation of each participating domain.
2.1.1
Network Infrastructure
Network infrastructure is a key part of the BoD service. To participate in the BoD service an NREN must
provide some resources that can be used to build the joint network infrastructure:

Physical interfaces allowing for the End User to access the BoD service

Physical interfaces used for interconnecting the NRENs

Appropriate amount of free bandwidth in NREN core network
The current version of the BoD service defines that the only supported transport technology is Ethernet, so only
Ethernet frames will be exchanged between End Users. It means that, depending on technology used by
participating NREN, the appropriate network devices (like MPLS, Ethernet or SDH switches) must be used in
order to offer transmission based on Ethernet technology independently from Ethernet frame payload.
Moreover a set of additional tools should be deployed by NREN to allow automatic path provisioning, service
monitoring and troubleshooting.
2.1.2
Path Provisioning
In order to establish an end-to-end (E2E) path between two End user sites over the federated, multi-domain
infrastructure, a part of this path must established in each participating domain. Path provisioning block
contains all functions and tools required to provision the part of the transmission path that belongs to each
participating domain. (E.g. between both end point - SDP and SSP). In general it contains a description of:

Topology exchange mechanism

Requirements for intra-domain transport

Procedures and tools for bandwidth allocation and automatic path provisioning
Path provisioning block also includes user interface (API and web portal) which is used for all activities related
to requesting the BoD service.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
9
2.1.2.1 Topology exchange
Each participating BoD domain must advertise information about its SDPs and SSPs along with their
capabilities to other BoD domains. In each domain, gathered information about SDPs should be included in the
list of available demarcation points that are presented to the End User during the service request. Gathered
information about SSPs must be used by the Inter-Domain Pathfinding in order to point out where stitching
between participating domains will be performed and how the edge interfaces will be configured to transport the
End User data.
Protocols used
The following protocols are used to exchange topology information between provisioning systems that are non
autobahn based:
IDCP v1.1
NSI v1.0 (still in test phase)
OLA
Naming of SDPs and SSPs
For the exchange and unique identification of topology information between the domains a consistent naming
scheme of these points is specified. The SDPs and SSPs should be characterized by the following parameters
in a path identifier tuple:
Description
Format
Equipment identifier
Unique URN.
Port identifier on equipment
Integer (0 to 2^16-1)
Service identifier. Unique number for the service on
the particular equipment and port.
Integer (0 to 2^16-1)
It is recommended to use URNs allowing easy identification of equipment main function and location. The URN
for an SDP may have the following format:

urn:sdp:[NREN name]:[city]:[campus/entity name]:[access port number]
The URN for SSP may have the following format:

urn:ssp:[NREN-1 name]:[NREN-2 name]:[location/city]:[port number]
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
10
Below are examples of URNs for SDP and SSP:

urn:sdp:pionier:poznan:put:1

urn:ssp:dfn:pionier:frankfurt:1
Support teams
A support team must exist at the local network domain in order to support the above requirements. It will be the
same team as for automatic provisioning tool.
2.1.2.2 Intra-domain transport
The dynamic, end-to-end, multi-domain transmission path (circuit) will consist of smaller segments of network
paths stitched together between the participating domains. Service Demarcation Points and Service Stitching
Points are established and maintained by the involved networks. The SDP is the point where End User traffic
enters and leaves the BoD service area. The SSP is the point where smaller network paths, provided by
different domains, are stitched together in order to form the end-to-end service.
The E2E link can be realized by making use of different technologies used in the domains such as native
Ethernet, Ethernet over SDH, Ethernet over MPLS or any other appropriate transport technology. Although
each of the above technology may be described with different parameters, all of them transport Ethernet frames
generated by the end user. In order to allow proper cooperation between domains and guarantee the reliable
transmission for the end user the following parameters must be given for each service instance
The NREN must be able to provide at least one of transport modes (described in the BoD Service Description
and SLS document):

ETS-untagged

ETS-VLAN

ETS-Port-Transparent

ETS-VLAN-to-Untagged
For more information related to transport modes please refer to the BoD Service Description and SLS
document.
OLA
Payload type
Payload type is a mandatory parameter that specifies the payload that is subject to the transmission in provider
network. For the BoD service it can be untagged or tagged Ethernet frame.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
11
The payload type is determined by the requesting end-user and depicted on the SDP configuration. The
participating domains must properly configure the devices on selected transmission type in order to provide
transport of requested frames. The configuration and parameters will be prepared by the automatic provisioning
tool.
For tagged frame, it is allowed to use different VLAN IDs on each end of the BoD circuit if this is acceptable by
the end user. Additionally the BoD service can provide transparent transmission of any Ethernet frame
generated by the end user. This will allow the end user to transmit Ethernet frames with any VLAN ID over a
single BoD service instance. The transport technologies used in participating domains must guarantee that
MAC header (especially MAC addresses) will not be changed at any point in the network (with exception of
VLAN ID).
The BoD service guarantees at least transparent untagged frame transmission between end user sites. The
payload type will be adjusted to meet requirements of particular transport mode selected for the BoD service
instance (see the Service Descriptions and Service Level Specification document).
Maximum Transmission Unit (MTU)
Maximum Transmission Unit specifies maximum size of data unit that will be carried over the network. In the
context of the BoD service the Payload type is Ethernet frame, so MTU specifies maximum frame size
generated by the Customer, which can be carried over provider network.
The BoD service area must be able to support 9000B MTU end user frames (excluding FCS field). This means
that all network components used in the provided path should support and configured with this value.
Maximum Burst Size (MBS)
When the traffic exceeds the bandwidth granted for the service, it becomes subject to the burst size rate. The
amount of the traffic specified by MBS is allowed to be transmitted even when the traffic exceeds the bandwidth
limit.
Recommended value for burst size should be calculated as follows:
Burst  2  RTT 
rate
8
Where

Burst is the number of bytes which will be accepted by the switch on the interface, in case when the
traffic exceeds configured data rate

RTT is round time trip in seconds. Currently assumed that this value is 0,020s

Rate is capacity requested by end user in bit per second
It is recommended to agree on a common MBS value for the entire service path. If possible the MBS set in
transit domains should be greater than in domains directly connected to the End Users. It is highly
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
12
recommended for the End User to apply traffic shaping on egress interfaces in order to smooth out the traffic
(to avoid the bursts exceeding committed capacity).
Capacity
Capacity specifies the total amount of bandwidth that is granted to the End User by the BoD Service for their
traffic. It does not contain network technology overhead. It is calculated for total payload size specified for the
service as subject of transmission (for example tagged or untagged frame).
Support teams
Support teams must exist in order to ensure guarantees for each parameter. In most cases NREN technical
staff responsible for network operation and maintenance will handle these tasks.
2.1.2.3 Bandwidth allocation and automatic provisioning
During the user request, the user supplies the BoD service with two SDPs and service delimiters. Chosen
SDPs can be located in two different domains and then the Inter-Domain Path finding service is required. In this
case, in order to implement the BoD service, one or more paths of domains must be calculated. The calculated
path must start on the ingress SDP and end on the egress SDP, and each domain on the list must be
connected with its previous and next (user constrains, e.g. domains that must be included or avoided, may also
apply).
When transit BoD domains are chosen by Inter-Domain Pathfinder then Inter-Domain Reservation service is
responsible for service reservation negotiation between two domains. Inter-domain signalization should affect
Intra-Domain Transport service of next domain on the chosen path.
OLA
Signalling
The bandwidth allocation supporting service must be able to signal with peering BoD domains regarding
establishment and removal of segments of end-to-end paths.
If the network domain offers multiple transport modes the inter domain signalling must allow specific request for
these.
Monitoring
Once a segment of an end-to-end path is established in the network domain, the bandwidth allocation
supporting service MUST ensure that the newly created segment is monitored by the End-to-end monitoring
supporting service.
Likewise, when the segment is removed the monitoring supporting service should be informed to stop sending
monitoring information for that specific segment. Monitoring functionality is not implemented in the current
version of the BoD service, however at the time of writing this is under development. Please consult the
Bandwidth on Demand Roadmap document for more details.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
13
Protocols used
The IDC (Inter-Domain Controller) protocol will be used for GN3 BoD inter-domain service signalling. In the
future, it is intended to use the NSI protocol.
Support teams
A support team must exist at the local network domain in order to support the above requirements.
2.1.3
Monitoring
The main function of the monitoring supporting service is to deliver monitoring data to the joint E2E monitoring
service. The monitoring supporting service only delivers monitoring information from its own network domain.
When a new E2E path is setup through the specific network domain the monitoring supporting service must
start to send or provide access to monitoring information for the E2E monitoring service.
Monitoring functionality is not implemented in the current version of the BoD service, however at the time of
writing this is under development. Please consult the Bandwidth on Demand Roadmap document for more
details.
2.1.3.1 OLA
The monitoring data should cover all the specified monitoring fields from the BoD service specification [BoD
Service Specification], section 2.3.5 [Service Functionality Description / User Interface and Procedures /
Monitoring].
Furthermore the monitoring data needs to be delivered at a frequency rate according to the above specification.
Protocols used
Control and sharing of results of measurements and metrics should be made using protocols defined by NMCWG [NMCWG].
2.1.3.2 Support team
A support team must exist at the local network domain in order to support the above requirements.
2.1.4
Authentication and Authorization Infrastructure (AAI)
This supporting service must be used to enhance security of BoD service. All End Users and Administrators of
BoD service must be authenticated in the egress BoD domain (web portal) and also authorized in each domain
participating in BoD service implementation. Authorization process must be based on Policy Management
rules. Where a domain does not currently operate an Identity Provider, they may obtain this service centrally
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
14
from the GÉANT Identity Provider. The current version of the BoD service supports a preliminary authentication
scheme based on static assigned Usernames and Passwords. Authorization is supported to a limited extent.
Please consult the Bandwidth on Demand Roadmap document for more details
Protocols used
In order to provide the communication protocol for authorization and authentication purposes both in the web
portal and service levels the Security Assertion Markup Language can be used. SAML is an OASIS
(Organization for the Advancement of Structured Information Standards) standard for exchanging
authentication and authorization data between security domains. SAML is an XML-based protocol that uses
security tokens containing assertions to pass information about a principal (usually an end-user) between an
identity provider and a web service. It enables web-based authentication and authorization scenarios including
single sign-on (SSO). SAML assumes the principal (often a user) has enrolled with at least one identity
provider. This identity provider is expected to provide local authentication services to the principal. On the basis
of this assertion, the service provider makes an access control decision. The eduGAIN service is using the
SAML 2.0 assertion language.
2.1.4.2 Support teams
A support team must exist at the local network domain in order to support the above requirements.
2.1.5
Service Support Desk
The local networks may offer a local service desk towards their end users. The Service Desk located at the
individual network domains performs three main functions:

Receive requests from the end users (directly or with using appropriate tools)

Operates the BoD service within an individual network domain.

Is the contact point for Service Support desks located in other BoD domains and the MDSD.

Provides a point of contact for End Users registered within a specified domain and communicates with
Service Support Desk instances located in other BoD domains.
The user requests for BoD service can be sent to the Service Support Desk directly (for example by phone or
email) or automatically (using web portal or API).
The local service desk will filter enquiries out that can be dealt with in the local network domain. The MultiDomain Service Desk will offer support to the individual service desk in cases that requires multi domain
coordination.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
15
The following topics must be coordinated between neighbour Service Support Desks in order to allow federated
BoD service operations:

Agreement on domain responsibility definition for each SSP (especially for cross border fibres or
leased infrastructure usage)

Agreement on SSPs capabilities

BoD software configuration with regards to inter-domain network resources
The Service Support Desk from which the BoD service request originates is responsible for initiating the public
steps needed to maintain network issues for the entire service:

Notifying the MDSD of the issue and providing as much information relating to the issue and likely
affected NRENs. The MDSD will coordinate the efforts of NRENs to investigate network issues for the
entire service.

Reacting to E2E link failure on the entire path and notify the local NOC if necessary and other Service
Desk domains participating in BoD service instance via the MDSD
Reacting
to
notifications
from
other
participating
NRENs
about
scheduled
events
(maintenance/reconfiguration)All participating Service Desks are responsible for sending notices to the MDSD
about scheduled events and network outages. The MDSD will propagate this information to affected NRENs
depending on the impact of the events and outages on the appropriate service instances. The MDSD Planned
Maintenance Calendar is used in instances where information should be provided to all participating NRENs.
2.1.5.1 OLA
The service desk can be contacted via the following means:

Email

Telephone
The availability of the service desk depends on local NREN rules, but should be provided for requesting end
user during service setup procedure.
2.1.5.2 Support teams
The Multi-Domain Service Desk will coordinate Service Support Desk operations if needed.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
16
2.1.6
Infrastructure support service
Infrastructure support service is responsible for providing and maintaining infrastructure for other supporting
services that are offered as functional entities by BoD domain. Infrastructure support service also maintains the
network infrastructure of the domain. The infrastructure which is provided by Infrastructure support services for
support services are IT resources and network connectivity. IT resources like servers are needed to run BoD
supporting service software components whereas network connectivity enables interoperability between those
components located both within a single BoD domain and between components of different BoD domains.
2.1.6.1 OLA
Service Availability Target
Service availability is the percentage of the agreed service time that the service was able to perform its agreed
function when required. The recommended minimum value for the end user is 99.5% not including planned
maintenance. Because of the chain topology between SDPs each NREN should make every effort to provide
this parameter in his domain at the highest level. It is strongly recommended that each NREN offers availability
at 99.9%, which gives total availability for a 4 domain link not less than 99.6%.
2.1.7
Support Teams
Support Teams administrate and maintain the supporting services and infrastructure required for the successful
operation of the services. Support Teams members can be network operators, software operators, IT resources
operators and also IT consultants.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
17
2.2
Joint infrastructure “blocks”
2.2.1
Joint Network Infrastructure
Joint network infrastructure consists of interconnected NREN domains. The NRENs are connected together
using SSPs. The End Users can get access to the BoD service through SDPs.
2.2.1.1 SDP/SSP database
The Service Demarcation Point list is maintained in a distributed archive and contains all SDPs and SSPs that
can be reached within the BoD service area. The archive consists of NREN database content. The local NREN
database can be maintained by the NREN using any suitable tool but should be accessible by consortium
members.
The SDP list can be used to build a coverage map of the BoD service domain. The coverage map can be used
to advertise the service offering and for domains to determine where requests can likely be fulfilled.
The SDP list may hold information about transport modes and conduit parameters offered by the individual
networks.
2.2.2
Automatic E2E Path Provisioning
Automatic E2E path provisioning provides required tools and protocols for selecting and establishing
transmission path between End Users (SDPs). Establishing transmission path between SDPs will be done by
NRENs individually in their domains. However NRENs must have common signaling interface to exchange
information required to set up path across multiple domains. When automatic provisioning tools will be used for
that purpose, it must support standardized interface to exchange signaling information between domains.
2.2.3
E2E Monitoring
Monitoring functionality is not implemented in the current version of the BoD service, however at the time of
writing this is under development. Please consult the Bandwidth on Demand Roadmap document for more
details.
The main function of the E2E Monitoring Service will be to collect monitoring data from the monitoring
supporting service of the participating BoD domains for the purpose of the following:

Fault detection (either degraded or broken circuit instance)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
18

Fault identification

Usage statistics
The usage statistics SHALL be made available to BoD participants on a monitoring web page.
In case of any faults or degradation detected the Joint service desk (and NOC) should be informed in order for
them to start solving the fault cause.
2.2.3.1 Protocols used
Control and sharing of results of measurements and metrics should be made using protocols defined by NMCWG [NMCWG].
2.2.3.2 OLA
The monitoring data should cover all the specified monitoring fields from the BoD service specification [BoD
Service Description], section 2.3.3.
2.2.3.3 Support team
The E2E monitoring Service will be supported and operated by the Infrastructure Supporting Service (see
2.1.6). Some tasks and operations related to publishing monitoring information and global status of the service
instance can be performed by the Multi-Domain Service Desk.
2.2.4
Authentication and Authorization Infrastructure
The Authentication and Authorization Infrastructure provides the information that is needed in order to enable
Authentication and Authorization for connection establishment between the end users. The required
functionality will be provided by the eduGAIN service. The AAI information is a sub set of the information kept in
the eduGAIN service, which allows the participating network domains to announce authorized users of the
service.
Although Authentication is provided by the simple use of statically assigned credentials, the AAI framework is
presently being implemented into AutoBAHN. Please consult the Bandwidth on Demand Roadmap
document for more details
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
19
2.2.5
Joint Accounting
Joint accounting is a set of rules and procedures required for cost recovery. The End User should be charged
for the service only by its NREN. The NREN representing the End User that originated the BoD service request
will serve as accounting center for the end user and participating NRENs.
The accounting and pricing details are out of scope of this document.
2.2.6
Service Support Desk
The infrastructure support service is responsible for operation and maintaining the following infrastructure
components:

AAI Archive access

E2E monitoring Service

SDP archive
2.2.6.1 Support teams
The NRENs support teams will cooperate together in order to give for the end user look and feel of single
support desk. When necessary, NREN Service Desks actions will be coordinated by MDSD.
2.2.7
MDSD
The Multi-Domain Service Desk coordinates operations of NRENs Service Desks. The MDSD is not a
centralized support desk for users. Instead it is a means by which the chain support model can be supported if
needed. For example, if there is a need to publish some information or to share measurement results etc. The
MDSD will operate as a point of contact for NRENs to discover the global status of the essential building blocks
of the BoD service. It will coordinate information flow in the chain support model.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
20
Service deployment checklist
3
This section contains a quick guide that can help to implement a basic/typical BoD service.
Item
Network
Infrastructure
Path
provisioning
Monitoring
AAI
Accounting
Service Desk
Support teams
3.1
Requirement
1. Connect to at least one BoD-enabled domain.
2. Prepare at least one access interface (SDP)
3. Enable transport of Ethernet frames with MTU 9000
octets
4. Assure Maximum Frame Loss Rate (MFLR) in a
domain: Less than 0,1% of lost frames
5. Provide Availability: at least 97 %
6. Support of at least one of transport modes
(ETS_untagged, ETS-VLAN, ETS-Port-Transparent,
ETS-VLAN-to-Untagged)
Notes
More details: section
2.1.2.2,
1. Install and configure any tool which can communicate
with AutoBAHN or use IDC protocol for interdomain
service signaling (.e.g. AutoBAHN, OSCARS)
2. Configure access to your network devices for the tool
3. Prepare access to the end users (preferred is web
portal)
More details: section
2.1.2.3
1. Enable monitoring tools (e.g. PerfSonar). Control and
sharing of results of measurements and metrics should
be made using protocols defined by NMC-WG
1. Define user groups and preferences
2. Provide usernames and passwords to the end users
1. Enable service usage accounting
More details: section
2.1.3
1. Prepare local service desk for processing user’s
requests and collaborating with service desks from
other domains.
2. Assure Availability of Service Desk: at least 95%
1. Define the Teams maintaining the infrastructure and
software services, NOC,
More details: section
2.1.4
More details section:
Error! Reference
source not found.
More details section:
2.1.5
Network Infrastructure
Any domain/NREN that wishes to participate in the BoD service area should prepare its network infrastructure
to support transport of Ethernet frames and exchange the traffic with other NRENs before enabling the service
in its perimeter. Following steps are recommended in order to achieve that goal:
1) Create Service Stitching Point with neighboring domain. It is recommended to use Ethernet interface
with VLAN IDs as service delimiter (however other technologies are also allowed). The different service
instances should be recognized by (outer) VLAN ID. Depending on traffic size estimation it can be 1GE
or 10GE interface.
2) Connect at least one End User site. The end user site can be single research institute or campus
network. It is also allowed to define single port that can be connected to the end user in near future.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
21
3)
4)
5)
6)
3.2
This port will be Service Demarcation Point, and certain BoD connections will be terminated on it. It is
recommended that the SDP should support VLAN tagging in order to allow provisioning of multiple
connections for single (or a few) end users.
Enable transport of Ethernet frames over core network. Each BoD service instance will carry Ethernet
frames received from the end user. An example technology that can do that is Virtual Leased Line
(called Virtual Private Wire Service) or L2 Circuit. The core network should be ready to carry end user
jumbo frames with size of 9000 bytes (excluding FCS field).
Assure that in your domain frames are not dropped. It is recommended to provide MFLR (Maximum
Frame Lost Rate) at lowest level as possible.
Provide high availability for the service by enabling redundant paths in the core network.
The domain must support to carry at least untagged Ethernet frames received from the end user. This
mode is called ETS-Untagged. It is recommended that the domain will support ETS-VLAN, ETS-PortTransparent and ETS-VLAN-to-Untagged transport modes.
Path provisioning
1) The domain should run a dynamic provisioning tool in order to provide more prompt and advanced
circuit provisioning. An example of dynamic provisioning tool is AutoBAHN. More information about
how to install this tool can be found at https://forge.GÉANT.net/forge/display/autobahn/Home.
2) The dynamic provisioning tool must be able to configure network devices in the participating domain.
The way that the dynamic provisioning tool can interact with network devices depends on the hardware
platform and any dynamic provisioning tool used inside by the domain.. The participating domain is free
to define policies for creation and maintenance of BoD connections provisioned by automatic
provisioning tool (for example VID range, VC IDs, connection naming scheme etc.).
3) The end user should be able to request the service over web portal/page. Therefore it is recommended
to create such portal if automatic provisioning tool does not offer that functionality. For example
AutoBAHN system provides web access for the end users.
3.3
Monitoring
1) Some monitoring functionality is required in order to deliver basic information about service usage and
parameters. Some of this information should be presented to the end users and participating domains.
The perfSONAR system will be enhanced for that purpose. More information about perfSONAR can be
found at http://www.perfsonar.net/.
Monitoring functionality is not implemented in the current version of the BoD service, however at the time of
writing this is under development. Please consult the Bandwidth on Demand Roadmap document for more
details.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
22
3.4
AAI
1) One of the main features of the BoD service is to allow the end user to request the service followed by
the automatic provisioning process. Because of the impact of this process on the production network
the end users must be properly authenticated and authorized before placing the request. Participating
domains must create and maintain a database of end users that will be allowed to place requests with
the BoD Service. This should be done very carefully because the other end point of the service can be
located outside of participating domain (so it will have influence on network devices in other domains).
An example of how to achieve this is to use AutoBAHN system and eduGAIN. More information about
eduGAIN can be found at http://www.edugain.org/.
2) The usernames and password should be distributed over appropriate end users.
3.5
Accounting
1) The participating domain must be able to account for service usage. It is recommended to collect
usage statistics (number of sent/received frames on SDPs and SSPs) and availability (uptime/duration)
for each service instance. Tools used by the domain internally can provide this functionality. However
some data should be ready to share with other domains.
3.6
Service desk
1) The end user should be able to contact its domain administrator in order to request help when this is
needed. Therefore a service desk must be defined to support the end users.
2) The Service Desk should be available at least within normal working hours.
3.7
Support teams
The participating domain must maintain teams that will support the operation and maintenance of all systems
required by the BoD service. In other words each domain should incorporate all systems and infrastructure
needed by the BoD service within its supporting scheme and procedures. There is no requirement to maintain
dedicated teams only for the BoD service.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
23
Appendix A Service Management Procedures
This chapter explains the steps that are needed in order to participate in the service offering.
A.1
Participation of a domain in the BoD Service Area
(Initialization)
When a domain that adheres to the requirements of the BoD Service joins the BoD Service Area, the following
initialization procedures are required in order to make the BoD Service functional for this domain.

Service Desk contact information should be published to GN3 Community and relevant End Users

Network resources must be registered to the Provisioning tool and optionally to the Domain Topology
Discovery tool (network resources information may be inserted manually in Domain Topology
Discovery tool by the domain operator)

Collect SDPs and SSPs present in the domain and their capabilities in the Domain Topology Discovery
tool (this function may be done manually by BoD domain operator)

Each BoD domain publishes a list of collected SDPs and SSPs to neighbouring BoD domains using
Inter-Domain Topology Exchange service provided by Provisioning tool (so that every domain
Provisioning tool will have knowledge about all SDPs/SSPs present in the GN3 BoD service federation)

Collect End Users/Operator identities and their network resources access policies for Authentication
and Authorization service of AAI tool
A.2
Service functions procedures
The following is a list of procedures for most important functions:
A.2.1
Service setup
Ordering a dynamic E2E link is usually performed via a service portal (web GUI). The users of the service are
required to be authenticated and authorized by a central system or by a federated authentication/authorization
mechanism. If AutoBAHN is used (IDM, DM, TP) users must login to the AutoBAHN service portal.
Short description
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
24
An end user from a source domain logs in to the link reservation system via a service portal (web GUI). The
user requests a new reservation by selecting the reservation details. Those include:

Start point (usually in source domain)

End point (in destination domain)

Duration (Future reservation scheduling is possible If AutoBAHN is used)

Bandwidth

MTU

VLANs

QoS (may apply for some reservation systems)
Once the request is submitted the user receives some feedback from the reservation system regarding the
reservation status. In the case of failure the user should receive sufficient information regarding the cause of
failure.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
25
Figure 3 Procedure Diagram for ordering a dynamic E2E link
Description of the procedure

The user logs in the BoD service Access Interface and is authenticated by the AAI Infrastructure tool

The user is presented with a list of all domains in the BoD federation and all available SDPs. The user
selects the two SDPs and specifies the parameters of the request

The provisioning tool in the user’s domain receives the user request from the service web portal

The Pathfinding service of the Provisioning tool attempts to identify a list of domains and the
appropriate stitching points (SSPs) in a fashion that meets the user’s criteria and SLS.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
26

For each domain in the list of domains returned by the Pathfinding service, a request for intra-domain
transport is submitted using the Inter-Domain Connectivity service. Negotiation about the delimiters of
the SSPs may need to take place

Authorisation of the user request on the specific network resources may take place in the AAI tool of
each participating domain

If any domain indicates a service setup failure, the Provisioning tool should try to find an alternate path;
repeat until service setup is successful or no path is available

The Provisioning tool of each participating BoD domain configures network resources within its local
domain in order to create the BoD service

If service setup is successful, the Provisioning tool gathers OLAs from the participating domains in
order to calculate the SLS; the SLS is presented to the user (optional).

Accounting & Billing service may take place
A.2.2
Service modification
The modification of an already reserved E2E link implies the alteration of the reservation parameters and is
usually performed via a service portal (web GUI). The users of the service are required to be authenticated and
authorised by a central system or by a federated authentication/authorisation mechanism. Once logged in, the
user selects the reservation to be modified and proceeds to the desired parameter modifications. As AutoBAHN
and OSCARS do not support reservation modifications at this time, a section below describes the procedure to
be followed when AutoBAHN or OSCARS are used.
Short description
An end user from a source domain logs in to the link reservation system via a service portal (web GUI). The
user selects to modify an existing link reservation by selecting the desired reservation (usually through its
Unique Global Identifier). Parameter modifications include:

Duration

Bandwidth

MTU

VLAN

QoS (may apply for some reservation systems)
Once the modification request is submitted the user receives feedback regarding the modification status. In the
case of failure the user should receive sufficient information regarding the cause of failure.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
27
Figure 4 Procedure Diagram for modifiying an E2E dynamic link
Modifying a dynamic E2E link in AutoBAHN or OSCARS
The current versions of AutoBAHN and OSCARS do not support modification of reservation parameters. The
modification of parameters in AutoBAHN or OSCARS implies the removal of an existing reservation and the
creation of a new one with the same endpoints but with different parameters. To see details about the removal
of a request go through section Remove a Dynamic Link
Description of the procedure
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
28

The user logs in to the BoD service Access Interface and is authenticated by the AAI Infrastructure tool

The user is presented with a list of services. The user selects one of the active services and specifies
the new parameters for the selected service

The Provisioning tool within the user’s domain receives a user request from the service web portal

If required, the Pathfinding service calculates a new inter-domain path with constraints that match the
user’s new criteria

For each domain in the list of domains returned by the Pathfinding service, a request for intra-domain
transport is submitted using the Inter-Domain Connectivity service. Negotiation of the delimiters of the
SSPs may need to take place

Authorisation of the user request on the specific network resources may take place in the AAI tool of
each participating domain

If any domain indicates a service setup failure, the Provisioning tool should try to find an alternate path;
repeat until service setup is successful or no path is available

The Provisioning tool of each participating BoD domain configures the network resources of its local
domain in order to modify the BoD service

If service setup is successful, the Provisioning tool gathers OLAs from the participating domains in
order to calculate the SLS; the SLS is presented to the user (optional).

Accounting & Billing service may take place
A.2.3
Service termination
E2E link removal is usually performed automatically by the reservation system once the request reaches its
expiration date. However in some circumstances users may want an early reservation termination. Removing a
dynamic E2E link is usually performed via a service portal (web GUI). The users of the service are required to
be authenticated and authorised by a central system or by a federated authentication/authorisation mechanism.
Removal of a link implies the complete removal of the configuration from all the corresponding network devices.
In AutoBAHN terminology this action is called reservation cancellation. Once the cancellation is successful the
configuration that led to the emulated topology as depicted in the Ordering a dynamic E2E link section will be
removed and connectivity between the two ends will be lost.
Short description
An end user from a source domain logs in to the link reservation system via a service portal (web GUI). The
user selects to remove an existing reservation by selecting the reservation through its Unique Global Identifier
(label). Once the removal request is submitted the user receives feedback regarding the removal status. In the
case of request failure the user should receive sufficient information regarding the cause of failure
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
29
Figure 5 Procedure Diagram for removing a dynamic E2E link
Description of the procedure

The user logs in to the BoD service Access Interface and is authenticated by the AAI Infrastructure tool

The user is presented with a list of active services. The user selects one of the active services and
chooses the removal of that selected service

The Provisioning tool within the user’s domain receives a user request from the service web portal

For each domain in the list of domains participating in the service, a request for service termination is
submitted using the Inter-Domain Connectivity service
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
30

A.2.4
The Provisioning tool within each participating BoD domain configures the network resources of its
local domain in order to terminate the BoD service
Monitoring of an implemented service
Monitoring functionality is not implemented in the current version of the BoD service, however at the time of
writing this is under development. Please consult the Bandwidth on Demand Roadmap document for more
details.

The user logs in the BoD service Access Interface and is authenticated by the AAI Infrastructure tool

The user is presented with a list of their services gathered from the Provisioning service of the user’s
domain.

The user selects one of the active services and requests monitoring information related to the service

Path domain segments monitoring data is collected from the Monitoring service of each participating
domain

Optionally, end-to-end monitoring data is gathered from the ingress and egress domains

Gathered data is presented to the user
A.2.5
Service problems indication
Troubleshooting an issue with the BoD service invokes the procedure(s) that will lead to resolution of the issue.
The majority of the issues can be either data plane issues or control plane issues. Other issues may include
GUI issues, AAI issues, etc. In general, the procedures followed in each case have many similarities. What
changes is the nature of the problem that requires different handling.
Short description
In general, troubleshooting consists of the following steps:

Identify the nature of the problem

Locate the root cause

Resolve

In parallel, broadcast to MDSD and optionally to other domains' SDs
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
31
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
32
Monitoring of a data plane link (only available for Administrators)
Monitoring functionality is not implemented in the current version of the BoD service, however at the time of
writing this is under development. Please consult the Bandwidth on Demand Roadmap document for more
details.

The user logs in to the BoD service Access Interface and is authenticated by the AAI Infrastructure tool

The user is presented with a list of all data links present in the BoD domain. The user selects one of the
active services and requests monitoring information related to the service

Data link monitoring data is collected from the Monitoring service of the user’s domain

Gathered monitoring data is presented to the user
A.2.6
Schedule maintenance for a dynamic E2E link
As part of day-to-day NREN NOC operations, it is sometimes necessary to perform maintenance of network
equipment or changes/updates in Network Management applications. This section covers such instances, plus
outages or faults that affect the proper operation of the BoD service. Performing a maintenance (firmware
upgrades, faulty equipment replacement, topology changes, etc) which would affect an active circuit or prevent
the creation/removal of new/existing ones implies that a prior notification has to be sent out. The same applies
for cases where an outage or a fault occurs inside a domain. The recipient of this notification is primarily the
MDSD (Multi Domain Service Desk) and optionally all the affected parties.
Domain participating in BoD schedules a maintenance or suffers an outage or faults (service affecting
issues)
1. Typical cases of maintenance:
a. Firmware upgrades
b. Recabling
c.
Equipment replacement
2. Cases of outages:
a. Fibre cuts
b. Equipment failures
3. Cases of faults:
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
33
a. Equipment failures
Domain with service affecting issues traces affected services

Locate currently active affected services using the RS. Locate which services terminate in or pass
through the domain. Notify MDSD about them

If you cannot do so, contact the MDSD
Domain with service affecting issues traces affected domains

Locate which NRENs are affected by the upcoming maintenance or current outage/faults

Inform the MDSD and optionally, the affected domains about the maintenance-outage/faults. Using the
RS, locate which domains run active services that terminate in or pass through the domain.

If you cannot do so, contact the MDSD
MDSD disseminates outage/planned maintenance information

Receive a notification about an outage from a domain and figure out which domains are affected and
disseminate the information to those domains.

Place an entry in the MDSD Planned Maintenance Calendar
Domain performs the maintenance/handles the outage/faults

Using internal procedures
Notify MDSD about end of activity and outcome

Notify the MDSD and optionally all the affected parties' Service Desks about the outcome of the
maintenance or problem resolution

Ensure the affected services' proper operation has been restored
End of activity

The expected result of this procedure is the least possible downtime and/or errors to the service, plus
an operational BoD provisioning mechanism
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
34
Figure 6 Procedure diagram for scheduling a maintenance activity
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
35
Appendix B Related GÉANT Tools
For the establishment of the BoD service by the GN3 consortium a set of software tools are developed within
the GN3 project. Each tool is a software entity that implements one or a set of Supporting Services. Depending
on the type of the tool it may be completely isolated from other domains (like cNIS which is used for storing
internal domain topology) or there may be an instance of the tool in each of the domain (e.g. AutoBAHN or
perfSONAR) which communicates with other instances of the same tool. Every BoD domain can use tools
created by the GÉANT Consortium or deploy its own tool, if necessary, in order to substitute certain supporting
services with them. However, externally created tools must provide similar functionality and implement the
same services interfaces as specified in this document.
B.1
AutoBAHN
AutoBAHN is an Infrastructure Tool that enables automatic bandwidth provisioning across domains. The
AutoBAHN architecture involves two main entities – Domain Manager (DM) focused on single domain activities
and Inter-Domain Manager (IDM) which performs activities related to inter-domain aspects of bandwidth
reservation. Both entities have to be deployed within a domain to allow bandwidth reservations. To create
reservations according to user requests, AutoBAHN service needs to perform topology management and
pathfinding.
B.1.1
AutoBAHN for Intra-Domain Transport provisioning
If supported by domain infrastructure, AutoBAHN can be used to provision the transport service in participating
domain. Basing on End User request, AutoBAHN will take all required actions in order to implement the BoD
service part on domain infrastructure (i.e. intra-domain topology discovery (using cNIS), intra-domain
pathfinding and network equipment configuration). In order to start provisioning process AutoBAHN must meet
following requirements:

domain requirements and policies for access to the network devices configuration

Positive End User request verification
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
36
B.1.2
AutoBAHN for Inter-Domain Topology Distribution
AutoBAHN is performing Inter-Domain Topology Distribution with all neighbouring domains. The exchanged
topology contains a list of links which are abstracted intra-domain links between SSPs and SDPs located in the
domain (abstracted full mesh topology) and inter-domain links related to SSPs.
AutoBAHN is using its own non-standardized schema for representation of the topology, however in the future it
plans use more standardized approach - NMWG Control Plane Schema prepared in OFG organization which
can be used to carry the information of SDPs and SSPs. The schema describes a network topology as a set of
network entities like domains, nodes, ports and links (links can be recursive, which means a logical link may
consist of several physical links). It also allows giving additional information on switching capabilities like:
encoding type, MTU, VLAN-ID ranges or VLAN translation availability.
B.1.3
AutoBAHN for Inter-Domain Pathfinding service
Path finder module is an internal part of the AutoBAHN tool. Its main task is to find a path across multiple
domains that:

meets constraints of the request,

is authorized under credentials presented in the request, and

is available for the requested time window
Path Finder gets as an inter-domain topology information from routing engine, path availability information from
the internal calendar and constraints specified by the user (compliant to the parameters specified in “GN3
Bandwidth on Demand Service: Service Descriptions and Service Level Specification”, section 2.2 Transport
parameters).
B.1.4
AutoBAHN for service Inter-Domain Connectivity
If supported by domain infrastructure, AutoBAHN will take all required actions in order to setup SSP for each
BoD service instance. It is important to properly map SSP capabilities, limitations and requirements in
AutoBAHN system to avoid SSPs misconfiguration. Basing on domain recommendation, AutoBAHN will select
service delimiter on SSP (if required). The actions taken by AutoBAHN on SSP are similar to SDP setup.
Intra-Domain Transport services stitching is triggered by inter-domain signalization carried out by AutoBAHN
IDM module. AutoBAHN implements two schemas for inter-domain signalization:


Non-standardized internal schema,
IDCP protocol standardized by DICE group.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
37
B.1.5
AutoBAHN for Access Interface
AutoBAHN interface offers service creation and termination functions for End Users and Administrators.
B.2
cNIS
The aim of the Common Network Information Service (cNIS) is to provide a unified repository of all relevant
network information about a single administrative domain.
B.2.1
cNIS for Intra-Domain Transport topology discovery
cNIS is a single point of storage, but more than just a database. Apart from the internal functionality required for
populating, validating and updating the database, it has modules for analysing topology data and presenting
data in a client-specified format. cNIS can store topology data just for a domain's IP infrastructure, but also for
other network technologies (Ethernet, SDH). Automatic population is a significant feature of the cNIS, since it
simplifies the work of network administrators (domains and others). As a result, cNIS delivers a mechanism for
the automatic discovery of the IP, Ethernet and SDH technologies. It provides various modes of collecting
topology data (manual, semi-automatic, automatic) completed with appropriate mechanisms ensuring data
consistency. Network topology information can be analyzed and presented to cNIS clients in their specific
formats.
B.3
PerfSONAR
perfSONAR is multi-domain monitoring (MDM) service which has cross-domain monitoring capability and is
useful for intra-network and inter-network analysis. One of its main goals is to make it easier to solve end-toend performance problems on paths that cross multiple networks. For the first time, it is possible to access
network performance metrics from across multiple domains and to perform network monitoring actions in
different network domains.
B.3.1
PerfSONAR for Monitoring service
When considering monitoring of network parameters, the following scenarios are foreseen in PerfSONAR:
1. Monitoring of operational intra-domain paths to validate their status against relevant service
level agreements
2. Monitoring of operational intra-domain paths to allow external instances of BoD to perform
intra-domain data aggregation
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
38
The first scenario allows End Users to retrieve monitoring information and make a validation if agreed SLS has
been met. Monitored parameters are exposed by perfSONAR.
The second scenario assumes the whole monitoring information is being available for BoD service. BoD service
must performs an intra-domain data aggregation in order to present to the system operator a general overview
of the inter-domain path state and traffic characteristic without revealing confidential intra-domain information.
B.3.2
PerfSONAR for Access Interface
PerfSONAR interface offers service monitoring functions for End Users and Administrators.
B.4
EduGAIN
The EduGAIN service being developed in the GÉANT project, aims to establish a confederation of identity
providers, enabling member organisations associated with different federations to seamlessly and securely
exchange information as though they were part of the same national identity provider.
B.4.1
EduGAIN for authorization and authentication service
GN3 BoD service will use external Authorization and Authentication Infrastructure (AAI) to validate user
requests and to provide security of the service. eduGAIN will be used to authenticate the users. The purpose of
eduGAIN is to provide the means for achieving interoperation between different Authentication and
Authorisation Infrastructures (AAI). There are a number of AAI systems developed and in use on the national
(NREN) level. All AAI systems used in NRENs (like Shibboleth, PAPI, A-Select, simpleSAMLphp, RADIUS and
SOAP (SAML) based AAI) have similar goals: enabling the creation of a trusted environment where users can
be identified electronically via an Identity Management System. eduGAIN provides the technology necessary
for user to authenticate in home AAI and authorize by the visited Service Provider.
An additional functionality needs to be provided within AutoBAHN which will allow authorisation of the users
and access to information and resources at the domain level. This will give participating BoD domains more
control over usage of resources.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
39
Appendix C Indicative Functions of the Access
Interfaces
Table 1 and Table 2 contains list of all functions available for End User and Administrator respectively.
Functions are described in context of a graphical user interface interactive functionality and should be properly
mapped to strict Access Interface API protocol specification. Each function is gathering input parameters
provided by an user and provide result information for the user. By default parameters are mandatory but there
are also optional parameters. Graphical user interface is providing a context containing additional input
parameters (user identifier, service identifier etc.). Because functions descriptions are GUI oriented thus there
are suggestions for presenting to user links calling other functions which are contextually helpful.
Access Interface
function
Input parameters provided by the End User
Result of function
Account Management functions
Get End User’s
account information
User doesn’t need to provide parameters.
(The GUI context is providing the End User
identifier)
Edit End User account
information
End User account information:
 Login name (optional)
 End User name (optional)
 Password (optional)
 Organization (optional)
 Contact information (optional)
(The GUI context is providing the End User
identifier)
End User’s account information:
 Login name
 End User name
 Organization
 Home domain
 SDP to End User (?)
 Contact information
 Link to list of get End User
services function
Edit successful
Edit failure:
 Reason of failure
Service Management functions
Get list of all End
User’s services
Get service
information
User doesn’t need to provide parameters.
(need for some filtering mechanisms???).
(The GUI context is providing the End User
identifier)
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
List of services
Service information:
 information about SLS
 information about involved
BoD domains
 Information about involved
SSPs (??)
 reservation
creation
day/time
40



Service setup
Service modification
Service cancelation
BoD Service parameters:
 Ingress SDP (Optional?)
 Egress SDP
 Bandwidth
 Ingress VLAN tag (Optional)
 Egress VLAN tag (Optional)
 Start time (?)
 End time
 Transport mode
 more parameters????
(The context is providing the End User
identifier)
New BoD service parameters:
 Bandwidth (Mandatory)
 Start time (?)
 End time
 Ingress VLAN tag (Optional)
 Egress VLAN tag (Optional)
 Transport mode
 more parameters????
(The GUI context is providing the service
identifier)
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
Get service end-toend monitoring
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
Get service segments
monitoring
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
reservation end day/time
Service cost (?)
User which requested the
service
 (optional) link to get
service
end-to-end
monitoring function
 (optional) link to get
service
segments
monitoring function
 Link
to
get
service
reported
problems
function
Setup successful:
 setup time
 link
to
get
service
information function
Setup failed:
 reason of failure
 link to report service
problem function
Modification Successful:
 setup time
 link
to
get
service
information function
Modification failed:
 reason of failure
 link to report service
problem function
Termination successful:
 termination time/duration
Termination failed:
 reason of failure
 link to report service
problem function
 link
to
get
service
information function
Monitored parameters:
 Connectivity status
 Mean end-to-end delay
 Service
bandwidth
utilization
 Frame loss
Monitored parameters:
 Connectivity status
 Mean end-to-end delay
41


Service
utilization
Frame loss
bandwidth
Problem management functions
Report service
problem
End User provides service problem description.
(The GUI context is providing the service
identifier)
Get service reported
problems
Filtering parameters:
 Time period (day, week, month, year)
 Pending
 Solved
(The GUI context is providing the service
identifier)
User doesn’t need to provide parameters.
(The GUI context is providing the service
reported problem identifier)
Get service reported
problem
Add service problem
response
End User provides additional response to
service problem.
(The GUI context is providing the service
problem entry identifier)
Reporting successful:
 Pending status
report
Report failure:
 reason of failure
List of reported problems
of
the
Service reported problem entry:
 End
User
problem
description
 Administrators/End User
responses
 Problem status
 Link to add service
problem response function
 Link
to
get
service
information function
Reporting successful:
 status of the report
Report failure:
 reason of failure
Table 1 End User functions provided via Access Interface service
Access Interface
function
Input parameters for the Administrator
Result of function
Account Management functions
Get Administrator’s
account information
User doesn’t need to provide parameters.
(The GUI context is providing the Administrator
identifier)
Edit Administrator
account information
Administrator information:
 Login name (optional)
 Administrator Name (optional)
 Password (optional)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
Administrator’s
account
information:
 Login name
 Administrator Name
 Domain
 Contact info
Administration Role
Edit successful
Edit failure:
 Reason of failure
42
Get list of all End
Users
Get End User
information
Add End User
Edit End User
information
 Domain (optional)
 Contact info (optional)
(The GUI context is providing the Administrator
identifier)
Filtering parameters:
 Home domain (is only local BoD
domain allowed?)
End User’s account information:
 Login name
 End User name
 Organization
 Home domain
 SDP to End User (?)
 Contact info
 Link to list of End User services
(The GUI context is providing the End User
identifier)
End User account information:
 Login name
 End User name (optional)
 Organization (optional)
 Home domain (optional)
 SDP to End User (optional?)
 Contact info (optional)
End User account information:
 Login name (optional)
 End User name (optional)
 Organization (optional)
 Home domain (optional)
 SDP to End User (optional?)
 Contact info (optional)
(The GUI context is providing the End User
identifier)
List of End Users
Edit successful
Edit failure:
 Reason of failure
Edit successful
Edit failure:
 Reason of failure
Edit successful
Edit failure:
 Reason of failure
Service Management functions
Get list of all services
Filtering parameters:
 Ingress domain
 Egress domain
 Domain participation
 User identifier
List of services
Get service
information
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
Service information:
 information about SLS
 information about involved
BoD domains
 information about involved
SSPs
 reservation
creation
day/time
 reservation end day/time
 service cost (?)
 User which requested the
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
43
service
Participating local BoD
domain links
 link to get service end-toend monitoring function
 link to get report service
problem function
 link
to
get
service
segments monitoring
 link to report service
problem function
 link to get service reported
problems link to report
service problem function
Setup successful:
 setup time/duration
 link to service information
Setup failed:
 reason of failure
 link to report service
problem function

Service setup
Service modification
Service cancelation
BoD Service parameters:
 Ingress SDP (Mandatory)
 Egress SDP (Mandatory)
 Bandwidth (Mandatory)
 Ingress VLAN tag (Optional)
 Egress VLAN tag (Optional)
 Start time (?)
 End time
 more parameters????
(The GUI context is providing the Administrator
identifier)
New BoD service parameters:
 Bandwidth (Mandatory)
 Ingress VLAN tag (Optional)
 Egress VLAN tag (Optional)
 Start time (?)
 End time (Optional)
 more parameters????
(The GUI context is providing the service
identifier)
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
Get service end-toend monitoring
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier)
Get service segments
monitoring
User doesn’t need to provide parameters.
(The GUI context is providing the service
identifier and BoD domain identifier)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
Modification Successful:
 setup time
 link to service information
Modification failed:
 reason of failure
 link to report service
problem function
Termination successful:
 termination time/duration
Termination failed:
 reason of failure
 link to report service
problem function
 link
to
get
service
information function
Monitored parameters:
 Connectivity status
 Mean end-to-end delay
 Service
bandwidth
utilization
 Frame loss
Monitored parameters:
 Connectivity status
 Mean end-to-end delay
 Service
bandwidth
utilization
44

Frame loss
Domain Management functions
Get list of BoD
domains in GN3
federation
User doesn’t need to provide parameters.
List of active BoD domains names
participating in GN3 BoD service
infrastructure
Get BoD domain
information
User doesn’t need to provide parameters.
(The GUI context is providing the BoD domain
identifier)
Edit BoD domain
information
Applicable after selecting a local BoD domain:
 Link to Edit list of SDPs
 Link to Edit list of SSPs
 Service Desk contact information
(The GUI context is providing the BoD domain
identifier)
Filtering parameters:
 Home BoD domain (is only local
domain allowed?)
User doesn’t need to provide parameters.
(The GUI context is providing the SDP
identifier)
BoD domain information:
 List of SSP
 List of SDP
 Service
Desk
contact
information
 Link to get BoD domain
services function
Edit successful
Edit failure:
 Reason of failure
Get list of SDPs
Get SDP information
Add SDP
Edit SDP information
Get list of SSPs
Get SSP information
Add SSP
Edit SSP information
Get list of local BoD
domain data plane
links
Get data plane link
(The GUI context is providing the BoD domain
identifier)
(The GUI context is providing the SDP
identifier)
Filtering parameters:
 Home BoD domain (is only local
domain allowed?)
User doesn’t need to provide parameters.
(The GUI context is providing the SSP
identifier)
(The GUI context is providing the BoD domain
identifier)
(The GUI context is providing the SSP
identifier)
Filtering parameters:
 Home BoD domain (is only local
domain allowed?)
User doesn’t need to provide parameters.
(The GUI context is providing the link identifier)
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
List of SDPs
SDP information:
 End User connected
 Active services
Add successful
Add failure:
 Reason of failure
Edit successful
Edit failure:
 Reason of failure
List of SSPs
SSP information:
 Neighbouring domain
 Active services
Add successful
Add failure:
 Reason of failure
Edit successful
Edit failure:
 Reason of failure
List of data plane links
Data plane link information:

45
information
Get data plane link
monitoring
User doesn’t need to provide parameters.
(The GUI context is providing the link identifier)
Data
plane
information:

link
monitoring
Problem (Ticketing) management functions
Get service reported
problems
Get service reported
problem
Filtering parameters:
 Time period (day, week, month, year)
 Pending
 Solved
(The GUI context is providing the service
identifier)
User doesn’t need to provide parameters.
(The GUI context is providing the service
reported problem identifier)
Edit service problem
status
New service problem status:
 Pending/solved
Add service problem
response
End User provides:
 additional response to service problem
 visibility of the response (total/all
service desk/ only local domain)
(The GUI context is providing the service
problem entry identifier)
Administrator provides:
 service problem description
 contact information (other BoD domain
Service Desk contact or End User
contact)
(The GUI context is providing the service
identifier)
Administrator chooses other contact to help
solve the problem:
 contact
information (Administrator
contact from local domain or Service
Desk of other domain)
Report service
problem
Join next Service
Desk contact to
service problem
List of reported problems entries
Service reported problem:
 End
User
problem
description
 Administrators/End User
responses list
 Problem status
 Link to add service
problem response function
 Link
to
get
service
information function
Edit successful
Edit failure:
 Reason of failure
Reporting successful:
 status of the report
Report failure:
 reason of failure
Reporting successful:
 Pending status
report
Report failure:
 reason of failure
of
the
Joining successful
Joining failure:
 Reason of failure
Table 2 Administrator functions provided via Access Interface service
The Access Interface must follow the requirements of the SDP naming scheme and AAA policies.
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
46
References
[DS2.1.1 ]
Deliverable on Multi Domain Connectivity Service
https://intranet.GÉANT.net/sites/Services/SA2/Deliverables/Lists/Deliverables%20List/Attachm
ents/2/GN3-10-126_DS2-1-1_Multi-Domain_Service_Architecture.pdf
[Service Description and SLS ]
Details of document that the reference marker is referring to (Including URL is available) e.g. S.
Ubik, V. Smotlacha, S. Trocha, S. Leinen, V. Jeliazkov, A. Friedl, “MS.3.7.5: Report on Passive
Monitoring Pilot”
http://www.GÉANT2.net/upload/pdf/GN2-08-191-MS3-7-5_Report_on_Passive_Monitoring.pdf
[NMCWG]
Network
[IDCP]
DICE IDC protocol description
[BoD Service Description]
BoD Service Descriptions and SLS
GN3 Bandwidth-on-Demand Service:
Joint Infrastructure and Operational
Level Agreement
Document Code:
47