PCE Topology Notifications with OpenDaylight Helium

Helium SR3

OpenDaylight released its third maintenance release for Helium last month. Helium SR3 included a lot of bug fixes across OpenDaylight projects. In this blog, I would like to share my experience with PCE topology notifications available in SR3.

Notifications

The OpenDaylight controller sal-remote YANG model defines the RPC notification subscription service and data change notification constructs. Change-event notification subscription makes it possible to obtain notifications about data manipulations (inserting, changing, deleting) that are done on any specified part of any specified data store with specific scope.

PCE Topology Notifications

PCE topology notification is available in Helium SR3. This feature allows the user to subscribe to a notification stream and listen for asynchronous remote notifications through WebSocket. The changes that get notified are:

    • Addition, update, deletion of Path Computation Clients (PCC)
    • Addition, update, deletion of Label Switched Paths (LSP)

Test Setup

The setup has four routers running the IOS XRv 5.3 image, a CentOS 7 VM hosting OpenDaylight Helium SR3, and Packet Design’s SDN Management and Orchestration Platform acting as remote notification listener.

PCE1

The routers are configured as path computation clients.

RP/0/0/CPU0:PE-203#show running-config mpls traffic-eng pce
Tue Apr 21 19:06:20.996 UTC
mpls traffic-eng
 pce
  peer source ipv4 10.66.0.203
  peer ipv4 10.64.19.1
  !
  stateful-client
   instantiation
   timers redelegation-timeout 0
   timers state-timeout 0
   delegation
  !
 !
!

The OpenDaylight controller has PCEP peering established using the ‘pcep-topology-stateful07’ module with all four routers.

RP/0/0/CPU0:PE-203#show mpls traffic-eng pce peer stateful
Tue Apr 21 19:09:05.635 UTC

PCE Address 10.64.19.1
State Up
  PCEP has been up for: 4w6d
Precedence 255
Learned through:
  Static Config
Sending KA every 30 s
Time out peer if no KA received for 120 s
Tolerance: Minimum KA 10 s

Stateful
  Update capability
  Instantiation capability


A Python-based remote listener in the Packet Design platform subscribes to the notification stream for the PCE topology changes by sending a RESTCONF request as below:

POST http:://<ODL IP>:8181/restconf//operations/sal-remote:create-data-change-event-subscription

<?xml version="1.0" encoding="UTF-8"?>
<input xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:remote">
  <path xmlns:a="urn:TBD:params:xml:ns:yang:network-topology">/a:network-topology/a:topology[a:topology-id=\'pcep-topology\']</path>
  <datastore xmlns="urn:sal:restconf:event:subscription">OPERATIONAL</datastore>
  <scope xmlns="urn:sal:restconf:event:subscription">SUBTREE</scope>
</input>

On successful subscription, OpenDaylight responds. The response contains URL information in which the notifications will be available.

{
  "output": {
    "stream-name": "network-topology:network-topology/network-topology:topology/pcep-topology/datastore=OPERATIONAL/scope=SUBTREE"
  }
}

Using WebSocket, the listener binds to the URL and listens for any changes in the PCE data store. As an example, OpenDaylight sends the following data when a PCC becomes unavailable:

<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2015-04-21T09:14:49-07:00</eventTime>
  <data-changed-notification xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:remote">
     <data-change-event>
        <path xmlns:odff="urn:TBD:params:xml:ns:yang:network-topology">/odff:network-topology/odff:topology[odff:topology-id='pcep-topology']</path>
        <operation>updated</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:nhqu="urn:TBD:params:xml:ns:yang:network-topology" xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep" xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">/nhqu:network-topology/nhqu:topology[nhqu:topology-id='pcep-topology']/nhqu:node[nhqu:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:stateful-tlv/stateful:stateful/stateful:lsp-update-capability</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:hnpq="urn:TBD:params:xml:ns:yang:network-topology" xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep">/hnpq:network-topology/hnpq:topology[hnpq:topology-id='pcep-topology']/hnpq:node[hnpq:node-id='pcc://10.66.0.243']/pn:path-computation-client</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep" xmlns:refs="urn:TBD:params:xml:ns:yang:network-topology">/refs:network-topology/refs:topology[refs:topology-id='pcep-topology']/refs:node[refs:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:state-sync</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep" xmlns:sdqu="urn:TBD:params:xml:ns:yang:network-topology" xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">/sdqu:network-topology/sdqu:topology[sdqu:topology-id='pcep-topology']/sdqu:node[sdqu:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:stateful-tlv/stateful:stateful</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:jilm="urn:TBD:params:xml:ns:yang:network-topology">/jilm:network-topology/jilm:topology[jilm:topology-id='pcep-topology']/jilm:node[jilm:node-id='pcc://10.66.0.243']/jilm:node-id</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:jmxc="urn:TBD:params:xml:ns:yang:network-topology" xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep">/jmxc:network-topology/jmxc:topology[jmxc:topology-id='pcep-topology']/jmxc:node[jmxc:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:ip-address</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:jeom="urn:TBD:params:xml:ns:yang:network-topology">/jeom:network-topology/jeom:topology[jeom:topology-id='pcep-topology']/jeom:node[jeom:node-id='pcc://10.66.0.243']</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:gils="urn:TBD:params:xml:ns:yang:network-topology" xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep">/gils:network-topology/gils:topology[gils:topology-id='pcep-topology']/gils:node[gils:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:stateful-tlv</path>
        <operation>deleted</operation>
     </data-change-event>
     <data-change-event>
        <path xmlns:crabbe="urn:opendaylight:params:xml:ns:yang:pcep:crabbe:initiated" xmlns:pn="urn:opendaylight:params:xml:ns:yang:topology:pcep" xmlns:qjpp="urn:TBD:params:xml:ns:yang:network-topology" xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">/qjpp:network-topology/qjpp:topology[qjpp:topology-id='pcep-topology']/qjpp:node[qjpp:node-id='pcc://10.66.0.243']/pn:path-computation-client/pn:stateful-tlv/stateful:stateful/crabbe:initiation</path>
        <operation>deleted</operation>
     </data-change-event>
  </data-changed-notification>
</notification>

Conclusion

Remote notification is a very powerful feature that SDN applications could use to know the near real-time changes happening in the network. At Packet Design, we are using this as one of our cues to build SDN analytics applications. A feature request has been made to the OpenDaylight community to return the notification response in JSON instead of XML.