[RPRWG] First Meeting of X.msr Ad-hoc
RPRWG,
please see attached minutes.
Next meeting is Wednesday Feb 26, 2003, 12:30 EST
866-902-7862 ID 8021717
mike
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 cell:613-220-6991
Minutes for the X.msr Ad-Hoc for 2/21/03
Attendees:
Mike Takefman, Glenn Parsons, David James, Kshitj Kumar, Anoop Ghanwani
Meeting Goals:
Discuss the points raised in the January 2003 Interim Meeting X.msr Ad-hoc
and in Dr. Yu's meeting report. Determine which if any requirements cause
changes in the draft and whether those changes are feasible.
Discuss the process for incorporating those changes into the work of the
group.
Specific Points from Dr. Yu's meeting report.
(1) Tributary Multicast can use group addresses for multicast and
broadcast. 802.17 to determine if the standard has to define a primitive
to support the setting/delete of a GA in the MAC or whether this is an
implementation detail.
Resolution:
This is an implementation detail 802 MACs do not provide group address
filters.
(2) Topology Database Interaction MA_CONTROL.indicate is a sufficient
protection trigger to X.msr as it delivers a new database on topology
changes. Request for a method to get the database from the MAC on client
demand. 802.17 to determine best method for achieving this ( MA_CONTOL.request
or some other method)
Resolution:
Raise a comment against D2.1 to add an opcode to MA_CONTROL.request and
MA_CONTROL.indicate called TOPOLOGY_STATUS. When MA_CONTROL.request is
invoked with TOPOLOGY_STATUS it causes MA_CONTROL.indicate to return the
current topology and status database.
(3) Tributatry Based Protection requires MAC to inform X.msr of a protection
events on a period basis.
Resolution:
The draft assumes that all indications are reliable and sent once.
The issue of creating a periodotic indication (that repeats until
acknowledged) is an implementation detail.
Raise a comment against D2.1 to add an informative note that recommends
this implementation in support of X.msr
(4) Broadcast Network - single fiber uni-directional chain or ring
may be supported by 802.17 depending on topology/protection mechanisms
being disabled. MA_DATA.request is currently specified to allow a packet
to be sent with Wrap Disable, Protection Disable, and Steering Disable
by explicitly requesting a particular ringlet with no protection.
Requires further study to determine if other MAC mechanisms would
prevent this request from being fulfilled..
Issues discussed by the group:
Ethernet PHYs are inherently bi-directional, if the incoming light is
lost, the transmit laser is shutdown. This is not the case for SONET PHYs.
Lack of a topology image means that the MAC cannot transmit any packets.
A possible solution is to allow a manual configuration of the database along
with an override so that the topology sublayer does not clobber it.
Fairness will not work, given the lack of a return path
Resolution:
The group feels that this is a unlikely enough case in terms of deployment
and does not justify the work to make the necessary changes to the draft.
(5) Need to provide specification for Manual Protection Switch invocation
Resolution:
Send a message to the PAH on the need to specify this in the standard.
Allow the PAH to determine what interface is used to cause the invocation
to occur. Possibilities are LME, MA_control.indicate.
(6) Plug and Play versus Pre-planned. RPR actually does both, Plug and
play operation guarantees that topology / protection works automatically.
The LME system allows the provisioning of bandwidths to be done.
Resolution:
Raise a comment against D2.1 to define the provisioning of BW. Should be
put into the LME?
(7) Need Fairness Algorithm (FA) of MAC to support services of Class B and C.
Resolution:
Given the change in X.msr to support fairness (and not just A0) there is no
change required
(8) Support for both local address and OUI MAC addresses. (MAC address will
be sent from MAC layer.)
Resolution:
This is supported, as all MAC address checks are done using the full 48 bits.
The setting of the MAC address within the MAC layer is an implementation
detail.
(9) Client needs the following additional opcodes: the supported
floodingForm (FF) (bi-directional or uni-directional), pastSource (PS),
strictOrder (SO), remote forwarding, single-queue / dual-queue (primary
or secondary), various shaper opcodes and chosen center wrap / edge wrap
for the data path. The supported fairness algorithm, including each station
in proportion to its relative weight, unused bandwidth, single-choke,
multi-choke, basic status, variables and parameters of FA. A sub-clause in
section 9 (FA) is needed to describe interface to client.
The supported topology database and the related opcodes.
The supported wrapping status opcodes, path indicator (PI), opcodes of
protection message request type (PMRT), basic status, variables and
parameters in section 11.
Resolution:
This paragraph is unclear. Mike is actioned to email Dr. Yu seeking
clarification as to what this paragraph is stating
(10) Annex added to current draft of P802.17.
Resolution:
At the end of the call it was agreed that none of the changes to the draft
are needed to be in an annex and were likely more suited to being part of
the existing clauses.
(11) Add X.85/Y.1321 (IP over SDH using LAPS) as a SONET/SDH Physical Layer
and Reconciliation layer. Requires a liason letter to ITU SG17 TSB for a
new SAPI value for RPR.
Resolution:
A motion must be made to the WG to adopt X.85. Assuming that the group
were to accept this, the PHY layer editor then has to add a new SONET PHY
in referencing the ITU standard. Dr. Yu must work with the Editor to create
the section.
(12) Dr. David James to contact IEEE 802 RAC and provide some helps for
Ether-type public codes assignment of X.msr-rpr. After checking IEEE web page,
0x88b5 and 0x88b6 may be two candidates.
Dr James will contact Dr. Yu to discuss.
Actions: Mike to Contact Dr. Yu on 9) and PAH on MS/FS
David to contact Dr. Yu