Project

General

Profile

Support #555

Link Failover reliability problem - implication to protection application

Added by Herbert Falk almost 4 years ago. Updated about 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Profile or Guideline
Start date:
02/16/2021
Due date:
10/25/2022 (over 2 years late)
% Done:

0%

Estimated time:
ID:
2
Source:
H30
TF Unique ID:
2 # H30
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
No
Short Proposal:

H30 to provide more details.

Standard(s):
Needs More Information:
Assigned TF:

Description

• Failover at link layer – from 2ms to 2 sec.
Link Failover reliability problem –
Solution 1: need for end-end to connection oriented monitoring
Feedback: Can relays monitor end-end link integrity? What existing IEEE 802.x standards? What new network standards – PSCC, …? Can failover be less then 1ms?
Solution 2: End-end communication path monitoring + centralized network monitoring including relay communication.
FAST switchover to backup protection (within 1 ms).

To define reassessment for other relative parties. To be completed by H30

#1

Updated by Herbert Falk almost 4 years ago

  • Status changed from New to Accepted
#2

Updated by Vladan Cvejic almost 4 years ago

  • Subject changed from • Failover at link layer – from 2ms to 2 sec. Link Failover reliability problem – Solution 1: need for end-end to connection or to Link Failover reliability problem - implication to protection application
  • Category set to Profile or Guideline
  • Discuss in Upcoming Meeting set to No

Checking done.

#3

Updated by Carlos Rodriguez del Castillo almost 4 years ago

  • Discuss in Upcoming Meeting changed from No to Yes
#4

Updated by Vladan Cvejic almost 4 years ago

  • Due date set to 08/16/2021
  • Status changed from Accepted to Triage
  • Start date set to 02/16/2021
  • Short Proposal set to H30 to provide more details.
  • Discuss in Upcoming Meeting changed from Yes to No
  • To discuss in WG10 set to No

H30 to provide more details.

#5

Updated by Carlos Rodriguez del Castillo almost 3 years ago

With PRP/HSR this should not be an issue, clarify with Dustin

#6

Updated by Carlos Rodriguez del Castillo almost 3 years ago

2 points:
1. Link status
- Link status could be reported by SNMP protocol (MIB) (IEEE 802.3.1-2013)
- SNMP mandatory in IEDs? It seems too hard
- LCCH LN? ChLiv / RedChLiv
- IEC 62351 is purely security related
- IED or switches should provide a MIB for monitoring purposes
- Herb will check where in the standard IEC 61850-90-4
- IEC 61850-90-22 Autorouting section 4.3.2
- IEC 61850-90-28 Comm supervision
2. Faiolver mechanism
- IEC 61850 allows HSR, PRP, RSTP as redundancy mechanism. Failover mechanism is described in 90-4.
- Action: Take a look on 90-4 and see if clarification is needed for failover use

#7

Updated by Carlos Rodriguez del Castillo almost 3 years ago

  • To discuss in WG10 changed from No to Yes

On the link failover topic, the ask is:
1. Link Monitoring: WG10 to map MIB (SNMP) to an a new attribute and make it available for monitoring –
• Minimum requirement is to have HEALTHY/FAIL status but it would helpful to have more detailed information.
• The expectation is not to make this mandatory at this time but in future
2. Link Failover: WG10 to include in Guide to help users understand:
• The options available on link monitoring
• Link-failover options & timelines & architectures
• HSR/PRP usage & monitoring

There are 2 topics: Link Monitoring and Linkfailover and both of them are not out of scope of 61850 as it is upto the users to decide on implementation based on their priorities. I agree that WG10 Guide can make recommendation on superior practice for PRP & HSR for GOOSE/SV applications but it does not make sense to use HSR/PRP for a metering application which is polled once every hour while link monitoring & link failover still has a use in this application.

#8

Updated by Carlos Rodriguez del Castillo almost 3 years ago

  • To discuss in WG10 changed from Yes to No

- 90-4 only mentions we should not take care about link failover because we have PRP/HSR as redundancy mechanism
- Topic: supervision
- Use LCCH.ChLiv and RedChLiv to indicate the status of the physical channels
- 90-4 models SNMP MIB to IEC 61850 LN, maybe it is not complete --> This should be a different issue in redmine
- 62351-7 maps MIB to 61850
- We need a detailed use case about SNMP information that needs to be mapped in IEC 61850 or with direction is needed
- Confirm if we are talking about SNMP mapping to IEC 61850 data model environment
- There is no request to do something with 90-4
- Topic: standardization
- You can use link failover transparent to 61850
- It is out of the scope of the standard
- IEEE 802.3ad "Link Aggregtion" is not the same thing as link failover

Actions:
- If LCCH.ChLiv/RedChLiv is not enough, then we need more information from H30
- Maybe SNMP map to IEC61850 in 90-4 is not enough. We have to create a new issue for this in redmine an provide users information
- To discuss in the plenary:
- 90-4 update
- 90-4/3 data models to 7-4 IS (for edition 3)

#9

Updated by Vladan Cvejic about 2 years ago

  • Due date changed from 08/16/2021 to 10/25/2022
  • Status changed from Triage to Rejected
#10

Updated by Vladan Cvejic about 2 years ago

Rejected since PRP and HSR are the standard ways to accomplish this. IEC 61850 is not providing mechanism to achieve this.
Application monitoring is already addressed by TF Supervision.
Link layer is intentionally abstract to application layer.

Also available in: Atom PDF