8/4/2019 1003_WG10_Ag20_DraftComm-VHerbFalk (2)

1/2

Systems Integration Specialists Company, Inc.6605 19 Mile Road, Sterling Heights, MI 48314-1408

Tel: +586-254-0020, Fax: +586-254-0053E-mail: info@sisconet.com, Web: http://www.sisconet.com

Date: 2/1/2010 Version: 0.2

Disclaimer: The following is a draft framework/proposal of a potential communication profile

that could be applied to IEC 61850-90-5. The technical information is incomplete and as such isnot 100% correct and should not be used as a basis for implementation. There are known issues

with this document. Additionally, the IEC 61850-90-5 team has not provided any feedback and

as such has no basis within IEC.

IPv4 IPv6

UDP or Other

IP QOS to IEEE Priority andVLAN Mappings

IEC Hdr PDUs

Tot MsgLength

Msg Num

SubSqNum

EOM

PDUType (Tunnel, ) Tunnel PDU

Dst Mac Address

Length

GOOSE or SV

Length of Segment

Secure HMACN+1 PDU (APDU)

The above figure represents the start of a thought process for a communication profile that could

satisfy the NASPInet requirements. It is far from complete and I have put this together in myspare time.

The profile is basically something like UDP (probably UDP), IP (v4 and/or V6), with aspecification that maps IP QOS to IEEE Priorities. We may also need to map some IPv6

attributes to IEEE VLAN tags. The reason for this is that priority needs to be maintainedthrough the intervening switches (e.g. between the implementation and the router).

The idea would be to utilize UDP/IP to provide multicast or unicast capability (it is suggested

that we concentrate on multicast).

I have identified two specific use cases for this type of profile:

The need to allow tunneling of the current GOOSE and SV packets (allowing agateway to provide proxy information so that relays and PMUs can send information over

NASPInet/new profile without modification.

The need to allow implementations to embed the new profile.

That is the proposed purpose of the PDU Type (e.g. to differentiate the tunnel vs. embedded). In

the case of a Tunneled PDU, the destination multicast address needs to be carried with the PDUin order to allow the PDU to be emitted with the same destination MAC address.

At a minimum, the IEC Header (IEC Hdr) portion needs to contain:

8/4/2019 1003_WG10_Ag20_DraftComm-VHerbFalk (2)

2/2

Page 2 Draft Framework for T-Profile for IEC 61850 conveyance of Synchrophasors

The total message length: this is needed to allow a large message to be delivered (e.g.potentially Jumbo grams or other for IPv4).

Msg Num: Message number so that duplicate delivery can be detected.

SubSqNum (Sub sequence number of the total message): Needed to allow segmentation,

reassembly, and delivery failure. Length of Segment: Allows the length of a segment to be conveyed. It is noteworthy

that the current proposal allows multiple APDU packets to be carried in a segment (e.g.multiple tunneled or other. It is anticipate that such groupings of APDUs would be based

upon destination address.

EOM (End of Message): Needed to indicate that the packet is the last packet required toreassemble the Message (e.g. Msg Num).

Each APDU (Application Protocol Data Unit) is tagged with its type (e.g. Tunnel, GOOSE,

SV, or other). Based upon the tagging, the Actual APDU is encapsulated in with specific

information.

As examples:

Tunneled: Would require the conveyance of the Destination MAC address and the lengthof the actual tunneled packet (e.g.