IETF News

IETF 66 Review: Wireless

By: James Kempf

Date: September 7, 2006

line break image

A new wireless-related working group, 16NG, which is working on IPv6 over 802.16 wireless links, met for the first time during IETF 66. The group previously met twice as a BoF and several times in interim meetings as part of its aggressive agenda to meet the deadlines for WiMax network deployment. A design team is currently working on a document describing how to map the IPv6 subnet onto the 802.16 link.

HOKEY, which deals with usage of the extensible authentication protocol (EAP) in emerging mobile networks held its second BoF meeting at IETF 66 to discuss standardizing the EAP application key hierarchy for handover, backend authentication-authorization-accounting (AAA) work for preauthentication, and AAA key distribution for services.

The number of new BoFs related to wireless appears to be slowing. With a number of working groups pursuing wireless topics already formed, particularly in the Internet area, the capacity for IETF to do more work is limited. Therefore, chartering new groups may need to wait until existing working groups are finished and have closed.

Group Providing IP Mobility Support for IPv6 Starts Up

NETLMM, a group recently formed in the Internet Area is currently developing a protocol to provide IP mobility support for IPv6 in the network, rather than as a host-based service like Mobile IP. According to the NETLMM charter, the host is not involved in IP-level movement. The host keeps the same IP address across a span of the wireless network and wired backhaul that is limited topologically to a local area, called a localized mobility management domain. The host keeps the same IP address as it moves around a geographical area that is covered by a collection of wireless access points. The access points are connected through a wired IP backhaul into a topologically limited domain, called a localized mobility management domain. The exact topological extent of the localized mobility management domain depends on particular deployment circumstances. The host never changes its IP address as it moves across the localized mobility management domain, while routing updates to a mobility anchor from the local access router ensure that the host continues to receive its traffic. Existing cellular architectures provide similar support, but are limited to a single family of wireless technologies, such as UMTS, while NETLMM is independent of wireless link technology. NETLMM serves to complement Mobile IP, since Mobile IP is still needed if the host requires session continuity as it moves between localized mobility management domains.

A problem statement document and a requirements document have been sent to the IESG. The IESG has reviewed the problem statement document and returned it for further editing; the requirements document is still in Area Director review.

At the IETF 66 meeting, the primary topic of discussion was the first draft of the design team protocol document. The design team has been meeting since February, and the first draft of its protocol design was published in June. The protocol consists of messages to associate a mobile node with a mobility anchor in the wired backhaul network, called a Localized Mobility Anchor (LMA), when the mobile node first comes on the network. The protocol also provides messages that allow a Mobile Access Gateway (MAG) located at the access router to move the forwarding end point for the mobile node from one access router to another as the mobile node moves across the localized mobility management domain. The working group gave feedback to the design team on the document, recommending that the design team try to simplify the protocol.

The working group also discussed a draft describing the mobile node to access router interface. Prior to the Montreal meeting, the working group was operating on a type of addressing model for the mobile node to access router interface called “multilink subnets”, in which the access routers all advertise the same IPv6 subnet prefixes on their wireless interfaces while continuing to function as routers on their wired interfaces. In the past, this model was discussed and rejected by the IETF. Currently, the working group is conducting discussions on its mailing list to determine the type of addressing model it will support. Outcomes are expected by early August.

The protocol design team plans to continue meeting for two months and to issue a final draft in the middle of September. The working group is planning an interim meeting at the end of September to discuss issues with the design. It hopes to have the protocol draft ready for working group last call by early October.

CAPWAP Makes Progress

The Control and Provisioning of Wireless Access Points (CAPWAP) working group, which operates in the Operations and Management Area, is developing a protocol for control and provisioning of wireless access points. The initial target wireless protocol is 802.11, which is designed to allow a centralized Access network Controller (AC) to control a collection of access points, called Wireless Termination Points (WTPs), in the CAPWAP architecture. The AC performs such functions as power management, load balancing, and security, functions that are difficult to perform on the individual access points because they require co-ordination. The working group recently published two RFCs as follows:

RFC 4564: describes objectives for the CAPWAP protocol
RFC 4565: describes a protocol-design evaluation to determine which of several candidate drafts the working group should use as the starting point for the standard.

The working group is planning to complete the protocol and MIB by June 2007. The chairs are interested in determining whether there are any implementations of CAPWAP underway, and in organizing an interoperability test.

At their meeting at IETF 66, the editors of the CAPWAP protocol specification discussed issue resolution on the document. One of the main issues was the replacement of the original CAPWAP security protocol with datagram transport layer security (DTLS). The protocol document has now been edited to reflect the design change. Use of DTLS will ensure that CAPWAP would benefit from fixes of any flaws discovered in the DTLS protocol by other applications. The working group decided that the first standardized version of the protocol will reflect only changes to the 802.11 protocol that are incorporated into the 802.11ma specification. 802.11ma is an update of the 802.11 specification, which is due out next year and which will include all of the amendments (such as 802.11i, 802.11e, etc.) that have been put in place since the original 802.11 specification was published in 1999.

The primary topic of discussion at the meeting was a proposal to multiplex control and data traffic between the WTPs and the AC on a single UDP port. This would cause all CAPWAP control messages in addition to all data traffic from the 802.11 terminals to go through a single port on the AC. The reason for this proposal is that it would simplify network-address-translation (NAT) keepalives for deployments in which NATs are positioned between the AC and WTPs. The keepalives on the control traffic between the WTPs and the AC serve to also keep the NAT bindings for the 802.11 terminal data channels active in case the terminals go dormant.

The main argument against this proposal is that it would limit scalability. All traffic for terminals on the WTPs would need to go through a single port on a single AC. This would put a reduced upper limit on the number of WTPs that an AC could support, compared with the case in which multiple ports are used.

Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects the author’s personal perspective on some current highlights.

In addition, existing middleboxes between the WTPs and the AC won’t recognize the multiplex header, which could cause problems. A consensus call made earlier this year resulted in an almost even split in opinion among working group members. Currently, the working group is undergoing a rather heated debate about this issue, and the chairs have requested that the IESG provide a designated domain expert to provide input.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *