The Internet Engineering Task Force http://www.ietf.org/ meets three times a year (fall, spring, and summer) in different parts of the world to discuss standards (called Request For Comments or RFCs) for the Internet. These meetings are the place to discuss everything related to the Internet Protocol (IP), the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP), Session Initiation Protocol (SIP), etc.
If you have not been to IETF meetings, here are two impressions of working group sessions:
http://www.youtube.com/watch?v=uJHtecw8lcU&feature=channel_page
http://www.youtube.com/watch?v=D4ga3iaU8zU&feature=channel_page
This was the second IETF meeting I attended (the first one was in 1997), and it was quite fascinating to observe the changes. First, many of the 100 or so IETF working groups are now running out of work items. IETF seems to be losing 5 working groups per meeting or 15 per year. If this trend continues, IETF can disappear by 2015, someone commented. At the meeting in San Francisco, most groups finished early because they ran out of agenda items.
Another change is in the number of participants representing vendors as compared to folks from education and research. It looks like a lot of vendors have flooded IETF over the years and - some say - made it slower, more competitive, and less efficient. You can look at the list of attendees https://www.ietf.org/registration/ietf74/attendance.py and make up your own mind.
Key topic of the meeting was IPv4–IPv6 migration. Service providers are really run out of IPv4 addresses – especially in Asia Pacific – and there was a sense of urgency to help. The Internet Architecture Board (IAB) created a document with their thoughts on the issue http://tools.ietf.org/html/draft-iab-ipv6-nat-00. The firewall folks discussed what functions to put in an IPv6-to-IPv6 firewall. There was a BOF (initial discussion of a new topic) on sharing IPv4 addresses among multiple users – this is to temporarily alleviate the pain of ISPs that are running out of IP addresses. Migration to IPv6 is important for Voice over IP and Video over IP products (basically the entire Polycom product portfolio) because they all have to support IPv6 and run in a dual stack (IPv4 and IPv6) mode for the transitional period that can span over many years. Note that IPv6 support is trivial. In addition to supporting the news IP packet header, endpoints have to also support a version of the Dynamic Host Configuration Protocol (DHCP) that supports IPv6, a special specification that describes how the Domain Name System (DNS) will support IPv6, etc.
Another new thing at IETF is the work on new transport protocols that enhance UDP and TCP. The Datagram Congestion Control Protocol (DCCP) is like UDP but with congestion control. While adding congestion control to the datagram transport protocol is not a bad technical idea, the business implications are huge. It looks like today even the two existing transport protocols (UDP and TCP) are one too many, and applications migrate from TCP to UDP because of its simplicity. Even signaling for real-time applications, which is the best fit for TCP, is frequently transported over UDP. There is also an effort to specify Transport Layer Security (TLS) over UDP.
Video and telepresence systems – such as Polycom RPX, TPX, and HDX – use UDP for transport of real time traffic (voice and video packets). Migrating to the DCCP protocol may make sense in the future if the congestion control mechanisms in DCCP are supported end-to-end. This is not the case today.
The Secure Transport Control Protocol (STCP) is another new transport protocol, a better version of TCP. I am not sure why STCP is better than just running Transport Layer Security (TLS) on top of TCP but the big question is whether there is space for additional transport protocols (beyond UDP and TCP). Video systems today are using TLS and TCP for secure transport of signaling messages during call setup and call tear-down STCP will therefore have no impact on video equipment, since TLS over TCP and TLS over UDP are doing beautiful job securing the communication.
DIAMETER was originally developed as a authentication protocol (to replace RADIUS) but is now adopted by many service providers and IETF is trying other uses, for example, for negotiating Quality of Service (QOS) and even for management of Network Address Translation (NAT) functions in carrier-to-carrier firewalls. Video applications require a lot of network resources (bandwidth, low latency and jitter, and low packet loss) and communicating QOS requirements from a video application such as Polycom CMA 5000 to a policy engine controlling the routers and switches in the IP network is a great idea. A standard solution based on DIAMETER would help interoperability among video vendors and IP networking equipment vendors.
As I already wrote in the summary of the International SIP Conference http://videonetworker.blogspot.com/2009/03/summary-of-international-sip-conference.html, SIP is getting too complex - with 140 RFCs and hundreds of internet drafts. IETF understands that the complexity of SIP is a problem and wants to create base SIP specification that includes only the key functionality. The problem is that different people within IETF want to include different set of RFCs (subset of the 140 SIP-related RFCs) in the base specification. Polycom has implemented a great deal of SIP RFCs in its voice and video products and is indeed interested in a simpler version of SIP that will ensure robust interoperability across the industry and include the basic call features that everyone uses, not the fancy ones that are rarely used.
I attended the meetings of the two IETF working groups that discuss conferencing: Centralized Conferencing (XCON) and Media Server Control. While XCON is focused on conference call setup, the Media Server Control group defines a protocol between a Media Resource Broker (MRB) and Media Server (MS), which is useful when you have a conferencing application control one or more conference servers (MCUs). When completed this standard could allow the Polycom Distributed Management Application to control non-Polycom MCUs, for example, Scopia MCUs from RadVision.
IETF is obviously getting into a mature phase and did what I would call ‘tribute to MPLS’ in Hollywood Oscar ceremony-style. They tried to portrait Multi-Protocol Label Switching as a great success of IETF standardization but many in the audience pointed out that MPLS interoperability among vendors and among operators just was not there.
No comments:
Post a Comment