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

opinions needed for trunk protection

Hi All,

 

I was reviewing the Trunk Protection section and found that assumptions made in 1904.1 and carried over into 1904.4 may not hold anymore.

Iâ??d like to get some feedback on my question below. To remind you, here is a drawing of trunk-protected PON:

 

The two OLTs can be in different central offices and the fiber length would be very different for the primary and backup trunks. The 1904.1 assumed that the backup OLT derives or is given the RTTs for all working ONUs and when the primary OLT or trunk fails, the backup OLT can just take over and start granting all registered ONUs.

 

 

The problem I see for 1904.4 is that now we have mandatory authentication and encryption. Is it reasonable to assume that the backup OLT can access ONUâ??s authentication and encryption data, including the encryption keys that exist within the primary OLT?

 

I donâ??t think this is feasible without creating major security problems.

If authentication data and keys are not available to the backup OLT, then the protection switching event should be followed by these steps:

 

1)  ONU and OLT stop sending all user data

2)  Synchronize MPCP clocks at the ONUs based on backup OLT MPCP clock

3)  Synchronize CipherClocks at the ONUs (for IV derivation)

4)  Re-authenticate all ONUs

5)  Derive the initial keys for every ONU.

6)  Start symmetric encryption (AES256)

7)  Enable user data

 

I donâ??t think we can avoid most of the steps of a normal ONU startup sequence shown below. Maybe we can avoid steps 1 and 6, if the backup OLT gets ONUs IDs and RTTs externally and the ONU preserves the configuration during the HOLDOVER period.

 

 

 

Thank you,

Glen

To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature