RE: [EFM-Copper] discovery and adding pairs...
Matt,
Let me correct your description a bit (there's also a problem description
with clause 45 at the end of the email, so read to the end).
>> 3) If that write fails, then some pair is already (and currently) active
in the aggregate.
If the write fails, then the remote PCS has been already discovered through
another pair belonging to the same aggregate group.
It's not clear to me what "active" means. In any case that other pair may
not be Up yet.
>> 6) If the write succeeded, the identifier should be recorded for future
PMD/pairs to compare against when they initialize.
That identifier is equal to the content of Aggregation Discovery Code for
that PCS, so there's no need to record it.
>>7) At any point where there are no pairs left in an aggregate, its
discovery register must be zero'd out again.
I'm not sure the remote discovery register should be zero'd at the end.
In my view it should retain it's value till Phy Reset, so that pairs can be
dynamically removed/added. Also it would help in the case when one pair is
detached and moved to another CO (as a result of human mistake for example)
when the aggregated link is still Up. The newly connected CO then would
discover that the remote PCS is already taken by another CO.
----------
There's a problem though with the current draft -
in 45.2.1.14.1 Link partner aggregate operation,
it says that Remote PMI_Aggregate_register is accessed via G.HS messages
(which is good since it allows to add a new pair to an existing aggregated
link via a G.HS message over that pair). However it also says that the
operation "must be performed only when the link status is down (i.e.,
neither Initializing nor Up).". I read the "link" here as the aggregated
link and not the pair, so this is bad, since it precludes dynamic
aggregation modifications.
If my understanding of this paragraph is correct I would suggest the
following change in 45.2.1.14.1:
"The write operation to the Remote PMI_Aggregate_register can be performed
independently of the aggregated link status, provided that at least one
PMA/PMD in aggregation group in -O is Ready for Handshake."
This would allow addition and removal of pairs to an already operating link.
Note also that if a pair is already assigned to the aggregation group in
both -O and -R PCS than it's addition/removal is done by PMA/PMD link
control register (see Table 45-5) which can set the pair down or initiate
it.
Regards,
-Edward
-----Original Message-----
From: Matt Squire
To: Towne, Jeffrey R (Jeff); stds-802-3-efm-copper@ieee.org
Cc: Barry O'Mahony (E-mail); Hugh Barrass (E-mail); Michael Beck (E-mail)
Sent: 10/11/03 22:43
Subject: RE: [EFM-Copper] discovery and adding pairs...
Hugh pulled me aside, and while threatening to break my legs, cleared
something up for me:)
Within the current draft, (somewhere) it indicates that the "write"
operation used for the discovery process is an atomic read/write that
fails if something has already been written. Such an atomic operation
(i.e. can't write to that register if something is already up in the
aggregate) is what ensures that PMDs/pairs can be discovered in the
future.
Since I was confused, I'll pass my new understanding. Hugh can break my
legs and threaten me again if I get it wrong. The basic operation is...
1) When a PMD/pair comes up, the CO-side attempts a write to a register
on the CP side.
2) If that write succeeds, then nothing has been written to this
aggregate register in the past (its initialized as zero), so this is the
first pair to come up in that aggregate.
3) If that write fails, then some pair is already (and currently) active
in the aggregate.
4) In either case, a read returns the identifier for that aggregate.
5) If the write had failed, then this identifier can be used to find the
aggregate to which this pair should be added.
6) If the write succeeded, the identifier should be recorded for future
PMD/pairs to compare against when they initialize.
7) At any point where there are no pairs left in an aggregate, its
discovery register must be zero'd out again.
The above process (I believe) addresses my concern, so I think things
are ok. However, I still find the text explaining the above process
pretty darn confusing.
- Matt
> -----Original Message-----
> From: Towne, Jeffrey R (Jeff) [mailto:jrt@lucent.com]
> Sent: Monday, November 10, 2003 8:46 AM
> To: Matt Squire; stds-802-3-efm-copper@ieee.org
> Cc: Barry O'Mahony (E-mail); Hugh Barrass (E-mail); Michael Beck
> (E-mail)
> Subject: RE: [EFM-Copper] discovery and adding pairs...
>
>
> I agree.
> Most "inverse multiplex" schemes can accomodate adding
> and/or removing members without restarting the aggregate link.
> Why invent a new one that does not have this capability?
>
> Jeff Towne
>
> -----Original Message-----
> From: Matt Squire [mailto:MSquire@hatterasnetworks.com]
> Sent: Sunday, November 09, 2003 9:53 PM
> To: stds-802-3-efm-copper@ieee.org
> Cc: Barry O'Mahony (E-mail); Hugh Barrass (E-mail); Michael Beck
> (E-mail)
> Subject: [EFM-Copper] discovery and adding pairs...
>
>
>
> One of my TR comments against D2.1 (#302) asked for a
> clarification about how the discovery process can add loops
> to an up and running EFM copper interface (10PASS/2BASE). I
> thought I just misunderstood the discovery process because
> it did not seem possible to add a loop to 10PASS/2BASE port
> that is already operational. The response to the comment is
> that I was correct and that its not possible.
>
> Does anyone else find it unacceptable to have to take down
> all pairs to "re-discover" which pairs can be included in an
> aggregate? IMHO, this is a bizarre and unobtainable
> restriction. Pairs, in general, don't come up at the same
> time. They can go away and come back. The discovery process
> we have in place does not take that into account.
>
> Am I out in left field? Do we think this idea of having all
> ports initializing at the same time is at all feasible?
>
> - Matt
>
>