Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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