5G is the latest generation of cellular network standards. There’s a tremendous amount of activity around it in the industry. But how does 5G relate to Internet technology? Are there 5G-related work items that the IETF should be working on, for instance?
While at times the 5G stories take on an almost myth-like nature, the basics underneath 5G are concrete changes in the technology and our increasing needs for communication. The traffic growth for both our smartphones and homes continues to be exponential. And as organisations and societies increasingly connect their systems, there are also many new needs.
5G responds to these needs with new radio technology and a core network that employs state-of-the-art network technologies such as an increased use of cloud, virtualisation, and open source components and processes. From a standards perspective, the timelines for the first systems are very near. The 5G work happens to a large extent in 3GPP, as did previous generations. The work on 5G is planned to take place in two releases, of which the first one is Release 15, scheduled to be stable and all protocols completed latest by September 2018, just 14 months away. Additional work will be done in Release 16, which will complete by March 2020.
What is 5G?
But what exactly is 5G then? First, it is a new, very capable radio. With beamforming, MIMO antenna technology, and frequency bands reaching to millimeter waves, it provides both higher transmission speeds and serves more users at the same time. The new radio is also needed to serve mass deployment of networked sensors, and to enable various mission-critical services that may require better latency or reliability characteristics. 5G radio can provide speeds in the Gigabit range, up to 10 Gbps or even beyond, although for large numbers of users the speeds are lower, but still target at least tens of megabits per user, for tens of thousands of users.
Second, 5G targets a set of use cases, such as the familiar mobile broadband use case. But 5G is also intended to open the use of communication and cellular networks for many new industries. The goal is to be able to tailor communication platform for a wide range of different services, ranging from low power IoT devices to self-driving
cars, from mission critical public safety communication to providing services to energy providers. any of these use cases were hard to provide with previous generation technologies. For instance, one use case is about controlling remote machinery — an example of a service that benefits from lower latencies that 5G provides. There is also a higher demand on flexibility and configurability/orchestration.
From an IP networking perspective, as noted, 5G follows the same evolution as the rest of the networking industry. From a practical perspective, this is a big change, however, and requires effort. The work on details is ongoing for Release 15, but architecturally, the key directions are clear.
To give a few practical examples, interfaces to the devices are relatively similar to those in 4G. One difference is an ability to place different devices in different virtual networks or “slices”, which can be tuned and evolve independently from each other, both in resources and networking technology behind. Another difference to 4G is that the 3GPP security group plans to enable a more flexible authentication framework for the devices. And some of the control protocols inside the network may be changed from DIAMETER-based ones to REST-based APIs. From what we understand, the tunneling-based architecture for mobility is not changing, but of course with most services being provided in virtualised environments, the tunnel endpoints may physically reside in different places.
It should also be said that 5G is not a replacement for Internet-based services or Internet technology: majority of the traffic that 5G will carry is for the usual Internet services, like videos from content providers. 5G is also not immune to impacts from Internet evolution. For instance, we’ve seen big changes in use of encryption in the Internet, transport protocols are evolving, the use of CDN systems is growing, and all networks are becoming virtualised, software-defined, and cloud-resident systems. 5G networks need to serve the Internet that continues to evolve in this manner.
Is there an IETF connection?
It is useful to understand how 5G affects Internet technology. IETF work has been and will be affected by 5G. To begin with, the IETF works on many of the general facilities that modern networked systems such as 5G are based on.
Conceptually, one can think of the interactions as falling in the following categories:
New dependencies on existing IETF technology. For instance, the flexible authentication framework mentioned above is EAP (RFC 3748, RFC 5448). This is likely to be merely a reference to existing RFCs, or if additions are needed, they are small.
Dependencies to ongoing work at the IETF. This includes various general facilities as noted above, but also other things. For instance, the IETF DETNET working group defines mechanisms to guarantee deterministic delays for some flows across a network. As one of the 5G use cases is time-critical communication and low-latency applications, this is a component technology that is being looked at. Similarly, IETF routing-related work such as traffic engineering, service chaining and source routing are likely tools in managing traffic flows in 5G networks.
Topics where there is clear demand for a feature, but it is unclear whether changes to Internet technology are needed, or the details remain to be determined. For instance, in the upcoming IETF meeting in Prague, we will be discussing whether some additional support is needed for what is in 5G called Network Slicing. There are many IETF tools, however, for dealing with virtualisation and separation of networks, so first order of business is probably mapping what can be done with those tools.
Larger, architectural changes, e.g., “future Internet” type solutions such as ICN (Information Centric Networking) are sometimes suggested also in the context of 5G. While these are perhaps unlikely in the first release of 5G, it is of course certain that the evolution of the Internet continues (and there will be future releases of 5G standards as well).
We asked Gonzalo Camarillo and Georg Mayer (liaisons between 3GPP and IETF) about collaboration between IETF and 3GPP. They said that our best approach is to ensure that the 3GPP engineers are involved in the IETF work they are interested in. And that 3GPP states clearly what their requirements (rather than solutions) are. They also noted that the work in 3GPP is ongoing. Hence completing protocol requirements for 5G will still take some time. Gonzalo and Georg will be contacting the relevant parties on both sides to keep us in sync.
Exchange of information would also benefit from informal collaboration, for instance through Internet technology experts working with the 3GPP community. This enables common topics to be easily discussed and brought forward.
We should also note that there are clear boundaries between the two organisations. The IETF works on Internet technologies which may or may not get used in different networks. 3GPP puts together systems, architectures, and designs protocols specific to their networks and layers. The IETF is not in charge of making system level or requirement decisions for the 3GPP. Similarly, 3GPP leaves the evolution of Internet protocols to the IETF.
Also, recently Alissa Cooper, Chair of the IETF, visited a 3GPP meeting. Her report is here.
Finally, it should be noted that many of the existing tussles in the Internet continue to exist with 5G. For instance, the ability to provide a highly dynamic and programmable radio environment continues to present opportunities for collaboration between networks and applications. Such collaboration is not something that has historically been easy in the Internet, however. When we discussed this as a part of the growing use of encryption, the necessary changes to network management practices due to the encryption changes caused pain for operators. Perhaps as some time has passed, and networks continue to evolve, we could consider network – application collaboration as an opportunity and ask what useful things networks can do for applications?
The Chicago IETF begins in a couple of days, and I wanted to point people to a few highlights from my perspective. Of course, with over hundred working groups, the IETF’s work program is quite diverse, and different people are interested in different topics. There is a lot that is particularly interesting for me:
New transport: I expect a lot of attention again on QUIC, the transport protocol designed to integrate functions from TCP and TLS. They are meeting Thursday at 09:00. They will use their meeting time to discuss the main protocol drafts, and issues such as details of the integration to HTTP. There will be a QUIC Tutorial on Sunday afternoon (15:00).
Coordinated Address Space Management: The CASM BOF will meet Monday 15:20 and discuss how organisations manage their address space and what possibly standardised tools may be useful in that.
Trusted Execution Environments: The A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BOF meets Tuesday 14:50. They talk about a possible application layer security protocol that would allow configuring security credentials and software running on a Trusted Execution Environment (TEE). These environments are often found in set-top boxes, smart phones, tablets, wearables, etc. Current control and configuration protocols are propietary.
GitHub: More and more of networking software gets developed in GitHub, and it has also become a popular way for us to collaborate on the specifications themselves, with everyone having an ability make edits, raise issues, etc. We now have some experience from doing this, and the WGs Using GitHub (WUGH) BOF will discuss those experiences and find ways to work even better with GitHub. They meet Monday 17:10. There’s also a mailing list for discussing this topic.
YANG: In the Routing Area, YANG work continues to be of high interest. A Joint YANG session among four Working Groups (CCAMP, MPLS, PCE, and TEAS) will be held on Friday 09:00 to coordinate the work. Topics will include TE topology models, MPLS, PCE, Microwave Radio Link, and Transport. In the RTGWG, an update on the RTG YANG Architecture Design Team and work on-going in OpenConfig will be presented Wednesday 09:00.
Administrative matters: Changes to how the IETF is administered are also a popular discussions for the IETF community. The MTGVENUE working group is continuing our effort to define requirements that IETF meeting sites must fulfill, which seems even more important among the increasing number of travel restrictions. The IETF needs to stay as open as possible for all attendees. The group recently went through some changes. The group meets Monday 15:20. And the IASA 2.0 BOF asks whether there should be adjustments or even restructuring of the IETF administrative arrangements overall. Our arrangements have served us well, but there are also issues, and with 10+ years of experience it is time to re-assess the system. We held two workshops earlier on this topic, and the results of those workshops are outlined in an Internet-Draft. The group meets Wednesday 13:00.
New leadership: The IETF Nominations Committee (Nomcom) is charged with selecting persons for the various IETF leadership positions. The changeover is in the March meeting. For our steering group, Eric Rescorla, Adam Roach, and Warren Kumari will be starting as new Security, Applications and Real-Time, and Operations Area Directors. And I will be stepping down after four yours as chair, with Alissa Cooper continuing in that role. Please welcome the new chair and ADs! And thank you for volunteering to do this!
Running code. Last but not least, none of the above matters without software that actually does those things. Our Hackathon and Code Sprint events are open for everyone to attend, do join us and work on something that is important to you or your business! Both events start Saturday morning (09:00/09:30) before the IETF. The Code Sprint is the way that much of IETF’s own web systems and tools have come about. I want to emphasise how much we depend there both on volunteers as well as capable contractors — we need you. There are also many side events during an IETF, for instance the network operators meeting (IEPG, Sunday 10:00).
I also wanted to thank all our sponsors and supporters, and Ericsson in particular for hosting us in Chicago.
The sponsors make our meetings and IETF services possible. Thank you!
See you soon, and I wish everyone safe travels to Chicago. Hopefully the effects of various last-minute restrictions (such as the laptop ban on some flights) will remain minimal. And those participating in the meeting online — see you virtually soon!
Jari Arkko, IETF Chair
Picture credits: Thompson’s original 1830 58-block plat of Chicago from Wikimedia. In public domain.
Recent news stories, and some IETF list discussion, have related to the release of (claimed) CIA materials relating to surveillance, hacking and information warfare. There has been quite a bit of discussion about the details of the various attacks contained in this leak, such as those relating to surveillance through smart TVs, or hacking vehicles. But are there more general conclusions that we can draw from release of this information?
First, we think the content of leaks is not particularly surprising, especially given knowledge of other leaks in recent years, such as those from Edward Snowden. Malware is another tool in the same toolbox that is already known to include many other efforts that attempt to compromise security, such as pervasive surveillance.
But the release of the current tranche of documents does seem to nicely support a number of things that we knew already and that are arguably more worthy of consideration:
Security is not a single feature, rather the level of security one experiences needs to be thought of as an emergent property of the whole system. Communications security, for instance, is necessary but not sufficient. You also have to worry about the security of your devices, platforms, operating systems, and components. And the reliability of your communication partners.
There is no such thing as privileged access for the good guys once there are more than a very small number of people involved. Sooner or later the privileged way to access information or hacks will either leak, be re-discovered independently by others, or be shared to parties that do not have your best interest in mind. In addition, systems built to take advantage of the privileged access will get broken and misused.
All malware is just that, malicious software designed to disrupt or compromise other systems. And all will eventually leak. Secretly held knowledge of vulnerabilities makes us all less safe. The vulnerabilities will be exploited, perhaps traded or shared, instead of being reported and fixed. And when they leak out, they do damage to your friends as well as your supposed enemies.
The security of our communications and applications matters a lot. Lives are at stake, not just your browsing history. Our entire societies run on top of our technical infrastructure, from hospitals and power plants to political processes and our economy. We cannot afford to compromise the security of these systems.
As noted, we think these are matters that are already known, but reminding ourselves of the big picture now and then can be useful.
From the IETF perspective we are of course committed to continuing our effort to provide the best possible technical tools for the Internet and the users. One technical observation that may be of use is that focusing on protecting data and not merely links or transport needs better support, make it easier to achieve in practise and at scale.
Jari Arkko, IETF Chair
Stephen Farrell, IETF Security Area Director
Photo credits: Image of the toxic leak in a reservoir in Ajka, Hungary affecting the villages of Kolontar and Devecsar, photo by DigitalGlobe, sourced from Wikimedia (CC BY 3.0).
The current IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago when the IETF initially took charge of its own administration . The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks and in the world around us since then . What administrative arrangements will best support the IETF going forward?
A series of virtual workshops have been arranged as part of an effort, dubbed the IASA 2.0 project, to gather community input as part of a review and possibly rework of IASA arrangements.
The workshops will help understand what is working well and what challenges or missed opportunities exist in the current system. We also want to understand what the IETF will need in coming years. Possible topics include:
internal IASA and IAOC organizational issues;
roles and interfaces between the IETF, the IAOC, ISOC, the IESG, and contractors;
availability of staff, contractor, and volunteer resources compared to the administrative workload;
finance and sponsorship arrangements.
The workshops will be virtual meetings where the participants can provide their experiences and suggestions. Proposed changes and solutions will be dealt with in a later phase . Meeting notes and an Internet Draft summarizing the input will be produced afterwards.
The agenda will be the same for both workshops, which are scheduled to accommodate participants in different timezones:
IASA 2.0 Workshop 1
Tuesday, 28 February 2017
11:00 UTC (6:00AM ET / 12:00 noon CET)
IASA 2.0 Workshop 2
Tuesday, 28 February 2017
16:00 UTC (11:00AM ET / 17:00 CET).
These documents will be helpful to review in advance of the workshop:
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The new members are Alissa Cooper (Cisco), who will be new IETF Chair as I am stepping down. Warren Kumari (Google), will be our new Operations and Management Area AD. And Eric Rescorla (Mozilla) becomes the new Security Area AD. Together with the continuing ADs, this is a great team, and the IETF is in extremely capable hands!
When the new members get seated, we will be saying goodbye and thank you to two long-serving ADs: Stephen Farrell (TCD) in the Security Area and Joel Jaeggli (Fastly) in the Operations and Management Area. Their service to the community, dedication to making the Internet better, and rational approach to contentious issues have made the IESG, the IETF, and the Internet better.
Notably, with these appointments we’ll be continuing to demonstrate gender diversity in our leadership. Not only has Alissa been selected as the first female chair, but we’ll continue to have five female area directors serving in the IESG, the most we’ve had at one time. They are in these roles because they are the best people for their roles, but I think this also sets a great example for other tech organisations to follow in gender diversity 🙂 I would like to challenge other standards organisations to top our results.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols. Our focus is the evolution of the Internet architecture and the smooth operation of the Internet. We do most of our work online, largely through email and mailing lists, but we also regularly meet in-person at locations around the world. Whether online or in-person, we come together as individuals with the shared goal of making the Internet work better.
An important part of the Internet’s success is that it is all voluntary. Everyone connected to the Internet uses the same mechanisms by choice, and the Internet only works because everyone connecting uses the same mechanisms. Those mechanisms are the protocols of the Internet.
Because the Internet is voluntary, it only works if everyone wants to use the same protocols. So, our work on open standards–like that of the open source and and scientific research communities–fundamentally depends on the ability to work collaboratively across national borders.
The IETF does not make comments on political matters. But we do comment on topics that affect the IETF and the Internet. Specifically, the recent action by the United States government to bar entry by individuals from specific nations raises concerns for us—not only because upcoming IETF meetings are currently scheduled to take place in the U.S., but also because the action raises uncertainty about the ability of U.S.-based IETF participants to travel to and return from IETF meetings held outside the United States.
The situation is fluid. Legal and political processes around the imposition of barriers to travel will likely continue. We plan to track the situation closely in the US and elsewhere. We believe that Internet protocols develop best when people of many backgrounds can offer their contributions, and we are negatively impacted by policies that prevent such collaboration.
IETF meeting venues are always reviewed for potential impact on attendance by participants from different countries. Our next meeting is planned for Chicago, and we believe it is too late to change that venue. We recognize, however, that we may have to review our other planned meeting locations when the situation becomes clearer. We are already reviewing what to do as far as location for the next open North American meeting slot.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate. They specify protocols, document registries and code points, and describe network experiments. They do all these things with an eye towards short-term relevancy, while being structured in such a way as to save this body of knowledge in perpetuity. Everything from the numbering scheme to the document style to the file format works together to balance the short-term and long-term needs. The RFC format project is pushing those boundaries quite a bit to make documents more easily consumed in the short term, while relying on the advances in technology to support that long-term archive of material. This is not, however, a post about the RFC format (though if you want to know more, feel free to read the FAQ!)
This is a post about what the RFC Editor is doing to improve the archival component of the RFC Series. Late in 2016, the RFC Editor entered into an agreement with the National Library of Sweden to properly archive RFCs, both the ones already published and new ones as they are posted via an RSS feed. The National Library of Sweden was established in 1661, and has had a digital archive since 1997. They take their archiving very seriously, storing material in a bunker 40 meters under the main building of the National Library.
Picture: The library’s system for digital preservation is called Mimer. Mimer is a figure from the old Norse mythology, a gentle giant who was the guardian of Mimers: a fountain of wisdom from which if you got a sip of that well you would become all wise and know everything that had happened before and everything that will happen in the future.
Stepping back for a moment from this very good news, let me explain a bit why archiving isn’t just about having a nice set of offsite backups. Quite a bit of this is explained in draft-iab-rfc-preservation but here is a quick high-level summary. A proper digital archive, at minimum, has that offsite backup component in storing a copy of the material. Beyond that, it also stores quite a bit of metadata about the document, such as when it was retrieved, when it was published, where it came from, who the author(s) and/or editor(s) are, the original location, title, all assigned identification numbers (such as DOI, ISSN, or other custom information, which in our case is the RFC number) and so on. A digital archive commits to storing and maintaining this information, and doing what it can to try and make sure the document can be viewed by whatever modern technology is available at the time.
The RFC Editor needs partners like the National Library of Sweden to archive the series. The resources available to the RFC Editor are necessarily prioritized towards the editing and publishing of RFCs; the archive itself is in those off-site backups and printed hard copies. Having an organization that specializes in digital archiving is a big win for preserving this rich set of material that documents the birth and evolution of the Internet. The RFC Editor will, of course, continue with proper backups, and will always consider the needs of an archive when we discuss any changes to the format and metadata around RFCs.
And with that, I want to offer many thanks to the people at the National Library of Sweden for agreeing to archive the RFC Series. Tack!
The essence of the IETF is that it is a place for people who both write code and specs. The IETF motto is “Running Code and Rough Consensus”. With that in mind, a big part of our work is helping and encouraging for that code writing to happen. This happens at many levels: the IETF Hackathon focuses on open source projects and Internet technology, the CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week. We will also get to demonstrate some of the results in the Bits-n-Bites later in the week.
So do considering joining this event. The signup page is here. You can keep up to date by subscribing to the Hackathon mailing list.
Hackathon is free to attend and open to the public.
And remember that what you do at these events is up to you. You decide what is the coolest tech thing that you need to implement! So don’t be afraid to add your own project or team!
I’ll say that again: add your own topic to the wiki, and work on it!
See Charles Eckel’s mail and the wiki for the details.
I would also like to offer IETF-98 as a place for various interop and test events. We typically have several at every IETF. Many people travel to the IETF anyway, so it is a convenient place to spend some time testing. Let us know if you are planning to do some testing, we may in some cases also be able to help with rooms, networking, and help publicise your event to other networkers!
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago. CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on. Everyone is welcome to attend! Read more from  and sign up .
And remember that what you do at these events is up to you, you decide. You decide what is the coolest or most useful feature; you decide what IETF data tracker feature you need for your work.
Secondly, we would like to draw your attention to work on tools that serve the IETF, and we would like to signal for a need to draw in further people and vendors in this effort.
Part of the work is on a volunteer basis, both in our Code Sprints and through various long-term efforts. Part of the work is run on a commercial basis, e.g., operations of the various IT systems that our Secretariat provides or the implementation of various new tools that we have decided to implement. The commercial efforts typically require some volunteer effort as well, for instance, Robert Sparks is the project manager for all datatracker related efforts and Joe Hildebrand is the project manager for the IETF web site redesign project.
Thanks to all of the volunteers for their efforts. We are VERY grateful for their work, and it is necessary work. But at the same, we are realizing that resources are spread fairly thin. We’re happy about the turnout in the IETF Code Sprints, but would love to get more people. And we would love to have individuals who care about particular tooling issues enough to adopt them as their longer term project and take them to completion. Getting involved with the volunteer tools work starts best at the Code Sprint, however. The next one will be on Saturday, March 25, just before the IETF begins in Chicago. Join us, and book your flight tickets so that you can spend the Saturday with us!
But the same issue applies even to the commercial parts , and we would like to have more companies or capable individuals bid for some of the projects. The Technology Management Committee and the IAOC have recently awarded the projects for building the tools necessary for the new RFC format, for instance, to two individuals that are very active in the IETF community, one of which was already doing quite a lot for the IETF. For the long-term sustainability of the IETF IT and tool efforts, we would desperately like to extend the set of people and companies looking at and bidding on these efforts. We know that many individuals in the IETF sphere have capabilities in this area, and we’d like to draw your attention to this opportunity as well. We welcome first time qualified bidders, and we pay competitively. If you can do the work, a contract to work on open source tools for the IETF can be rewarding.
Jari Arkko, IETF Chair
Russ Housley, Chair of the IAOC Tools Committee
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
New ideas can be proposed in the IETF in many ways:
Small improvements and features of ongoing work: these fit right in, just take the idea to the relevant working group. You can send that mail today!
Bigger new ideas may need a working group’s charter be extended or a new working group be created. Often these can be done directly online after discussion; talk to your WG chairs or Area Directors to get the process started. The proposals for significant new work always get discussed in the whole IETF community, on the mailing list, and approved by the steering group (IESG).
Some bigger ideas benefit from face-to-face discussion with the larger community. This is helpful particularly on complex topics, where we need some time to even get to understand the topic well. This also allows discussion of various common trade-off situations, as improvements often come with cost, for instance.
These ideas need to be discussed in a so called Birds-of-Feather (BoF) session; talk to your Area Director about your idea, and follow the RFC 5434 recommendations for setting up a successful BoF. The deadline for submitting BoF proposals for Chicago is February 10, which is one month away! But the process with new Internet-Drafts, mailing lists, and so on needs to start earlier.