This topic describes the characteristics of SAF.
- SAF supports the advertisement of any service.
- CCD is the first Cisco application that uses SAF to advertise services (call routing).
- SAF network components:
- SAF forwarders
- Exchange service information with each other
- Use SAF-FP
- SAF clients
- Advertise services to and learn services from SAF forwarders
- Use SAF-CP to interact with SAF forwarders
- Serve (with CCD) as call agents
- SAF forwarders
SAF is a network-based, scalable, bandwidth-efficient, real-time approach to service advertisement and discovery.
SAF can be used to advertise any service to, and learn any service from, the SAF-enabled network. CCD is the first Cisco application that utilizes SAF. As mentioned earlier, the devices within the SAF network are SAF forwarders. SAF forwarders are responsible for propagating services within the network. SAF forwarders do not interpret the service information; SAF forwarders only guarantee fast and reliable exchange of the information. SAF forwarders use the SAF-FP between each other.
SAF forwarders can interact with SAF clients. A SAF client is an entity that processes SAF service data. A SAF client can independently advertise (generate) SAF service information to be propagated in the network, or it can subscribe to (receive) SAF service information. A SAF client communicates with one or more SAF forwarders by the SAF-CP. With CCD, the SAF client is a call agent such as Cisco Unified Border Element, Cisco UnifiedSRST, Cisco Unified Communications Manager, Cisco Unified Communications Manager Express, or Cisco IOS gateway.
SAF Client Types
This section describes the two available CCD SAF client types.
- The SAF forwarder is always a Cisco IOS router.
- Two types of SAF clients:
- SAF client and SAF forwarder are different devices.
- SAF client is Cisco Unified Communications Manager.
- SAF-CP is used.
- SAF client and SAF forwarder are colocated functions within the same device.
- SAF clients are Cisco Unified Communications Manager Express, Cisco Unified SRST, Cisco Unified Border Element, and Cisco IOS gateways.
- An internal API is used.
SAF clients register to the network or, more precisely, to a SAF forwarder. SAF clients can publish services (that is, advertise information) to the SAF network or subscribe to services (that is, request information) from the SAF network. To allow the SAF client and the SAF forwarder to detect dead peers quickly (for example, if the device is powered off), they exchange keepalives.
SAF forwarders propagate updates that are received from SAF clients that publish services to other SAF forwarders. SAF forwarders send updates to SAF clients, which subscribe to services. In addition, SAF forwarders exchange hellos with other SAF forwarders to detect dead peers.
A SAF forwarder is always a Cisco IOS router. Remember that SAF forwarders do not process the propagated service information. Their function is to propagate the information within the SAF network and to pass it on to SAF clients.
SAF clients then interpret the service information. With CCD, the SAF client is a call control device, which sends and receives call-routing information. Depending on the type of call control device, the CCD device can be an internal or external SAF client:
- External: The SAF client and the SAF forwarder are two different devices and use SAF-CP for communication. An example of a CCD external SAF client is Cisco Unified Communications Manager.
- Internal: The SAF client and the SAF forwarder are two different functions within the same device—a Cisco IOS router. The SAF client and the SAF forwarder use an internal API for communication. Examples of CCD internal SAF clients are Cisco Unified Border Element, Cisco Unified SRST, Cisco Unified Communications Manager Express, and Cisco IOS gateways.
SAF clients and SAF forwarders exchange SAF messages that consist of two components:
- SAF header: The SAF header is relevant mainly to SAF forwarders. It identifies the service type (for example, CCD) and includes information that is relevant for the dynamic distribution of SAF services, such as metrics and loop detection information.
- SAF service data: SAF service data is relevant to the SAF client only. A SAF forwarder cannot interpret the SAF service data. SAF service data includes the IP address and port of the advertising SAF client and detailed client data that describes the advertised service. With CCD, client data includes call-routing information such as directory numbers, the IP address of the call control device, the signaling protocol that is used to communicate with the call control device, PSTN prefixes, and so forth.
SAF Routing Characteristics
This section describes the main characteristics of SAF routing.
- SAF-FP uses features and functions of EIGRP, including the following:
- Bandwidth percentage
- Hello interval
- Hold time
- Split horizon
- Authenticated updates
- Incremental updates (only when changes occur)
- Independent of IP routing protocol
- Dynamic (EIGRP, OSPF, BGP, and so on)
SAF-FP uses features and functions of the EIGRP for SAF routing. Features and mechanisms from EIGRP include the DUAL to prevent loops, reliable transport over IP (IP protocol 88), support for authenticated updates, and incremental, event-triggered updates for fast convergence and low-bandwidth consumption. Configurable parameters that relate to these EIGRP-derived features include bandwidth percentage, hello interval, hold time, split horizon, maximum hops, and metric weights.
Although SAF routing is very like EIGRP, it is independent of the used IP routing protocol. SAF works over static routing and in networks that use dynamic routing protocols such as EIGRP, OSPF, and BGP.
SAF forwarders can be, but do not have to be, directly neighboring devices. If they are Layer 2-adjacent, there are two configuration options:
- Multicast: When multiple SAF forwarders are connected via a broadcast-capable medium like a LAN using Ethernet, they can communicate with each other via multicasts. This communication allows a dynamic neighbor discovery because there is no need to statically configure the Layer 2-adjacent neighbors.
- Unicast: When it is not desired that all SAF devices on a broadcast-capable medium automatically discover each other, SAF forwarders can be configured to send updates to statically configured neighbors only via unicast messages. In the figure in the “SAF Client Types” section, the lower-left example shows three routers that are connected to an Ethernet. However, other than in the upper-right example, they should not build adjacencies between each other in a full-mesh fashion. Instead, they should communicate in a hub-and-spoke fashion only (one router communicates with both of the others, and the other two routers do not communicate directly with each other).
When SAF forwarders are not Layer 2-adjacent—that is, when there are one or more IP hops between them—these nonadjacent neighbors must be statically configured. Discovery is not possible.