Internet DRAFT - draft-carrozzo-pce-pcep-route-price
draft-carrozzo-pce-pcep-route-price
PCE Working Group G. Carrozzo
Internet-Draft G. Bernini
Intended status: Experimental G. Landi
Expires: September 5, 2012 Nextworks
March 4, 2012
PCEP extensions for the computation of route offers with price
draft-carrozzo-pce-pcep-route-price-00
Abstract
The PCE defined in RFC4655 is a functional entity generally confined
in the control plane to elaborate explicit optimal routes with
related costs to be installed as [G]MPLS tunnels/LSPs. The resulting
route cost(s)/metric(s) are Traffic Engineering indicators used by
the network administrator (carrier) to optimize the usage of its
network resources.
In this document a framework for the usage of PCE in cooperation with
the Network Service and Business Plane (NSBP) is proposed, along with
related PCEP extensions. The NSBP invokes this extended PCE (service
PCE) to trigger the computation of network service offers with
related price information. The price of a network connectivity
service generally depends on strategic factors, but it could also be
influenced by the amount of mobilized network resources (along the
route), the ingress/egress interfaces/PoPs, etc. Therefore, it could
be provided by an extended service-PCE as an additional route
information.
This document focuses on the extensions to the PCEP protocol in
support of the computation of route prices for intra- and inter-
domain network connectivity services. Mechanisms for elaborating and
retrieving price information in the PCE are vendor-specific and out
of the scope of this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Carrozzo, et al. Expires September 5, 2012 [Page 1]
Internet-Draft PCEP PRICE INFO March 2012
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Carrozzo, et al. Expires September 5, 2012 [Page 2]
Internet-Draft PCEP PRICE INFO March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology used in this document . . . . . . 4
3. Service-PCE framework . . . . . . . . . . . . . . . . . . . . 6
3.1. Route cost vs. route price . . . . . . . . . . . . . . . . 8
4. PCEP protocol extensions . . . . . . . . . . . . . . . . . . . 8
4.1. Price Request bit . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Processing rules . . . . . . . . . . . . . . . . . . . 10
4.2. PRICE-INFO Object . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Processing rules . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. PRICE INFO Object . . . . . . . . . . . . . . . . . . . . 14
6.2. RP Object Flag . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Carrozzo, et al. Expires September 5, 2012 [Page 3]
Internet-Draft PCEP PRICE INFO March 2012
1. Introduction
Carriers usually deploy traffic engineering (TE) technologies coupled
with network control plane (CP) protocol suites, such as the Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS), to
offer value added network connectivity services to their customers.
The constraint-based route computation is a key function for these
connectivity services, and it is executed by the Path Computation
Element (PCE) functional entity. The PCE architecture is defined in
[RFC4655] and allows the computation of network routes based on a
network graph; the graph is derived from the controlled network with
various means (e.g. IGP/EGP, other proprietary interfaces, etc.),
and can contain multi-domain, multi-region/multi-layer topology
information.
In general, the PCE function is completely confined in the control
plane to compute optimal inter-domain constrained explicit routes
(ERO) for (G)MPLS TE LSPs/tunnels. However, the computation and
instantiation of these tunnels in the Transport Plane (TP) is
preceded by mandatory phases of service/product offering, offer
composition and negotiation, which involve the service supplier(s)
and the final service end-customer (see TMF IPSPHERE Framework
[IPSPHERE]). These service phases are generally handled at the
management and business planes (OSS/BSS) only. However, control
plane functionalities like the PCE ones can definitely support in the
definition/specification of network connectivity offers within a
carrier network domain.
This document briefly introduces a framework for the usage of a PCE
for route offers (Service-PCE) and describes some extensions to the
PCEP protocol that allow the Network Service and Business Plane
(NSBP) to request the Service-PCE for the computation of network
service offers with related price information.
Mechanisms for elaborating and retrieving price information in the
Service-PCE are assumed to be vendor-specific and out of the scope of
this I-D.
2. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Moreover, the following terminology is used in this document.
Carrozzo, et al. Expires September 5, 2012 [Page 4]
Internet-Draft PCEP PRICE INFO March 2012
BSS: Business Support System.
Control Plane (CP): The CP performs the basic functions of
signaling, routing and resource discovery. These are essential
operations which allow for the automation of higher-level network
functions like connection establishment (i.e., path computation,
resource availability, verification and connection set-up and
tear-down), reconfiguration of signaled connections, and
connection restoration.
FCAPS: Fault, Configuration, Accounting, Performance, and Security
management.
GMPLS: Generalized Multiprotocol Label Switching.
Management Plane: The network management plane performs functions
like alarm reporting, system configuration and connection
provisioning for the network data and network control planes. The
complexity of the network management plane strongly depends on the
capabilities of the network control plane. In general the network
management plane performs FCAPS functionalities (Fault,
Configuration, Accounting, Performance, and Security management).
Where applicable the network management plane follows the TMN
architecture as described in [ITU-T M.3010].
NMS: Network Management System.
Network Service and Business Plane (NSBP): This plane refers to
functions related to the management and handling of network
product offerings, service specifications and service instances.
This can range from service specification and offer creation, to
their publishing, service instance request and handling.
Functions of this plane may also include customer-relationship
management and various functions related to operations support.
OSS: Operation Support System.
Parent PCE: As per [I-D.ietf-pce-hierarchy-fwk], a PCE responsible
for selecting a path across a parent domain and any number of
child domains by coordinating with child PCEs and examining a
topology map that shows domain inter-connectivity.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
Carrozzo, et al. Expires September 5, 2012 [Page 5]
Internet-Draft PCEP PRICE INFO March 2012
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
PCEP: Path Computation Element Communication Protocol.
Service PCE: A parent PCE interfaced to the NSBP for the computation
of route offers with price information. PCEP protocol is used to
implement the interface between NSBP and the Service PCE.
TE: Traffic Engineering.
TED: Traffic Engineering Database.
Transport Plane (TP): The transport plane performs various framing,
forwarding or switching, and the transportation of data blocks to
specific destinations. This plane identifies the set of data
bearing transport resources (possibly grouped into domains on a
policy or technology basis).
3. Service-PCE framework
The NSBP includes all the functions related to the management and
handling of network connectivity product offers, service
specifications and service instances from an operational and business
perspective ([IPSPHERE] [ETICS]). In particular, the NSBP controls/
coordinates the service specification and offer creation, publishes
these product offers, composes different offers for an end-to-end
service, and eventually triggers the instantiation and operation of
the final service
The constraint-based route computation functions provided by a PCE
can be very useful for the network connectivity offer creation. In
fact, the PCE can implement constraint-based route selection
procedures providing the requesting client also with route price
information tight to the route to be followed, the ingress/egress
endpoints, some policy data, etc.
A Path Computation Client (PCC) could be integrated in the NSBP, to
request route offer computation either on-demand (i.e. connectivity
offer tailored to a specific customer request at the NSBP interfaces)
or in-advance (i.e. pre-computation of a connectivity offer to be
stored in a catalogue-like function of the NSBP).
The standard PCE route request/response mechanisms based on PCEP is
applied in the Service- PCE as per [RFC4655] and [RFC5440].
Carrozzo, et al. Expires September 5, 2012 [Page 6]
Internet-Draft PCEP PRICE INFO March 2012
Moreover, the Service-PCE better adapts to extend the concept and
functionalities of a parent PCE ([I-D.ietf-pce-hierarchy-fwk]), as it
can be used for a group of child technological/administrative domains
within a carrier/Autonomous System, and the produced route offers can
be in the form of sparse multi-domain EROs.
-----------------------------------------------------------------
| |
| NETWORK SERVICE AND BUSINESS PLANE |
| ------- |
| | PCC | |
| ------- |
--------------------------------|--------------------------------
|
| PCEP
--------------------------------|--------------------------------
| Domain 4 (AS) | |
| ------------- |
| | Service-PCE | |
| ------------- |
| / | \ |
| PCEP ~~~~/~~~~~~~~~~~~|~~~~~\~~~~ PCEP |
| / | \ |
| ---------------- / ------------|--- \ --------------- |
| | Domain 1 |/ | Domain 2 | | |\ Domain 3 | |
| | / | | | | \ | |
| | ----- /| | ----- | | \ ----- | |
| | |PCE 1|/ | | |PCE 2| | | \|PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| ---------------- ---------------- ---------------- |
-----------------------------------------------------------------
Figure 1: Service-PCE and NSBP in the hierarchical model
Carrozzo, et al. Expires September 5, 2012 [Page 7]
Internet-Draft PCEP PRICE INFO March 2012
3.1. Route cost vs. route price
The route cost(s)/metric(s) are Traffic Engineering indicators used
by the network administrator (carrier) to optimize the usage of its
network resources.
The route price is a different information with respect to the route
cost, as it refers to the customer-supplier interaction at the
business level for offering, negotiating and, eventually,
instantiating a network connectivity service (e.g. a [G]MPLS LSP).
The price of a network connectivity service generally depends on
strategic factors, but it could also be influenced by the amount of
mobilized network resources (along the route), the ingress/egress
interfaces/PoPs, etc.
Therefore, it could be provided by an extended PCE (i.e. the Service-
PCE) as an optional route information, by using a mix of topology
data, explicit route and policy data (both local and external to the
service-PCE).
4. PCEP protocol extensions
The procedures and encoding adopted by a PCC and a service-PCE to
handle the route offer computation with price information are
described in this section.
Two different set of extensions are defined for the PCEP for route
offer computations: one for the PCEP Request (PCReq) message, and
another for the PCEP Reply (PCRep) message.
4.1. Price Request bit
The format of a PCReq message for the request of a route offer
computation is unchanged with respect to [RFC5440] and subsequent
extensions.
Carrozzo, et al. Expires September 5, 2012 [Page 8]
Internet-Draft PCEP PRICE INFO March 2012
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<segment-computation> | <path-key-expansion>
where:
<segment-computation> ::= <END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion> ::= <PATH-KEY>
The route offer computation is identified by a new flag in the RP
Object, the Price Request bit (P) (to be assigned by IANA,
recommended bit 2). The PCC requesting the PCE for a route offer
computation will set the P bit in the corresponding RP object in the
PCReq.
Since all the other PCReq objects and parameters are left unchanged,
the route offer computation constraints and parameters are similar to
the ones defined for standard path computations.
Carrozzo, et al. Expires September 5, 2012 [Page 9]
Internet-Draft PCEP PRICE INFO March 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Modified RP object with P bit (Price Request bit)
4.1.1. Processing rules
A PCC sets the Price Request bit in the PCReq RP object to inform the
PCE that the incoming PCReq message is requesting for a price
computation. On the other hand, when a PCE receives a PCReq message
it checks the Price Request bit in the RP object to distinguish
between a price computation and a standard path computation.
When the Price Request bit is set, the PCE computes a set of route
offers for the given endpoints by also calculating the respective
route prices according to the constraints specified by the PCC in
terms of end points, bandwidth, metrics, load balancing, etc. and the
policies configured within the PCE. In case the Price Request bit is
set, but the PCE does not support the price computation function, it
must return a PCErr message with Error-Type "Capability not
supported" as per [RFC5440].
4.2. PRICE-INFO Object
The price computation performed by the PCE is delivered to the PCC in
a new defined optional object, the PRICE-INFO object, carried in the
path attribute-list section of the PCRep message. The PRICE-INFO
object, when present, encodes the set of route offers computed by the
PCE for the end-to-end connectivity service requested by the PCC.
More PRICE-INFO objects can be included in a PCRep message to provide
more than one price for the same service.
Carrozzo, et al. Expires September 5, 2012 [Page 10]
Internet-Draft PCEP PRICE INFO March 2012
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::= [<PRICE-INFO-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<PRICE-INFO-list>::=<PRICE-INFO>[PRICE-INFO-list]
The PRICE-INFO Object-Class is to be assigned by IANA (recommended
value is 202).
The PRICE-INFO Object-Type is to be assigned by IANA (recommended
value is 1).
The PRICE-INFO object format is shown in the following figure.
Carrozzo, et al. Expires September 5, 2012 [Page 11]
Internet-Draft PCEP PRICE INFO March 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| priceModel | currencyType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|priceUnitTime |priceUnitData | capUnitTime | capUnitData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| priceValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EDITOR NOTE: Usage of TLVs within PRICE-INFO could be considered, e.g
to make the object more flexible and/or add multiple caps. For the
applicability to inter-carrier frameworks one cap is commonly enough,
and usage of TLVs would just increase overhead on the object.
Figure 3: PRICE-INFO object
priceModel (8 bits): Indicates the cost model applied to compute the
price. The following types of price models are currently defined:
o Pay-as-you-go (0x01)
o Flat (0x02)
currencyType (24 bits): Indicates the currency used to express the
price. It is expressed with the 3 characters of the currency codes
specified by the ISO-4217 standard ([ISO4217], e.g. EUR, USD, etc.).
priceUnitTime (8 bits): Indicates the time interval for a unitary
price value. The following types are currently defined for the time
unit:
o None (0x00)
o Minute (0x01)
o Hour (0x02)
o Day (0x03)
o Week (0x04)
o Month (0x05)
Carrozzo, et al. Expires September 5, 2012 [Page 12]
Internet-Draft PCEP PRICE INFO March 2012
o Year (0x06)
priceUnitData (8 bits): Indicates the data volume for a unitary price
value. The following types are currently defined for the data unit:
o None (0x00)
o KB (0x01)
o MB (0x02)
o GB (0x03)
o TB (0x04)
capUnitTime (8 bits): Indicates the time unit used to express the Cap
Value (same types of priceUnitTime are defined).
capUnitData (8 bits): Indicates the data volume unit used to express
the Cap Value (same types of priceUnitData are defined).
priceValue (32 bits): Indicates the value of the price.
capValue (32 bits): Indicates the value of the upper bound for this
service offer (e.g. max data volume or time length) for which the
given offer is valid at the specified price. For example, a 10 EUR/
month price with 15GB cap in Flat model would correspond to:
o priceModel = 2 (Flat)
o currencyType = "EUR"
o priceUnitTime = 5 (Month)
o priceUnitData = 0 (None)
o priceValue = 10
o capUnitTime = 5 (Month)
o capUnitData = 3 (GB)
o capValue = 15
Carrozzo, et al. Expires September 5, 2012 [Page 13]
Internet-Draft PCEP PRICE INFO March 2012
4.2.1. Processing rules
In case of successful route offers computation, the requested PCE
replies to the requesting PCC with a PCRep message that must include
at least one PRICE-INFO object. Multiple PRICE-INFO objects can be
included in the PCReq when more than one route offer is identified by
the PCE for the requested end-to-end connectivity service. In
particular each PRICE-INFO object identifies a specific route offer:
for instance, for the same carrier connectivity services two
different route offers could be identified by the PCE, one for a with
a Flat Price Model, and another with a Pay-as-you-go Price Model.
All the PRICE-INFO objects carried in the PCReq message refer to the
same ERO computed by the PCE: the ERO object, as a mandatory PCEP
object, is always included in the PCReq message and along with the
route offers identification build the extended PCReq path section in
case of price computation (ref. Figure 3). On the other hand, in
the case of unsuccessful price computation, the PCRep message must
not carry any PRICE-object, while a NO-PATH object is included as
specified in [RFC5440] for the standard path computation procedure.
5. Acknowledgements
This work has been partially supported by the European Commission
through the FP7 ICT Integrated Project ETICS (Economics and
Technologies for Inter-Carrier Services, contract no: INFSO-ICT-
248567).
Authors would like to thank R. Douville and N. Le Sauze from Alcatel-
Lucent, and J. Meuric and O. Dugeon from France Telecom for the
preliminary discussions of this work.
6. IANA Considerations
6.1. PRICE INFO Object
IANA manages the PCEP Objects code point registry (see [RFC5440]).
This is maintained as the "PCEP Objects" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry. This document
defines a new PCEP object, the PRICE-INFO object, to be carried in
PCRep messages.
IANA should make the following allocation for PRICE-INFO object:
Carrozzo, et al. Expires September 5, 2012 [Page 14]
Internet-Draft PCEP PRICE INFO March 2012
Object Name Object Name Reference
Class Type
--------------------------------------------------------------------
202 PRICE-INFO 1 PRICE-INFO This Doc
6.2. RP Object Flag
A new flag of the RP object (specified in [RFC5440]) is defined in
this document. IANA maintains a registry of RP object flags in the
"RP Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
IANA should make the following allocation:
Bit Description Reference
------------------------------------------------
2 Supply PRICE INFO on response This Doc
7. Security Considerations
PCEP security mechanisms are described in [RFC5440] and are used to
secure entire PCEP messages. Nothing in this document changes the
message flows or introduces any new messages; therefore, the security
mechanisms set out in [RFC5440] continue to be applicable. This
document introduces a single new object that may optionally be
carried on PCEP messages and will be automatically secured using the
mechanisms described in [RFC5440]. If a PCEP message is vulnerable
to attack (for example, because the security mechanisms are not
used), then the price request bit in RP and the PRICE-INFO object
could be used as part of an attack; however, it is likely that other
objects will provide far more significant ways of attacking a PCE or
PCC in this case.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
Carrozzo, et al. Expires September 5, 2012 [Page 15]
Internet-Draft PCEP PRICE INFO March 2012
March 2009.
8.2. Informative References
[ETICS] FP7 ICT ETICS project, "Deliverable D5.2 - ETICS Draft
Detailed specification of the inter-carrier service
delivery system", https://www.ict-etics.eu/fileadmin/
documents/publications/deliverables/D5_2-V5_0-final.pdf,
2011.
[I-D.ietf-pce-hierarchy-fwk]
Farrel, A. and D. King, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS",
draft-ietf-pce-hierarchy-fwk-00 (work in progress),
October 2011.
[IPSPHERE]
TMFORUM, "IPsphere Framework: General Requirements and
Technical Architecture (Release 2.0)", TR158 version 1.1,
July 2010.
[ISO4217] ISO 4217, "Currency and funds name and code elements",
International Organization for Standardization
(ISO) http://www.iso.org/iso/currency_codes_list-1.
[ITU-T M.3010]
ITU-T M.3010, "Principles for a telecommunications
management network", ITU-T Recommendation M.3010 ,
February 2000.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Authors' Addresses
Gino Carrozzo
Nextworks
via Livornese 1027
Pisa, 56122
Italy
Phone: +39 050 3871 600
Email: g.carrozzo@nextworks.it
Carrozzo, et al. Expires September 5, 2012 [Page 16]
Internet-Draft PCEP PRICE INFO March 2012
Giacomo Bernini
Nextworks
via Livornese 1027
Pisa, 56122
Italy
Phone: +39 050 3871 600
Email: g.bernini@nextworks.it
Giada Landi
Nextworks
via Livornese 1027
Pisa, 56122
Italy
Phone: +39 050 3871 600
Email: g.landi@nextworks.it
Carrozzo, et al. Expires September 5, 2012 [Page 17]
