SAF: Service Advetisement Framework

Service Advetisement Framework (SAF) is a method to transport discovery information that would typically resides locally across Wide Area Networks. A SAF-enabled network will transport encapsulated messages and distribute those as it they were part of an IP routing protocol.

Current Cisco implementation leverage EIGRP as a transport medium, independent of the actual routing protocol; could be a BGP, OSPF or IS-IS routed network.

The first application I want to spend a bit more time on is Call-Control Discovery.

Problematic with a large number Call-agent is to have them inter-working and in particular adjusting dial-plan amongst and between them. Previous to SAF, two options were offered as depicted below:

Fully meshed network of h.323 or SIP trunks

Centralized SIP proxy or h.323 gatekeeper

You’ll note that in both case the operational overhead and technical complexity can ramp up pretty quickly as the number of call-agents to inter-work is growing.

Cisco Unified Communications is using a new service, CCD, that leverages SAF to exchange call routing information, automatically, between multiple SAF-enabled call control systems (like CUCM, CUCME, CUBE). This permits those systems to update their call routing table dynamically.

SAF enabled network

The call-control, being a SAF-client, is sending CCD information to the first connected SAF-forwarder, a router in this case. CCD is contained in a SAF Advertisement, itself having a header and ‘service data’ payload.

Terminology:

SAF Client: any application wishing to advertise a service to the network or request a service from the network or both
SAF Forwarder: router feature – provides relationship between client and framework, stores service information and propagates it to other forwarders
Service: any information that a SAF client wishes to advertise and “consume” (e.g., dial plans for CCD)
SAF Advertisement: carries service information, consists of SAF Header and Service Data
Non-SAF Node: any router that does not run the SAF protocols

How does it work ?

In the following example, you have the San Jose site updating, via the SAF-enabled  network, the New-York office with its call routing information.

Then New-York office is also sending its CCD to the SAF-enabled network, and by which San Jose call-control also gets updated call routing information.

Now a third call-control, London, is added to the scheme, the CCD does not need to be re-send by the call-control as it’s the SAF-agent that will update the new call-control, without other intervention. In the meantime, London’s CCD will be propagated across the SAF-enabled network.

If for any reason the IP path becomes unavailable to a specific call agent, the network will update itself the call routing information, alerting the other call-control to use the PSTN path to reach those location.

And the beauty of this, it all happened without any administrative actions with regards to the call-routing…. great isn’t it  🙂

Stay tuned to an upcoming post on how to configure CUCM to use SAF.