[802SEC] Trip Report ITU-T SG 9/15, 7/17 Joint Meeting
please find attached my report from my trip to
Oslo to present the IEEE 802 liason to ITU-T SG17.
I had sent it earlier, but it appears that it
was eaten enroute.
Michael Takefman firstname.lastname@example.org
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867
ITU-T Q7/17 & Q9/15 Joint Meeting on X.msr - Oslo, Norway
Mr. Ghani Abbas, Marconi Communications, Rapporteur Q9/15
Mr. Shaohua Yu, Wuhan Research Institute of P&T, Rapporteur Q7/17
Mr. Arve Meisingset, Telenor R&D, Vice Chair SG 17
Mr. Michael Takefman, Cisco Systems, Chair IEEE 802.17
Mr. Glenn Parsons, Nortel Networks, OAM Editor IEEE 802.17
Mr. Ming Feng, China Telecom Corp
Mr. Mingkai Ma, China Academy of Telecommunications Technologies
Mr. Wedong Wang, China Academy of Telecommunications Technologies
Mr. Huub van Helvoort, Lucent Technologies
Mr. Vitorrio Mascolo, Alcatel
Mr. Fabio Perunzzini, Tilab
Mr. Rune Skogan, ADVA Optical Networking
Mr. Audun Fosselie Hansen, Telenor R&D
Mr. Hakon Lonsethagen, Telenor R&D
Mr. Oyvind Arntzen, Telenor Networks
Mr. Asbjorn Klomstad, Telenor Networks
Mr. Bjorn Johan Vullum, Netenor Networks
The purpose of the meeting was to share liasons from
ITU-T SG 15 and IEEE 802, 802.17 with Q7/17 on the
X.msr draft and to come to a decision on the issues of
Approximately 2/3 of a day was devoted to presentations
of the liasons and other background material from Q9/15,
Q7/17 and IEEE 802.17. The material includes comparisons
between the two technologies, feature sets and questions highlighting
technical concerns with the proposals. The remaining 1 1/3 days was
spent creating a feature table of X.msr and RPR and determining
areas of overlap and "responsability" within ITU-T and IEEE 802.
A few observations:
1) the scope of IEEE 802.17 is confined to the MAC layer while
X.msr defines both a MAC layer and a service (client) layer.
Mr.Takefman made it clear that the service layer was outside the
scope of 802.17 and that 802.17 was focused only on defining
a MAC layer.
2) X.msr is intended for deployment throughout the world, as
compared to being a regional technology for China.
3) X.msr is providing transport services as compared to bridged
services. X.msr could be described as an ADM that uses packets rather
than timeslots as the multiplexing method.
4) X.msr is intended for provisioned environments only with no
possibility of over subscribing the media and hence no need for
5) X.msr allows for protecting the tributaries (service) as well as
protecting the MAC.
6) X.msr is defining a larger number of physical topologies that include
2 fiber rings, 4 fiber rings (although not discussed, the assumption is
that this is similar to a BLSR ring), single fiber unidirectional rings,
uni-directional linear chains (for broadcast video distribution)
7) Q7/17 has timeline to agree to the final text of X.msr at the November
meeting (similar to WG ballot), during the plenary of that meeting
they would consent the draft recommendation (similar to initiating
Sponsor ballot). ITU-T procedures are that following consent, the document
is distributed to members. Following a comment period (or 2 months) if
no objection or comment has been received from an ITU member the
recommendation is approved. Note there is no voting, per se, as
approval has to be unanimous.
White board discussions were held on ways that X.msr could run over
RPR in a non bridged mode. While there are differences in the frame
formats, it is the belief of IEEE 802.17 that the RPR frame format
can meet all of the requirements of X.msr while the reverse is not true.
The major difference in the frame formats revolve around the concept
of tributary services. The X.msr idea is to be able to identify a tributary
based on its type (TT) and a locally administered number (TN).
The decision to receive a packet is based on a match between the
node address (or multicast address) and the TN. Mr. Takefman suggested
that this was similar to a VLAN in 802 and offered to do some research
to determine if this was the case. Clearly, X.msr would use the RPR MAC
in an non bridged environment.
A report was generated summarizing the activities of the meeting
(to be released by Mr. Ghani Abbas (rapporteur Q9/15 and chair of the
joint meeting)). The net result is that there is overlap between
the work in the ITU-T (currently in Q7/17) and IEEE (between 45 %
overlap of features and 75% of features of common interest. Though,
it is actually the opinion of Mr. Takefman that at the MAC layer, the
overlap is closer to 100 %). The overlap between SG15 and SG17 at 50% was
acknowledged as necessitating joint work.
An informal meeting was held after the official meeting closed
to discuss ways in which to proceed.
1) Mr. Abbas suggested that given the maturity of the X.msr document,
it would require significant work to receive consent within the ITU and
that attempting to achieve consent and approval in November was not
likely to be successful.
2) Mr Shaohua Yu (rapporteur Q7/17) initially suggested that X.msr
would be modified to increase the separation between X.msr and RPR
to avoid overlap at the MAC layer. Mr. Takefman suggested, that while
that was possible, it was not clear that given the requirements of the upper
layer of X.msr that the MAC layers would really be that different
in the end, and that IEEE 802.17 could still feel that this would
create two competing international standards and that was exactly
what IEEE 802 would like to avoid as stated in the liason letter.
3) It was then suggested by Mr. Takefman that SG 7/17 seriously consider
using RPR as their MAC layer and building their service standard on top
of it. Mr. Takefman informed Mr. Yu that in IEEE 802.17, equipment vendors
are designing boxes that do a range of services, allowing operators to build
transparent bridged networks, MPLS networks, routed (IP) networks. X.msr
is really just another type of box that can be built on the RPR MAC.
4) Mr. Glenn Parsons (Nortel, 802.17 OAM Editor) talked about how
all of the companies understand the need to get commonality on the MAC layer
and are willing to differentiate at the service layer. Further, it has taken 2
years of intense discussion and negotiation to reach the current state of the
RPR draft, with everyone accepting the loss of some of their favorite
MAC features in order to converge.
5) It was then suggested by both Mr. Abbas and Mr. Takefman that Q7/17
study RPR and attend the next IEEE 802.17 meeting in New Orleans. It was
suggested that they prepare a presention on the X.msr service layer and
the network design / services that they are trying to achieve and a
presentation on how well RPR provides the required MAC services for X.msr.
The hope would be that Q7/17 standardize a service layer and re-uses the
IEEE 802.17 MAC. Mr. Takefman will be preparing a letter to invite Mr. Yu
to the 802.17 meeting.