IETF/IEEE 802 Liaison Report
Bernard Aboba
July 2006
IEEE 802.11
Dorothy Stanley’s July IEEE 802.11 status report is available here:
http://www3.ietf.org/proceedings/06jul/slides/capwap-0/sld1.htm.
A liaison statement has been received from IEEE 802.11, relating to “Network Discovery and Selection Problem”, draft-ietf-eap-netsel-problem-04.txt. The statement is available here:
https://datatracker.ietf.org/documents/LIAISON/file346.doc
IEEE 802.16
DJ Johnston has been appointed as the liaison from IEEE 802.16 to IETF, replacing Jeff Mandin.
IEEE 802.16 has been requested to review the IAB Multiple Encapsulations document. No feedback has been received yet. The document is available here:
http://www.ietf.org/internet-drafts/draft-iab-link-encaps-02.txt
IEEE 802.17
A revised version of the RPR MIB was forwarded by IEEE 802.17 Working Group to the IETF Operations and Management Area with a request for MIB Doctor review. Bert Wijnen performed the MIB Doctor review and answered back on August 24.
IEEE 802.1 Liaison
(from Bert Wijnen)
Bert Wijnen has been appointed as the IETF liaison to IEEE 802.1.
Bert’s IEEE 802.1 Liaison Presentation at the July IEEE 802 Plenary in San Diego is available here:
http://www.drizzle.com/~aboba/IEEE/ietf-to-8021-July2006.ppt
VLAN Tags
A liaison statement was received from IEEE 802.1 relating to appropriate use of IEEE 802.1Q VLAN Tags:
http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-mef-dsl-forum-0706.pdf
GMRP
An informal liaison request relating to GMRP was sent to IEEE 802.1 by the MBONED WG, and an informal response was received from IEEE 802.1 which was provided to the MBONED chairs (see below).
Congestion Management
Lars Eggert presented input from the IETF Transport Area to the IEEE 802.1 Congestion Management PAR:
http://www.ieee802.org/1/files/public/docs2006/au-eggert-ietf-cn-par-input.pdf#search=%22IEEE%20802%20Congestion%20Control%20Lars%20Eggert%22
As a result, 802.1 CM has added coordination with the IETF Transport Area to the list of work items.
-----------------------------------------------------
Date: Fri, 21 Jul 2006 01:07:49 +0200
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: 'Hiroshi Ohta' <ohta.hiroshi@lab.ntt.co.jp>,
'Marshall Eubanks' <tme@multicasttech.com>
Cc: "Dan Romascanu (E-mail)" <dromasca@avaya.com>,
"Bernard Aboba (E-mail)" <aboba@internaut.com>,
'Pekka Savola' <pekkas@netcore.fi>,
"David Kessens (E-mail)" <david.kessens@nokia.com>
Subject: RE: IEEE 802.1 liaison query from MBONED w.r.t usage of GMRP
MBONED WG chairs,
The below proposed answer has been agreed to at this weeks 802.1 meeting. It is not a formal liaison response, because we also did an informal liaison request. But it does represent (informal) agreement from 802.1 as discussed at their closing plenary on 20 july 2006.
I assume you wil further communicate this back to the WG.
Bert and Dan
-----Original Message----- From: IEEE 802.1 list-owner On Behalf Of Norman Finn (nfinn) Sent: Thursday, July 20, 2006 15:07 To: STDS-802-1-L@listserv.ieee.org Subject: [802.1 - 456] Communication with IETF
These were the questions from IETF regarding GMRP, along with my proposal for an answer.
Question from IETF MBONED WG IEEE 802.1D-2004 GMRP implementation/deployment
MBONED WG is in the process of writing a multicast routing architecture [1]. One part of that is flooding reduction in LAN networks. The most typical solutions deployed include IGMP/MLD snooping, but IEEE 802.1D-2004 (and previous, separate specifications) also describe GARP Multicast Registration Protocol (GMRP) which could be used between a host and a switch to perform multicast flooding reduction.
However, GMRP requires support at both the host stack and the switch. We know about at least one switch stack GMRP implementation, but it is not clear whether there is more widespread support. It is not clear whether host stacks support GMRP.
The current MBONED WG document [1] states that GMRP “implementation status is unknown”.
What does IEEE 802.1 think is the current status of LAN IP multicast flooding reduction?
What does IEEE 802.1 see as the vision for LAN IP multicast flooding reduction? Deployment/implementation status?
Could you summarize the implementation status of GMRP both at host and switch stacks?
Could you summarize the deployment status of GMRP both at host and switch stacks?
PROPOSED ANSWER
At the time GMRP was prior to publication in (IEEE Std. 802.1D-1998), it was not clear what was the best way for bridges to prune back multicast addresses. The original intention of the standard was that routers and hosts would run both L3 multicast control protocols and run GMRP. A host that wanted to receive a particular IP multicast would issue both IGMP and GMRP. The bridges would pass IGMP transparently through, to the routers, and use GMRP to prune the bridged paths.
Among the assumptions made by those standardizing GMRP were that multicast would be a large proportion, if not most of, the traffic carried by a bridge, that there would be other sources of multicast frames besides IP. Furthermore, because IGMP specified that the destination MAC address of an IGMP packet was the same as that used by the corresponding data flow, it was not clear whether bridge vendors would be willing to make the hardware changes to then-current bridges to enable them to violating layering rules and “snoop” on IGMP.
In the event, IGMP snooping became the norm. Implementations of GMRP are rare, and in fact, a proposal to remove GMRP from IEEE Std 802.1D-2004 was seriously considered. Similarly, there was very little support for GMRP’s cousin, GVRP, that pruned back the distribution of broadcasts and flooded unicasts based on VLAN, rather than by destination MAC address.
New work was begun in 2002 on Provider Bridges. Whereas 100 VLANs had been a very large number in the enterprise space, this new effort made it clear that, in the provider space, 4094 VLANs were not enough. Pruning back these VLANs became important, and it was realized that GVRP could not satisfactorily handle that many VLANs. Also, the work on Provider Backbone Bridges, begun in 2004/2005, gave reason for a provider to wish to control the distribution of many thousands of (non-IP) multicast destination addresses.
One result of the provider bridging activity has been the creation of project P802.1ak, Multiple Registration Protocol, which is just now coming to completion. This protocol allows a bridge to express its preferences (and anti-preferences) for approximately 4k VLANs or consecutive MAC addresses in a single 1500-byte control packet, and for the very efficient propagation of that information through a bridged network.
Lastly, 802.1 started P802.1aq Shortest Path Bridging, last year. Although this project is not as far along as the other projects mentioned, it has become clear that, in order to forward unicast frames along optimum paths through the bridged network, and also forward multicasts optimally, bridges are likely to place a premium on knowing which hosts and routers can serve as sources of each multicast stream, as well as knowing which want to be sinks.
At this time, in the absence of widespread knowledge in IEEE 802.1 of your work, it is unknown whether snooping on IETF protocols, or adding a new protocol to hosts’ and routers’ repertoires is the better way to supply bridges with this information.
So, to answer to your question about GMRP: “It’s obsolete. It has been replaced by something much better, for bridges’ purposes, MMRP. We do not expect hosts and routers to use MMRP for obtaining IP multicasts. But, we would like to talk to you about possibilities for satisfying our needs for source information, while avoiding a repeat the IGMP experience, wherein bridges had to add hardware features in order to snoop on the IETF control protocol.”