(Orange Group,4 rue du Clos Courtel,Cesson⁃Sévigné,35512,France)

Service Parameter Exposure and Dynamic Service Negotiation in SDN Environmenttss

M.Boucadair and C.Jacquenet

(Orange Group,4 rue du Clos Courtel,Cesson⁃Sévigné,35512,France)

Software⁃defined networking(SDN)is a generic term and one of the major interests of the telecoms industry(and beyond)over the past two years.However,defining SDN is a somewhat controversial exercise.The claimed flexibility,as well as other presumed as⁃sets of SDN,should be carefully investigated.In particular,the use of SDN to dynamically provision network services suggests the introduction of a certain level of automation in the overall network service delivery process,from service parameter negotiation to delivery and operation.This paper aims to clarify the SDN landscape and focuses on two main aspects of the SDN framework:net⁃work abstraction,and dynamic parameter exposure and negotiation.

software⁃defined networking(SDN);service parameter exposure and negotiation;network operation automation;autonomic network⁃ing

1 Introduction

Software⁃defined networking(SDN)has become one of the hottest topics in the telecoms industry over the past two years.Although the definition of SDN is con⁃tested,there seems to be rough consensus within the Internet community that SDN promises dynamically program⁃mable,configurable,responsive networks for optimized,some⁃what automated network service delivery and operation.

This paper gives a network provider’s view of some of the techniques under the SDN umbrella that may be used to intro⁃duce a high degree of automation in the preliminary stages of a typical network service lifecycle.This paper describes the dy⁃namic negotiation of service parameters which,when complet⁃ed,feed the computing intelligence of an SDN architecture so that corresponding resources can be allocated and appropriate policies can be enforced.

The ability to dynamically expose and negotiate the set of pa⁃rameters that pertain to a given network service is promising and should help introduce a high degree of automation in the overall service⁃delivery procedure.This will,in turn,facilitate the use of autonomic networking techniques.Currently,most if not all existing network services typically delivered over an In⁃ternet Protocol/Multiprotocol Label Switching(IP/MPLS)infra⁃structure assume little or no negotiation besides price negotia⁃tion,if any.A customer is presented with a set of services theymay want to subscribe to(e.g.,a basic Internet service or VPN service),but the service parameters are hardly detailed.

Most residential customers are unlikely to care about the technical details that define the service they have subscribed to as long as they can access the service with a perceived,of⁃ten qualitative,QoS.Nevertheless,there are other customers, such as corporate customers or peering network providers,who pay attention to the quantitative definition of the service they have subscribed to as well as the possible penalties for failure to adhere to the terms of the contract.With these kinds of cus⁃tomers,negotiation is often static.Service parameters may vary from one customer to another and from one service to another. There are often long negotiations between when the service pro⁃duction chain kicks in(and the long⁃awaited order is pro⁃cessed)and when the service is actually delivered.

There is therefore a need to automate the service parameter exposure and negotiation procedure somewhat.Service parame⁃ter exposure is 1)the process of capturing the service require⁃ments of an application or customer and 2)presenting the bene⁃fits of an underlying infrastructure to a service and customer. Service parameter negotiation involves a customer and network provider mapping the customer’s service requirements with the underlying network capabilities.We believe such an ad⁃vanced procedure requires a standard template that details all the service parameters that may be valued as a function of the service to be delivered,which must conform to the customer’s expectations.

In this paper,a network provider is the entity that owns and

administers one or many transport domain(s)and is responsi⁃ble for ensuring connectivity services(e.g.,offering global or restricted reachability).A customer subscribes to a service of⁃fered by a provider.

The paper is organized as follows:In section 2,we introduce SDN and the techniques we believe it encompasses.In section 3,we introduce connectivity provisioning profile(CPP)[1], which facilitates the exposure and negotiation of service param⁃eters.In section 4,we discuss Connectivity Provisioning Nego⁃tiation Protocol(CPNP)[2],which is one of the candidate proto⁃cols for conveying service parameter negotiation arguments be⁃tween two parties(typically a customer and network provider). In section 5,we outline additional areas of investigation that complement the dynamic negotiation of service parameters. These areas are SDN bootstrapping procedures and dynamic service structuring based on ordered sets of elementary service functions,also known as service function chaining(SFC)[3].

2 Introduction to Software-Defined Networking

2.1 Global Framework

Networking environments generally have three planes:for⁃warding,control,and management.Each of these planes sup⁃ports various features,e.g.,forwarding and routing,traffic engi⁃neering(TE),and security and management.

These capabilities need to be configured in the switches, routers,service platforms,etc.according to the services sup⁃ported by the network and,ideally,according to the customer’s requirements in terms of QoS,service robustness and avail⁃ability,and service resiliency.

In the case of inter⁃provider network services,implementing such capabilities involves exchanging(configur⁃ing)information via various protocols and interfac⁃es located between the forwarding,control,and management planes;between the customer and network(customer⁃to⁃network interface,CNI);and between two networks(inter⁃carrier interface,ICI) (Fig.1).

Subsequent network operations,such as the pro⁃cessing of a customer order,can be triggered by an application.Other network operations,such as connection of an additional site to a VPN infra⁃structure,can be triggered by customer requests. And yet other network operations can be triggered by internal service engineering modules,e.g.,with⁃in the context of a maintenance period.Any combi⁃nation of these is also possible.The configuration information used by participating devices to deliv⁃er a service is the product of various combined in⁃puts and includes:

·The actual capabilities supported by the partici⁃ pating devices.

·The completion of the service⁃parameter negotiation be⁃tween the customer and the provider,which conforms to cus⁃tomer’s requirements and network resource information. Such parameters often follow the guidelines of business de⁃velopment teams.Service parameters can be negotiated ac⁃cording to a specific template,such as a CPP template de⁃tailed in section 3.

·The traffic forecasts that can be derived from the number of CPP templates that need to be processed over different time scales(a minute,a day,etc.)but which also relate to the net⁃work planning policy that needs to be enforced over several years.

·The number and the nature of the various,possibly service⁃specific policies enforced by the network provider.Such pol⁃icies may not only rely on the device capabilities or informa⁃tion derived from the customer requirements;they may also reflect technology⁃specific recommendations.

2.2 From Service Subscription to Delivery and Operation

Fig.1 shows a service⁃structuring layer that is meant to doc⁃ument the nature of the service,including its scope and associ⁃ated parameters.This service⁃structuring layer is where negoti⁃ation between the customer and network provider takes place [4].

The management plane can then be seen as a substratum of the service⁃structuring layer,and the management layer is where management information is maintained.Such informa⁃tion is used according to the typical ISO⁃defined Specific Man⁃agement Functional Areas(SMFAs),i.e.,fault,configuration, accounting,performance and security management informa⁃tion,and is detailed in information and data models.

▲Figure 1.Three⁃plane representation of networking environments and related interfaces.

The control plane is where policy and management substra⁃

tums reside.These are designed to derive the outcomes of the CPP⁃formatted service parameter negotiation into policy⁃provi⁃sioning information,such as metrics to be assigned to link in⁃terfaces and constraints to be taken into account by,for exam⁃ple,a Constrained Shortest Path First(CSPF)[5]algorithm for TE policy enforcement.

Such policy⁃provisioning information can either be service⁃or customer⁃specific,depending on the nature and number of services that a customer can subscribe to.

This policy⁃provisioning information is then passed to net⁃work devices as configuration information so that the requested service can be delivered.The forwarding of this configuration information may rely upon a variety of protocols that include but are not limited to:

·OpenFlow,which is used exclusively to populate the for⁃warding information base(FIB)maintained by network de⁃vices and is now complemented by the NETCONF⁃based OpenFlow Management Configuration Protocol[6]

·Path Computation Element Communication Protocol(PCEP) [7],which is used in particular to provision VPN configura⁃tion information

·Network Configuration Protocol(NETCONF)[8]

·Common Open Policy Service(COPS)protocol,which isused in particular to support policy provisioning(COPS⁃PR) [9]

·Interface for Metadata Access Points(IF⁃MAP)[10]

2.3 The Deterministic Nature of Dynamic Network Operation Procedures

In physics,determinism refers to the principle that the val⁃ues of a system’s variables at a given time determine the val⁃ues of the same variables at a later time.

In SDN,determinism is a key feature of dynamic,(possibly) automated service⁃delivery procedures.It is expected that re⁃sources and policies used to deliver and operate any given net⁃work service will derive from the service parameters that have been negotiated between the customer and network provider.

Indeed,the behavior of systems deployed into operational networks should be predictable and controlled.The outputs and states of those systems should be deterministic and with⁃out unexpected behavior,which risks provoking chaotic situa⁃tions.

From a deterministic standpoint,a high degree of automa⁃tion can be introduced into a system only if automation relies on well⁃known,carefully designed procedures.Such proce⁃dures can be decomposed into state machines,policies,etc., which reflect the different behaviors of the system under vari⁃ous conditions.This means that how the service/network be⁃haves in certain circumstances,with particular entries,is known in advance,and the expected result of such behavior is predictable and deterministic.

The path to full network automation is paved with numerous challenges.In particular,it is critically important that automa⁃ tion is well implemented in order to facilitate testing,including validation checks,and troubleshooting.This suggests the need for simulation tools that accurately assess the impact of intro⁃ducing high⁃level automation into the overall service delivery procedure and avoid the typical“mad robot”syndrome.This syndrome recently made some Google services unreachable. On January 24,2014,most Google users who subscribed to log⁃in services such as Gmail,Google+,Calendar,and Documents were unable to access those services for approximately 25 min⁃utes.For about 10 percent of users,the problem persisted for as long as another 30 minutes.

This recent event further emphasizes the need for a network automation system that relies on deterministic behaviors that can be used during service operation cycles.The behavior ex⁃hibited under normal operating conditions should be the input to such an automation system in order to,for example,assess whether a service is up and running as expected.The automa⁃tion system must also integrate a feedback loop to assess whether policies are properly enforced and whether the set of policies is consistent with service objectives.The automation system can be pre⁃wired to indicate how it will react when a problem occurs.This deterministic assessment capability can also be implemented inside the supervision system in order to improve fault detection.

The recent Google misadventure is a lesson that should not be forgotten by SDN proponents who claim that service flexibil⁃ity and agility come at no cost.Automation is where the com⁃plexity resides,and so⁃called“service orchestration intelli⁃gence”should not be solicited,regardless of the nature and number of services to be delivered,without accurate modeling of predictable behaviors.

Fig.2shows the service lifecycle and control loops that should be implemented in order to assess whether an engi⁃neered service matches the service objectives,as expressed by

business development teams,or customers.

▲Figure 2.The importance of control loops.

Fig.2 shows an example of the steps for delivering a service. The challenge facing a network provider is to deliver a service that corresponds to the“measured service”level and that ful⁃fils the clauses of a targeted service.The targeted service level is technology⁃agnostic;that is,it is described as a set of ser⁃vice requirements that are translated into and accommodated within an architectural and technological view during the de⁃signed⁃service phase.

Once this is accomplished,suitable engineering rules are written up,and the required configuration information is de⁃rived.This is the engineered service stage.The advent of SDN contributes to a high level of automation in each step of the ser⁃vice lifecycle.

Completion of the service⁃parameter negotiation phase,or a dedicated trigger received from an application[11],including an internal application managed by the same provider[12],pro⁃vide input to the SDN intelligence so that the corresponding service can then be structured according to the service⁃specif⁃ic policy⁃provisioning information derived from the negotiation.

Such policy⁃provisioning information is then translated into device⁃specific configuration information.Upon completion of these configuration tasks,the service is delivered to the cus⁃tomer in a completely deterministic manner.

During service operation,certain techniques are used for service fulfillment and assurance.In particular,monitoring techniques are used to verify that policies are properly en⁃forced and to ensure that the delivered service complies with the outcomes of a negotiation with the customer,or what has been requested by a customer(in the case of a subscription mode),or what has been requested by internal business devel⁃opment teams.

2.4 A Tentative Definition of Software-Defined Networking

Fig.1 underscores some of the current discussions related to SDN.The so⁃called separation of forwarding and control planes,beyond implementation considerations,has almost be⁃come a gimmick to promote flexibility as a key feature of SDN.

Flexibility,which is heavily touted by SDN promoters,is un⁃doubtedly a key objective for network providers.The ability to adapt to a wide range of customer requests and flexibly deliver network services is an important competitive advantage.How⁃ever,flexibility is much,much more than separating the con⁃trol and forwarding planes in order to facilitate forwarding deci⁃sion⁃making processes.

Here,we define SDN as the set of techniques used to facili⁃tate the design,delivery,and operation of network services in a deterministic,dynamic,scalable manner.

2.5 Meta-Functional Domains of Software-Defined Networking

Such a definition assumes a high level of automation in over⁃ all service delivery and operation procedures.From this per⁃spective,SDN techniques can be divided into the following functional meta⁃domains[13]:

·Techniques for dynamic discovery of network topology,de⁃vices,and capabilities along with relevant information mod⁃els that are precisely document such topology,devices,and capabilities.

·Techniques for dynamically exposing and negotiating ser⁃vice parameters,which are used to measure the level of qual⁃ity associated to the delivery of a given service or a combina⁃tion of services.These techniques are not only meant to be used in business roles(e.g.,by the customer)but also by ap⁃plications and services.We assume that these triggers can be implemented using a common information model(section 3) that reflects the set of service⁃inferred policies.These poli⁃cies are enforced by the network provider and ease the auto⁃mation of network operations through dynamically and auto⁃matically translating customer,application,and service con⁃nectivity requirements to network⁃management actions.

·Techniques used by dynamic resource allocation schemes and policy enforcement schemes derived from service re⁃quirements.These techniques include techniques for auto⁃matically setting traffic engineering objectives for a given network.

·Dynamic feedback mechanisms that assess how efficiently a given policy(or set of policies)is enforced from a service⁃ful⁃fillment and assurance perspective.Such feedback mecha⁃nisms have features such as self⁃tuning and autonomic ser⁃vice diagnosis and repair.

Several approaches can be taken with the proposed SDN framework:application⁃initiated network programming[11], CPP⁃inferred[1,section 1],or path computation element⁃based[7].

Here we focus on the second meta⁃domain mentioned above, and discuss the benefits and stakes in dynamic service parame⁃ter negotiation.

3 Exposing Network Services: The CPP Concept

Defining a clear interface between services,including third⁃party applications,and network layers has various advantages, such as rationalizing the engineering of network infrastruc⁃tures.The CPP interface is designed to expose and character⁃ize,in a technology⁃agnostic way,the IP transfer requirements that need to be met when invoking the IP transfer capabilities of a provider network.These requirements are then translated into IP/MPLS⁃related technical clauses that,for example,de⁃fine the class of service and specify the need for recovery means and control⁃plane protection.At a later stage,these clauses are addressed by the activation of adequate network features and technology⁃specific actions(e.g.,MPLS⁃TE),Re⁃source Reservation Protocol(RSVP),Open Shortest Path First

(OSPF)or Intermediate System to Intermediate System(IS⁃IS) configuration,etc.).

The CPP template is designed to capture connectivity needs and represent and value these requirements in a standardized way.Service⁃and customer⁃specific IP provisioning rules may dramatically increase of the number of IP transfer classes that need to be(pre)⁃engineered in the network.Instantiating each CPP into a distinct class of services should therefore be avoid⁃ed for the sake of performance and scalability.Application⁃ag⁃nostic IP provisioning is recommended because the require⁃ments and guarantees in the CPP determine which network class of service can be used.From this perspective,the CPP is used to design and engineer a limited number of generic class⁃es so that individual CPP documents,which capture the con⁃nectivity requirements of services,applications and Custom⁃ers,can be easily mapped to these classes.Fig.3 shows the connectivity⁃provisioning interfaces covered by CPP:customer⁃network service⁃network,and network⁃network.Services and applications using CPP via the service⁃network connectivity⁃provisioning interface may belong to the same administrative entity managing the underlying network or to a distinct admin⁃istrative entity managing the underlying network.

A generic CPP template facilitates 1)automation of service negotiation and activation processes,which thus accelerates service provisioning,2)setting of traffic objectives of TE func⁃tions and service⁃management functions by means of formal⁃ized parameters,and 3)improvement of service and network management systems with decision⁃making capabilities based on negotiated/offered CPPs.The CPP defines the set of IP/ MPLS transfer guarantees to be offered by the underlying trans⁃port network.It also defines capacity needs and reachability scope,i.e.,the set of destinations that can be reached from a customer site,within the context of a given service.Appropri⁃ate performance metrics,such as one⁃way delay or one⁃way packet delay variation,characterize the IP transfer service. Guarantees on availability and resiliency are also included in the CPP.Fig.4 shows the Routing Backus⁃Naur Form(RBNF) [14]format of the CPP template.

Some important CPP clauses are described below.A full de⁃scription of all CPP clauses can be found in[1].

A CPP must include the list of customer nodes,e.g.,CEs,to be connected to the underlying transport network.For each customer node,a border link or node belonging to the connec⁃tivity domain and connected to the customer node needs to be identified.Operations appropriate to the location of the custom⁃er node should be performed to retrieve the corresponding bor⁃der link or“provider node”(e.g.,PE).A customer node may be connected to several provider nodes,and multiple customer nodes may be connected to the same provider node.

▲Figure 3.Typical connectivity⁃provisioning interfaces.

The scope clause specifies the reachability of each of the in⁃volved customer nodes.The scope is a unidirectional parame⁃ter,and both directions should be described in the CPP.The reachability scope is the set of destination IP prefixes that can be reached from the customer site.Both global and restricted reachability scopes can be captured in the CPP.A restricted reachability scope means that global(i.e.,whole Internet) reachability is not allowed,and only a subset of destinations are reachable.

The QoS guarantee clause specifies performance metrics for the quality of IP transfer experienced by a flow crossing an IP transport infrastructure.This flow is issued by or destined for a (set of)customer node(s).IP performance metrics can be ex⁃pressed as qualitative or quantitative parameters.When quanti⁃tative metrics are used,maximum or average numerical values are provided together with a validity interval that should be in⁃dicated in the measurement method.

The availability guarantee clause specifies the percentage of time the IP performance guarantee applies.This clause can be expressed as maximum or average.The guarantee covers QoS deterioration,i.e.,IP transfer is available but it is below the agreed performance bounds;physical failure;or general ser⁃vice unavailability.

The capacity clause specifies the capacity that needs to be provided by the underlying network infrastructure.This capaci⁃ty is bound by a given scope and IP transfer performance guar⁃antees.The capacity may be expressed on a border link basis and for both directions,i.e.,incoming and outgoing.This clause includes a traffic limit up to which quantitative perfor⁃

mance is guaranteed.

The traffic⁃isolation clause specifies whether traffic issued by or destined for customer nodes should be isolated when crossing the network.This clause is translated into IP engineer⁃ing policies on activating dedicated tunnels that use IPsec,or establishing BGP/MPLS VPN facilities,or using a combination of these.Activated tunnels or facilities should be consistent with those used to provide guaranteed availability and perfor⁃mance.

The flow⁃identification clause specifies which information is used to identify the flows that need to be processed in the con⁃text of a given CPP.This identifier is used for traffic classifica⁃tion.A flow identifier may comprise source IP address,source port number,destination IP address,destination port number, DiffServ Code Point(DSCP)field,tail⁃end tunnel endpoint,or a combination of these.

4 Dynamic Resource Allocation According to Service Requirements

4.1 Connectivity Provisioning Negotiation Protocol

CPNP is designed to dynamically exchange and negotiate connectivity provisioning parameters between a customer and provider.CPNP is service⁃agnostic;that is,it can support addi⁃tional services,such as storage,as well as the base connectivi⁃ty service.CPNP is extensible because new methods and nego⁃tiation options can be defined as required.CPNP introduces automation into the service negotiation and activation proce⁃dures and thus benefits the overall service delivery process.

CPNP negotiation cycles can be triggered by connectivity re⁃quirements that are exposed by applications or explicitly re⁃quested by customers.Resource allocation and TE objectives can be derived from the outcomes of CPNP negotiation cycles. These TE objectives can be tweaked according to customer re⁃quests,available network capacity,and business development guidelines.CPNP can accommodate both technical and busi⁃ness⁃related requirements.It also supports various negotiation modes,including administrative validation operations.

4.2 CPNP Functional Elements

CPNP operations involve two main functional elements: CPNP client and CPNP server.

The CPNP client is a software instance that sends CPNP re⁃quests and receives CPNP responses.A CPNP client creates a quotation order,cancels a quotation order being negotiated, withdraws a pre⁃negotiated quotation order,or updates a pre⁃negotiated order.

The CPNP server is a software instance that receives CPNP requests and sends back CPNP responses.The CPNP server processes quotation orders,cancels a quotation order being ne⁃gotiated,and handles a quotation order withdrawal.

Several models can be used to locate the CPNP client and server functional elements.In one model,the customer deploys a CPNP client while the provider deploys one or several CPNP servers.In a second model,the customer does not enable any CPNP client,but the provider maintains a customer order man⁃agement portal instead.This model assumes that the same ad⁃ministrative entity,i.e.,network provider,is responsible for both the CPNP client and server.In such a model,the custom⁃er initiates connectivity⁃provisioning quotation(CPQ)orders via the portal,and appropriate CPNP messages are then gener⁃ated and sent to the relevant CPNP server.Once connectivity provisioning parameters have been negotiated and an order has been placed by the customer,network provisioning operations are initiated.

4.3 CPNP Customer Order Processing Models

There are three models for customer order processing:fro⁃zen,announcement,and negotiation.

In a frozen model,the customer cannot negotiate the parame⁃ters of the connectivity service provided.After consulting a ser⁃vice portfolio,the customer selects the offer they want to sub⁃scribe to and places the corresponding order with the provider. On the provider side,handling the order request is quite sim⁃ple because the service is not customized to the customer’s re⁃quirements.Rather,it is pre⁃designed to target a group of cus⁃tomers with similar requirements(and who therefore share the same CPP).

In an announcement model,the provider proceeds to the an⁃nouncement of a set of service templates.The customer can then initiate a negotiation cycle using these templates and pre⁃pare their request order.

In a negotiation model,the customer documents their re⁃quirements in a request for quotation,which is sent to one or several providers.These solicited providers then check wheth⁃er they can meet these requirements and get back to the cus⁃tomer,possibly with an offer that does not exactly satisfy cus⁃tomer’s requirements.The customer and provider then negoti⁃ate,and the customer places an order.

CPNP uses announcement and negotiation⁃based models.In particular,it uses a quotation order/offer/answer model where 1)the client specifies their requirements in a provisional quota⁃tion order(PQO);2)the server makes an offer that satisfies or partly satisfies these requirements,or it declines the PQO;and 3)the client either accepts or declines the offer.Fig.5 shows a typical CPNP negotiation cycle.

A CPNP transaction,comprising all CPNP messages,occurs between when the first request is sent by the client to the serv⁃er and when a final response is sent by the server to the client. This final response completes the transaction.The CPNP trans⁃action is bound by a CPNP session.Because multiple CPNP transactions can be maintained by the CPNP client,the client assigns an identifier to each active transaction.This identifier is denoted Transaction⁃ID and must be randomly assigned ac⁃cording to the best current practice for generating random num⁃bers.It must not be guessed easily.Transaction⁃ID is used in the validation of CPNP responses received by the client.

▲Figure 5.CPNP negotiation model.(a)1⁃step successful negotiation cycle,(b)1⁃step failed negotiation cycle,(c)N⁃step successful negotiation cycle,and(d)N⁃step failed ne⁃gotiation cycle.

There is only one offer/answer stage in a single CPNP trans⁃action.Nevertheless,multiple CPNP transactions can be han⁃dled by the CPNP client.

The CPNP server can be configured in several order⁃han⁃dling modes.In a fully automated mode,no action is required from the administrator when a service is requested.The CPNP server automatically makes decisions about received orders and generates corresponding quotations.In another mode, some or all CPNP server operations are subject to validation by an administrator.This mode requires the administrator to act on some or all requests received by the CPNP server.

The CPNP server may support the option of publishing avail⁃able services,which are exposed to customers.Dedicated tem⁃plates can be used for the purpose of announcing services.The CPNP client will use these templates to initiate its CPNP nego⁃tiation cycle.

Two key identifiers are used by the CPNP client and server: customer order and provider order.The customer order identifi⁃er is assigned by a CPNP client to uniquely identify an order among existing orders.This identifier is included by the CPNP client in all its CPNP messages.The provider order identifier is assigned by the CPNP server to uniquely identify an order among existing orders.

4.4 CPNP Operations

Table 1lists the operations supported by CPNP,which uses several kinds of connectivity provisioning documents(CPDs) (section 3).A requested CPD is a CPD included by a CPNP cli⁃ ent in a PROVISION request.An offered CPD is the document included by a CPNP server in an OFFER message.An offered CPD indicates that the server will accommodate all(or a subset of)the clauses in a requested CPD.The offer also has a validity date.If the CPNP client accepts the offer,the offered CPD is included in an ACCEPT message,and the document is called an Agreed CPD.The Agreed CPD is also in⁃cluded in an ACK message.

4.5 CPNP Client Behavior

To place a CPQ order,the CPNP client initiates a local order object,which has a unique identifier (Customer Order Identifier)that is assigned by the CPNP client.Then,the CPNP client generates a PROVISION request that includes the assigned iden⁃tifier,possibly an expected response date,Transac⁃tion⁃ID,and Requested CPD.The CPNP client may include additional information elements,such as“cost”or“setup purpose”negotiation options.The setup purpose clause may contain a request for con⁃nectivity only for testing purposes and only for a lim⁃ited period of time.The order can become perma⁃ nent if the customer is satisfied during the test period.

Once the request has been sent to the CPNP server,the CPNP client sets a timer to the expiration date,which is includ⁃ed in the PROVISION request.If the CPNP server has not an⁃swered before the retransmission timer expires,the CPNP cli⁃ent retransmits the request up to three times.If a FAIL mes⁃sage is retuned,the CPNP client may decide to make another request to the same CPNP server,cancel the local order,or contact another CPNP server.If an OFFER message is re⁃ceived,the CPNP client checks whether a PROCESSING mes⁃sage with the same Provider Order Identifier has been received from the CPNP Server.If a PROCESSING message was al⁃

ready received for the same order but the Provider Order Iden⁃tifier does not match the identifier included in the OFFER mes⁃sage,the CPNP client silently ignores the message.If a PRO⁃CESSING message with the same Provider Order Identifier was already received and matches the CPNP transaction identi⁃fier,the CPNP client changes the state of the order to OfferRe⁃ceived and sets a timer according to VALIDITY_DATE in the OFFER message.

▼Table 1.Operations supported by CPNP

If an offer is received from the CPNP server,the CPNP cli⁃ent decides whether it will accept or reject the offer.The CPNP client accepts the offer by generating an ACCEPT mes⁃sage,which confirms that the customer has agreed to subscribe to the offer in the OFFER message(Fig.6).The transaction is terminated if an ACK message is received from the server.If no ACK is received from the server,the client proceeds to re⁃transmit the ACCEPT message.

The CPNP client can reject the offer by sending a DECLINE message(Fig.7).If an offer is not acceptable to the CPNP cli⁃ent,it may decide to contact a new server or submit another or⁃der to the same server.

The CPNP client can withdraw a completed order by send⁃ing a WITHDRAW message.It can also update a completed or⁃der by sending an UPDATE message(Fig.8).

4.6 CPNP Server Behavior

▲Figure 6.A flow of a successful CPNP negotiation cycle.

▲Figure 7.An unsuccessful CPNP negotiation cycle.

When a PROVISION message is received from a CPNP cli⁃ent,the CPNP server stores the Transaction⁃ID,generates a Provider Order Identifier,and runs preliminary validation checks.Then,the CPNP server returns a PROCESSING mes⁃sage to notify the client that the quotation order has been re⁃ceived and is being processed.A PROCESSING message can include an expected offer date that tells the CPNP client when an offer will be proposed.The CPNP server runs a decision⁃making process to decide which offer best suits the received or⁃der.The CPNP server makes an offer before the expected offer date.

If the CPNP server can satisfy the request,it sends an OF⁃FER message to the client making the request.This message includes Transaction⁃ID,Customer Order Identifier(indicated in PROVISION),Provider Order Identifier generated for the or⁃der,a Nonce,the offered Connectivity Provisioning document, and an offer validity date(Fig.6).

If the CPNP server determines that additional resources from another network provider are needed to accommodate a quotation order,it creates a child/children PQO(s)and behaves as a CPNP client in order to negotiate a child/children PQO(s) with the partnering providers.Fig.9 shows CPNP messages ex⁃changed in such a case.

5 Additional Paths to Automated Service Delivery Procedures

5.1 SDN Bootstrapping

▲Figure 8.CPNP withdrawal.

▲Figure 9.Inter⁃provider CPNP negotiation cycle.

The means of dynamically discovering the functional capa⁃

bilities of devices to be programmed by SDN intelligence need to be provided.Acquiring information related to actual network capabilities will help structuring this intelligence so that poli⁃cy provisioning information can be derived accordingly.

Dynamic discovery may depend on the exchange of specific information via an Interior Gateway Protocol(IGP)or Border Gateway Protocol(BGP)between network devices or between network devices and SDN intelligence in legacy networks.This intelligence can also send unsolicited commands to network de⁃vices in order to acquire a description of their capabilities and derive network and service topologies accordingly.

SDN techniques could be used in IGP/BGP⁃free networking environments;however,in such environments,SDN bootstrap⁃ping still requires the following support capabilities:

·dynamic,resilient discovery of participating SDN nodes,in⁃cluding the SDN intelligence,and their respective capabili⁃ties.This assumes mutual authentication of the SDN intelli⁃gence and participating devices.The integrity of the informa⁃tion exchanged between the SDN intelligence and participat⁃ing devices during discovery must also be preserved.

·dynamic connection of the SDN intelligence to SDN⁃capable nodes and avoidance any forwarding loop

·dynamic enabling of network services as a function of device capabilities and(possibly)what has been dynamically nego⁃tiated between the customer and network provider

·dynamic checking of connectivity between the SDN intelli⁃gence and participating nodes and between participating nodes themselves so that a given network service or set of services can be delivered.

·dynamic assess to the reachability scope as a function of the service to be delivered.

·dynamic detection and diagnosis of failures so that correc⁃tive measures can be taken accordingly.

Likewise,the means of dynamically acquiring descriptive in⁃formation(including base configuration)of any network device that may participate in the delivery of a service should be pro⁃vided.This helps the SDN intelligence structure the services that can be delivered in light of various factors,such as avail⁃able resources and resource location.

In networking environments without IGP/BGP,a specific bootstrap protocol may be required to support the previously mentioned capabilities and proper SDN operation.There may also be a need for a specific additional network with discovery and connectivity features.

In particular,SDN design and operation in an IGP/BGP⁃free environment should provide performances similar to that of leg⁃acy environments that run an IGP and BGP.For example,the underlying network should remain operational even if connec⁃tion with the SDN intelligence is lost.

Furthermore,operators should assess the cost of introducing a new,specific bootstrap protocol compared to the cost of inte⁃grating the previously mentioned capabilities into existing IGP/ BGP machinery.

Because SDN⁃related features can be grafted into an exist⁃ing network infrastructure,they may not all be enabled at once from a bootstrapping perspective,so a gradual approach can be taken instead.A typical deployment example is using an SDN decision⁃making process as an emulation platform that helps network providers and operators make appropriate technical decisions before their actual deployment in the network.

5.2 Dynamic Service Function Chaining

The current model used by network providers to offer value⁃added services has reached its limits.This model relies on the invocation of advanced service functions in addition to basic forwarding and routing.Typical examples of such service func⁃tions include:NAT,NPTv6,SSL Offload,HOST_ID injection [15],HTTP header enrichment,cache content,and deep pack⁃et inspection.Managing and introducing these advanced ser⁃vice functions is hindered by the underlying physical topolo⁃gies.Furthermore,the model used to deploy these service func⁃tions in has a cascaded scheme.This is not optimal in terms of capex and performance.A technique called SFC[3]is a suit⁃able means of invocating a set of service functions in an order. In reference to the SDN framework in section 2,the SDN intel⁃ligence can embed the SFC structuring and orchestration func⁃tionality.

6 Conclusion

Beyond the current hype surrounding SDN there is a com⁃plex combination of multi⁃metric,service⁃dependent,computa⁃tion algorithms,negotiation protocols,and service⁃modeling languages that presents significant challenges for network pro⁃viders.

From service parameter exposure to delivery,it is true that automation;flexibility;and adaptive,self⁃tuning network infra⁃structures have increased complexity and sometimes led to per⁃formance degradation.Such impacts should be quantitatively and qualitatively assessed by network providers.

A dynamic service⁃parameter negotiation approach is still in its infancy,and various service⁃specific simulations and valida⁃tion studies will need to be conducted to refine critical dimen⁃sioning figures,e.g.,in terms of the amount of traffic ex⁃changed between a customer and provider during service⁃pa⁃rameter negotiation.

Furthermore,the robustness of SDN techniques should be analyzed and characterized.The amount of traffic to be ex⁃changed between the SDN intelligence and participating nodes and dynamic policy⁃enforcement schemes can lead to mad ro⁃bot situations similar to that recently experienced by Google.

Predictable behavior is key to efficient service⁃parameter ex⁃posure,negotiation,and subsequent translation into technology⁃specific provisioning information.This requires strictly deter⁃ministic approaches with carefully designed information and data models,test cases,and control operations as cornerstones.

To this end,network providers must play a key role in stan⁃dardizing such tools for the sake of global consistency.

[1]M.Boucadair,C.Jacquenet,and N.Wang,“IP/MPLS connectivity provisioning profile,”IETF,draft⁃boucadair⁃connectivity⁃provisioning⁃profile⁃05,Apr.2014.

[2]M.Boucadair and C.Jacquenet,“Connectivity provisioning negotiation protocol (CPNP),”IETF,draft⁃boucadair⁃connectivity⁃provisioning⁃protocol⁃01,Oct. 2013.

[3]M.Boucadair,C.Jacquenet,R.Parker,D.Lopez,J.Guichard,and C.Pignataro,“Service function chaining:framework&architecture,”IETF,draft⁃boucadair⁃sfc⁃framework⁃02,Feb.2014.

[4]TM Forum.(2014).IPsphere[Online].Available:http://www.tmforum.org/In⁃Depth/6918/home.html

[5]O.Younis,S.Fahmy,“Constraint⁃based routing in the internet:basic principles and recent research,”IEEE Communication Surveys&Tutorials,vol.5,no.1, pp.2-13,Dec.2009.doi:10.1109/COMST.2003.5342226.

[6]OpenFlow Management Configuration Protocol,ONF OF⁃CONFIG 1.1.1,Jan. 2013.

[7]K.Kumaki,T.Murai,and P.Jiang,“PCEP extensions for a BGP/MPLS IP⁃VPN,”IETF,draft⁃kumaki⁃murai⁃pce⁃pcep⁃extension⁃l3vpn⁃12.txt,Oct.2013.

[8]Network Configuration Protocol(NETCONF),IETF RFC 6241,Jun.2011.

[9]COPS Usage for Policy Provisioning(COPS⁃PR),IETF RFC 3084,Mar.2001.

[10]TCG.(2012,May).Trusted Network Connect IF⁃MAP(InterFace to Metadata Ac⁃cess Points)2.1 Specification[Online].Available:http://www.trustedcomputing⁃group.org/files/static_page_files/93869B41⁃1A4B⁃B294⁃D0C211E85C7CF901/ TNC_IFMAP_v2_1r20.pdf

[11]R.Penno,T.Reddy,M.Boucadair,D.Wing,and S.Vinapamula,“Application enabled SDN(A⁃SDN),”IETF,draft⁃penno⁃pcp⁃asdn⁃00,Sept.2013.

[12]MESCAL.(2005).Path Computation System[Online].Available:http://www.ist⁃ mescal.org/roadmap/pcs.html

[13]Software⁃Defined Networking:A Perspective From Within A Service Provider, IETF RFC 7149,Mar.2014.

[14]Routing Backus⁃Naur Form(RBNF):A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications,IETF RFC 5511,Apr.2009.

[15]Analysis of Potential Solutions for Revealing a Host Identifier(HOST_ID)in Shared Address Deployments,IETF RFC 6967,June 2013.

Manuscript received:2014⁃02⁃18

Biograpphhiieess

Mohamed Boucadair(mohamed.boucadair@orange.com)is a senior IP architect at France Telecom.He has worked for France Telecom R&D and has been part of the team working on VoIP services.He is now working at France Telecom corporate di⁃vision and is responsible for making recommendations on the evolution of IP/MPLS core networks.He has been involved in IST research projects,working on dynamic provisioning and inter⁃domain traffic engineering.He has published many journal articles and written extensively on these subject areas.Mr.Boucadair holds several patents on VoIP,IPv4 service continuity,IPv6,etc.

Christian Jacquenet(christian.jacquenet@orange.com)graduated from the Ecole Nationale Supérieure de Physique de Marseille,a French school of engineers.He joined Orange in 1989 and is currently the director of the Strategic Program Office for Advanced IP Networking.In particular,he is responsible of the Groupwise IPv6 Program that aims to define and drive enforcement of the Group’s IPv6 strategy.He has authored and co⁃authored several Internet drafts and RFCs in the field of dy⁃namic routing protocols and provisioning techniques.He has also authored and co⁃authored multiple papers and books on IP multicast,traffic engineering and auto⁃mated IP service provisioning techniques.

New Member ofZTE CommunicationsEditorial Board

Kun Yangreceived his PhD from the Department of Electronic&Electrical Engineering of University College London(UCL),UK.His MSc and BSc were in Computer Networks and Computer Science respectively,both from Jilin University,China.He is currently a Chair Pro⁃fessor in the School of Computer Science&Electronic Engineering,University of Essex,UK, and the Head of the Network Convergence Laboratory(NCL)in Essex.Before joining Essex at 2003 he worked at UCL as a Research Fellow on several EU projects such as FAIN,etc.His main research interests include wireless networks/communications,fixed mobile convergence, future Internet technology(such as network virtualization)and cloud computing/networking. He has published 150+papers in the above research areas.He serves on the editorial boards of both IEEE and non⁃IEEE journals(such as Wiley and Springer)and(co⁃)chairs of IEEE conferences.He has been actively involved in research projects funded by European Union(e. g.,PURSUIT),UK EPSRC(e.g.,PANDA),UK TSB(e.g.,PAL)and industries(e.g.,British Telecom).He is the Coordina⁃tor of EU FP7 Project EVANS and technical leader of several other EU FP7 projects.He is a UK EPSRC Peer Review College Member and is a research proposal review expert on research funding bodies from France,Norway,Canada,Singa⁃pore,Hong Kong,China,etc.He is one of the six Executive Committee Members of IEEE InterCloud Initiative.He is a Se⁃nior Member of IEEE and a Fellow of IET.

This work was supported in part by the EIT SOFTNETS Project.