Cisco® Service Advertisement Framework (SAF), initially released as part of Cisco IOS® Software 12.5(1)M in October 2009, provides host applications the ability to perform service advertisement, discovery, and selection in the network. Using SAF, host application services are automatically adaptable to changes in both the network and application in real-time through SAFs capabilities.
Cisco SAF is a dynamic communications framework for network applications that allows servers and clients to advertise and discover services. The network-based Service Advertisement Framework (SAF) application is designed to propagate information in the same way that routing propagates information and thus allows customers greater scale, availability, and adaptability to deploy and manage applications across the enterprise.
The nature of system configuration today between application clients and servers is that configuration is primarily statically done and results in large barriers to deployment, reconfiguration, and redeployment in any typical medium to large scale enterprise application. Typically once a service is put in place and all the clients and servers are statically configured for that service, despite any business needs otherwise, the effort and cost to move, add, change, or delete any portion of the system are simply barriers to the business. The desire for companies to improve the flexibility and availability of their application services results in further additional costly manual configuration and management tool investments. Normally these different aspects of the system are only aware of each other by changing statically configured information or though other limited service discovery mechanisms such as Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Bonjour, or Lightweight Directory Access Protocol (LDAP) (see Table 1).
Table 1. Service Discovery Mechanisms
Wide Area Bonjour
Relies on DNS, which (depending on the deployment model) may be a potential single point of failure. DNS may also no respond well to the dynamic nature of some applications.
Central directory for service registration and discovery: potential single point of failure. Represents an overlay on the network (i.e. no real network integration.
PNRP + Other P2P
Distributed database, but relies on intelligence and load on the clients.
Uses multicast to announce services. Can very chatty. Scale issues.
Stores service information in distributed directory. Client uses RPC-based lookup API. No network integration. Not widely deployed.
Uses the DNS SRV record type to store service information including priority and weight.
Carrying "Stuff" *in* Routing Protocols
Storage of information may become an issue for most IGPs as it would impact routing convergence and memory consumption.
To help our customers overcome some of these complexities and limitations Cisco introduced SAF, which can help reduce costs while improving the adaptability of applications and services over their entire lifecycle. Now greater ease of deployment, dynamic and scalable lookups, selection and reconfiguration of application services can be realized while at the same time helping customers meet their rapidly evolving business needs. Cisco SAF provides a dynamic and real-time network-based messaging service for clients, servers, and applications.
Lower Application TCO Through Service Advertisement
One goal of SAF is to lower the application TCO by helping reduce the costs of initial deployment and lifecycle costs of redeployment and reconfiguration. For example, instead of a traditional client and server deployment model in which all the clients and servers need to be manually and statically configured to each other, users can simply discover their target application services in the network dynamically at startup just by doing a SAF lookup. Such a model can be much easier to deploy and manage compared with the traditional overlay and centralized approaches, whose models are hindered in terms of scalability and flexibility.
Such setups shift or remove much of the configuration and management burden on client and server applications to the network, where they need only know how to look up their servers and peers or attain reachability. The network can take care of the applications' service advertisement routing, distribution, updates, or unreachable announcements through the LAN and across the WAN. This helps reduce much of the costs normally associated with traditional, static, manual configuration processes.
The Four Elements of SAF
Figure 1. SAF Client Nodes, Forwarder Nodes, Transit Forwarder Nodes, and Transparent Nodes
The four core node types or elements that participate in Cisco SAF and that make up the framework include the SAF clients, SAF forwarder nodes, SAF transit forwarder nodes, and SAF transparent nodes (Figure 1). The SAF client normally resides in a host application that wishes to advertise a service to the network or request (discover) a service from the network or both. This way, the SAF client establishes a relationship to an SAF forwarder node in order to advertise or discover services. Next an SAF client may send its own advertisement that contains header information and any additional information it may require as further application-specific opaque data.
The Cisco IOS Software SAF forwarder node provides the relationship between SAF clients and the network and is normally found at the edges or boundaries of a network. The forwarder node receives the service advertisements and keeps a copy before forwarding the advertisements to its neighboring SAF nodes. The client and the forwarder relationship maintains the advertisement, and should a client remove a service or disconnect from the forwarder node, this node will inform the rest of the SAF network about the services that are no longer available. The forwarder node will keep a copy of the entire advertisement (header and opaque data) that it forwards on to other SAF peers.
The SAF advertisement is intended to provide sufficient information about the service, what is being offered, and how to contact the service and can be used to update high-level information between services as it changes. For example a directory service would advertise that it was a directory service for Cisco.com and is reachable using LDAP at IPv4 address 10.1.1.1 TCP 389. Another example might be if Unified Communications call agents would advertise themselves as a call agent at IPv4 address 10.2.1.1 E.164 address 330XXXXXX.
Inside the SAF message used by the clients and the forwarders, the header contains information that the SAF network requires in order to propagate the advertisement correctly and maintain the integrity of the advertisements within the network. This would include the source of the advertisement, which is the advertising SAF node, the type of service being advertised, and how to contact the service point or service advertiser. An SAF client that requires a service would establish a relationship to the forwarder and request whatever type of services it requires. The SAF forwarder node then sends current advertisements to the clients that were previously learned from the other SAF forwarders.
The SAF transit forwarder is a node with no clients connected; this type of node is generally found within the network and provides the connectivity "backbone" between the forwarder nodes. Transit nodes are optional in small deployments as all nodes might just be forwarder nodes with simple peering arrangements. When a transit node receives advertisements from an SAF peer, the node forwards a copy to all other peers and then discards the opaque data, keeping a copy of the header information. The transit node requires the header information so that advertisements can be updated or flushed during topology changes. Using the header information the entire framework helps ensure that during connectivity changes the integrity and connectivity of the available services are maintained and correct. This allows the framework to become segmented, operating autonomously with only the reachable services being advertised. As connectivity is reestablished with the services, they become reachable and will be advertised once more.
Any node in the network that does not understand SAF is considered a transparent or non-SAF node. As SAF messages are IP based, they will pass through such network nodes unaffected.
Enterprise applications that choose to distribute various services throughout their networks can better help ensure availability, scalability, and ease of deployment. The ability to advertise these services will allow networks to advertise application services transparently to various service clients located anywhere throughout the network. Cisco SAF focuses on Cisco's strength in IP routing to provide end-to-end service availability awareness for our customers to help them increasing the value of their networks, reducing application configuration complexity and operational costs, while increasing availability.
The first SAF supported application will be Cisco Unified Communications v8.0 Call Control Discovery.
For More Information
Please visit http://www.cisco.com/go/saf for more information or contact your Cisco sales representatives directly. SAF is a feature of Cisco IOS Software and can be used starting in October 2009 with Cisco IOS Software Release 12.5(1)M.