LRIT ASP Technical Requirement.doc

Commanding Officer

U.S. Coast Guard

Operations Systems Center

Kearneysville, WV 25430

ASP Technical Requirements March 2010 Table of Contents

41.

LRIT MESSAGING FORMAT SUMMARY

41.1 Summary of LRIT Messages

72.

LRIT SHIP POSITION REPORTS (MESSAGES 1 AND 2)

133.

LRIT SHIP POSITION REQUEST MESSAGES (MESSAGE 4)

194.

RECEIPT MESSAGE (MESSAGE 7)

255.

SYSTEM STATUS MESSAGE (MESSAGE 11)

286.

COMMUNICATION PROTOCOL STRATEGY

286.1 General Overview

296.2 Specific Communication Protocols

296.2.1 General

296.2.2 Physical Layer

296.2.3 Data Link Layer

296.2.4 Network Layer

296.2.5 Transport Layer

296.2.6 Application Layer

296.2.7 Simple Object Access Protocol (SOAP) Overview

317.

DATA SECURITY WITHIN THE ASP / NDC COMMUNICATIONS

317.1 General

317.1.1 Adherence to Performance standards

317.1.2 Identification and Authentication

317.1.3 Integrity

317.1.4 Application Layer

327.1.5 Public - Private Key Cryptography

338.

ASP/NDC OPERATIONAL COMMUNICATIONS

338.1 Ship Reporting

338.2 Quality of Service

349.

ANNEX A –MESSAGE EXAMPLES

349.1 Examples of LRIT Messages

349.2 Ship Position Report Message

359.3 Ship Position Request Message

379.4 Receipt Message

389.5 Status Message

399.6 Types.xsd

4310.

ANNEX B – EXAMPLES OF MESSAGE FLOW DIAGRAMS

List of Figures

28Figure 3 LRIT Communication Links

43Figure 10-1 Message Flow Example: Positional Message (Message Type 1)

44Figure 10-2 Message Flow Example: Request and Positional Response

List of Tables

4Table 1 Summary of LRIT Messages

Table 2 Summary of LRIT Positional Data (Position Reports) Messages (Message 1 and 2 ) (1) Table 3 Summary of LRIT Request Messages (Messages 4) Ship Position Request Messages(1) Table 4a Destination Parameters Table 4 Summary of Receipt Message (Message 7) (1) Table 5 Summary of System Status Message (Message 11) Table 6 Summary of LRIT Communications Links

1. LRIT MESSAGING FORMAT SUMMARY

1.1 Summary of LRIT Messages

1.1.1. Table 1 provides a summary of all ASP / NDC LRIT messages.

Table 1 Summary of LRIT Messages

LRIT Positional Data (position report) Messages

LRIT Request Messages

LRIT Ship Position Request Messages

Other Messages

ASP → DC

Messages from the NDC to and from the ASP and messages from the IDE to and from the DCs and the DDP server.

DC → ASP

ASP → DC

DC, DDP → IDE

IDE → DC, DDP

1.1.2. Sections 2 to 4 describe each of the LRIT messages. Each messages is presented in tabular format with the following columns:

1.1.2.1. Parameter Provided By - indicates the particular LRIT component that provides the parameter information contained in the LRIT message;

1.1.2.2. Parameter - lists the various parameter names contained within the LRIT message;

1.1.2.3. Values - lists the potential values of each associated parameter;

1.1.2.4. Description - provides brief information pertaining to each of the various parameters in the LRIT message;

1.1.2.5. LRIT segments – indicates which of the LRIT communications segments of Figure 1 contain each parameter; and

1.1.2.6. Processed format – defines the specific format for each parameter.

1.1.2.6.1 The definition of the various processed formats listed in the Processed format column of Tables 2 to 5 are provided below. For full schemas for the various processed formats, reference should be made to Section 9 (Annex A) on XML Schemas.

1.1.2.6.1.1. n – indicates 1 ASCII decimal digit (0-9);

1.1.2.6.1.2. n1...nn – indicates 1 to n ASCII decimal digits;

1.1.2.6.1.3. c – indicates 1 ASCII alphabetic character;

1.1.2.6.1.4. c1…cn- indicates 1 to n ASCII alphabetic characters;

1.1.2.6.1.5. xs:dateTime - represents a Timestamp: Timestamps used within the LRIT system are of the XML Schema Datatype dateTime, as defined in http://www.w3.org/TR/xmlschema-2. The lexical representation of dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)? where • '-'? yyyy is a four-or-more digit optionally negative-signed numeral that represents the year; if more than four digits, leading zeros are prohibited, and '0000' is prohibited (note that a plus sign is not permitted);

· the remaining '-'s are separators between parts of the date portion;

· the first mm is a two-digit numeral that represents the month;

· dd is a two-digit numeral that represents the day;

· 'T' is a separator indicating that time-of-day follows;

· hh is a two-digit numeral that represents the h; '24' is permitted if the min and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the h property of a dateTime object in the ·value space· cannot have a value greater than 23);

· ':' is a separator between parts of the time-of-day portion;

· the second mm is a two-digit numeral that represents the minute;

· ss is a two-integer-digit numeral that represents the whole seconds;

· '.' s+ (if present) represents the fractional seconds;

· zzzzzz (if present) represents the timezone (as described below).

· LRIT timestamps must all be in UTC. An example of a valid timestamp would be 2009-10-10T12:00:00Z or 2009-10-10T12:00:00.067Z.

1.1.2.6.1.6. TEXT – unformatted alpha numeric text string in the English language.

1.1.2.6.1.7. All times in the LRIT system should be indicated as Universal Co-ordinated Time (UTC) and all time stamps should use UTC with an accuracy of less than or equal to 1 second. This may be achieved by synchronization with an NTP server (a list of publicly available time servers can be found on the web site NTP.org) or other technical means.

1.1.2.6.1.8. All geographical positions and coordinate points (latitude and longitude) should be based on the WGS 84 datum.

1.1.2.6.1.9. XML data formats will use UTF-8 to encode Unicode characters in the English language.

1.1.2.6.1.10. All DCs should archive all LRIT Messages with the exception of the file attachments associated with Message 10 (DDP Update) and Message 12 (Journal), in the case or RDC, CDCs and the IDC, for at least one year and until such time as the Committee reviews and accepts the annual report of the audit of its performance by the LRIT Coordinator. The US ASP should have the ability to queue messages for 2 hours, should the US NDC go down.

1.1.2.6.1.11. However, the archived LRIT Messages should provide a complete record of the activities of the centre between two consecutive annual audits of its performance.

2. LRIT SHIP POSITION REPORTS (MESSAGES 1 AND 2)

2.1. Table 2 outlines the parameters associated with the positional data messages (ship position reports).

2.2. The parameters provided by the LRIT shipborne equipment include: the latitude; longitude; UTC Time Stamp when the position was generated; and the shipborne equipment identifier.

2.3. The Processed Format of these parameters as outlined in Table 2 indicates how the parameters shall be formatted (Refer Article 1.1.2.6.1) while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information.

2.4. The parameter ASP ID provides the unique LRIT component ID of the ASP that has received the LRIT positional data.

2.5. The parameter CSP ID provides the unique LRIT component ID of the CSP that transmitted the LRIT positional data message to the ASP.

2.6. The Message Type parameter indicates the type of message of the associated LRIT message. This parameter is used to distinguish between the various LRIT messages listed in Table 1.

2.7. The Message ID parameter is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID for the ship position report is generated by linking together the ASP LRIT ID, UTC timestamp and a 5 digit unique sequence decimal number. The unique sequence number is generated by the ASP and the timestamp consists of the year, month, day, hour, minute and second in which the parameter was generated. An example of a message ID would be 01992007013011552311111 (LRIT ASP ID = 0199, year = 2007, month = 01, day = 30, hour = 11, minute = 55, second = 23, unique number = 11111).

2.8. The Reference ID parameter will either be a message ID of an associated request message or a 0 value. The 0 value is populated if the message is not the result of a request message. A valid “Message ID” value indicates that a request message has initiated the LRIT positional data report.

2.9. The IMO Number and MMSI parameters are the IMO ship identification number and the Maritime Mobile Service Identity (MMSI) number of the ship being tracked, respectively. The IMO Number is a mandatory item and is used as the unique identifier of ships within the LRIT system. The MMSI is not a mandatory item, though it is preferred that the MMSI be included if the ASP has an accurate MMSI for the ship.

2.10. The Time Stamp 2 and Time Stamp 3 parameters represent the date and time associated with when the ASP received and transmitted the positional data message, respectively. Both Time Stamps shall be indicated as Universal Coordinated Time (UTC).

2.11. The TimeStamp4 and TimeStamp5 parameters are the date and time associated with when the DC received and transmitted the LRIT information message, respectively.

2.12. The ResponseType parameter provides information with respect to why the receiving LRIT Data User (DataUserRequestor) is receiving the LRIT information. The LRIT Data User’s entitlement to receive the LRIT information is based upon its functioning as: a flag State; a port State; a coastal State; or a SAR service.

2.13. The DataUserRequestor parameter is the LRIT ID of the LRIT Data User that is intended to receive LRIT information as a result of a request message or a standing order. The IDE should look at this parameter during processing of the message and use it to correctly route the message to the appropriate DC.

2.14. The Ship Name parameter represents the ship name. This value is not mandatory, though it is preferred that the ship name be included if the ASP has this information and it is considered accurate.

2.15. The DataUserProvider parameter is the LRIT ID of the LRIT Data User (i.e. the Administration) associated with that ship.

2.16. The DDPVersionNum parameter is the version number of the DDP that is being used by the DC sending the message.

2.17. The test parameter indicates whether the message is a test message intended for testing purposes only, or a regular LRIT message.

2.18. The schemaVersion parameter represents the release number associated with the set of XML schema files that define the LRIT messages. This parameter is informative only and no processing action is required by the receiving LRIT component.

Table 2 Summary of LRIT Positional Data (Position Reports) Messages (Message 1 and 2 ) (1)

(see Figure 1) Processed Format (4)

1 – Periodic Report

2 – Polled Report

3 – SAR Report

1 – Coastal

2 – Flag 3 – Port

4 – SAR

0 – Regular LRIT message

1 – Test message n

Notes:

(1) Refer to 2 for description of column headings.

(4) Refer to 1.1.2.6.1

3. LRIT SHIP POSITION REQUEST MESSAGES (MESSAGE 4)

3.1. Table 3 outlines the parameters associated with the ship position request messages.

3.2. The LRIT ship position request messages are intended to provide LRIT Data Users with the ability to poll a ship’s specific position, change the LRIT positional reporting rate of a ship, query archived LRIT ship position report messages or stop receiving LRIT ship position reports from a given ship.

3.3. The Message Type parameter indicates the type of message of the associated LRIT message. This parameter is used to distinguish between the various LRIT messages listed in Table 1.

3.4. The Message ID parameter is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID for the position request message is generated by linking the LRIT ID for the “LRIT Data User Requestor” (in general, the LRIT ID of the “United States” LRIT Data User), UTC timestamp and a 5 digit unique sequence number together. The unique sequence number is generated by the LRIT Data User and the timestamp consists of the year, month, day, hour, minute and second in which the parameter was generated. An example of a message ID would be 03002007013011552322222 (LRIT Data User ID = 0300, year = 2007, month = 01, day = 30, hour = 11 minute = 55, second = 23. unique sequence number = 22222).

3.5. The IMO number parameter is the IMO ship identification number of the ship for which data is being requested.

3.6. The Data User Provider parameter is the LRIT ID of the LRIT Data User of the Administration for that ship. This parameter is used to identify the destination of the request message. The IDE should look at this parameter during processing of the request message and use it to correctly route the message to the appropriate DC.

3.7. The AccessType parameter indicates the requesting LRIT Data User’s entitlement to receive the LRIT information. The LRIT Data User might be requesting the LRIT information as: a flag State; a port State; a coastal State; or a SAR service. If the AccessType is port State, then the trigger mechanism should be: a distance from a port, or commence tracking upon receiving request message, or a specific time. AccessType 0 is used in conjunction with RequestType 0 in order to restart/reset all previous requests to the referenced ship. The LRIT Data User issuing the request message with this parameter combination has effectively cancelled all previous request messages and should only receive LRIT information based upon standing orders in the DDP for that ship.

3.8. The Port, PortFacility, or Place parameter should be populated with the UN/LOCODE code for the port, IMO port facility number of the port facility or a unique code MSC.1/Circ.1259/Rev.1 ANNEX Page 56 for places under the jurisdiction of Contracting Governments that the ship is intending to enter. This parameter should not be present if the request is not a port State request. This parameter is only valid for AccessTypes 3 and 5.

3.9. The Distance parameter should be the distance in nautical miles from a port or port facility where the requesting Contracting Government wishes to track the designated ship. This parameter is only valid when the AccessType parameter is set to 3.

3.10. The RequestType parameter should indicate whether the request is for: a restart/reset; a one-time poll; a specified periodic rate ; archived data; most recent position report; stop tracking; or do not start sending position reports. The do not start sending position reports message option provides Contracting Governments with the ability to temporarily override standing orders in the DDP. Consider the scenario where a Contracting Government is tracking a ship via port State access and does not want to receive LRIT information as a coastal State. The Contracting Governments could build a request message with coastal for the “Accesstype parameter and stop / don’t start sending for the RequestType. The providing DC, after receiving such a request message, should not start sending any coastal LRIT information for the period of time stated in the RequestDuration parameter.

3.11. The RequestDuration parameter provides information on the start and stop times for tracking of a ship. If the AccessType is 3, then the RequestDuration and the Distance are both valid parameters. If the RequestDuration is unspecified, then only the distance from port is valid for the port State request with distance trigger. The Data User Provider should queue and continue to process request messages with AccessTypes 3 and 5 and with a valid RequestDuration until the time expires or the Data User Requester terminates the ship position request. If the start time is not populated, it will default to the current time. If the stop time is not populated, it will default to infinity.

3.12. The DataUserRequestor parameter is the LRIT ID of the LRIT Data User originating the request message. For SAR position requests, the DataUserRequestor parameter should be populated with an LRIT ID that is associated with a valid SAR service for SAR related messages.

3.13. The TimeStamp parameter is the date and time associated with the generation of the message.

3.14. The DDPVersionNum parameter is the version number of the DDP that is being used by the DC sending the message.

3.15. The test parameter indicates whether the message is a test message intended for testing purposes only or if it is a regular message.

3.16. The schemaVersion parameter represents the release number associated with the set of XML schema files that define the LRIT messages. This parameter is informative only and no processing action is required by the receiving LRIT component.

Table 3 Summary of LRIT Request Messages (Messages 4) Ship Position Request Messages(1)

(see Figure 1) Processed Format(4)

4 – Ship position request or poll request

5 – SAR position request or poll request

0 - Restart/reset for all entitlements of LRIT Data User

1 – Coastal

2 – Flag

3 - Port with distance trigger from port or port facility

4 - Reserved for future use

5 - Port with time trigger

6 - SAR (only valid with message type 5)

Parameter is valid only for Access Type 3 and 5

Parameter is only valid for Access Type 3

0 - Restart/reset 1 - One time poll of ship 2 - 15 min periodic rate 3 - 30 min periodic rate 4 - 1 h periodic rate 5 - 3 h periodic rate 6 - 6 h periodic rate 7 - Archived LRIT information request 8 - Stop / don’t start sending position reports 9 - Most recent position report 10 - 12 h periodic rate 11 - 24 h periodic rate

STOP refers to the end time for receiving LRIT reports. If not specified, it defaults to infinity (Contracting Governments might decide to use repeat polling or periodic rate modification to obtain variable position report intervals)

0 – Regular LRIT message n

(1) Refer to 1.2 for description of column headings.

(4) Refer to 1.6.

4. RECEIPT MESSAGE (MESSAGE 7)

4.1. Table 4 outlines the receipt message.

4.2. The Receipt message should be sent in order to acknowledge the receipt of a message that cannot be processed for some reason. When an LRIT component receives a message it should process the message and either send the requested information or send a Receipt message with the appropriate Receipt code informing the originating LRIT component why the message could not be processed.

4.3. The MessageType parameter indicates the type of the message. The LRIT components such as the DCs should use this parameter to distinguish between the various types of messages listed in Table 1.

4.4. The MessageId parameter is a unique identification number that LRIT components should use to identify individual messages within the LRIT system. The MessageId is generated by linking the LRIT ID of the LRIT Component generating the receipt message, the date and time, and a 5 digit unique sequence number together. An example of a MessageId is 39992007013012552377777 where the LRIT ID of the LRIT Component = 3999, year = 2007, month = 01, day = 30, h =12, min = 55, second = 23, unique sequence number = 77777.

4.5. The Reference ID parameter is the Message ID of an associated message.

4.6. The Receipt code parameter provides information with respect to the specific Receipt message that has been generated. In particular:

4.6.1. ReceiptCode 0 – Not entitled to data Receipt message should be generated by a DC when it determines that the requesting LRIT Data User is not entitled to receive the LRIT information it has requested;

4.6.2. ReceiptCode 1 - No ship in SAR SURPIC area should be generated in response to a SAR SURPIC request message if a DC that is processing a SAR SURPIC request message determines that there are no ships within the geographical area specified in the SAR SURPIC request message;

4.6.3. ReceiptCode 2 - IDE not available should be generated when the IDE is not available for any reason. The Receipt message should typically be generated by a DC in order to indicate that the IDE is off line. A DC is able to detect this type of error by using the System status message transmitted from the IDE;

4.6.4. ReceiptCode 3 - DC not available should be generated when a DC is not available. The IDE should be responsible for determining if all DCs are on line, as indicated by the System status message;

4.6.5. ReceiptCode 4 - CSP not available should be generated when a DC has determined a CSP is off line. The DC is responsible for detecting when the CSP is not available;

4.6.6. ReceiptCode 5 - Ship not responding should be generated by a DC if a ship that transmits to that DC is not responding. All DCs should be detecting if ships associated with that DC are transmitting LRIT information at the preset MSC.1/Circ.1259/Rev.1 ANNEX Page 66 time intervals. If a LRIT Data User requests LRIT information from a ship that is not responding, then the DC to which the ship transmits should generate a Receipt message with text content stating how long the ship has not been responding;

4.6.7. ReceiptCode 6 - Ship not available should be generated by a DC when a request has been made for LRIT information associated with a ship that should be transmitting to that DC but which has never transmitted information to the DC;

4.6.8. ReceiptCode 7 - System fault should be generated when a fault occurs in the system that is not covered by the other Receipt Codes;

4.6.9. ReceiptCode 8 - Could not load DDP should be generated when a DC or the IDE is unable to process the received DDP. The message should be sent to the DDP server; and

4.6.10. ReceiptCode 9 - Incorrect DDP version, message discarded should be generated by the IDE when the DDPVersionNum parameter contained within the message does not match the DDPVersionNum being used by the IDE. The IDE should discard the message and build a Receipt message with the ReferenceId populated with the MessageId of the discarded message.

4.7. The Destination parameter is the LRIT ID associated with the LRIT component to which the receipt message is destined. The value of this parameter should be determined by the message type of the referenced message (the message indicated by the Reference Id parameter) as follows:

Table 4a Destination Parameters

4.8. The Originator parameter is the LRIT ID of the LRIT component generating the message. This parameter should be used to identify where the message originated.

4.9. The Message parameter should contain text providing information in relation to the nature of the Receipt message.

4.10. The TimeStamp parameter is the date and time associated with the generation of the message.

4.11. The DDPVersionNum parameter is the version number of the DDP that is being used by the DC sending the message.

4.12. The test parameter indicates whether the message is a test message intended for testing purposes only or if it is a regular message.

4.13. The schemaVersion parameter represents the release number associated with the set of XML schema files that define the LRIT messages. This parameter is informative only and no processing action is required by the receiving LRIT component.

Table 4 Summary of Receipt Message (Message 7) (1)

(see Figure 1) Processed Format (4)

LRIT ASP or US LRIT National Data Centre

7 – Receipt message

4 – CSP not available (ASP( Data User)

5 – Ship not responding (ASP( Data User)

6 – Ship not available (ASP( Data User)

7 – System fault (ASP( Data User or Data User (ASP)

8 – Could not load DDP

9 – Incorrect DDP version, message discarded

98 – Unable to respond due to incorrectly formatted position request message (ASP( Data User)

99 – Incorrectly formatted position report message (Data User (ASP)

nnnn

nnnn

TEXT

XML dateTime

(yyyy-mm-ddThh:mm:ss)

0 – Regular LRIT message n

(1) Refer 1.2 for description of column headings.

(4) Refer to 1.6.

5. SYSTEM STATUS MESSAGE (MESSAGE 11)

5.1. Table 9 outlines the parameters associated with the System status message.

5.2. The System status message is sent by the IDE to all DCs and the DDP server in order to provide them with information pertaining to the operational status of the IDE, while the System status message sent by the DCs or the DDP server to the IDE provide similar information to the IDE. The U.S. NDC and its ASP shall exchange system status messages every 30 minutes to confirm continuous availability and satisfactory operations.

5.3. The MessageType parameter indicates the type of the message. LRIT components such as the DCs should use this parameter to distinguish between the various types of messages listed in Table 1.

5.4. The MessageId parameter is a unique identification number that LRIT components should use to identify individual messages within the LRIT system. The MessageId is generated by linking the LRIT ID of the LRIT Component (IDE, DC, or DDP server), the date and time, and a 5 digit unique sequence number together. An example of a MessageId is 39992007013015552311111 where the LRIT ID of the LRIT Component = 3999, year = 2007, month = 01, day = 30, h = 15, min = 55, second = 23, and unique sequence number = 11111.

5.5. The TimeStamp parameter is the date and time when the originator transmits the message.

5.6. The SystemStatus parameter provides information pertaining to the operational status of the LRIT component (i.e. the IDE, DC or the DDP server) that transmitted the message. If the value is 0, then the LRIT component is functioning normally, while a value of 1 indicates that the component is not adhering to the Performance standards and/or the technical specifications.

5.7. The Message parameter is for the provision of text providing information in relation to the message. It might, for example, state that the IDE Operator has turned off the DDP version validation function of the IDE due to a catastrophic failure of the DDP server.

5.8. The Originator parameter is the LRIT ID of the LRIT component generating the message. This parameter is used to identify where the message originated.

5.9. The DDPVersionNum parameter is the version number of the DDP that is being used by the LRIT component.

5.10. The test parameter indicates whether the message is a test message intended for testing purposes only or if it is a regular message.

5.11. The schemaVersion parameter represents the release number associated with the set of XML schema files that define the LRIT messages. This parameter is informative only and no processing action is required by the receiving LRIT component.

Table 5 Summary of System Status Message (Message 11)

1 - Not able to provide functionality as described in the Performance standards and/or the technical specifications

0 - Regular message 1 - Test message

6. COMMUNICATION PROTOCOL STRATEGY

6.1 General Overview

6.1.1. An illustration of the various communication links in the LRIT system is shown in Figure 3. LRIT messages will flow through the LRIT network and along each communication link. Communication protocols ensure that the LRIT messages are transported from one LRIT component to the next.

Figure 3 LRIT Communication Links

6.1.2. All communication links shall comply with the functional description as identified in MSC.210(81) while the specific communication protocols stated in the subsequent sections apply only to certain links as summarized in Table 6. Communication link 4 shall implement the specific communication protocols detailed in the subsequent sections.

Table 6 Summary of LRIT Communications Links

6.2 Specific Communication Protocols

6.2.1 General

6.2.1.1. The communication protocols specified in the following sub-sections are specified specifically for NDC/ASP communications.

6.2.2 Physical Layer

6.2.2.1. The physical medium that the LRIT data messages transverse and the associated physical layer standards are not limited to one specific type or protocol. Thus, many different low-level mediums such as fibre optics, copper lines, microwave, and their associated physical layer standard such as sonnet, OC192, T1, E1 are all applicable (examples only).

6.2.3 Data Link Layer

6.2.3.1. The data link layer that sits on top of the physical layer is also not limited to one single standard. There are numerous data link layer protocols that are acceptable and can be used in the implementation of data communication between the various LRIT network components. Some examples of applicable standards are: Ethernet, ATM, ISDN, and 802.X.

6.2.4 Network Layer

6.2.4.1. The network layer shall be based upon version 4 (IPv4) of the Internet Protocol specification. Later versions of the Internet Protocol must be reviewed for compliance prior to implementation. Each component (e.g. ASP, Data Centres) in the LRIT network shall have its own unique IP address.

6.2.5 Transport Layer

6.2.5.1. The transport layer shall be based upon the Transmission Control Protocol (TCP).

6.2.6 Application Layer

6.2.6.1. The application layer should use Transport Layer Security (TLS version 1.1 or later) subsequently referred to as TLS and should communicate via XML-based SOAP messages between the various LRIT components. The SOAP messages are exchanged between SOAP nodes by binding to the HTTPS protocol as defined by SOAP.

6.2.7 Simple Object Access Protocol (SOAP) Overview

6.2.7.1 General

6.2.7.1.1. The application layer for exchanging LRIT messages amongst the LRIT components should be based upon version 1.2 of the SOAP (Simple Object Access Protocol) as defined by the World Wide Web consortium (W3C). SOAP is an application layer protocol that allows communications between nodes without requiring any specific communications network, operating system, or programming language. SOAP Version 1.2 specification was available is http://www.w3.org/TR/soap12.

6.2.7.1.2. As detailed under the SOAP Binding section below, SOAP messages travel using HTTP as the underlying protocol. Although HTTP by definition is a request/response communication mechanism, it is suggested that designers and implementers adopt asynchronous patterns and reliable non-blocking mechanisms to receive the HTTP response message to ensure an optimum performance. From the application implementation perspective, messages travel one-way.

6.2.7.2 SOAP Processing

6.2.7.2.1 SOAP nodes

6.2.7.2.1.1. The LRIT components following the communications protocol strategy referenced in this section functionally operate as SOAP nodes. Two asynchronous one-way message connections are established between each connecting node. The LRIT messages as defined earlier flow between SOAP nodes across the communication links illustrated in Figure 5.

6.2.7.2.1.2. There should only be two nodes associated with the relaying of any SOAP message: the initial sender and the ultimate receiver. Thus, there should be zero intermediary SOAP nodes in the routeing path of any SOAP message.

6.2.7.2.1.3. SOAP messages should have the role attribute omitted or set to “http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver” to indicate that messages are sent to ultimate receivers and no intermediates.

6.2.7.2.1.4. POST /LRITSample/Service HTTP/1.1 Host: localhost Content-Type: application/soap+xml; charset=utf-8 Content-Length: length

6.2.7.2.1.5. SOAP forwarding mechanism is not used given that there are no intermediate nodes involved.

6.2.7.2.1.6. Whenever a received SOAP message content is to be sent to a different location, a new SOAP message is to be constructed and sent via a SOAP node acting as initial sender. Any possible association or correlation that might be established between an inbound SOAP message and an outbound one is to be established and maintained at the application level by the Software application modules. Software application modules operating on LRIT components that must follow the communications protocol strategy should process SOAP messages as outlined in version 1.2 of the SOAP specification. As mentioned above, LRIT Software modules act as ultimate receivers and as such they should process the SOAP messages.

6.2.7.2.2 SOAP binding

6.2.7.2.2.1. SOAP messages should be exchanged between SOAP nodes by binding to the HTTP(s) protocol as defined by SOAP 1.2.

6.2.7.2.2.2. SOAP messages should be sent using the HTTP POST web method only. The body of an HTTP POST message should contain the message parameters embedded within a SOAP message structure.

6.2.7.2.2.3. The following is an example of an HTTP header. Note that SOAP 1.2 message bound to HTTP should have the Content-Type set to “application/soap+xml” (without quotes).

7. DATA SECURITY WITHIN THE ASP / NDC COMMUNICATIONS

7.1 General

7.1.1 Adherence to Performance standards

7.1.1.1. Data between the NDC and ASP shall be encrypted using Transport Layer Security as specified in 7.1.4.

7.1.2 Identification and Authentication

7.1.2.1. The various LRIT components in the LRIT network shall perform identification and authentication of each component before exchanging information using a standard authentication process.

7.1.3 Integrity

7.1.3.1. The LRIT data exchanged between LRIT components shall not be altered by any entity during transit across the LRIT network. The data exchanged between LRIT components should not be altered by any entity during transit across the LRIT system. Native TLS features providing integrity checks of the data transport should be used. This should be accomplished by using standard digital cryptography techniques featuring an encryption strength equivalent to or better than 128 bits.

7.1.4 Application Layer

7.1.4.1. Each LRIT component that forms a point to point communications link should use Transport Layer Security (TLS version 1.1 or later) when exchanging LRIT information. The TLS specification is defined by the Internet Engineering Task Force in RFC 4346. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery and addresses the security requirements for confidentiality and integrity.

7.1.4.2. Confidentiality and integrity is achieved via 128 bit (minimum) TLS encryption using a cryptographic Hash Message Authentication Code (HMAC) symmetric algorithm. The HMAC value protects both a message’s integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content. HMAC can be used with a variety of different hash algorithms.

7.1.4.3. Each LRIT component should use Key Hashing for Message Authentication Code (HMAC) when communicating across a TLS secured link. HMAC should ensure that data is not altered during transit and the data integrity is maintained.

7.1.4.4. HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake with two different algorithms, MD5 and SHA-1, denoting these as HMAC_MD5 (secret, data) and HMAC_SHA (secret, data). Additional hash algorithms can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for this version of the protocol.

7.1.5 Public - Private Key Cryptography

7.1.5.1. Before exchanging LRIT information, LRIT components connecting over the TLS link should use an industry standard, public - private (asymmetric) key infrastructure strategy to ensure positive identification and authentication of the LRIT components. The global industry standard public key infrastructure (PKI) certificate should be issued by a trusted party to ensure the vetting of, and authentication of, user identities. The Organization should ensure that the LRIT IDs are populated in the PKI certificate.

7.1.5.2. If either component detects an issue with the other LRIT component’s PKI certificate, then exchange of data information should not occur.

8. ASP/NDC OPERATIONAL COMMUNICATIONS

8.1 Ship Reporting

8.1.1. The NDC shall provide the ASP with a list of reporting ships.

8.1.2. The ASP shall maintain a listing of the reporting frequency of all ships assigned to the ASP. When a ship has failed to report within 15 minutes of its specified frequency, the ASP shall notify the NDC that the ship is not reporting as required.

8.1.3. The NDC shall provide a listing of all LRIT ID’s within the system.

8.1.4. Should a US or foreign ship change ownership and/or flag, the NDC will provide the information to the ASP to adjust the reporting schedule.

8.2 Quality of Service

8.2.1. The ASP shall maintain a 24 hours by 7 days a week contact phone number. The ASP shall maintain a 99.5% up time, on-air, reporting capability over a year and no less than 95% up time, on-air, reporting capability for any given day.

8.2.2. The ASP shall forward messages to the NDC with less than 15 seconds delay from receipt to transmission to the NDC.

8.2.3. The ASP shall be capable of buffering/caching 24 hours of messages if the NDC is down for any reason.

8.2.4. The ASP shall archive all position reports for one audit cycle, approximately one year.

9. ANNEX A –MESSAGE EXAMPLES

9.1 Examples of LRIT Messages

9.1.1. The examples provided form the suggested XML format upon which the LRIT messages should be based. It is expected that messages will be sent between the ASP and the US NDC as email messages, where the body of the message will contain an XML document of one of the following formats.

9.2 Ship Position Report Message

9.2.1. The Ship Position Report is expected to be sent from the ASP to the US NDC. The following is an example of the LRIT ship position report encoded into XML format.

File: ShipPositionReport.xsd

Version: 1.1

Date: 24 October 2008

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/positionReport/2008" xmlns="http://gisis.imo.org/XML/LRIT/positionReport/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" elementFormDefault="qualified">

<xs:import namespace="http://gisis.imo.org/XML/LRIT/types/2008" schemaLocation="Types.xsd"/>

<xs:simpleType name="messageTypeType">

<xs:restriction base="xs:integer">

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

</xs:restriction>

</xs:simpleType>

<xs:element name="ShipPositionReport" type="ShipPositionReportType"/>

<xs:complexType name="ShipPositionReportType">

<xs:sequence>

<xs:element name="Latitude" type="lrit:latitudeType"/>

<xs:element name="Longitude" type="lrit:longitudeType"/>

<xs:element name="TimeStamp1" type="xs:dateTime"/>

<xs:element name="ShipborneEquipmentId" type="xs:string"/>

<xs:element name="ASPId" type="lrit:aspLRITIDType"/>

<xs:element name="CSPId" type="lrit:cspLRITIDType" minOccurs="0"/>

<xs:element name="MessageType" type="messageTypeType"/>

<xs:element name="MessageId" type="lrit:msgIDType"/>

<xs:element name="ReferenceId" type="lrit:refIDType"/>

<xs:element name="IMONum" type="lrit:imoNumType"/>

<xs:element name="MMSINum" type="lrit:mmsiNumType" minOccurs="0"/>

<xs:element name="TimeStamp2" type="xs:dateTime"/>

<xs:element name="TimeStamp3" type="xs:dateTime"/>

<xs:element name="DCId" type="lrit:dataCentreLRITIDType"/>

<xs:element name="TimeStamp4" type="xs:dateTime"/>

<xs:element name="TimeStamp5" type="xs:dateTime"/>

<xs:element name="ResponseType" type="lrit:responseTypeType"/>

<xs:element name="DataUserRequestor" type="lrit:lritIDType"/>

<xs:element name="ShipName" type="lrit:shipNameType" minOccurs="0"/>

<xs:element name="DataUserProvider" type="lrit:lritIDType"/>

<xs:element name="DDPVersionNum" type="lrit:ddpVersionNumType"/>

</xs:sequence>

<xs:attribute name="test" type="lrit:testType" use="optional" default="0"/>

<xs:attribute name="schemaVersion" type="xs:decimal" use="required"/>

</xs:complexType>

</xs:schema>

9.3 Ship Position Request Message

9.3.1. The Ship Position Request Message is expected to be sent from the US NDC to the ASP to request an immediate poll of a ship's position, or to adjust the polling interval for the specified ship. The following is an example of the ship position request message encoded into XML format.

File: ShipPositionRequestxsd

Version: 1.0

Date: 22 August 2008

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/positionRequest/2008" xmlns="http://gisis.imo.org/XML/LRIT/positionRequest/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" elementFormDefault="qualified">

<xs:import namespace="http://gisis.imo.org/XML/LRIT/types/2008" schemaLocation="Types.xsd"/>

<xs:simpleType name="messageTypeType">

<xs:restriction base="xs:integer">

<xs:enumeration value="4"/>

<xs:enumeration value="5"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="accessTypeType">

<xs:restriction base="xs:integer">

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

<xs:enumeration value="5"/>

<xs:enumeration value="6"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="requestTypeType">

<xs:restriction base="xs:integer">

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

<xs:enumeration value="4"/>

<xs:enumeration value="5"/>

<xs:enumeration value="6"/>

<xs:enumeration value="7"/>

<xs:enumeration value="8"/>

<xs:enumeration value="9"/>

<xs:enumeration value="10"/>

<xs:enumeration value="11"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="requestDurationType">

<xs:attribute name="startTime" type="xs:dateTime" use="optional"/>

<xs:attribute name="stopTime" type="xs:dateTime" use="optional"/>

</xs:complexType>

<xs:simpleType name="distanceType">

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

…