IETF/IEEE 802 Liaison Report
Bernard Aboba
May 2006
Liaison Appointments
Bert Wijnen has been appointed the IETF liaison to IEEE 802.1.
IEEE 802.16 is in the process of selecting a new liaison to the IETF.
MIB Transfer to IEEE 802.1
David Harrington’s MIB Transfer document has been approved for publication as an RFC:
http://www.ietf.org/internet-drafts/draft-harrington-8021-mib-transition-03.txt
Liaison Communications
Review of PANA Framework by IEEE 802.11
IEEE 802.11 has completed their review of the PANA Framework Document, as well as ruling on an interpretation request relating to PANA. This material is available here:
http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc
http://www.drizzle.com/~aboba/IEEE/11-06-0789-00-000m-response-to-interpretation-request-2.doc
PAR and Charter Reviews
IEEE 802 PAR Reviews
Some IAB and IESG members expressed interest in the PAR request for the Congestion Management project in 802.1. Dan Romascanu provided the IAB and IESG with pointers to the Study Group materials available in the public 802.1 documents folder. Lars Eggert has sent a note to the PILC RFC authors, requesting that they review the PAR. The note is enclosed below.
IETF BOF Reviews
EAP Extensions
The IEEE 802.11 liaison has sent a note relating to the potential use of EAP extensions by IEEE 802.11r. The note is enclosed below.
16ng
IEEE 802.16 has completed their review of the 16ng charter. No additional comments were received beyond what was already sent by Roger Marks, Chair of IEEE 802.16. A conference call was held to discuss the review process; the summary note is enclosed below.
---------------------------------------------------------- From: Lars Eggert <lars.eggert@netlab.nec.de> To: Aaron Falk <falk@isi.edu>, mascolo@poliba.it,marie@mjmontpetit.com, karn@qualcomm.com,Carsten Borman <cabo@tzi.org>,Gorry Fairhurst <gorry@erg.abdn.ac.uk>, dan.grossman@motorola.com,reiner.ludwig@ericsson.com, jmahdavi@earthlink.net, gab@sun.com,Joe Touch <touch@isi.edu>, lwood@cisco.com CC: Magnus Westerlund <magnus.westerlund@ericsson.com>,Sally Floyd <floyd@icir.org>,Bernard Aboba <bernard_aboba@hotmail.com>,Bert Wijnen <bwijnen@lucent.com>, Dan Romascanu <dromasca@avaya.com> Subject: PILC input to IEEE 802.1 Date: Thu, 22 Jun 2006 12:01:29 +0200
Hi,
sending this to the authors of the PILC RFC, because you have the relevant expertise in this area.
The IETF has been informed through our liaison to IEEE 802 that there is a proposal for a IEEE 802.1 study group on congestion control at the link layer. There seems to be a potential here for problematic interactions of congestion control algorithms at different layers.
Apparently, in my current understanding, the resulting mechanism would not be primarily meant to carry IP traffic. However, there are still concerns with regards to co-existence with regular (non- congestion-controlled) Ethernet traffic that does carry congestion- controlled IP traffic.
I’d like to ask whether some of you would be willing to form a team to look at the details of the proposed 802.1 work and craft a short, initial statement to the IEEE that helps them to decide how to scope their work?
The IEEE meets in the week after Montreal, which would be the very last time to provide such input to them. Ideally, we’d send this earlier. (I’m sorry for this short notice, but I have just found out about this myself.)
I believe it will be important to give them input from the IETF side for this meeting, even if it is short and preliminary. There may be an opportunity to establish an ongoing dialog that can discuss the details of the IEEE’s proposal after that.
I’m attaching three related documents on this below. Additional documents are available at http://www.ieee802.org/1/files/public/docs2006/
Please let me know if you’d be willing to help provide this input to the IEEE.
Thanks,
Lars
---------------------------------------------------------- Date: Thu, 1 Jun 2006 09:36:41 -0700 From: Dorothy Stanley <DStanley@arubanetworks.com> To: Bernard Aboba <aboba@internaut.com>, jesse.walker@intel.com, cchaplin@sj.symbol.com Subject: Re: EAPExt and 802.11r - Some thoughts
Bernard, all,
Thank you for the opportunity to comment on the attached slides.
I have the following comments:
1. The current TGr draft key hierarchy uses the existing MSK to derive the R1Keys, as shown in slide 4. This is adequate for TGr’s needs.
2. Potential use of the EMSK has been discussed in the past, and was not adopted, as the MSK could meet the needs of TGr, and not introduce a dependency on future IETF work. Reconsideration of this decision, while possible, would need to have a compelling set of advantages, to gain the required consensus level.
3. The scope of TGr is intra-ESS roaming. Inter-ESS roaming and Cross-media roaming is out of scope.
Dorothy
---------- Forwarded message ----------
Date: Tue, 06 Jun 2006 07:25:03 +0300
From: Jari Arkko <jari.arkko@piuha.net>
To: Roger B. Marks <r.b.marks@ieee.org>, paul.congdon@hp.com,
kstanwood@cygnuscom.com, pbarber@broadbandmobiletech.com,
Jeff Mandin <jmandin@streetwaves-networks.com>,
"Riegel, Maximilian" <maximilian.riegel@siemens.com>
Cc: Jari Arkko <jari.arkko@piuha.net>, aboba@internaut.com,
Soohong Daniel Park <soohong.park@samsung.com>,
gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: Conference call to discuss potential chartering of "IP over .16"
work in IETF
Thanks for a very useful and informative conference call yesterday.
Here’s the latest charter along with some additional background information regarding IETF discussions on it.
Re: were all comments addressed in this version?
The two comments that Roger had made earlier have been addressed in this version. If you meant some other comments, let me know what you are missing.
Thanks,
--------
IP over IEEE 802.16 Networks (16ng)
===================================
Current Status: Proposed Working Group
Chair(s):
TBD
Internet Area Director(s):
Jari Arkko <jari.arkko@piuha.net>
Mark Townsley <townsley@cisco.com>
Technical Advisor(s):
TBD
Mailing Lists:
General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe:
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive: http://eeca16.sogang.ac.kr/pipermail/16ng
Description of Working Group:
Broadband Wireless Access Networks address the inadequacies of low
bandwidth wireless communication for user requirements such as high
quality data/voice service, wide coverage, etc. The IEEE 802.16 Working
Group on Broadband Wireless Access Standards develops standards and
recommended practices to support the development and deployment of
Broadband Wireless Metropolitan Area Networks.
A particularity of IEEE 802.16 is that it does not include a rigid upper
edge MAC service interface. Instead, it provides multiple "convergence
sublayers (CS)" with the assumption that the choice and configuration of
the upper edge will be done in accordance with the needs of a specific
deployment environment (which might be DSL replacement, mobile access,
802.11 or CDMA backhaul etc.).
Specifically, immediately subsequent to network entry, an 802.16 subscriber
station has no capability whatsoever for data (as opposed to management)
connectivity. Especially, in IP CS case, the criteria by which the Base
Station (or other headend elements) sets up the 802.16 MAC connections for
data transport are not part of the 802.16 standard, and depend on the type
of data services being offered (e.g., the set up of link layer connections
will be different for IPv4 and IPv6 services).
Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16
subscriber station is not capable of multicasting (e.g., for neighbor
discovery, ARP, IP multicasting services, etc.) or direct communication
to the other nodes attached to the same Base Station within the same subnet
(prefix).
Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to-end
system definition. Currently, the WiMAX Forum, and, in particular, its
NWG (Network Working Group) is defining a network architecture based on
IEEE 802.16.
The principal objective of the 16ng working group is to specify the
operation of IPv4 and IPv6 over IEEE 802.16, taking into account the
IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may
issue recommendations to IEEE 802.16 and WiMax aiming at improving
support for IP.
The scope of this working group is as follows (WG Deliverables);
- Produce "16ng Problem Statement, Goal and Requirement" to identify the
specific gaps in the 802.16 MA for IPv4/IPv6 support, describe possible
network models (ie. point-to-point, broadcast etc.), and provide 16ng
related terminology to be used for the base guideline while defining
solution frameworks. [Informational RFC]
- Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS"
to define IPv6 operation including the transmission of IPv6 over IEEE
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and
Stateless Address Configuration, Broadcast, Multicast, etc.
[Proposed Standard RFC]
- Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS"
to define IPv6 operation including the transmission of IPv6 over IEEE
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless
Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC]
- Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS"
to define IPv4 operation including the transmission of IPv4 over IEEE
802.16 links, ARP operation, Stateful Address Configuration (DHCPv4),
Broadcast, Multicast, etc [Proposed Standard RFC]
- Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS"
to define IPv4 operation including the transmission of IPv4 over IEEE 802.16
links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast,
Multicast, etc [Proposed Standard RFC]
- Produce "IP deployment over IEEE 802.16 Networks" to illustrate the
IP deployment scenarios including IP CS and Ethernet CS considerations
over IEEE 802.16 networks based on the WiMAX and WiBro.
[Informational RFC]
16ng will not initially consider other work items than the ones listed
above; however, other works related to improved IP over 16ng may occur
in other relevant WGs, and 16ng will participate and help coordinate
with such efforts.
This working group will take dual stack operation into account in its
specifications, and reuse existing specifications whenever reasonable
and possible.
Goals and Milestones:
Jul 06 Submit Internet-Draft on 16ng Problem Statement, Goal and
Requirement to the IESG for considerations of publication
as Informational RFC
Sep 06 Submit Internet-Draft on IPv6 over IPv6 CS transmission over
IEEE 802.16 networks to the IESG for consideration of publication
as Proposed Standard RFC
Oct 06 Submit Internet-Draft on IPv4 over IPv4 CS transmission over IEEE
802.16 to the IESG for consideration of publication as Proposed
Standard RFC
Nov 06 Submit Internet-Draft on IPv4 over Ethernet CS transmission over
IEEE 802.16 networks to the IESG for consideration of
publications as Proposed Standard RFC
Dec 06 Submit Internet-Draft on IPv6 over Ethernet CS transmission over
IEEE 802.16 networks to the IESG for consideration of publication
as Proposed Standard RFC
Feb 07 Submit Internet-Draft on IP deployment over IEEE 802.16
networks to the IESG for consideration of publication as
Informational RFC
----
Some additional information regarding the proposal to charter IP over 802.16 networks (16ng) WG:
In the IETF, IESG, and IAB review of this charter a discussion arose about the the standardization of multiple different encapsulations for the same functionality. It is understood that this matches the different convergence sublayers defined in 802.16, that the characteristics of the link layers are outside the domain of the IETF, and that the decisions about these sublayers have already been taken. Nevertheless, having multiple ways to provide the same functionality can be harmful for interoperability, users, and can even affect the adoption of the technology in question.
Comments addressing this issue would be highly appreciated.
In the IETF discussion we converged on the following:
1. Handle both EthCS and IPCS work in the WG, with both specifications targeting Proposed Standard Status.
2. Ensure that there are sufficient mechanisms for the selection of the CS layers during usage. For instance, negotiation of the supported and used CSes. This functionality (or most of it) may already exist in 802.16.
3. The IETF shall not start mandating mandatory-to- implement CSes, at least not on client side. Such mandates on the network side equipment could potentially be useful, as any type of client implementation would be sure that it can connect to the network. But how disjoint are the different deployments? If they are for very different types of networks and devices, additional mandates may not be worthwhile.
4. The scope of the EthCS work requires clarification. In a DSL replacement scenario, for instance, IP/ARP/ND behaviour needs to be the same as we already have, assuming we may be bridging to regular Ethernet. So it seems that we are mainly talking about how bits are arranged in 802.16, not a change in, say, ND. Its unclear what specification work remains, although details and guidance could of course be documented. But the scope is much narrower than in the IPCS case. It would also be useful to understand what the ambition level is for, say, introduction of advanced compression schemes for IP over EthCS, and their relation to work in IEEE 802.16.