D25 - Service TF contribution

thoughtlessskytopΔίκτυα και Επικοινωνίες

29 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

90 εμφανίσεις


IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
1

of
9

D25
-

Service TF contribution



Status and Version:


Version 7.0


Date of issue:

26.10.2005


Distribution:


Project Internal


Author(s):


Fabio Baroncelli


Barbara Martini


Piero Castoldi

SSSUP


Håkon Lønsethagen

Telenor

Reviewed by

Guillaume Juillot

Siemens

5


Service Supportive GMPLS Networks

5.1

Problem statement

5.1.1

Introduction

Architectural and technology evolution is opening the path to the revision of the definition of
the services provided by a transport network. In fact, the introduction of GMPLS co
ntrol
plane functionalities and the capability of optical switching in the core nodes enable
transport networks to provide automatic switched connectivity in mesh topologies, i.e. to
support dynamic connectivity. In addition, the appearance of client devic
es (e.g., routers,
storage devices and content servers) operating at optical line rates at network edge,
enables the optical transport technology to get closer to the customer offering a wider
range of bandwidths and services. This trend will open up new a
nd more flexible
opportunities regarding how the access segment and the metro edge segment are
connected, along with new ways of how service providers and network providers
interconnect and interact.

As a consequence, it appears that a transport network ma
y take profit from the ability to
support and fulfill service requests going beyond pure point
-
to
-
point connectivity services
and possibly including some requirements coming from the world of applications and
advanced network services (e.g. a VPN service,
i.e. a logical adjacency of nodes at a given
network layer, or a service requests that implies the flexible set up of several point
-
to
-
point
connectivity services or VPN services). These considerations highlight that transport
networks should be able, in t
he near future, to receive, handle and “dispatch” new complex
primitives.

To clarify the previous concepts we distinguish among:

• Network service: a (technology
-
dependent) connectivity service provided by the network
and thoroughly classified in both WP1
and WP4 [D2][D6].


IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
2

of
9

• Application service: a (possibly interactive) service that implies the set
-
up of one or more
network services and the logic needed for coordinating them (e.g. e
-
mail, storage, and on
-
demand streaming services).

In section 5.1.2 and 5.1.
3, the current UPI and UNI abilities are critically reviewed in order
to highlight their limitations with regard to the previous considerations.

In order to extend the capabilities of ASTN
-

or GMPLS
-
based solutions D18 provided high
-
level requirements that

should be considered when extending and improving the
architecture. In Section
5.2

architectural issues are identified and discussed with respect to
VPN service use cases. Section
5.3

elaborates on

the architectural issues and suggests
issues for further work.

5.1.2

Review of the User to Provider Interface (UPI)


The UPI (User to Provider Interface), as defined in NOBEL WP4, (Network Management
Interface as defined in most technical literature) is the int
erface dedicated to the interaction
between the management plane of a transport network and its client network.

So far, UPI was never standardized for a lack of interaction between different
standardization bodies (ITU
-
T proposed the X interface [M.3320])
and, currently, it is
implemented resorting to proprietary solutions or not implemented at all.

Currently, a client requests connectivity services to transport providers via fax, web
interface, mail etc. These interactions are error
-
prone and time
-
consumi
ng.

Another shortcoming of the UPI is related to the centralized paradigm adopted by the
network management: if each client interacts with a centralized managing entity, in a long
-
term perspective problems of scalability may arise.

Although, in a historic

perspective there are several shortcomings related to such a
management interface, new drivers are about to appear that could revitalize the “UPI”
discussion. The UPI interface is further considered below.

5.1.3

Review of the User to Network Interface (UNI)


Th
e ITU
-
T defines User to Network Interface (UNI) as “
a bi
-
directional signaling interface
between service requester and service provider control plane entities
” [G.807]. The
Optical
Internetworking Forum (OIF) and the Internet Engineering Task Force (IETF)
are currently
the most important standardization bodies that are working for the definition of a standard
UNI.

5.1.3.1

UNI OIF

The OIF defines UNI
for overlay networks

as “
the service control interface between the
transport network and the customer premise equipme
nt (CE)”

[OIF
-
UNI
-
01.0
-
R2]

(e.g., IP routers, ATM switches, Ethernet Switches, SDH/SONET Cross
-
connects).

The
OIF UNI version 1.0 is also referred as the “Public UNI”.

OIF defines five activities that are supported across the UNI:


IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
3

of
9



Connection establishment

(signaling)



Connection deletion (signaling)



Status exchange (signaling)



Auto
-
discovery (signaling)



Use (traffic)

The set of services associated with the creation and deletion of connections, the
connectivity monitoring, and the topology discovery are call
ed Network services [OIF
-
UNI
-
01.0
-
R2].

The OIF signaling and routing protocols over the UNI
have been developed as OIF specific
extensions to RSVP
-
TE, OSPF and LMP (that constitute the GMPLS protocol suite)
in
order to invoke services that the transport ne
twork offers to clients [OIF
-
UNI
-
01.0
-
R2]. The
UNI OIF is worldwide accepted. In fact, several vendors have presented OIF
-
compliant UNI
equipments. In addition, the UNI of the MUPBED project [MUPBED] is based on the
guidelines expressed in the OIF
-
UNI
-
01.0
-
R2 recommendation.

5.1.3.2

UNI IETF


The UNI OIF is based on an
OIF specific
extension of the GMPLS protocol suite. For this
reason it will not be able to meet the future requirements of GMPLS
-
compliant network
equipment. Hence a flexible, extensible, and fully G
MPLS
-
compliant UNI is being defined
by the Internet Engineering Task Force (IETF): the Private UNI
[Swallow]
.

The Private UNI enhances the interaction between the packet and transport network
control planes of multilayer network architecture. This interfa
ce is particularly suitable for a
control
-
plane interconnection model in which the equipment belongs to a common
administrative entity (i.e., a single carrier environment). Signaling sessions through the
Private UNI are used to invoke two main services tha
t require constructive coordination
between the network layers: provisioning and network recovery [Papadimitriou]. The IETF
UNI standardization activity is at the beginning. This is the reason why UNI IETF is not as
widely adopted as the UNI OIF.

5.1.4

Advantage
s of the UNI

The principal outstanding features of the UNI are:



Dynamic connectivity provisioning
: optical control planes have tight and real
-
time
access to the underlying network elements, as well as an accurate view of the
underlying network state.



Optim
al routing and bandwidth utilization
: the use of OSPF
-
TE routing and RSVP
-
TE bandwidth reservation schemes optimizes network resources. Sophisticated traffic
engineering algorithms and solutions provide high utilization of network resources.



Fast restorat
ion
: it is possible to dynamically discover a failure and, consequently, to
re
-
route a circuit.


IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
4

of
9

5.1.5

Drawbacks of the UNI

The UNI (both “OIF” and “IETF”) poses limitation on the characteristics of the network
services it can support:



UNI implies an intimate kno
wledge of the network since it is based on RSVP
-
TE /OSPF
protocols, whose handled entities refer to physical resources of the network.



It is impossible to address complex service requests, already highlighted in D18 like:



Set
-
up of an LSP if not issued by
the ingress node.



Complex connectivity requests (e.g. VPNs).



Interactive dialogs for VPN status enquiry (in terms of logical topology, resource
utilization).



Optimization of paths using extended set of network parameters and resource
description, from th
e perspective of an application services (e.g., network
-
awareness support for distributed applications).

The above drawbacks are partially due to the reduced set of features supported by the
RSVP
-
TE/OSPF and partially due to the intrinsic nature of these p
rotocols whose signaling
is propagated via neighboring nodes. In fact, the UNI approach for service provisioning
does not permit to trigger complex network services (such as VPNs), nor enables the
translation of an application services into its serving net
work services. In addition an
application service originated in a given node cannot be based on network services
originated in different nodes.

On the one hand, the improvement of the set of functionalities supported by RSVP
-
TE and
LMP could have a negati
ve impact on the scalability and the efficiency of the CP. On the
other hand, the abandonment of the RSVP/LMP protocol extension for the UNI implies the
loss of backward compatibility with the equipments, OIF


ITU
-
T compliant, already
operative in ASON/GM
PLS networks.

5.2

VPN network service


The establishment of a VPN involving more than 2 nodes is an example of network service
not based on a trivial composition of Point
-
to
-
Point connectivity services supported by the
current implementation of the Control Pla
ne. In fact the establishment of a VPN
requires to
deal with network connectivity operations (e.g., configuration, provisioning, and
management of the network elements) and also with security aspects (e.g., device
authentication, authorization, and securit
y policies).

In particular, the customer does not
usually deal with the technical aspects related to VPN provisioning because he prefers an
abstracted VPN service invocation, and the network operator itself does not allow the
knowledge of the inner technic
al details of its own network for security reasons.

For these reasons the customer may have benefits in setting up a VPN using a dedicated
interface for service requests thereby triggering either a manual or an automated
provisioning.

This section reviews

the solutions available nowadays for VPN provisioning in optical
networks. In particular, it identifies elements for both short/medium term and
long
-
term
solutions suitable for improving the scalability and the reliability of the current set
-
up

IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
5

of
9

procedures

and then it identifies, for each case, the service interface that permits customer
to request the establishment or modification of VPNs.

In the short/medium
-
term scenario a
ll the operations needed for setting up the service are
performed by the network m
anagement that fulfill the VPN requests by handling all
technical aspects related to the service provisioning
.
Currently, the customer interacts with
the network management for requesting services via a “human
-
based” interface (e.g., fax,
e
-
mail). The evol
ution towards a management interface for customer service provisioning
based on a network protocol will permit to support a basic level of machine
-
based
interaction thus addressing a faster service establishment and an easier change of service
parameters d
uring the provisioning period. This scenario concerns an evolution of the UPI,
as an interim service interface

In the long
-
term scenario a completely automatized service provisining supported by a
specific distributed entity is envisaged. In particular, th
is entity supports a dedicated service
interface towards the customer and it relies on the CP functionalities in order to fulfill
networks service requests without the explicit involvement of the management plane, thus
opening the path to a dynamic service

interaction. This scenario concerns the introduction
of a specific service interface, named User
-
to
-
Service (USI) interface.

5.2.1

VPN set
-
up via Management Plane



Figure
1
:
Short
-
medium term VPN request scenario


Figure
1

shows a use case where a customer can request a VPN service to the
Management Plane through the User to Provider Interface (UPI) that, in this context,
represents an implicit service interface.


IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
6

of
9

So far the interaction through UPI was based o
n written formal request to a management
operator that started all needed activity depending on the VPN
-
specific layer for configuring
on
-
site all involved network nodes.

In an automated scenario
a customer may use the UPI as a service
-
signaling interface
in
order to dynamically request a VPN service to the Network Management System (NMS) of
the transport network. The UPI can be implemented, for example, as a Web interface that
finally permits the customer to trigger an automatic procedure for VPN establish
ment or
modification.
NMS identifies the VPN involved nodes by discovering their network address,
resolves all the intra and inter domain issues in order to establish the requested
connectivity and than it generates proper configuration files in order to s
et up the network
elements through the management interface.

This service interface is based on an automated machine
-
machine interaction that
represents an improvement in customer
-
network interaction, still being based on a
centralized approach due the in
volvement of the NMS.

5.2.2

Towards a VPN service based on distributed service support
in optical networks



Figure
2
: Long
-
term VPN request scenario


The future success of VPNs depends also on the possibility offered to the customers
for a
dynamic setup and management of the VPN without dealing with the technology details
related to its implementation. This objective could be realized through an automated
process that exploits the distributed operation of a number of dedicated processe
s, called

IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
7

of
9

Service Entities (SE), that in turn rely on and interwork with GMPLS control functionalities
of the optical network, as shown in
Figure
2
.

The SE takes over the VPN request issued by the customer through

a dedicated service
interface named User to Service Interface (USI). The SE, through an exchange of
informative messages with the other SEs, can learn how to handle the request, identify the
nodes involved, translate identifiers into physical interface ad
dresses and finally it can set
up the network nodes exploiting the CP capabilities.

These distributed entities represent an improvement of the current Control Plane Elements
(CPE). In particular, the USI can be implemented as an enhancement of the UNI by
i
ntroducing, for example, new and powerful protocols ad
-
hoc for the VPN, similar to the
existing
Layer Two Tunnelling Protocol (L2TP)

already present in IP networks.

5.3

Architectural issues and further work

In a future perspective, the set of the distributed
SEs will not be limited to the automatic
provisioning of network services like advanced VPN services but it will also open the path
for the provisioning of application services for the direct benefit of the customer application
(e.g., TV broadcasting).

In
any case the objective of introducing the SE with its distributed approach, in conjunction
with the dedicated User Service Interface (USI), is more dynamic, interactive, and scalable
service capabilities and associated provisioning possibly also taking int
o account
application level knowledge. This permits to overcome the limits of the current service
provisioning implementation without the need to modify the already deployed CP and MP
functionalities.

Architectural issues have been indicated above and were

discussed in D18 on a general
level. In the following some more specific issues are pointed out. The main starting point
and hypothesis for the further work is the introduction of an USI that does not have a direct
dependency on the technology of the tran
sport plane UNI, and that allows the client to
communicate with a distributed SE.

The immediate issue is; what service capabilities should such an interface offer? The
origins of network service needs are either applications running at customer hosts or so
me
customer network resource and traffic engineering aware processes that may determine
when new services or changes to existing services are needed. Depending on the
customer network characteristics these processes might be best collocated with the CE or
with the Customer Network Management System (CNMS) or on some dedicated hardware
element hierarchically in between the CNMS and the CE. Observing this, it is reasonable to
believe that the USI should offer similar capabilities as the UNI but extended with
capabilities as indicated in the VPN use cases above.

To achieve greater flexibility of the location of the process invoking USI services a
dedicated “service usage agent” entity could be desirable. Furthermore, a modular design
of the USI should be attem
pted where more advanced capabilities can be added as
separate modules. State of the art technologies such as XML, SOAP and SIP should be
taken into account along with the advantages of their associated middleware capabilities.

It has been mentioned that t
he USI should also offer application level services. However,
we will limit the scope of the USI to application level services that are closely related to and
dependent on associated network services, such as file transfer services, storage services,
and c
ontent on
-
demand services. Thus, we will not take into account more high
-
level

IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
8

of
9

application services requiring a richer set of architectural elements that go beyond the
NOBEL focus on network services. However, the goal is to build a flexible and future
ori
ented USI architecture that such higher
-
level application services can be based on.

Furthermore, it is not anticipated that the USI will completely replace the UNI. The UNI
-
based approach will be sufficient and preferred in several cases. But UNI and USI m
ay live
side
-
by
-
side depending on per instance and case specific issues as well as backward
compatibility considerations.

The difference between UPI and USI is to some extent a matter of definition and
terminology as the USI cover several of the service c
apabilities that previously were
considered as candidates for a customer management (or user provider) interface. If a rich
set of capabilities are assumed to be provided by the USI interface, the distinction should
be that on one hand the USI interface is

dealing with session level services and service
capabilities. On the other hand the UPI is concerned with service management services
providing for instance SLA assurance, service usage statistics, customer policy
management and similar services.

There ar
e several architectural issues related to the provider side as well. These issues will
become more evident as one make a closer analysis of the specific capabilities needed for
what so far has been generically named service entities (SE). There are several

more or
less mature and upcoming architectural “patterns” or concepts that should be considered in
this respect. In the IETF the concept of Path Computation Element (PCE) is highly
relevant. PCE allows a more centrally but still distributed (e.g. per doma
in) handling of
topology and network state information. USI service processing collocated and associated
with PCE should be further explored in order to take benefit of the state information already
available in PCEs. Moreover, the work conducted by the IE
TF NSIS (Next Steps In
Signalling) working group must also be considered.

Furthermore, NGN and IMS
-
based service platform architectures should also be further
assessed. The NGN approach by ITU
-
T and ETSI is also focused on session oriented
services and ses
sion control capabilities. A pertinent question is, to what extent can the
NGN architecture be reused and extended for “next generation transport networks” and
their related services, taking into account the cost
-
saving potential that can be obtained by
re
using and adapting the NGN solutions. NGN makes a distinction between session control
capabilities handled by the IMS (IP Multimedia Subsystem) functional block and network
resource and admission control capabilities handled by the Resource Admission Contr
ol
Subsystem (RACS). These functional blocks can either be distributed or more centralized,
and typically the session control is more centralized than network resource control. This
distinction between session control and network resource control can be ap
plied to NOBEL
as well. Furthermore, careful comparison and analysis of RACS and PCE should be
performed looking for similarities and possibilities of reusing and “merging” RACS and PCE
functionalities to support USI processing.

NGN
-
based (inter
-
provider)
interconnection is an area that will get more attention as the
NGN approach matures. Again one should consider to what extent the NGN approach can
be reused, extended and adapted for the purpose of inter
-
carrier interconnection of next
generation transport

networks.

Several business models exist considering the service provider role and the network
provider role. Whether these roles are provided by to separate business actors or not and
properties of the network architecture will influence how these two ro
les should interact.
For instance, a service provider may run an IMS
-
based service platform that should be
allowed to request transport services from a network provider over a USI interface.

IST IP NOBEL "Next generation Optical
network for Broadband
European
Leadership"


Title of the document

thoughtlessskytop_2ff6e683
-
e516
-
4ee6
-
a55e
-
7d64b98e9808.doc





Version 1.0 (
30
-
Oct
-
13
)

Page
9

of
9

Depending on whether the transport service offered provides acces
s to the service provider
or “core” transport of services provided by means the IMS solution, different USI
capabilities may apply. Moreover, the case where the service provider and the network
provider is one and the same business unit should also be cons
idered. This case opens
the possibility of having one integrated service platform covering both the IP services
provisioning and control as well as provisioning and control of the transport network
services.


REFERENCES


[D2] Nobel WP4 Deliverable 2 “Defin
ition of Network Management and Control
requirements of network scenarios and solutions supporting Broadband Services for All”


[D6] Nobel WP1 Deliverable 6 “Preliminary definition of drivers and requirements for core
and metro networks supporting end
-
to
-
end broadband services for all”


[Swallow] G. Swallow, J. Drake “Generalize Multiprotocol Label Switching (GMPLS) User
-
Network Interface (UNI): Resource ReserVation Protocol
-
Traffic Engineering (RSVP
-
TE)
Support for the Overlay Model” IETF draft
-
ietf
-
ccamp
-
gmpls
-
overlay
-
05.txt.


[Papadimitriou] D. Papadimitriou,


B. Rousseau,


W. Körber,


S. Brockmann, and D.
Verchère,

"The Private User Network Interface
-
a GMPLS
-
compliant signaling interface for
overlay
-
based multilayer networks," J. Opt. Netw. 3, 119
-
132 (
2004).

[M.3320] “Recommendation M.3320, Management requirements for the TMN X
-
interface”,
ITU
-
T, March 1997.

[OIF
-
UNI
-
01.0
-
R2] Recom.
OIF UNI Ver.1.0 ‘User Network Interface (UNI) 1.0 Signling
Specification” October 2001

[MUPBED] P. Szegedi, “Delay Models

for Different UNI Signalling Implementations in the
Context of IST Project MUPBED”, 7th International Conference on Transport Optical
Networks, Barcelona, Spain, July 3
-
7, 2005