cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6320
Views
0
Helpful
9
Replies

Feedback on Service Advertisement Framework (SAF)

stefanog
Cisco Employee
Cisco Employee

NOTE: This thread has been created to capture customer and partner feedback for the BRKUCC-2003 breakout session that will be presented at Networkers @ Cisco Live in Barcelona on January 27, 2010. The title of the session is "A New Approach to Call Routing and Dial Plans based on the Service Advertisement Framework".

Hi,

Please reply to this message to provide your feedback to Cisco product managers and architects on the Service Advertisement Framework (SAF) and its potential applications, not only in the area of Unified Communications but also in general.

Does the Call Control Discovery (CCD) service respond to your needs for dial plan simplification?

What other services should Cisco build on top of SAF?

Are you interested in leveraging SAF to create and distribute your own services?

More information on SAF and CCD will be posted on the community site as well as Cisco.com in the coming months.

Thanks,

Stefano Giorcelli

9 Replies 9

Ernest Mikulic
Level 1
Level 1

Thanks Stefano for starting this thread as UC 8.0 and Service Routing w/SAF get ready to FCS. I'll post updates as soon as the Service Routing Cisco.com sites are up and running which should be this Jan or begining of Feb.

Ernest Mikulic

SAF, PFR, & OSPF

Product Mgr, NSSTG

Cisco Systems Inc.

San Jose, CA 95134

Hi Guys,

This looks like a great initiative and having the ability to intelligently advertise higher-order services using intelligent network devices could change the competitive landscape.

I'm a bit of an old git and remember well the use of Novell's Service Advertising Protocol (SAP) within the IPX environment. SAP made life a lot easier in respect of configuration and, importantly, finding service.

CDP is a great low-level discovery tool. In terms of higher-order discovery then I think SAF could really help, especially in a Mobile setting :

  • Video. As I move between locations wouldn't it make sense to use 'local' video resources for transcoding ?. I know this throws up a wider issue of why would we need to Transcode anyway if, for example, we used H.264SVC, but might be useful for devices that are AVC based ?.
  • PhysSec........cameras use SAF to advertise their capability to the network.
  • DMPs.....as above
  • SAF driver on Thin Client devices. This might be handy for disaggregated services whereby the network understands the capability of the Thin Client device (i.e. what can be achieved locally on the device, for example voice/video media) while other services are operating as a VDI bubble in the Data Center.
  • As an extension to the above, use SAF to advertise to the VDI enabled Data Center in order to handshake capability.......i.e. you do some stuff locally and this other stuff you can run in the DC and the reason I can do this is because SAF is telling me what your device can do.
  • Use SAF to advertise capability based upon location (or origin of traffic). i.e., so when my device is connected to a known-good IP network (perhaps using similar to the Cisco Secure Services Client) then give me full steam. However, if I'm connected via a known IP network but this is known to be a VPN-origin address then give me less steam.
  • If I have more than one device (PC, netbook, tablet, smart mobile, device, etc) then use SAF to get an aggregated view of the 'user' rather than individual devices to make intelligent decisions on disaggregated service.
  • Intelligent Data Store (perhaps similar to Hierarchical Storage Management) and based upon location. A bit like WAAS and have the PC think it's dumping files to a share in the DC but it's going to a local store (cache) for it to then be trickled back to the DC.

I'm sure there are a million and one examples of where this could be really useful and look forward to seeing how SAF develops in the very near future.

Kind regards,

Steve

wright-d
Level 4
Level 4

Hi Stefano,

I just viewed your presentation on-line.  Great stuff.  I do have do have a couple of questions.  We are looking to implement PfR shortly and based upon this being a service, I would imagine the call routing will not follow the routing table but the table built for the services?  With the ip slas I would hope it would follow the routing table for optimal performance.

The 2nd question is in regards to CAC.  I believe you stated SAF would not do CAC until the later version of UC 8.0(2).  Would that eliminate the need a gatekeeper network then for on-net dialing?

Thanks!!

Diane Wright

McCormick & Company

Diane,

I will try to answer your PfR question.

>"We are looking to implement PfR shortly and

>based upon this being a service, I would imagine the call routing will

>not follow the routing table but the table built for the services? 

>With the ip slas I would hope it would follow the routing table for

>optimal performance."

SAF distributes call control information between call agents (CUCM, CME, SRST, GWs,...).  IP reachability between the call agents is the same with or without SAF. Voice call signaling and bearer traffic take the best IP path between end points.

PfR can move voice call signaling and bearer traffic to take a better performing path based upon a voice policy.  For example, PfR can redirect voice traffic to take the path with a delay < 100ms or MOS > 3.5.  PfR sends IP SLA probes across all paths to gather the performance measurements of each path to make the best "voice" path policy decision.  All of this is independent and transparent to UC and SAF.

Does this answer the customers question?

Regards,

Scott

Yes, thank you. How about the elimination of the gatekeeper network for

CAC in the next version?

From:

svandeho <community@cisco.com>

To:

<diane_wright@mccormick.com>

Date:

03/04/2010 03:26 PM

Subject:

New message: "Feedback on Service Advertisement

Framework (SAF)"

wright-d,

A new message was posted in the thread "Feedback on Service Advertisement

Framework (SAF)":

https://communities.cisco.com/message/38280#38280

Author : svandeho

Profile : https://communities.cisco.com/people/svandeho

Message:

Hi Diane,

to answer your second question regarding Call Admission Control for SAF, the 8.0(1) release of CUCM will support RSVP over SIP trunks, which means that you can combine SAF CCD for call routing and RSVP for CAC to interconnect multiple clusters without the need for a gatekeeper.

The 8.x SRND, which will appear on Cisco.com around the FCS date of 8.0(1), will explain in more detail the relationship between SAF and RSVP over SIP trunks.

Does this help?

Thanks,

Stefano

Yes, this does help...Now if I could just get my service providers to

support RSVP, my life would be a walk in the park!

From:

stefanog <community@cisco.com>

To:

<diane_wright@mccormick.com>

Date:

03/05/2010 01:04 PM

Subject:

New message: "Feedback on Service Advertisement

Framework (SAF)"

wright-d,

A new message was posted in the thread "Feedback on Service Advertisement

Framework (SAF)":

https://communities.cisco.com/message/38399#38399

Author : stefanog

Profile : https://communities.cisco.com/people/stefanog

Message:

As an note, there are discussions of a possible PFR + RSVP Integration down the road a bit that could help reroute CAC/RSVP calls based on performance.

amansin74
Level 1
Level 1

Its been year since release . I am new to SAF now , wanted to know how is it working in industry . also , can someone suggest me How RSVP + SAF can be implemented to remove gatekeeper . I have implemented SAF in our LAB. but need to know about CAC in SAF.

Thanks to all

“If you have knowledge, let others light their candles in it.”
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: