PCE Detailed Architecture

The ADRENALINE PCE Server is a network appliance that implements a Path Computation Element. It combines, in a single system, a Path Computation Engine and a standard PCEP protocol interface to access Path Computation Services. The system is composed of a main PCE multi-threaded asynchronous process, running as a PCEP/TCP server in order to accept and process path computation requests from Path Computation Clients (PCC). When required, the PCE will also act as a Path Computation Element communication Protocol (PCEP) /TCP client to request path computations to other PCEs in other domains. The application runs on top of a Debian™ GNU/Linux operating system. It supports most current IETF PCE WG standards and has succesfully been deployed in single and multi-domain scenarios. It is also composed of a connection manager and of a plug-in manager. The former listens for PCEP/TCP connections, concurrently servicing many clients, using the well known port 4189, accepting PCEP sessions from both end-host clients and PCE peers, asynchronously; it managems all active connections (e.g. to locate a given connection object for a peer given its IP address). The latter maintains a set of registered plug-ins, which either extend the functionality of the server, or implement algorithms. Upon connection of a PCEP client (PCC), the PCE Communications Protocol and its associated FSM allows flexible path computation requests with optional constraints. An overview of the PCE is given in the ADRENALINE testbed description

The PCE will reply to path computation requests by computing a route based on the local cache of the TEDB. The pced will act as a reader of the local cache, in a stateless approach. In the event of a request for the establishment of an LSP, the pced will compute a path that will be sent in a reply to the PCC. A successful establishment of the LSP will be seen by a change in the local cache of the TEDB once it is updated as defined in the following point. The PCE will not keep track of request history other than for logging purposes. The PCE may have different and dedicated “updater threads”, defined as threads within the pced process whose main purpose is to update the local TEDB cache with the status of the Transport Plane Network. The pced “updater threads” and the threads that perform the actual path computation will act as writers/readers of the TEDB local cache. The PCE is able to use different algorithms, and the implementation will allow the seamless addition of new algorithms in a pluggable (modular) approach e.g., as shared libraries (.so files in Unix systems) with a well defined interface (algorithm API) in order to:

• Access to the parameters of the Path Computation Request.
• Output a (set of) route(s) back to the main pced process.

The pced keeps a copy / cache of the Traffic Engineering Database (TEDB), characterizing the Links and nodes from the Data Transport plane (as in GMPLS OSPF-TE extensions), and possibly new node and link TE attributes as identified and defined in the first tasks of the project. The TEDB will be modelled as a Graph Data Structure, and TEDBs will be seen as graph instances.

Fig. 1. PCE architecture

PCE Core

The core of the server has been designed as an asynchronous process, where operations happen as a reaction to some event, by means of callbacks. Specific parts and components of the server are configurable via a configuration file, which is loaded and stored in a config object. The main server object does create a TCP acceptor object, including a listening socket that listens to the port provided by the configuration file. It starts an asynchronous accept operation, giving a handler method as callback once the accept socket procedure is complete.

During the initialization phase, the server looks at all the pre-configured directories (<dir> entries in the configuration file) and loads recursively any shared library (.so file) that may be present, which we refer to as the plug-ins. Plug-ins can extend the PCE functionality and/or implement algorithms. Once the plug-ins have been loaded, it is possible to request the plug-in manager in order to know the Objective Function (OF) codes of the algorithms that have been registered.

PCEP Finite State Machine

Upon connection of a Path Computation Client (PCC), a new connection object is created, and a Context and a Finite State Machine (FSM) are bound to this connection object. The Context will maintain dynamic data that has been learnt during the handshake procedure (such as dead and keepalive timers, or the objective functions that the peer is able to use). The Finite State Machine drives the PCEP protocol and maps the FSM as defined in current normative documents. The FSM is defined in a C++ Domain Specific Embedded Language (DSEL) so it enables us to clearly specify events and reactions to events along with state transitions. The figure below details the OpenWait state.

PCEP Grammar and Message / Object Parsing

One key point of the PCE software is the ability to process and parse PCEP messages. The parsing functions have been designed with ease of use and extensibility in mind. For this, the PCE will use the Boost.Spirit and the Boost.Phoenix libraries, allowing the specification of Message formats in a Domain Specific Embedded Language (DSEL), mapping the syntax of the Extended-Bakus-Naur Form (EBNF) within the limitations of the C++ language. The PCE will use the Boost.Statechart library to specify the Finite State Machine (FSM) that controls the Path Computation Element Protocol (PCEP). The DSEL allows specifying parsing grammars that are close to the formal notation, as it is easy to extend with proprietary formats, objects and TLVs.

TED management

Fig. 3. PCE TED synchronization

One of the key aspects of the Path Computation Element is the mechanism by which the PCE obtains a copy of the Traffic Engineering Database in order to perform path computation. As mentioned above, one of the updating mechanisms reads and parses OSPF-TE packets, processing the TLV information found in the Node and Link TLVs of the TE LSAs, in order to map such information to node and link TE attributes.

Another possible mechanism to perform the TE synchronization is by means of using an XML file. This is adequate for testing and debugging, to test the PCE implementation without deploying all components and as a basis to define an interface so the PCE can obtain a full topology from a “topology server”. The XML format is based on the Serialization library, which allows a simple and straightforward way to add persistence to objects. The figure below shows a fragment of the XML file for a 14-node NSFNET topology for the ADRENALINE testbed. Note that the format of the XML file is still open to requirements, and may change if due to either an algorithm or new OSPF-TE extensions, new attributes are added to both TE links and TE nodes

Path Computation Engine

Additionally, the core creates a thread pool, with a default num of threads that corresponds to the hardware cores, which will execute path computation jobs, once they are scheduled for execution. This happens upon reception of a Path Computation Request (PCReq) message. For each of the requests that are contained in the PCReq message, the server will iterate on them and create a corresponding path job, after checking all the requirements (e,g. the Request is well formed, that it has RP and ENDPOINTS objects, that those that require it have the p-flag set, etc.) The job is “posted” in a concurrent queue, which allows a producer thread (the server) to add items and consumer threads (the path computation threads) to remove items and to execute algorithms. Note that, due to the requirements to interoperate with implementations following outdated previous drafts, there exists the defined PCEP_STRICT. If defined, we adhere to the latest normative documents. Otherwise, we allow mal-formed messages. The latest draft and RFC state that the P flag of the RP object MUST be set in PCReq and PCReq messages and MUST be cleared in PCNtf and PCErr messages. If the RP object is received with the P flag set incorrectly according to the rules states above, the receiving peer MUST send a PCErr message with Error-type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification. As we will detail later, this has been relaxed. It is possible to select the algorithm to apply on a per request basis, using both the configuration default algorithm, and the client preference (if any). In short, the program selects the algorithm based on whether the code point of the algorithm exists and whether the client “suggests" or "requires" the algorithm (bit_p) to select the Objective Function identifier (OF code point) and thus the algorithm to apply to the request.

Multi-Domain Path Computation

Typically in the GMPLS architecture, Label Switched Routers or LSRs (i.e., Optical Connection Controller or OCC in WSON) have full topology visibility within their domain boundaries and limited visibility of the other domains. Indeed, multi-domain information is usually exchanged as limited aggregated topology information (e.g., reachability). Consequently, in traditional source routing approaches, a source OCC is not able to compute, autonomously, an end-to-end multi-domain path with the same control and degree of Traffic Engineering than for an intra-area path. In this context, two methods are applicable for inter-domain path computation, the per-domain path computation method and the PCE-based path computation method.

In this sense, CTTC PCE software is able to perform multi-domain path computation in several scenarios:

• Multi-area path computation with distributed path computation amongst collaborating PCEs, using the Backwards Recursive Path Computation (BRPC) which may be extended at the algorithm level to apply the wavelength continuity constraint (WCC).

• Multi-AS Path Computation with BRPC. This is limited since the PCE does not have the information of inter-AS TE links.

• Multi-Domain path computation with segment path computation. This method is limited since the PCE does not have the information of inter-AS TE links. In principle, this covers the main functionality for a PCE. However, and as noted above, topology confidentiality is becoming a common requirement, especially when interconnecting domains, specially between different carriers. The main purpose of this work is to combine multi-domain path computation with topology confidentiality.

Supported Standards

One of our objectives is to supporting most (all?) WG RFCs, although it is still a work in progress and we cannot claim *full* support, since:

• Development is driven by research or specific needs of a client. A given feature or needed extension may be implemented on a case-by-case basis.
• "Supporting" a specific feature may mean that the PCEP engine is able to parse/construct and manage a set of TLV/Objects/Messages but also that the back-end algorithm (which may be developped by a third party) must take it into account. For example, a) the PCEP engine can parse, construct and manipulate the PCEP IRO object, but it is a given algorithm that must insure to use the IRO subobjects or b) we understand P2MP requests with Type 2,3 and 4 P2MP tree leaves but for no algorithm able to re-optimize a constrained tree has been implemented.
• Specific features may have limited support. For exmaple, SVEC objects are supported, but all requests involved in the synchronized vector must be present in the same request message, which implies that the sync timer for SVEC is 0

Request For Comments

PCE Architecture

• A. Farrel, J.-P. Vasseur, J. Ash, A Path Computation Element (PCE)-Based Architecture, IETF Request for Comments RFC 4655, August 2006

PCEP

• J. P. Vasseur, JL. Le Roux, Path Computation Element (PCE) Communication Protocol (PCEP), IETF Request for Comments RFC 5440, March 2009
• LSPA: back-end algorithm
• LOAD_SHARING: back-end algorithm

PCEP SVEC

• J. P. Vasseur, JL. Le Roux, Path Computation Element (PCE) Communication Protocol (PCEP), IETF Request for Comments RFC 5440, March 2009
• I.-D. draft-ietf-pce-pcep-svec-list
• SVEC: default algorithm based on iterative computation and trimming of paths (e.g. k-shortest disjoint paths algorithm)
• SVEC: Sync Timer set to 0 (all sync requests must be included in the same Request message)

Iterative Example, 3 requests Link Disjoint

PCREQUEST Length: 112 svec: 1

       SVEC(11/1) - 20 bytes - P<0> - I<0>
       flags: 0
       S: 0    N: 0    L: 1
        reqid: 1
        reqid: 2
        reqid: 3

       OF(21/1) - 8 bytes - P<0> - I<0>
       code: 2001

       GC(24/1) - 8 bytes - P<0> - I<0>
       Max Hop (MH):                    127
       Max Utilization Percentage (MU): 80
       Min Utilization Percentage (mU): 80
       Overbooking Factor (OB):         100

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 2

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 3

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ERO(7/1) - 32 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 1
       label (3-3) - len: 8
       0x26000001 (637534209) ctype: 2 U: <0> -- R: <0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 2

       ERO(7/1) - 100 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 2
       label (3-3) - len: 8
       0x26000004 (637534212) ctype: 2 U: <0> -- R: <0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.3    interface id: 2
       label (3-3) - len: 8
       0x26000004 (637534212) ctype: 2 U: <0> -- R: <0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.5    interface id: 3
       label (3-3) - len: 8
       0x26000004 (637534212) ctype: 2 U: <0> -- R: <0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.4    interface id: 2
       label (3-3) - len: 8
       0x26000007 (637534215) ctype: 2 U: <0> -- R: <0>
       regenerator (6-6) - len: 8
       0x0 (0) ctype: 1        (3R)
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 3

       NOPATH(3/1) - 44 bytes - P<0> - I<0>
       NOPATH issue: 0 - No path found
       flags: 0
       bitc:  0
               NO PATH VECTOR (1) vlen: 4
               FLAGS: 10000000000000000000000000000000
               ASCII (32768) vlen: 24
               Ascii Text: SVEC no path found 32768

ClassType

• S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki, Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol, IETF Request for Comments RFC 5455.
• CLASSTYPE: parsing / construction.
• CLASSTYPE: PCReq grammar.
• CLASSTYPE: back-end algorithm.

PCREQUEST Length: 56 request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       CLASSTYPE(22/1) - 8 bytes - P<0> - I<0>
       CLASSTYPE code: 0

BRPC

• J. P. Vasseur, R. Zhang, N. Bitar, JL. Le Roux A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths, IETF Request for Comments RFC 5441.
• Support of both BRPC and per segment approaches

Path Key

• R. Bradford, JP. Vasseur, A. Farrell, Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Path Key”, IETF Request for Comments RFC 5520
• A. Farrel, Ed., “Resource Reservation Protocol (RSVP) Extensions for Path Key Support, IETF Request for Comments RFC 5553.
• PKS v4, PKS v6

Request

PCREQUEST Length: 48 request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 0 C<1> B<0>     V: 0

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ERO(7/1) - 28 bytes - P<0> - I<0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.1/32
       pks_ipv4 (64-64) - len: 8
       PCE ID:       10.0.0.1  Path Key: = 1 0x1
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       OF(21/1) - 8 bytes - P<0> - I<0>
       code: 32768

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: IGP metric (1) flags: 2 C<1> B<0>    V: 1

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 2 C<1> B<0>     V: 1

Expansion

PCREQUEST Length: 28

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<1> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       PATH_KEY(16/1) - 12 bytes - P<0> - I<0>
       pks_ipv4 (64-64) - len: 8
       PCE ID:       10.0.0.1  Path Key: = 1 0x1

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<1> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ERO(7/1) - 32 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 1
       label (3-3) - len: 8
       0x26000001 (637534209) ctype: 2 U: <0> -- R: <0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       OF(21/1) - 8 bytes - P<0> - I<0>
       code: 32768

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: IGP metric (1) flags: 2 C<1> B<0>    V: 1

Failure

PCREQUEST Length: 28 request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<1> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       PATH_KEY(16/1) - 12 bytes - P<0> - I<0>
       pks_ipv4 (64-64) - len: 8
       PCE ID:       192.168.0.50      Path Key: = 43690 0xaaaa

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<1> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       NOPATH(3/1) - 44 bytes - P<0> - I<0>
       NOPATH issue: 0 - No path found
       flags: 0
       bitc:  0
               NO PATH VECTOR (1) vlen: 4
               FLAGS: 00000000000000000000000001000000
               FLAG: PKS expansion failure
               ASCII (32768) vlen: 22
               Ascii Text: [REQ]: 1 - pks_error

Objective Function

• J. P. Vasseur, JL. Le Roux, Y. Lee, Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP), IETF Request for Comments RFC 5541 (partial)
• Support for OF and OF_LIST
• MCP (OF code 1) implemented

Exclude Route

• E. Oki, T. Takeda, A. Farrel, Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions, IETF Request for Comments RFC 5521 (partial)
• EXRS not supported.
• PCEP: support for XRO with all defined subobjects
• Implemented Algorithm: Support for the exclusion of Unnumbered Interface Ids and Node Ids

Request without XRO

request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2
       t: TE metric (2) flags: 0 C<1> B<0>     V: 0

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ERO(7/1) - 24 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 1
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 2 C<1> B<0>     V: 1

Request with XRO

request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       XRO(17/1) - 20 bytes - P<0> - I<0>
       flags:      0x0
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 1

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ERO(7/1) - 60 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 2
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.3    interface id: 2
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.5    interface id: 3
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.4    interface id: 2
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 2 C<1> B<0>     V: 4

P2MP

• I.-D. draft-ietf-pce-pcep-p2mp-extensions
• Parsing of P2MP requests with RRO
• Support for Leaf types 1,2,3,4
• Algorithms not implemented.

PCREQUEST Length: 196 request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<1> F<0>
       reqid: 1

       ENDPOINTS(4/3) - 20 bytes - P<1> - I<0>
       Leaf Type: 1
       Source:
               10.0.50.1
       Destinations:
               10.0.50.2
               10.0.50.5

       ENDPOINTS(4/3) - 16 bytes - P<1> - I<0>
       Leaf Type: 2
       Source:
               10.0.50.1
       Destinations:
               10.0.50.4

       RRO(8/1) - 20 bytes - P<0> - I<0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.1/32
       ipv4_prefix (1-1) - len: 8
       10.0.50.4/32

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       ENDPOINTS(4/3) - 16 bytes - P<1> - I<0>
       Leaf Type: 3
       Source:
               10.0.50.1
       Destinations:
               10.0.50.6

       RRO(8/1) - 20 bytes - P<0> - I<0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.1/32
       ipv4_prefix (1-1) - len: 8
       10.0.50.6/32

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       ENDPOINTS(4/3) - 16 bytes - P<1> - I<0>
       Leaf Type: 3
       Source:
               10.0.50.1
       Destinations:
               10.0.50.8

       RRO(8/1) - 20 bytes - P<0> - I<0>
       ipv4_prefix (1-1) - len: 8
       10.0.50.1/32
       ipv4_prefix (1-1) - len: 8
       10.0.50.8/32

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 0 C<1> B<0>     V: 0

       OF(21/1) - 8 bytes - P<1> - I<0>
       code: 8

Monitoring

• JP Vasseur, JL Le Roux, Y. Ikejiri, A Set of Monitoring tools for Path Computation Element (PCE)-based architectures, IETF Request for Comments RFC 5886 (partial)

Support for PCE MONITORING following RFC 5886 has been implemented as a stand-alone plug-in, which can be disabled without impact on the performance of the server. The plugin registers callbacks for specific events and monitors the reception of PCMonReq messages and PCReq messages with (optional) MONITORING objects. Stats are computed on a per-request basis, acculating mean, std.deviation, etc. both support for general and specific monitoring requests has been implemented.

• Parsing/Construction of Extended PCReq / PCMonReq messages
• Parsing/Construction of Extended PCRep / PCMonRep messages
• Support for OVERLOAD, PROC_TIME, MONITORING, PCC_REQ_ID, PCE_ID objects
• Statistics on waiting time and stay time on a per-request basis.
• PCE_ID_LIST parsed, but not honored (need to modify BRPC). Only stats of a single PCE chained.
• Implementation notes: there are a few issues with RFC

1. In Section 3.1 it is stated that "there is one mandatory object that MUST be included (...) Other objects are optional"; however, the EBNF notation suggests that PCC-ID-REQ is mandatory (pag 7). Also, Section 4.2 states that "PCC-ID-REQ MUST be included (...)". There seems to be a contradiction in Section 3.1
2. Similar questions apply for PCReq (pag 8), PCMonRep(pag 10), PCRep, regarding the same PCC-ID-REQ object.
3. If PCC-ID-REQ is mandatory, souldn't an Error 6 : Mandatory Object missing / 5: PCC-ID-REQ Object missing be added"? along the lines of "If a PCE receives a PCMonReq with the PCC-ID-REQ missing or a PCReq with a MONITORING object but without a PCC-ID-REQ missing it MUST generate aPCEPError 6,5?
4. The draft specifies the procedure when the flags, are set. For the sake of completeness, if flags L, P, C are *not* set in the MONITORING object, what would be the recommended action? the PCE should/should not/may/must not/ include the correspondong PCE_ID, PROC_TIME and OVERLOAD metrics?
5. In PROC-TIME object, the variance is said to be indicated in milliseconds (it should be in squared milliseconds or(alternatively one should use the standard deviation)
6. Section 4.5 refers to the OVERLOAD object but in pag 19. the old? CONGESTION name is used: "the format of the CONGESTION object"

• General Request

PCMONREQUEST Length: 56

       MONITORING(19/1) - 12 bytes - P<0> - I<0>
       I<0> C<0> P<0> G<0> L<0>
       monitoring_id_number: 1234

       PCC_REQ_ID(20/1) - 8 bytes - P<1> - I<0>
       Address: 11.0.0.1

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.1

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.2

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.3

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.4

       MONITORING(19/1) - 12 bytes - P<0> - I<0>
       I<0> C<0> P<0> G<0> L<0>
       monitoring_id_number: 0

       PCC_REQ_ID(20/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.1

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 0.0.0.1

       PROC_TIME(26/1) - 96 bytes - P<0> - I<0>
       E: 1
       cur_processing_time: 0
       min_processing_time: 2
       max_processing_time: 2
       avg_processing_time: 2
       var_processing_time: 0
               ASCII (32768) vlen: 61
               Ascii Text: Note: exact values (avg/min/max): 2423.07/2277/2616 microsecs

       OVERLOAD(27/1) - 8 bytes - P<0> - I<0>
       flags: 0
       duration: 0

• Specific Request

PCREQUEST Length: 68

       MONITORING(19/1) - 12 bytes - P<0> - I<0>
       I<0> C<0> P<0> G<0> L<0>
       monitoring_id_number: 1234

       PCC_REQ_ID(20/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       BANDWIDTH(5/1) - 8 bytes - P<0> - I<0>
       bw:      1.25e+08

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 0 C<1> B<0>     V: 0

       RP(2/1) - 12 bytes - P<0> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       MONITORING(19/1) - 12 bytes - P<0> - I<0>
       I<0> C<0> P<0> G<0> L<0>
       monitoring_id_number: 0

       PCC_REQ_ID(20/1) - 8 bytes - P<1> - I<0>
       Address: 10.0.0.1

       ERO(7/1) - 24 bytes - P<0> - I<0>
       unnum_ifid (4-4) - len: 12
       Router ID: 10.0.50.1    interface id: 1
       ipv4_prefix (1-1) - len: 8
       10.0.50.2/32

       OF(21/1) - 8 bytes - P<0> - I<0>
       code: 1

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: IGP metric (1) flags: 2 C<1> B<0>    V: 0

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: TE metric (2) flags: 2 C<1> B<0>     V: 1

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: Hop Count (3) flags: 2 C<1> B<0>     V: 1

       METRIC(6/1) - 12 bytes - P<0> - I<0>
       t: OSNR (200) flags: 2 C<1> B<0>        V: 0

       PCE_ID(25/1) - 8 bytes - P<1> - I<0>
       Address: 0.0.0.1

       PROC_TIME(26/1) - 96 bytes - P<0> - I<0>
       E: 0
       cur_processing_time: 2
       min_processing_time: 0
       max_processing_time: 0
       avg_processing_time: 0
       var_processing_time: 0
               ASCII (32768) vlen: 64
               Ascii Text: Note: exact value 2.32 (avg/min/max): 2416.2/2277/2616 microsecs

       OVERLOAD(27/1) - 8 bytes - P<0> - I<0>
       flags: 0
       duration: 0

Global Concurrent Optimization

• Y. Lee, JL Le Roux, D. King, E. Oki, Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization, IETF Request for Comments RFC 5557 (partial)
• Parsing of GCO objects
• Standard Objective Functions for GCO not implemented.

PCREQUEST Length: 112 svec: 1

       SVEC(11/1) - 20 bytes - P<0> - I<0>
       flags: 0
       S: 0    N: 1    L: 0
        reqid: 1
        reqid: 2
        reqid: 3

       OF(21/1) - 8 bytes - P<0> - I<0>
       code: 2001

       GC(24/1) - 8 bytes - P<0> - I<0>
       Max Hop (MH):                    127
       Max Utilization Percentage (MU): 80
       Min Utilization Percentage (mU): 80
       Overbooking Factor (OB):         100

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 2

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 3

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.2

Vendor constraints

Internet Drafts

Note: Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. The following drafts are work-in-progress, and reflect features we are tracking or actively working on. The list may change without previous notice.

draft-ietf-pce-pcep-gmpls (was: draft-margaria-pce-gmpls)

• Support for new ENDPOINTS object type (generalized endpoints class 4 / type 5)
• Support for IPv4/IPv6 numbered interface TLVs
• Support for Unnumbered Interface TLVs
• Support for Label / Labelset object
• Support for Label / Labelset TLVs

• • Generalized end-points with numbered ipv4 interfaces

       ENDPOINTS(4/5) - 72 bytes - P<1> - I<0>
       Type: 0
               ENDPOINT_IP (32000) vlen: 4
               ENDPOINT_IP : 10.0.50.1
               ENDPOINT_IP (32000) vlen: 4
               ENDPOINT_IP : 10.0.50.14
               LABELSET (32010) vlen: 20
               Action:  I:  U: 
               Labeltype: 
               Labels: 1 2 3 4 
               SUGGESTED_LABELSET (32011) vlen: 12
               Action:  I: U: 
               Labeltype: 
               Labels: 3 4 
               SWCAP (32006) vlen: 4
               Enc. Type : 10
               Sw. Type  : 20
               GPID      : 30

• • Generalized end-points with unnumbered interfaces

               ENDPOINT_UNNUMBERED (32002) vlen: 8
               ENDPOINT_UNNUMBERED : 10.0.50.1:100
               ENDPOINT_UNNUMBERED (32002) vlen: 8
               ENDPOINT_UNNUMBERED : 10.0.50.14:200
               LABELSET (32010) vlen: 20
               Action: I: U: 
               Labeltype: 
               Labels: 1 2 3 4 

draft-zhao-pce-p2mp

draft-king-pce-hierarchy

draft-ietf-pce-inter-layer-ext [1]

       INTER_LAYER(18/1) - 8 bytes - P<0> - I<1>
       T: 0    M: 1    I: 1

       SWITCH_LAYER(119/1) - 16 bytes - P<0> - I<0>
       row: 94
       row: 95
       row: 96

       REQ_ADAP_CAP(120/1) - 8 bytes - P<0> - I<0>
       switching cap: 123      encoding: 210

draft-vendor-constraints

       VENDOR_CONSTRAINTS(23/1) - 16 bytes - P<0> - I<0>
       enterprise_number: 100

       00000000  01 02  03 04  |....|
       00000004  04 03  02 01  |....|

Proprietary Extensions

PCEP extensions for Hierarchical PCE (H-PCE)

PCEP extensions for Wavelength Switched Optical Networks (WSON)

• LABEL_SET support (deprecated see. draft-ietf-pce-pcep-gmpls). Used to insure Wavelength continuity constraint (WCC) with Lambda G.694 encoding.

PCREQUEST Length: 84 request: 1

       RP(2/1) - 12 bytes - P<1> - I<0>
       pri: 0 R<0> B<0> O<0> V<0> OF<1> P<0> D<0> M<0> E<0> N<0> F<0>
       reqid: 1

       ENDPOINTS(4/1) - 12 bytes - P<1> - I<0>
       Source: 10.0.50.1       Destination: 10.0.50.14

       LABELSET(130/1) - 28 bytes - P<0> - I<0>
       flags: 0
       labels: 637534208 637534210 637534212 637534214 637534216

PCEP extensions for Shared Path Protection (SPP)

PCEP extensions for management and monitoring

Software Language and Licenses

The main development language is standard C++. Other than very specific plugins and modules that may require specific components, the main portability constraints are those defined by the Boost c++ libraries.

Supported Platforms

• Currently, CTTC PCE Software runs on POSIX systems.
• Specific modules and plug-ins may depend on a given platform.
• Minimum Requirements depend on the selected algorithms and installed plugins. May range from Basic embedded systems to Multi-core servers.

A reference/target platform is GNU/Linux (both 32 and 64 bits), running on top of e.g. Pentium III, IV or higher CPUs, with 2-8 GBytes of RAM, running Debian (tested on 5.0/6.0) or Ubuntu distributions (tested on Intrepid-Jaunty-Lucid-Karmic-Maverick).

Development Environment

• The suggested development environment is:
  • A PC with GNU/Linux operating system with a 2.6 kernel.
  • A recent C++ compiler (e.g. gcc 4.4 or gcc 4.5.1), since the software uses of advanced c++ including heavy use of templates and metaprogramming.
  • At least 1-2 GB RAM, due to the high number of template instantiations, 4-8 GB Recommended.
  • CMake

• We use Boost Libraries, covered by the Boost software license, which allows Open source and closed (proprietary) software. In particular, highlighting:
  • Boost.Asio: for async I/O network management
  • Boost.Thread: for threading and concurrence
  • Boost.Graph: For TED and graphs, used in algorithms
  • Boost.Spirit: for protocol parsing (PEG, EBNF-like Grammars)
  • Boost.PropertyTree: for configuration file
  • Boost.StateChart (FSM, although we plan to migrate to newer Boost.MSM)
  • Others: Boost.Any, Boost.Function, Boost.Variant, Boost.MPL, Boost.Signals, Boost.Optional, Boost.SmartPtr, etc.

• Software licenses may vary depending on the component and some (adhoc) modules may require components that are constrained

• No kernelspace dependencies required, except some specific plugins that interface with kernel IP packet processing or routing tables.

Tests and Performace

The software has been used in research and production in different scenarios, used in several research papers, involving hundreds of hours of tests (note that a signle point in an experimental paper plot involves, typically, 10000 connection requests). We consider the core of the application to be stable (newer components haven't been exposed to the same stress testing).

A set of regression tests is also used. These are basic tests that test the handshake, specific behavior, reply to unknown objects, etc.

Regarding the performance, the papers listed in the document can provide some data, but consider that a Path request is on the order of 3-7 ms for a request using loopback 127.0.0.1 with a 14-node photonic mesh TED using a modified Dijkstra algorithm, which is executed by a thread in around 700 microsecs. We have used it in real GMPLS networks (photonic meshes) of up to 40-50 nodes, and part of the STROGEST FP7 IP project is to evaluate it with at least 100 nodes, obtaining latencies of 20-40 ms, depending on network latency. We have stressed it with runs of requests (within a single client and with different clients) each few milliseconds.

Publications

Journal/Magazine Papers

1. R. Casellas, R. Martinez, R. Muñoz, S. Gunreben, Enhanced Backwards Recursive Path Computation for Multi-area Wavelength Switched Optical Networks Under Wavelength Continuity Constraint, IEEE/OSA Journal of Optical Communications and Networking (JOCN), Vol. 1, Iss. 2, pp. A180–A193, July 2009.

International Conferences

1. R. Casellas, R. MArtinez, R. Munoz, L. Liu, T. Tsuritani, M. Tsurusawa, Lab-Trial of Multi-Domain Lightpath Provisioning with PCE Path Computation combining BRPC and Path-Key Topology Confidentiality in GMPLS Translucent WSON networks, accepted for oral presenation at the 36th European Conference on Optical Communication 2010 (ECOC 2010) Torino, Italy, on September 19-23, 2010.
2. L. Liu, T. Tsuritani, R. Casellas, R. Martinez, R. Muñoz, M. Tsurusawa, Experimental Demonstration and Comparison of Distributed and Centralized Multi-domain Resilient Translucent WSON , accepted for oral presenation at the 36th European Conference on Optical Communication 2010 (ECOC 2010) Torino, Italy, on September 19-23, 2010.
3. R. Muñoz, R. Casellas, R. Martinez, Experimental Evaluation of Dynamic PCE-based Path Restoration with Centralized and Distributed Wavelength Assignment in GMPLS-enabled Transparent WSON networks,accepted for oral presenation at the 36th European Conference on Optical Communication 2010 (ECOC 2010) Torino, Italy, on September 19-23, 2010.
4. L. Liu, T. Tsuritani, R. Casellas and M. Tsurusawa, Demonstration of a Resilient PCE/GMPLS Controlled Translucent Optical Network, accepted for the 15th Optoelectronics and Communications Conference (OECC 2010), Sapporo Convention Center, Hokkaido, Japan, July 5-9, 2010
5. L. Liu, T. Tsuritani, R. Casellas and M. Tsurusawa, Interoperability Investigation of PCE and Extended GMPLS Controller for Translucent Wavelength Switched Optical Networks, 6th International Conference on IP Over Optical (iPOP 2010), June 10-11, 2010, at NTT Mushashino Center, Tokyo, Japan.
6. S. Gunreben, J. Scharf, R. Casellas, R. Martinez, R. Muñoz, Experimental Validation and Assessment of Multi-domain and Multi-layer Path Computation, accepted for publication in the 6th International ICST Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities (Tridentcom 2010), being held in Berlin, Germany, on 3-6 May 2010.
7. R. Casellas, T. Tsuritani, S. Okamoto, R. Martínez, R. Muñoz, Experimental Field-Trial of Multi-domain PCE-based Path Computation for OSNR-aware GMPLS enabled translucent WSON, in Proceedings of 35th European Conference and Exhibition on Optical Communication (ECOC), September 20 – 24, 2009, Vienna (Austria).
8. A. P. Bianzino, J.-L. Rougier, S. Secci, R. Casellas, R. Martinez, R. Muñoz, N. B. Djarallah, R. Douville, H. Pouyllau, Implementation and validation of control-plane extensions for inter-domain GMPLS-TE provisioning in Proc. 5th International Conference on testbed and Research Infrastructures for the Development of Networks and Communities (Tridentcom 2009), April 6 -8 2009, Washington D.C (USA).
9. R. Casellas, R. Muñoz, R. Martínez, A Path Computation Element for Shared Path Protection in GMPLS-enabled Wavelength Switched Optical Networks, in Proceedings of 34th European Conference on Optical Communications (ECOC2008), 20-25 September 2008, Brussels (Belgium).
10. R. Casellas, R. Martínez, R. Muñoz, Design, Implementation and Validation within ADRENALINE® Testbed of a Path Computation Element for Wavelength Switched Optical Networks, in Proceedings of 4th International Symposium on IP over Optical (iPOP 2008), 5-6 June 2008, Tokyo (Japan).

PCE related technology transfer activities

Industrial Grants for Research Projects

KDDI R&D Labs

RAION4 (Inter-domain all-optical transport Networks - Phase 4) Research Project, Industrial Grant of KDDI R&D Labs (Japan). Research on architectures for intelligent translucent Wavelength Switched Optical Networks (WSON) with PCE-based path computation. Project Duration: 1/09/2010 - 31/03/2011 More info

RAION3 (Inter-domain all-optical transport Networks - Phase 3) Research Project, Industrial Grant of KDDI R&D Labs (Japan). Research Topic on extending the results obtained in RAION Phase 1 and 2, covering two main activities: interoperability studies of multi-domain translucent transport networks using the Path Computation Element (PCE) architecture, and the performance evaluation of the OSNR-aware path computation algorithm conceived during phase 1, focusing on PCE-based deployments. Project Duration: 01/12/2009 - 31/03/2010 More info

RAION2 (Inter-domain all-optical transport Networks - Phase 2) Research Project, Industrial Grant of KDDI R&D Labs (Japan). Resarch Topic: Experimental Field-Trial of Multi-domain Impairment-aware PCE-based Path Computation and protocol extensions for dynamic GMPLS-enabled translucent Wavelength Switched Optical Networks (WSON). Project Duration: 01/01/2009 - 30/06/2009 More info

Technology Transfer Contracts

KDDI Corporation

Service Contracts

Telefónica I + D

Roadmap

Management Interfaces

• The main mangement mechanism right now is a configuration file. Our unstable branch has been extended recently to support skeletons for "management" interface based on a) SNMP using netsnmp, b) web-based with in-process embedded web server. We are also considering having some sort of "CLI"

Hierarchical PCE

• We have started to implement a solution based on a Hierarchical PCE (H-PCE) using a 2-level hierarchy.