* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Timeframe IETF 87 (Berlin)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Monday, June 17, 2013. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconferece, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before June 27.



  • Name: Domain-based Message Authentication, Reporting & Conformance (DMARC)
  • Status: Approved
  • Description:
    Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (or its "brand"). SPF (RFC4408) and DKIM (RFC6376) provide basic domain name authentication methods for email. A recent industry effort has added a trust-oriented layer, called Domain-based Message Authentication, Reporting & Conformance (dmarc.org). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. The existing base specification is being submitted for standardization as an Individual Submission. The working group will consider optional, incremental enhancements to DMARC, particularly focusing on those listed below. It also will produce usage guidance.

    The current specification reflects practical constraints in scope and mechanism for which eventual improvements would be helpful. These include, but are not limited to:
    • a mechanism for determining the base (organizational) domain name based on an arbitrary fully-qualified hostname
    • a mechanism for protecting the <display-name> portion of the RFC5322.From field
    • a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list
    • support for the notion of transitive trust (i.e., "host X trusted the sender of this message, and I trust X, so I should trust the original sender.")
    • more robust transport of reports

    Accurately and universally determining an organizational domain name, such as appears in the second-level name below .com, is primarily a DNS issue, with a scope that is broader than DMARC; so it will be pursued outside this working group. The working group will be free to abandon work on any of the above if it is determined that a consensus solution cannot be reached in a reasonable period of time.

    The working group will also deliver an implementation and deployment guide, which catalogs best current operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will also advise practices that are not yet well-established but which are believed to be appropriate.
  • The responsible Area Director (AD): Barry Leiba
  • BoF Chairs (or the ADs as placeholders): Russ Housley
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): app area sessions, sec area BoFs, saag, dnsext, intarea, dnsop, opsawg
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.:
  • Proposed agenda:
    (This agenda assumes that the base specification is not part of the proposed working group. By the time of the BOF, we expect enough community feedback to be able to make adjustments, if needed.)
    • Summary of DMARC base specification, for background.
    • Summary of open issues for work on possible enhancement
    • Introduction to rough draft of Using DMARC BCP
    • Review of draft working group charter



  • Name: IPRBIS
  • Status: Approved
  • Description: Further discussion on IPR rules revisions. xperience shows that BCP 79 needs a few updates. A draft is available with the proposed updates, and this BOF will provide the community an opportunity to discuss the proposed changes. Not intended to form a WG.
  • The responsible Area Director (AD): Jari Arkko
  • BoF Chairs (or the ADs as placeholders): Jari Arkko
  • Number of people expected to attend: 75
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): All other BOFs and please schedule from Monday to Wednesday
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: https://datatracker.ietf.org/doc/draft-bradner-rfc3979bis http://www.ietf.org/mail-archive/web/ipr-wg/current/maillist.html




  • Status: Not Approved
  • Name: Intelligent Transportation Systems (its)
  • Description:
    Intelligent Transportation Systems (ITS) ITS is about extending the Internet to mobile vehicular platforms. These platforms include:
    • vehicles and embedded devices (ruggedized units, actuators and sensors),
    • mobile devices carried by passengers (tablets, smartphones) and
    • fixed infrastructure units (Internet access points, charge stations, geo-broadcasting units). The entire system may be connected to the Internet with generic radio-WANs or radio-LANs specific to vehicular communications; in certain cases the vehicles are disconnected from the Internet yet may be inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively).
      The radios have the following characteristics:
      • lower capacity, higher noise than customary Internet plumbing.
      • presence of mission critical needs and safety applications.
      • stable in-vehicle network structure.
      • volatile topology as vehicles (and the routers they contain) move.
      An example scenario of vehicular communications is the following: an instrumented ambulance is connected to the Internet and offers access to individual equipments deployed in-vehicle; it moves through a traffic jam and may signal its direction by multicasting IP communication packets over IEEE 802.11p direct links, or it establishes direct subnets to vehicles to request their position. Other similar scenarios are described in a dedicated document.
      The areas addressed by the group are the following:
      • establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol,
      • layering of IPv6 over IEEE 802.11p communication technology and
      • IPv6-based network-layer distribution of content in a geographic area.
      For each of the three areas, security aspects will be considered: authenticity of routing message exchanges, influence of the absence of link-layer security of IEEE 802.11p, and security of multicast distribution. In each of these areas, the problem space will be identified in detail, in a dedicated draft. The problem will be expressed in terms of protocol behaviour and point precisely to the lack of feature or other breaking points. For the IP addressing and mobility aspects of in-vehicle subnetworks, single-subnet V2V, and single-subnet V2I, the WG will consider and if necessary, profile, existing IPv6 network protocols. The protocols considered are: MANET protocols, ICMPv6, MLDv2. Other higher layer protocols, although relevant to geo-localization, will be considered as a complete reuse (e.g. RFC 5222). Establishment of networking from vehicle to ground is considered achieved to a large extent, by using existing IPv6 protocols (Mobile IPv6). This would be out of scope of work. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications, in a non overlapping manner. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications. The group ISO TC204 describes ITS station architecture, IPv6 networking and security, and optimizations. The group ETSI ITS describes IPv6 for networking in vehicles. IEEE TGp, AUTOSAR, GENIVI and IPSO describe other aspects of vehicular communications. When possible, liaisons will be established with these organizations. This group will survey these SDO's documents to identify how it relates to this group's work.
      Potential new work items:
      • Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios.
      • Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications.
      • The use of IP over 802.11p - with or without intermediary layers, with or without modifications - will de described.
      • One particular practice to document is the IP addressing architecture within a vehicle, between vehicles, and between vehicle and infrastructure: the preferred address auto-configuration methods, the requirements for address stability and scope of visibility (in-vehicle, to vehicles nearby, to infrastructure, to Internet, etc.)
      • A problem statement draft should be written which documents the problem which is a real-world problem, points precisely to the protocols which may break, and may easily lead to a solution that can be designed in a straightforward manner.
  • Responsible AD: Ted Lemon
  • Chair: Alexandru Petrescu <alexandru.petrescu@gmail.com>
  • Conflicts to avoid: Prefer Monday evening, as this was a date used for informal ITS meetings at IETF, but otherwise please avoid conflicts with 6MAN, V6OPS, DHC, MANET, DMM, NETEXT, MIF.
  • Full description of BoF: please see in attachment the proposed Charter.
  • Expected attendance: max 20 person; past informal meetings gathered approx. 10-20 person.
  • Length of session: 1hour.
  • The email list is at http://ietf.org/mailman/listinfo/its


  • Long name and abbreviation: DNS-SD Extensions (dnssdext)
  • Status: Approved
  • Description, including whether the BoF is intended to form a WG or not:
    This BoF is a WG-forming BoF. The proposed WG will develop solutions to provide scalable DNS-SD services in multi=-link, routed networks as found in academic, enterprise, home network and mesh radio networks. It is a second BoF, following the mdnsext BoF during IETF 85.
  • The responsible Area Director (AD):
    Ted Lemon
  • BoF Chairs (or the ADs as placeholders):
    Tim Chown (tjc@ecs.soton.ac.uk), Ralph Droms (rdroms@cisco.com)
  • Number of people expected to attend:
  • Length of session (1, 1.5, 2, or 2.5 hours):
    2 hours
  • Conflicts to avoid (whole Areas and/or WGs):
    First priority: dnsop, v6ops, appsawg, homenet, 6man, dhc, 6lo, mboned, core, sdnrg
    Second priority: INT area WGs
  • Does it require WebEX? If so, why?
  • Does it require Meetecho? If so, why?
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Mailing list: mdnsext@ietf.org
Archive: https://www.ietf.org/mailman/listinfo/mdnsext

draft-cheshire-mdnsext-hybrid Hybrid Unicast/Multicast DNS-Based Service Discovery
draft-lynn-mdnsext-requirements Requirements for DNS-SD/mDNS Extensions

Draft agenda:

  1. Administrivia (Chairs, 5 mins)
    Note Well and agenda bashing
  1. Goals of the BoF (Chairs, 15 mins)
    Review of IETF 85 mdsnext BoF and progress since then
  1. Requirements (Kerry Lynn, 30 mins)
  1. Open discussion (Chairs, 40 mins)
    Open mic; includes draft charter and deliverables

  1. Key questions (Chairs, 30 mins)
    Are we ready to form a WG with the agreed charter, subject to mail list confirmation? Note RFC5434 section 1.

Draft charter:

Description: Currently, zeroconf networking protocols are generally used to discover services within the scope of a single link. In particular, the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD (RFC 6763), are widely used for discovery and resolution of services and names on a single link.

The Bonjour protocol suite is commonly used in many scenarios, including home networks, commercial and campus enterprise networks, and may be of use in certain mesh networks. However, the multicast Bonjour protocols are constrained to link-local scope, so can only be used to discover services on the same link. In a typical current home network, which is a single link, users should experience the desired discovery behavior. However, in future multi-link home networks (as envisaged by the homenet WG) and in routed campus or enterprise networks, devices and thus users can only discover services on the same link, which is a significant limitation. Such limitations have led to calls, such as those by the Educause petition, to develop an appropriate solution to span multiple links, or to perform discovery across a wide area (not necessarily on directly connected links).

In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial standard currently under development has specified the Bonjour protocols as its method of zero configuration discovery. However, its use of wireless mesh multi-link subnets and its use across traditional routed networks will require extensions to the Bonjour protocols to allow operation across multiple links.

As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship their own early solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards- based solution.

Goals: To that end, the primary goals of the dnssdext WG are as follows:

  1. To document a set of requirements for scalable DNS-based service discovery in routed, multi-link networks in the following four scenarios:

a) Commercial enterprise networks
b) Academic/educational/university campus networks
c) Multi-link home networks, such as those envisaged by the HOMENET WG
d) Multi-link/single subnet (mesh) networks, such as those described by the ZigBee Alliance Z-IP specification

  1. To develop an improved, scalable solution for wide-area service discovery that can operate in multi-link networks, applicable to the scenarios above.
  1. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast (global DNS) name services in such multi-link networks, which should include consideration of both the name resolution mechanism and the namespace.

It is important that the dnssdext WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the mdsnext WG, and thus coordination between the WGs is desirable.

Deliverables: The WG will produce three documents: an Informational RFC on the requirements for wide-area service discovery protocols; a Standards Track RFC documenting a wide-area service discovery solution that is applicable to those scenarios; and a BCP document describing the most effective method to integrate mDNS and global DNS name services.


Sep 2013 Formation of the WG
Oct 2013 Adopt requirements draft as WG document
Nov 2013 Submit requirements draft to the IESG as an Informational RFC
Mar 2014 Adopt wide-area service discovery solution draft as WG document
Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG document
Sep 2014 Submit wide-area service discovery solution draft to the IESG as Standards Track RFC
Sep 2014 Submit zeroconf and unicast DNS integration solution draft to the IESG as BCP


Draft charter:
6Lo focuses on INT area work that is needed for constrained node networks. Specifically, it is working on:

  • adaptation layer specifications for link layer technologies of interest in constrained node networks;
  • related MIBs;
  • common infrastructure specification such as header compression specific to constrained node networks;
  • maintenance and informational documents required for the existing IETF specifications in this space.

6Lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6Lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6Lo will also coordinate with LWIG and INTAREA.

6Lo works on small, focused pieces of INT area work. 6Lo does not take on larger cross-layer efforts (such as the 6TSCH work under discussion). The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible.

Security and management work that is not specific to the link layers being worked on is out of scope. 6Lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as today ROLL (RTG) and CoRE (APP), and appropriate groups in the IETF OPS and Security areas including potential future groups spawned from efforts such as COMAN and SOLACE.

Operations and Management

LMAP, Large-Scale Measurement of Broadband Performance





Network services are widely deployed and essential in many networks. The services provide a range of functions such as security, WAN acceleration, and server load balancing. Service functions that form part of the overall service may be physically located at different points in the network infrastructure such as the wide area network, data center, campus, and so forth.

New data center network and Internet cloud architectures require more flexible network service deployment models. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic service delivery, the movement of service functions and application workloads in the network and the ability to easily bind service policy to granular information such as per-subscriber state.

Service chaining is a broad term used to describe a common model for delivering multiple services in a specific order. Service chaining de-couples service delivery from the underlying network topology and creates a dynamic services plane that addresses the requirements of cloud and virtual application delivery. Packets and/or flows that requires service chaining are classified and redirected to the appropriate, available services. Additionally, context can be shared between the network and the services.

Service chaining has been discussed in other forums -- for example I2RS WG has raised the issue at an interim meeting, and the ETSI NFV group is discussing service chaining as part of network function virtualization.

The goal of this BoF is to let service providers explain their NSC use cases and requirements so that the IETF is exposed to the problem space and can determine the next actions.


  • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
  • Status: Approved
  • Description

The IETF has two packet-based forwarding technologies: IP and MPLS.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

The BoF will seek to address the following questions:

  • What are the use cases driving this work?
    • What are the requirements for explicit routing?
    • What are the fast-reroute and recovery use cases?
    • Is traffic engineering in scope?
      • Does it include resource reservation?
    • Can this technology be used for OAM features?
    • How does this work interface to application level routing and service chaining?
  • How much data plane variety is needed? MPLS? IPv6? IPv4?
    • What are the inherent costs in supporting more than one data plane?
  • What are the basic assumptions about the stability of the existing data planes?
    • Can changes be made to the existing data plane architectures?
    • Can changes be made to the existing data planes themselves?
    • What are the backward-compatibility requirements?
  • What management/control architecture do we want?
    • How is this integrated with SDN?
    • Should we support only a distributed control plane?
    • Should we allow "programming" at the network edges?
    • Should we support programming of all the network nodes?
    • If TE is in scope do we support distributed TE or centralized TE?
  • What does a label represent?
    • Should a label have local semantics or is it "just" a forwarding tag?
    • Do we need a generalized segment scheme versus specific models for different applications?
  • Potential Agenda
  • Administrivia [5/5]
  • Intro by ADs and Chairs [5/10]
  • Operator 1 on Use Cases [15/25]
  • Operator 2 on Use Cases [15/40]
  • Operator 3 on Use Cases [15/55]
  • Vendor 1 on architecture/issues [20/75]
  • Vendor 2 on architecture/issues [20/95]
  • Open Discussion [20/115]
  • [Charter discussion if time]
  • Wrap-up by Chairs and ADs [5/120]
  • Draft (and hypothetical) charter

The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used.

The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source-routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices.

Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS).

The working group is chartered for the following work items:

  1. A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing.
  1. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support.
  1. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information.
  1. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate.

The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively).



  • Name: SACM
  • Status: Approved (likely to be approved as WG before Berlin)
  • Responsible AD: Sean Turner
  • Slot length: 2 hours
  • Link: https://datatracker.ietf.org/wg/sacm/charter/

This is a place holder. This charter ought to be under Internal review on 2013-06-11.


  • Description:

Channel encryption with TLS depends on proper checking of the server's identity, as specified in RFC 2818 or RFC 6125 for PKIX certificates. However, in multi-tenanted environments it is effectively impossible for a hosting service to offer the correct certificates on behalf of a hosted domain, since neither party wants the hosting service to hold the hosted domain's private keys. As a result, typically the hosting service offers its own certificate (say, for hosting.example.net), which means that TLS clients and peer servers need to "just know" that the hosted domain (say, foo.example.com) is hosted at the service.

This situation is clearly insecure. The use of DNSSEC and DANE has the potential to solve the problem, but that potential is most likely many years from being fully realized. Hosting services and hosted domains need a method that can be deployed more quickly to overcome the lack of secure delegation on the Internet today.

POSH (PKIX Over Secure HTTP) provides a way to solve the problem, involving two interconnected aspects:

  1. TLS clients and peer servers retrieve the material to be used in checking the TLS server's identity by requesting it from a well-known HTTPS URI, where the response contains one or more certificates formatted as a JSON Web Key set defined within the JOSE WG.
  1. If a hosted domain securely delegates an application to a hosting service, it redirects requests for the well-known HTTPS URI to an HTTPS URI at the hosting service.

The goal is to form a working group to produce a specification for POSH, and might informally provide advice about how to use the POSH technique for particular application protocols.


  • Description:

There is an increased use of wireless control networks in city infrastructure, environmental monitoring, industrial automation, and building management systems. These wireless control networks comprise many electronic devices, sensors and actuators that are connected to each other, and in most cases Internet connected, thus creating a trend towards Internet of Things (IoT). The CoRE working group has defined a framework for resource-oriented applications intended to run on Constrained Node Networks (CNN) (see I-D-ietf-lwig-terminology). A CNN connects devices which are constrained by power, limited amount of code size and memory in a network with severe limits on throughput. The Constrained Application Protocol (CoAP) can be used to manipulate resources on a device in a CNN.

Group communication is an important feature in CNNs as it can be effectively used to convey messages to a group of devices without requiring the sender to perform multiple time- and energy-consuming unicast transmissions, one for each group member. For example, in a building control management system, Heating, Ventilation and Air-Conditioning (HVAC) and lighting devices can be grouped according to the layout of the building, and control commands can be issued to a group of devices. Unsecured group communication for CNNs is enabled by using CoAP on top of IP-multicast. However, it must be secured as it is vulnerable to the usual attacks (eavesdropping, tampering, message forgery, replay, etc). Datagram Transport Layer Security (DTLS) has been chosen by CoRE to protect CoAP unicast communications, and it would be beneficial if the same security protocol, i.e., DTLS can be used to protect CoAP group communication as well.

The current design of DTLS leads to fragmentation of DTLS handshake messages over the wireless link, in particular when Raw Public-key and Certificate modes are used. From the various implementation experiences reported in the LWIG working group, the complexity of re-transmission and re-ordering of DTLS handshake messages in CNNs has resulted in a significantly increased code size and RAM. Additional reliability mechanisms for transporting DTLS handshake messages are required as they will ensure that handling of re-ordered messages needs to be done in a single place in the stack only.

This WG combines expertise from both the IETF Application and Security areas in order to work out the appropriate security solutions for the Internet of Things.

The scope of this WG is to define the following:

Document the problems with the DTLS handshake for IoT, and define a suitable profile of DTLS for an IoT architecture and use case that minimizes the complexity and overhead of DTLS for constrained devices.

The use of DTLS Record Layer in combination with the (derived) multicast key to protect the CoAP group communication without source authentication. The DTLS Record Layer should not be modified/altered.

Goals and Milestones

  • Oct 2013 WG document for DTLS for IoT profile
  • Nov 2013 WG document for secure multicast group communication in CNNs
  • Feb 2014 DTLS for IoT profile specification submitted to the IESG
  • Mar 2014 Secure Multicast group communication specification submitted to the IESG



  • Name: AQM - Active Queue Management and Packet Scheduling
  • Status: Approved
  • Description:
    Internet routers, lower-layer switches, other middleboxes include buffers or queues to hold packets when they are not immediately able to be forwarded to the next hop.

The queues are intended to absorb bursts of traffic that may naturally occur, and avoid unnecessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can cause issues and complications for interactive applications.

Extremely large buffers have been noticed in some software and equipment. When these queues fill, interactive applications and other traffic can be severely impacted or completely broken, due to high and potentially oscillating delays.

The Active Queue Management and Packet Scheduling working group (AQM) is intended to work on algorithms for proactively managing queues in order to:

(1) help flow sources control their sending rates before the onset of necessary losses, e.g. through ECN

(2) help minimize delays for interactive applications

(3) help protect flows from negative impacts of other more aggressive or misbehaving flows

  • Responsible AD: Martin Stiemerling
  • BoF Chairs: Wed Eddy, Richard Scheffenegger
  • Type: WG forming
  • Number of people expected to attend: 100
  • Length of session: 1 hour
  • Conflicts to avoid: all TSV WGs, TSVAREA, and ICCRG
  • Does it require Webex: No
  • Does it require Meetecho: No
  • Links to the mailing list, draft charter, relevant I-Ds:


  • Name: TCMTF - Tunneling Compressed Multiplexed Traffic Flows
  • Status: Approved
  • Description:

The interactivity requirements of some emerging services (VoIP, videoconferencing, telemedicine, video vigilance, online gaming, etc.) make them send high rates of small packets, in order to transmit frequent updates between the two extremes of the communication. They also demand small network delays. In addition, some other services also use small packets, although they are not delay-sensitive (e.g., instant messaging, m2m packets sending collected data in sensor networks using wireless or satellite scenarios). For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead.

When a number of small-packet flows share the same path, bandwidth can be saved by multiplexing packets belonging to different flows. If a transmission queue has not already been formed but multiplexing is desired, it is necessary to add a multiplexing delay, which has to be maintained under some threshold in order to grant the delay requirements. Some examples of the scenarios where grouping packets is possible are:

  • aggregation networks of a network operator
  • an end-to-end tunnel between appliances located in two different offices of the same company
  • a satellite connection used for collecting the data of a high number of sensors.

RFC4170 (TCRTP) defined a method for grouping VoIP packets considering three different layers: header compression by means of ECRTP; multiplexing by means of PPPMux; tunneling by means of L2TPv3. However, in the last years, emerging real-time services which do not use UDP/RTP have become popular: some of them use UDP or even TCP. In addition, new header compression methods have been defined (ROHC). So there is a need of widening the scope of RFC4170 in order to consider not only UDP/RTP but also other protocols. The same structure of three layers will be considered: header compression, multiplexing and tunneling.

The BOF aims for the creation of a Working Group in order to specify the protocol stack, signaling mechanisms and maximum added delay recommendations for tunneling, compressing and multiplexing traffic flows (TCMTF).

  • Responsible AD: Martin Stiemerling
  • BoF Chairs: Gorry Fairhurst and Janardhan Iyengar
  • Type: WG forming
  • Number of people expected to attend: 100
  • Length of session: 1.5 hours
  • Conflicts to avoid: all TSV WGs, TSVAREA, 6lowpan, avtcore, avtext, rtcweb, mmusic, l2vpn, l3vpn, softwire
  • Does it require Webex: No
  • Does it require Meetecho: Yes (expecting remote participants)
  • Links to the mailing list, draft charter, relevant I-Ds: