This guide contains information on how to use the OpenDaylight Path Computation Element Configuration Protocol (PCEP) plugin. The user should learn about PCEP basic concepts, supported capabilities, configuration and operations.
This section provides a high-level overview of the PCEP, SDN use-cases and OpenDaylight implementation.
Contents
The Path Computation Element (PCE) Communication Protocol (PCEP) is used for communication between a Path Computation Client (PCC) and a PCE in context of MPLS and GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs). This interaction include path computation requests and computation replies. The PCE operates on a network graph, built from the (Traffic Engineering Database) TED, in order to compute paths based on the path computation request issued by the PCC. The path computation request includes the source and destination of the path and set of constrains to be applied during the computation. The PCE response contains the computed path or the computation failure reason. The PCEP operates on top the TCP, which provides reliable communication.
The Path Computation Element perfectly fits into the centralized SDN controller architecture. The PCE’s knowledge of the availability of network resources (i.e. TED) and active LSPs awareness (LSP-DB) allows to perform automated application-driven network operations:
The OpenDaylight PCEP plugin provides all basic service units necessary to build-up a PCE-based controller. In addition, it offers LSP management functionality for Active Stateful PCE - the cornerstone for majority of PCE-enabled SDN solutions. It consists of the following components:
Important
The PCEP plugin does not provide path computational functionality and does not build TED.
This section explains how to install PCEP plugin.
Install PCEP feature - odl-bgpcep-pcep
.
Also, for sake of this sample, it is required to install RESTCONF.
In the Karaf console, type command:
feature:install odl-restconf odl-bgpcep-pcep
The PCEP plugin contains a default configuration, which is applied after the feature starts up. One instance of PCEP plugin is created (named pcep-topology), and its presence can be verified via REST:
URL: restconf/operational/network-topology:network-topology/topology/pcep-topology
Method: GET
Response Body:
<topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<topology-id>pcep-topology</topology-id>
<topology-types>
<topology-pcep xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep"></topology-pcep>
</topology-types>
</topology>
The PCEP extension for Stateful PCE brings a visibility of active LSPs to PCE, in order to optimize path computation, while considering individual LSPs and their interactions. This requires state synchronization mechanism between PCE and PCC. Moreover, Active Stateful PCE is capable to address LSP parameter changes to the PCC.
Contents
This capability is enabled by default. No additional configuration is required.
The OpenDaylight PCEP implementation is supporting TCP MD5 for authentication.
Sample configuration below shows how to set authentication password for a particular PCC.
It is required to install odl-netconf-connector-ssh
feature first.
URL: /restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-pcep-topology-provider-cfg:pcep-topology-provider/pcep-topology
Method: PUT
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">x:pcep-topology-provider</type>
<name>pcep-topology</name>
<data-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-async-data-broker</type>
<name>pingpong-binding-data-broker</name>
</data-provider>
<dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:pcep">x:pcep-dispatcher</type>
<name>global-pcep-dispatcher</name>
</dispatcher>
<rpc-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-rpc-registry</type>
<name>binding-rpc-broker</name>
</rpc-registry>
<scheduler xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:programming:spi">x:instruction-scheduler</type>
<name>global-instruction-scheduler</name>
</scheduler>
<stateful-plugin xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<type>pcep-topology-stateful</type>
<name>stateful07</name>
</stateful-plugin>
<topology-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">pcep-topology</topology-id>
<client xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<address>43.43.43.43</address>
<password>topsecret</password>
</client>
</module>
|
@line 26: address - A PCC IP address.
@line 27: password - MD5 authentication phrase.
Warning
The PCE (pcep-topology-provider) configuration is going to be changed in Carbon release - moving to configuration datastore.
The LSP State Database (LSP-DB) contains an information about all LSPs and their attributes. The LSP state is synchronized between the PCC and PCE. First, initial LSP state synchronization is performed once the session between PCC and PCE is established in order to learn PCC’s LPSs. This step is a prerequisite to following LSPs manipulation operations.
path-computation-client
+--ro reported-lsp* [name]
+--ro name string
+--ro path* [lsp-id]
| +--ro lsp-id rsvp:lsp-id
| +--ro ero
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro subobject*
| | +--ro loose boolean
| | +--ro (subobject-type)?
| | +--:(as-number-case)
| | | +--ro as-number
| | | +--ro as-number inet:as-number
| | +--:(ip-prefix-case)
| | | +--ro ip-prefix
| | | +--ro ip-prefix inet:ip-prefix
| | +--:(label-case)
| | | +--ro label
| | | +--ro uni-directional boolean
| | | +--ro (label-type)?
| | | +--:(type1-label-case)
| | | | +--ro type1-label
| | | | +--ro type1-label uint32
| | | +--:(generalized-label-case)
| | | | +--ro generalized-label
| | | | +--ro generalized-label binary
| | | +--:(waveband-switching-label-case)
| | | +--ro waveband-switching-label
| | | +--ro end-label uint32
| | | +--ro start-label uint32
| | | +--ro waveband-id uint32
| | +--:(srlg-case)
| | | +--ro srlg
| | | +--ro srlg-id srlg-id
| | +--:(unnumbered-case)
| | | +--ro unnumbered
| | | +--ro router-id uint32
| | | +--ro interface-id uint32
| | +--:(exrs-case)
| | | +--ro exrs
| | | +--ro exrs*
| | | +--ro mandatory? boolean
| | | +--ro attribute enumeration
| | | +--ro (subobject-type)?
| | | +--:(as-number-case)
| | | | +--ro as-number
| | | | +--ro as-number inet:as-number
| | | +--:(ip-prefix-case)
| | | | +--ro ip-prefix
| | | | +--ro ip-prefix inet:ip-prefix
| | | +--:(label-case)
| | | | +--ro label
| | | | +--ro uni-directional boolean
| | | | +--ro (label-type)?
| | | | +--:(type1-label-case)
| | | | | +--ro type1-label
| | | | | +--ro type1-label uint32
| | | | +--:(generalized-label-case)
| | | | | +--ro generalized-label
| | | | | +--ro generalized-label binary
| | | | +--:(waveband-switching-label-case)
| | | | +--ro waveband-switching-label
| | | | +--ro end-label uint32
| | | | +--ro start-label uint32
| | | | +--ro waveband-id uint32
| | | +--:(srlg-case)
| | | | +--ro srlg
| | | | +--ro srlg-id srlg-id
| | | +--:(unnumbered-case)
| | | +--ro unnumbered
| | | +--ro router-id uint32
| | | +--ro interface-id uint32
| | +--:(path-key-case)
| | +--ro path-key
| | +--ro pce-id pce-id
| | +--ro path-key path-key
| +--ro lspa
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro hold-priority? uint8
| | +--ro setup-priority? uint8
| | +--ro local-protection-desired? boolean
| | +--ro label-recording-desired? boolean
| | +--ro se-style-desired? boolean
| | +--ro session-name? string
| | +--ro include-any? attribute-filter
| | +--ro exclude-any? attribute-filter
| | +--ro include-all? attribute-filter
| | +--ro tlvs
| | +--ro vendor-information-tlv*
| | +--ro enterprise-number? iana:enterprise-number
| | +--ro (enterprise-specific-information)?
| +--ro bandwidth
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro bandwidth? netc:bandwidth
| +--ro reoptimization-bandwidth
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro bandwidth? netc:bandwidth
| +--ro metrics*
| | +--ro metric
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro metric-type uint8
| | +--ro bound? boolean
| | +--ro computed? boolean
| | +--ro value? ieee754:float32
| +--ro iro
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro subobject*
| | +--ro loose boolean
| | +--ro (subobject-type)?
| | +--:(as-number-case)
| | | +--ro as-number
| | | +--ro as-number inet:as-number
| | +--:(ip-prefix-case)
| | | +--ro ip-prefix
| | | +--ro ip-prefix inet:ip-prefix
| | +--:(label-case)
| | | +--ro label
| | | +--ro uni-directional boolean
| | | +--ro (label-type)?
| | | +--:(type1-label-case)
| | | | +--ro type1-label
| | | | +--ro type1-label uint32
| | | +--:(generalized-label-case)
| | | | +--ro generalized-label
| | | | +--ro generalized-label binary
| | | +--:(waveband-switching-label-case)
| | | +--ro waveband-switching-label
| | | +--ro end-label uint32
| | | +--ro start-label uint32
| | | +--ro waveband-id uint32
| | +--:(srlg-case)
| | | +--ro srlg
| | | +--ro srlg-id srlg-id
| | +--:(unnumbered-case)
| | | +--ro unnumbered
| | | +--ro router-id uint32
| | | +--ro interface-id uint32
| | +--:(exrs-case)
| | | +--ro exrs
| | | +--ro exrs*
| | | +--ro mandatory? boolean
| | | +--ro attribute enumeration
| | | +--ro (subobject-type)?
| | | +--:(as-number-case)
| | | | +--ro as-number
| | | | +--ro as-number inet:as-number
| | | +--:(ip-prefix-case)
| | | | +--ro ip-prefix
| | | | +--ro ip-prefix inet:ip-prefix
| | | +--:(label-case)
| | | | +--ro label
| | | | +--ro uni-directional boolean
| | | | +--ro (label-type)?
| | | | +--:(type1-label-case)
| | | | | +--ro type1-label
| | | | | +--ro type1-label uint32
| | | | +--:(generalized-label-case)
| | | | | +--ro generalized-label
| | | | | +--ro generalized-label binary
| | | | +--:(waveband-switching-label-case)
| | | | +--ro waveband-switching-label
| | | | +--ro end-label uint32
| | | | +--ro start-label uint32
| | | | +--ro waveband-id uint32
| | | +--:(srlg-case)
| | | | +--ro srlg
| | | | +--ro srlg-id srlg-id
| | | +--:(unnumbered-case)
| | | +--ro unnumbered
| | | +--ro router-id uint32
| | | +--ro interface-id uint32
| | +--:(path-key-case)
| | +--ro path-key
| | +--ro pce-id pce-id
| | +--ro path-key path-key
| +--ro rro
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro subobject*
| | +--ro protection-available? boolean
| | +--ro protection-in-use? boolean
| | +--ro (subobject-type)?
| | +--:(ip-prefix-case)
| | | +--ro ip-prefix
| | | +--ro ip-prefix inet:ip-prefix
| | +--:(label-case)
| | | +--ro label
| | | +--ro uni-directional boolean
| | | +--ro (label-type)?
| | | | +--:(type1-label-case)
| | | | | +--ro type1-label
| | | | | +--ro type1-label uint32
| | | | +--:(generalized-label-case)
| | | | | +--ro generalized-label
| | | | | +--ro generalized-label binary
| | | | +--:(waveband-switching-label-case)
| | | | +--ro waveband-switching-label
| | | | +--ro end-label uint32
| | | | +--ro start-label uint32
| | | | +--ro waveband-id uint32
| | | +--ro global? boolean
| | +--:(unnumbered-case)
| | | +--ro unnumbered
| | | +--ro router-id uint32
| | | +--ro interface-id uint32
| | +--:(path-key-case)
| | +--ro path-key
| | +--ro pce-id pce-id
| | +--ro path-key path-key
| +--ro xro
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro flags bits
| | +--ro subobject*
| | +--ro mandatory? boolean
| | +--ro attribute enumeration
| | +--ro (subobject-type)?
| | +--:(as-number-case)
| | | +--ro as-number
| | | +--ro as-number inet:as-number
| | +--:(ip-prefix-case)
| | | +--ro ip-prefix
| | | +--ro ip-prefix inet:ip-prefix
| | +--:(label-case)
| | | +--ro label
| | | +--ro uni-directional boolean
| | | +--ro (label-type)?
| | | +--:(type1-label-case)
| | | | +--ro type1-label
| | | | +--ro type1-label uint32
| | | +--:(generalized-label-case)
| | | | +--ro generalized-label
| | | | +--ro generalized-label binary
| | | +--:(waveband-switching-label-case)
| | | +--ro waveband-switching-label
| | | +--ro end-label uint32
| | | +--ro start-label uint32
| | | +--ro waveband-id uint32
| | +--:(srlg-case)
| | | +--ro srlg
| | | +--ro srlg-id srlg-id
| | +--:(unnumbered-case)
| | +--ro unnumbered
| | +--ro router-id uint32
| | +--ro interface-id uint32
| +--ro of
| | +--ro processing-rule? boolean
| | +--ro ignore? boolean
| | +--ro code of-id
| | +--ro tlvs
| | +--ro vendor-information-tlv*
| | +--ro enterprise-number? iana:enterprise-number
| | +--ro (enterprise-specific-information)?
| +--ro class-type
| +--ro processing-rule? boolean
| +--ro ignore? boolean
| +--ro class-type class-type
+--ro metadata
+--ro lsp
| +--ro processing-rule? boolean
| +--ro ignore? boolean
| +--ro tlvs
| | +--ro lsp-error-code
| | | +--ro error-code? uint32
| | +--ro lsp-identifiers
| | | +--ro lsp-id? rsvp:lsp-id
| | | +--ro tunnel-id? rsvp:tunnel-id
| | | +--ro (address-family)?
| | | +--:(ipv4-case)
| | | | +--ro ipv4
| | | | +--ro ipv4-tunnel-sender-address inet:ipv4-address
| | | | +--ro ipv4-extended-tunnel-id rsvp:ipv4-extended-tunnel-id
| | | | +--ro ipv4-tunnel-endpoint-address inet:ipv4-address
| | | +--:(ipv6-case)
| | | +--ro ipv6
| | | +--ro ipv6-tunnel-sender-address inet:ipv6-address
| | | +--ro ipv6-extended-tunnel-id rsvp:ipv6-extended-tunnel-id
| | | +--ro ipv6-tunnel-endpoint-address inet:ipv6-address
| | +--ro rsvp-error-spec
| | | +--ro (error-type)?
| | | +--:(rsvp-case)
| | | | +--ro rsvp-error
| | | +--:(user-case)
| | | +--ro user-error
| | +--ro symbolic-path-name
| | | +--ro path-name? symbolic-path-name
| | o--ro vs-tlv
| | | +--ro enterprise-number? iana:enterprise-number
| | | +--ro (vendor-payload)?
| | +--ro vendor-information-tlv*
| | | +--ro enterprise-number? iana:enterprise-number
| | | +--ro (enterprise-specific-information)?
| | +--ro path-binding
| | x--ro binding-type? uint8
| | x--ro binding-value? binary
| | +--ro (binding-type-value)?
| | +--:(mpls-label)
| | | +--ro mpls-label? netc:mpls-label
| | +--:(mpls-label-entry)
| | +--ro label? netc:mpls-label
| | +--ro traffic-class? uint8
| | +--ro bottom-of-stack? boolean
| | +--ro time-to-live? uint8
| +--ro plsp-id? plsp-id
| +--ro delegate? boolean
| +--ro sync? boolean
| +--ro remove? boolean
| +--ro administrative? boolean
| +--ro operational? operational-status
+--ro path-setup-type
+--ro pst? uint8
The LSP-DB is accessible via RESTCONF.
The PCC’s LSPs are stored in the pcep-topology
while the session is active.
In a next example, there is one PCEP session with PCC identified by its IP address (43.43.43.43) and one reported LSP (foo).
URL: /restconf/operational/network-topology:network-topology/topology/pcep-topology/node/pcc:%2F%2F43.43.43.43
Method: GET
Response Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 | <node>
<node-id>pcc://43.43.43.43</node-id>
<path-computation-client>
<ip-address>43.43.43.43</ip-address>
<state-sync>synchronized</state-sync>
<stateful-tlv>
<stateful>
<lsp-update-capability>true</lsp-update-capability>
</stateful>
</stateful-tlv>
<reported-lsp>
<name>foo</name>
<lsp>
<operational>up</operational>
<sync>true</sync>
<plsp-id>1</plsp-id>
<create>false</create>
<administrative>true</administrative>
<remove>false</remove>
<delegate>true</delegate>
<tlvs>
<lsp-identifiers>
<ipv4>
<ipv4-tunnel-sender-address>43.43.43.43</ipv4-tunnel-sender-address>
<ipv4-tunnel-endpoint-address>39.39.39.39</ipv4-tunnel-endpoint-address>
<ipv4-extended-tunnel-id>39.39.39.39</ipv4-extended-tunnel-id>
</ipv4>
<tunnel-id>1</tunnel-id>
<lsp-id>1</lsp-id>
</lsp-identifiers>
<symbolic-path-name>
<path-name>Zm9v</path-name>
</symbolic-path-name>
</tlvs>
</lsp>
<ero>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>201.20.160.40/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>195.20.160.39/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>39.39.39.39/32</ip-prefix>
</ip-prefix>
</subobject>
</ero>
</reported-lsp>
</path-computation-client>
</node>
|
@line 2: node-id The PCC identifier.
@line 4: ip-address IP address of the PCC.
@line 5: state-sync Synchronization status of the PCC’s LSPs. The synchronized indicates the State Synchronization is done.
@line 8: lsp-update-capability - Indicates that PCC allows LSP modifications.
@line 12: name - Textual representation of LPS’s name.
@line 14: operational - Represent operational status of the LSP:
- down - not active.
- up - signaled.
- active - up and carrying traffic.
- going-down - LSP is being torn down, resources are being released.
- going-up - LSP is being signaled.
@line 15: sync - The flag set by PCC during LSPs State Synchronization.
@line 16: plsp-id - A PCEP-specific identifier for the LSP. It is assigned by PCC and it is constant for a lifetime of a PCEP session.
@line 17: create - The false indicates that LSP is PCC-initiated.
@line 18: administrative - The flag indicates target operational status of the LSP.
@line 20: delegate - The delegate flag indicates that the PCC is delegating the LSP to the PCE.
@line 24: ipv4-tunnel-sender-address - Contains the sender node’s IP address.
@line 25: ipv4-tunnel-endpoint-address - Contains the egress node’s IP address.
@line 26: ipv4-extended-tunnel-id - The Extended Tunnel ID identifier.
@line 28: tunnel-id - The Tunnel ID identifier.
@line 29: lsp-id - The LSP ID identifier.
@line 32: path-name - The symbolic name for the LSP.
@line 36: ero - The Explicit Route Object is encoding the path of the TE LSP through the network.
The LSP control delegations is an mechanism, where PCC grants to a PCE the temporary right in order to modify LSP attributes. The PCC can revoke the delegation or the PCE may waive the delegation at any time. The LSP control is delegated to at most one PCE at the same time.
Following RPC example illustrates a request for the LSP delegation give up:
URL: /restconf/operations/network-topology-pcep:update-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <input>
<node>pcc://43.43.43.43</node>
<name>foo</name>
<arguments>
<lsp xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>false</delegate>
<administrative>true</administrative>
<tlvs>
<symbolic-path-name>
<path-name>Zm9v</path-name>
</symbolic-path-name>
</tlvs>
</lsp>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 2: node The PCC identifier.
@line 3: name The name of the LSP.
@line 6: delegate - Delegation flag set false in order to return the LSP delegation.
@line 10: path-name - The Symbolic Path Name TLV must be present when sending a request to give up the delegation.
The LSP Update Request is an operation where a PCE requests a PCC to update attributes of an LSP and to rebuild the LSP with updated attributes. In order to update LSP, the PCE must hold a LSP delegation. The LSP update is done in make-before-break fashion - first, new LSP is initiated and then the old LSP is torn down.
Following RPC example shows a request for the LSP update:
URL: /restconf/operations/network-topology-pcep:update-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>foo</name>
<arguments>
<lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>true</delegate>
<administrative>true</administrative>
</lsp>
<ero>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>200.20.160.41/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>196.20.160.39/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>39.39.39.39/32</ip-prefix>
</ip-prefix>
</subobject>
</ero>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 2: node The PCC identifier.
@line 3: name The name of the LSP to be updated.
@line 6: delegate - Delegation flag set true in order to keep the LSP control.
@line 7: administrative - Desired administrative status of the LSP is active.
@line 9: ero - This LSP attribute is changed.
The PCEP Extension for PCE-initiated LSP Setup allows PCE to request a creation and deletion of LSPs.
This capability is enabled by default. No additional configuration is required.
The PCE can request LSP creation. The LSP instantiation is done by sending an LSP Initiate Message to PCC. The PCC assign delegation to PCE which triggered creation. PCE-initiated LSPs are identified by Create flag.
Following RPC example shows a request for the LSP initiation:
URL: /restconf/operations/network-topology-pcep:add-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>update-tunel</name>
<arguments>
<lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>true</delegate>
<administrative>true</administrative>
</lsp>
<endpoints-obj>
<ipv4>
<source-ipv4-address>43.43.43.43</source-ipv4-address>
<destination-ipv4-address>39.39.39.39</destination-ipv4-address>
</ipv4>
</endpoints-obj>
<ero>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>201.20.160.40/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>195.20.160.39/32</ip-prefix>
</ip-prefix>
</subobject>
<subobject>
<loose>false</loose>
<ip-prefix>
<ip-prefix>39.39.39.39/32</ip-prefix>
</ip-prefix>
</subobject>
</ero>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 2: node The PCC identifier.
@line 3: name The name of the LSP to be created.
@line 8: endpoints-obj - The END-POINT Object is mandatory for an instantiation request of an RSVP-signaled LSP. It contains source and destination addresses for provisioning the LSP.
@line 14: ero - The ERO object is mandatory for LSP initiation request.
The PCE may request a deletion of PCE-initiated LSPs. The PCE must be delegation holder for this particular LSP.
Following RPC example shows a request for the LSP deletion:
URL: /restconf/operations/network-topology-pcep:remove-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>update-tunel</name>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 2: node The PCC identifier.
@line 3: name The name of the LSP to be removed.
The PCE-initiated LSP control is delegated to the PCE which requested the initiation. The PCC cannot revoke delegation of PCE-initiated LSP. When PCE returns delegation for such LSP or PCE fails, then the LSP become orphan and can be removed by a PCC after some time. The PCE may ask for a delegation of the orphan LSP.
Following RPC example illustrates a request for the LSP delegation:
URL: /restconf/operations/network-topology-pcep:update-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <input>
<node>pcc://43.43.43.43</node>
<name>update-tunel</name>
<arguments>
<lsp xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>true</delegate>
<administrative>true</administrative>
<tlvs>
<symbolic-path-name>
<path-name>dXBkYXRlLXR1bmVs</path-name>
</symbolic-path-name>
</tlvs>
</lsp>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 2: node The PCC identifier.
@line 3: name The name of the LSP.
@line 6: delegate - Delegation flag set true in order to take the LSP delegation.
@line 10: path-name - The Symbolic Path Name TLV must be present when sending a request to take a delegation.
The PCEP Extensions for Segment Routing (SR) allow a stateful PCE to compute and initiate TE paths in SR networks. The SR path is defined as an order list of segments. Segment Routing architecture can be directly applied to the MPLS forwarding plane without changes. Segment Identifier (SID) is encoded as a MPLS label.
This capability is enabled by default. In PCEP-SR draft version 6, SR Explicit Route Object/Record Route Object subobjects IANA code points change was proposed. In order to use the latest code points, a configuration should be changed in following way:
URL: /restconf/config/pcep-segment-routing-app-config:pcep-segment-routing-app-config
Method: PUT
Content-Type: application/xml
Request Body:
1 2 3 | <pcep-segment-routing-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:segment-routing-app-config">
<iana-sr-subobjects-type>true</iana-sr-subobjects-type>
</pcep-segment-routing-config>
|
The PCEP SR extension defines new ERO subobject - SR-ERO subobject capable of carrying a SID.
sr-ero-type
+---- c-flag? boolean
+---- m-flag? boolean
+---- sid-type? sid-type
+---- sid? uint32
+---- (nai)?
+--:(ip-node-id)
| +---- ip-address inet:ip-address
+--:(ip-adjacency)
| +---- local-ip-address inet:ip-address
| +---- remote-ip-address inet:ip-address
+--:(unnumbered-adjacency)
+---- local-node-id uint32
+---- local-interface-id uint32
+---- remote-node-id uint32
+---- remote-interface-id uint32
Following RPC example illustrates a request for the SR-TE LSP creation:
URL: /restconf/operations/network-topology-pcep:add-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>sr-path</name>
<arguments>
<lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>true</delegate>
<administrative>true</administrative>
</lsp>
<endpoints-obj>
<ipv4>
<source-ipv4-address>43.43.43.43</source-ipv4-address>
<destination-ipv4-address>39.39.39.39</destination-ipv4-address>
</ipv4>
</endpoints-obj>
<path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<pst>1</pst>
</path-setup-type>
<ero>
<subobject>
<loose>false</loose>
<sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
<m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
<sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24001</sid>
<ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
</subobject>
</ero>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 16: path-setup-type - Set 1 for SR-TE LSP
@line 21: ipv4-node-id - The SR-ERO subobject represents IPv4 Node ID NAI.
@line 22: m-flag - The SID value represents an MPLS label.
@line 23: sid - The Segment Identifier.
Following RPC example illustrates a request for the SR-TE LSP update including modified path:
URL: /restconf/operations/network-topology-pcep:update-lsp
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>update-tunnel</name>
<arguments>
<lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<delegate>true</delegate>
<administrative>true</administrative>
</lsp>
<path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<pst>1</pst>
</path-setup-type>
<ero>
<subobject>
<loose>false</loose>
<sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
<m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
<sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24002</sid>
<ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">200.20.160.41</ip-address>
</subobject>
<subobject>
<loose>false</loose>
<sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
<m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
<sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24001</sid>
<ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
</subobject>
</ero>
</arguments>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
This extension bring optimizations for state synchronization:
This capability is enabled by default. No additional configuration is required.
The State Synchronization Avoidance procedure is intended to skip state synchronization if the state has survived and not changed during session restart.
The Incremental State Synchronization procedure is intended to do incremental (delta) state synchronization when possible.
The PCE-triggered Initial Synchronization procedure is intended to do let PCE control the timing of the initial state synchronization.
Following RPC example illustrates a request for the initial synchronization:
URL: /restconf/operations/network-topology-pcep:trigger-sync
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
The PCE-triggered Re-synchronization: To let PCE re-synchronize the state for sanity check.
Following RPC example illustrates a request for the LSP re-synchronization:
URL: /restconf/operations/network-topology-pcep:trigger-sync
Method: POST
Content-Type: application/xml
Request Body:
1 2 3 4 5 | <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<node>pcc://43.43.43.43</node>
<name>update-lsp</name>
<network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
</input>
|
@line 3: name - The LSP name. If this parameter is omitted, re-synchronization is requested for all PCC’s LSPs.
The PCC Mock is a stand-alone Java application purposed to simulate a PCC(s). The simulator is capable to report sample LSPs, respond to delegation, LSP management operations and synchronization optimization procedures. This application is not part of the OpenDaylight Karaf distribution, however it can be downloaded from OpenDaylight’s Nexus (use latest release version):
https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/bgpcep/pcep-pcc-mock
The application can be run from command line:
java -jar pcep-pcc-mock-*-executable.jar
with optional input parameters:
--local-address <Address:Port> (optional, default 127.0.0.1)
The first PCC IP address. If more PCCs are required, the IP address will be incremented. Port number can be optionally specified.
--remote-address <Address1:Port1,Address2:Port2,Address3:Port3,...> (optional, default 127.0.0.1:4189)
The list of IP address for the PCE servers. Port number can be optionally specified, otherwise default port number 4189 is used.
--pcc <N> (optional, default 1)
Number of mocked PCC instances.
--lsp <N> (optional, default 1)
Number of tunnels (LSPs) reported per PCC, might be zero.
--pcerr (optional flag)
If the flag is present, response with PCErr, otherwise PCUpd.
--log-level <LEVEL> (optional, default INFO)
Set logging level for pcc-mock.
-d, --deadtimer <0..255> (optional, default 120)
DeadTimer value in seconds.
-ka, --keepalive <0.255> (optional, default 30)
KeepAlive timer value in seconds.
--password <password> (optional)
If the password is present, it is used in TCP MD5 signature, otherwise plain TCP is used.
--reconnect <seconds> (optional)
If the argument is present, the value in seconds, is used as a delay before each new reconnect (initial connect or connection re-establishment) attempt.
The number of reconnect attempts is unlimited. If the argument is omitted, pcc-mock is not trying to reconnect.
--redelegation-timeout <seconds> (optional, default 0)
The timeout starts when LSP delegation is returned or PCE fails, stops when LSP is re-delegated to PCE.
When timeout expires, LSP delegation is revoked and held by PCC.
--state-timeout <seconds> (optional, default -1 (disabled))
The timeout starts when LSP delegation is returned or PCE fails, stops when LSP is re-delegated to PCE.
When timeout expires, PCE-initiated LSP is removed.
--state-sync-avoidance <disconnect_after_x_seconds> <reconnect_after_x_seconds> <dbVersion>
Synchronization avoidance capability enabled.
- disconnect_after_x_seconds: seconds that will pass until disconnections is forced. If set to smaller number than 1, disconnection wont be performed.
- reconnect_after_x_seconds: seconds that will pass between disconnection and new connection attempt. Only happens if disconnection has been performed.
- dbVersion: dbVersion used in new Open and must be always equal or bigger than LSP. If equal than LSP skip synchronization will be performed,
if not full synchronization will be performed taking in account new starting dbVersion desired.
--incremental-sync-procedure <disconnect_after_x_seconds> <reconnect_after_x_seconds> <dbVersion>
Incremental synchronization capability enabled.
- dbVersion: dbVersion used in new Open and must be always bigger than LSP. Incremental synchronization will be performed taking in account new starting dbVersion desired.
--triggered-initial-sync
PCE-triggered synchronization capability enabled. Can be combined combined with state-sync-avoidance/incremental-sync-procedure.
--triggered-re-sync
PCE-triggered re-synchronization capability enabled.
Data Change Counter tool registers a Data Change Listener to a specified topology’s subtree. This will allow us to know the quantity of changes produced under it, with each data change event counter will be incremented.
Installing data change counter tool
feature:install odl-restconf odl-bgpcep-data-change-counter
Once we set the configuration, a new data change counter will be created and registers to example-linkstate-topology.
Important
Clustering - Each Counter Identifier should be unique.
URL: /restconf/config/odl-data-change-counter-config:data-change-counter-config/data-change-counter
Method: PUT
Content-Type: application/xml
Request Body:
1 2 3 4 | <data-change-counter-config xmlns="urn:opendaylight:params:xml:ns:yang:bgpcep:data-change-counter-config">
<counter-id>data-change-counter</counter-id>
<topology-name>example-linkstate-topology</topology-name>
</data-change-counter-config>
|
@line 2: Counter Id - Unique counter change identifier.
@line 3: Topology Name - An identifier for a topology.
Counter state for topology
URL: /restconf/operational/data-change-counter:data-change-counter/counter/data-change-counter
Method: GET
Response Body:
1 2 3 4 | <counter xmlns="urn:opendaylight:params:xml:ns:yang:bgp-data-change-counter">
<id>data-change-counter</id>
<count>0</count>
</counter>
|
@line 2: Counter Id - Unique counter change identifier.
@line 3: Count - Number of changes under registered topology’s subtree.
This section offers advices in a case OpenDaylight PCEP plugin is not working as expected.
Contents
First of all, ensure that all required features are installed, local PCE and remote PCC configuration is correct.
To list all installed features in OpenDaylight use the following command at the Karaf console:
feature:list -i
Check OpenDaylight Karaf logs:
From Karaf console:
log:tail
or open log file: data/log/karaf.log
Possibly, a reason/hint for a cause of the problem can be found there.
Try to minimize effect of other OpenDaylight features, when searching for a reason of the problem.
Try to set DEBUG severity level for PCEP logger via Karaf console commands, in order to collect more information:
log:set DEBUG org.opendaylight.protocol.pcep
log:set DEBUG org.opendaylight.bgpcep.pcep
Before you report a bug, check BGPCEP Bugzilla to ensure same/similar bug is not already filed there.
Write an e-mail to bgpcep-users@lists.opendaylight.org and provide following information: