Category Archives: QoS

Juniper Seminar: Key Takeaways

Posted on by
1

Yesterday, I attended the Toronto session of a Juniper seminar focused on security and datacenter solutions.

The following are the key takeaways I extracted:

  • Juniper is standards-oriented. In the area of NAC, e.g., they are co-chairing with Symantec the Trusted Computing Group‘s Trusted Network Connect (TNC) effort. It’s not (yet) clear to me how the TCG interplays with the IETF … And speaking of IETF, Juniper’s Network and Security Manager (NSM) makes use of IETF’s NetConf standard in, e.g., simplifying the provisioning of new devices on the network.
  • Juniper has a comprehensive portfolio of offerings at the intersection of security and networking. Interestingly, Juniper’s Security Threat Response Manager (STRM) OEMs technology from Q1Labs.
  • 802.1x is a solid bet. Based on a number of trends, and a variety of requirements, Juniper promotes use of 802.1x. Even though this is a path we’ve already identified, it’s good to have it independently validated …
  • Security, and other services, can be offloaded to purpose-built devices in the core. Instead of inserting, e.g., a FWSM into a device (e.g., a Cisco 65xx) that is primarily providing routing and switching services, Juniper has recently introduced a new paradigm with its SRX series. Touted as a services gateway for the core, the purpose of the SRX is to offload from the routing/switching devices various services – e.g., firewall, VPN, etc. As I understand it, the SRX runs JUNOS with various enhancements from ScreenOS (their O/S from their firewall devices). Even if you don’t make use of Juniper solutions, it may make sense to understand and potentially apply the offloading-of-services concept/paradigm in your core.
  • Juniper allows for the virtualization of switches. Juniper Virtual Chassis (VC) is currently only available for their EX 4200 platform. With VC, it’s possible to virtualize up to 10 physically distinct EX 4200s into one. Within the next year, Juniper plans to provide VC on, e.g., their EX 8200 platform. Because vmWare’s vMotion requires layer-2 adjacency, server virtualization may prove to be a significant driver for switch virtualization. I expect that this will prove, e.g., to be particularly relevant in providing failover services (at the networking layer) between multiple, physically distinct, and geographically separated locations.

Even though the event appeared to be more of the sales-y/marketing-y variety, there was substantial technical content in evidence.

CANHEIT 2008: York Involvement

Posted on by
Reply
York University will be well represented at CANHEIT 2008. 
Although you’ll find the details in CANHEIT’s online programme, allow me to whet your appetite regarding our contributions:

QoS On My Mind …

Posted on by
1
QoS has been on my mind lately.
Why?
I suppose there are a number of reasons.
We’re in the process of re-architecting our data network at York. We’re starting off by adding redundancy in various ways, and anticipate the need to address QoS in preparing for our future deployment of a VoIP service.
Of course, that doesn’t mean we don’t already have VoIP or VoIP-like protocols already present on our existing undifferentiated network. In addition to Skype, there are groups that have already embraced videoconferencing solutions that make use of protocols like RTP. And given that there’s already a Top 50 list of Open Source VoIP applications to choose from, I’m sure these aren’t the only examples of VoIP-like applications on our network. 
At the moment, I have more questions about QoS than answers. 
For example:
  • If we introduce protocol-based QoS, won’t this provide any application using the protocol access to a differentiated QoS? I sense that QoS can be applied in a very granular fashion, but do I really want to turn my entire team of network specialists into QoS specialists? (From an operational perspective, I know I can’t afford to!)
  • When is the right time to introduce QoS? Users are clamoring for QoS ASAP, as it’s often perceived as a panacea – a panacea that often masks the root cause of what really ails them … From a routing and switching perspective, do we wait for tangible signs of congestion, before implementing QoS? I certainly have the impression that others managing Campus as well as regional networks plan to do this. 
  • And what about standards? QoS isn’t baked into IPv4, but there are some implementations that promote interoperability between vendors. Should MPLS, used frequently in service providers’ networks, be employed as a vehicle for QoS in the Campus network context? 
  • QoS presupposes that use is to be made of an existing network. Completely segmenting networks, i.e., dedicating a network to a VoIP deployment, is also an option. An option that has the potential to bypass the need for QoS. 
I know that as I dig deeper into the collective brain trust answers, and more questions, will emerge. 
And even though there are a number of successful deployments of VoIP that can be pointed to, there still seems to be a need to have a deeper discussion on QoS – starting from a strategic level. 
As I reflect more and more on QoS I’m thinking that a suitably targeted BoF, at CANHEIT 2008 for example, might provide a fertile setting for an honest discussion.