Service Advertisment Framework and call control discovery (SAF and CCD)

Hi Guys

So today a coworker was telling me about the latest CIPT2 exam which he aced, and he mentioned it featured SAF and CCD heavily.

To me SAF and CCD are totally unknown up until this point: I had heard about them, and knew the theory of what they were meant to accomplish, but I had never used them before. For those of you interested I can say (and pretty sure I am not violating any NDA here) that SAF and CCD are not mentioned on the blueprint, so therefore are not in the exam. Maybe they are now, maybe they will be in the future, I could not tell you. What I can say is at the moment they are not in the blueprint.

So with that aside, I wanted to learn about them anyway because well, i have finished my CCIE voice :p, i just need to know all the new technologies.


So without any further introduction let's talk a little about SAF and CCD and how they work.

SAF and CCD work in conjunction with each other, to provide a method to publish and subscribe (you will hear those terms a lot through this article) directory numbers that belong to particular call agents (such as a CUCM cluster or a CME.) The idea being to provide the same flexiblity for directory numbers that IP routing gives us for static routes vs dynamic routes (i.e. by using a dynamic "routing protocol" (SAF) for directory numbers, we get all the usual benefits such as redundant path selection, simplified changes, best-path selection etc. etc.)

Here are some key concepts about SAF you should know:

There are two types of devices that participate in SAF, a SAF forwarded, which is a router of some description running the SAF protocol, and a SAF client (which is a call manager or other call processing agent.) For CME, obviously your router is both a SAF Forwarded and Client at the same time, the two don't join together but rather communicate with each other through API's, but as far as your router is concerned they are two separate processes.

A router does _not_ have to any voice configuration on it at all to be a SAF forwarded, a forwarded is simply a router that is participating in the routing of the SAF messages.


So, what is the lovely protocol we use for SAF? The protocol itself that communicates from SAF forwarded to SAF forwarded is called SAF-FP (SAF forwarder protocol, super creative name! Give the naming department a gold star for that one! They must be competing hard with the guys who named the protocol that communicates between SAF forwarded to SAF client, which is SAF-CP, for.. you guessed it.. client protocol)

So SAF-FP is based on EIGRP, it uses the same sort of metrics, it uses DUAL for routing loops, etc. etc. Now it's important to note: JUST BECAUSE IT IS BASED ON EIGRP, DOES NOT MEAN YOU NEED TO USE EIGRP AS YOUR DYNAMIC ROUTING PROTOCOL!


Just like PIM (Multicast Routing Protocol) can be used with any underlying routing protocol, so too can SAF, it is totally independent of your routing protocol.

Speaking of sweet sweet candy multicast, SAF uses multicast to discover adjacent neighbors, you can configure static neighbors too if you like, and because its not actually a routing protocol, your static unicast configured neighbors don't even have to be on a common subnet, so along a path you don't actually have to have SAF enabled on every single hop

So if you had:

CME < - SAF-CP -> SAF Forwarder Router < - > Big gigantic Layer 3 network with routers, toaster routers, pancake toaster routers, just plain toasters <-> SAF Forwarder Router <- SAF CP - > CUCM


That is perfectly valid, your two SAF routers can become adjacent over any number of router-toaster hops in your L3 network.


So now that we have the SAF forwarding protocol, let's discuss the SAF packet. A SAF packet will travel through the SAF network. it contains a SAF header which has all the information a SAF forwarder will ever need to look at such as a hop count to prevent routing loops, a service type identifier (in our examples, this is CCD (call control discovery) but SAF can be extended for other purposes as Cisco release more exciting tech, so at some point this service type may change) and some metric stuff too.

The SAF service data portion of the packet is the important part for our SAF clients. A SAF client will read this information if the service type (in the SAF header) is relevant to it. A SAF client will publish services (i.e. advertise prefixes) to the SAF network and will subscribe for CCD updates too (that is, ask for information.) keepalives are also used.



So the SAF-CP is used to exchange info between the SAF client to the SAF forwarder, which then passes it onto other SAF-Forwarders specified as neighbors, and then finally these SAF-forwarders pass on the packet to their own SAF-CP Clients. Simple enough right?


So now we move onto Call Control Discovery, which leverages all this lovely SAF framework we have.

Call Control Discovery allows a call-agent to advertise or publish its locally configured directory number range that it owns (so as us voice guys know, you might have a site with the extension range 5XXXX) to a SAF forwarded, which in turn will advertise it to all other SAF Clients with CCD on the network.

This means by the time SAF is finished all our call agents know about all the directory ranges each of the call agents is "hosting." It also knows the full, PSTN reachable number of these ranges (more on this later.)

So inside these CCD advertisements is the following info:

• Range of Directory Numbers
• IP Address of call agent
• Signal protocol to use (SIP or H.323 for example)

Depending on if you desire rerouting over PSTN for some reason, you may also advertise a PSTN number, but very oddly and confusingly, this is not done by just advertising, such as in our example above:

9305 XXXX

but rather, the instructions used to manipulate the internal directory number (5XXXX) into the full PSTN number. This is called a PSTN failover Digit-Transformation-Rule, or for some reason, this can be shortened to a ToDID rule (those guys in charge of naming sure are earning their pay check with this protocol!)


The way this looks is very similiar to the way you can add/remove digits from a number as it comes into a gateway, so for example, to add 930 to the beginning of our example, your rule would look like:
+619305
(hey, we use E.164 here!)

if you wanted to strip digits from the start (maybe your PSTN number doesn't match your DID, so maybe in our example it is +619300XXXX but that maps to 5XXXX, you can strip digits:

1:+619300

Still with me? good stuff.


Let's talk about CUCM