2008 spring ccsds meeting ( washington, usa ) smwg 1 ccsds service management validation test quick...

1

2008 Spring CCSDS meeting ( Washington, USA )SMWG

CCSDS Service Management Validation Test Quick Report

12. March 2008JAXA

YAGI Nobuhiro/SUZUKI Kiyohisa

2


Contents 1 Background　 2 Objectives　 3 Test Procedure 3-1 Interface Test 3-2 Test Tracking 　 4 Test Result 4-1 Interface Test 4-1-1 Security 4-1-2 Data Compression 4-2 Test Tracking

3


1 ． Background• Interoperability test activity by participant agencies of the CCSDS to

validate the Service Management was determined at a meeting of the IOAG-10 on October, 2006.

• JPL and JAXA agreed to develop the following prototypes based on the CCSDS Service Management(R-1) Specification and validate the effectiveness of information and procedure exchanged by the Service Management to assured and control required resources for the spacecraft mission operations.

　　 - JPL ： The development of the SLE SM service-provider prototype　　 - JAXA/Tsukuba ： The development of the SLE SM service-user prototype

2. Objectives

Primary Objectives 　　 - 　 Validation of the SLE SM standard via prototyping 　　 - 　 Demonstration of SM interoperability across JPL and JAXA. Specifically; - 　 Validate demonstration scenario - Validate service request exchange protocol - Gain experience in application of security techniques

4


3. Test Procedure 3-1. Interface test This test was conducted to verify the SLE-SM interface between service-provider

prototype and service-user prototype. SLE-SM message exchange was handled by SMTP.

In this test, the following specification and schema were applied to the 　 service-provider prototype and the service-user prototype. 　

　 -SPACE LINK EXTENSION SERVICE MANAGEMENT SERVICE SPECIFICATION 　　　　 (CCSDS 910.11-R-

1) -Service Management Schema File Set V 0.3.0.P1

Figure 3-1 Interface TEST Configuration

SLE SM Service-provider

Prototype (CSSXP)

JPL

Internet

JAXA/Tsukuba

a SLE SM Service-user Prototype (UMR-1)

SLE-SM message exchanged by SMTP

5


SM Service Operations JPL JAXA Interface test

Service Agreement Query Service Agreement QSA X X X

Trajectory Prediction

Add Trajectory Prediction ATP X X X

Delete Trajectory Prediction DTP X X X

Query Trajectory Prediction QTP X N/A

Configuration Profile

Add Carrier Profile ACP X X X

Delete Carrier Profile DCP X X X

Query Carrier Profile QCP X X X

Add Event Profile AEP N/A

Delete Event Profile DEP N/A

Query Event Profile QEP N/A

Service Package

Create Service Package CSP X X X

Delete Service Package DSP X X X

Select Alternate Scenario SAS X N/A

Apply New Trajectory ANT X N/A

Query Service Package QSP X X X

Replace Service Package RSP X N/A

Service Package Cancelled SPC X X X

Service Package Modified SPM N/A

Table 3-1 difference of Implemented service management operations and Interface test operations

6


3-2. Test tracking Test Tracking was conducted to verify the end to end interface and

procedures of SLE transfer service utilization by SLE-SM Red-1 coordination.

　　 In the test tracking, JPL and JAXA used the JAXA’s “SELENE” spacecraft which is in the lunar orbit.

　　　　Test tracking outline 　 Service request was sent from the SLE-SM service-user prototype”UMR-1” at

　　　　　　　　 JAXA/Tsukuba to the JPL SLE-SM service-provider prototype “CSSXP”.　 JPL/DSN received return data from the SELENE compliant with the service 　

　　　 request, and then transmitted these data to JAXA/Sagamihara using SLE 　

　　　 transfer service (RAF).　 JAXA/Sagamihara checked the received date by the SELENE control system.

7


Figure 3-2 Test Tracking Configuration

DSS-24

Operational requirements

JAXA/Sagamihara

DSN Goldstone

JPL

SLE1 TLM SLE

SLE Transfer Service

Provider

SLE SM

Service-provider Prototype (CSSXP)

DSS-27

SLE SM

Service-user Prototype (UMR-1)

Internet

JAXA Flight

dynamics system

JAXA/Tsukuba

OEM

SLE1 TLM SLE

SLE Transfer

Service User

SELENE

Control system 2

SELENE

Control system 1 JAXA Ground station

SELENE

Return link

Return link

Up link

Actual Operation

Dedicated line

SLE-SM message exchanged by SMTP

SLE RAF Transfer Service Telemetry data

8


SM Service Operations JPL JAXAInterface

TestTest

tracking

Service AgreementQuery Service

AgreementQSA X X X X


Add Trajectory Prediction

ATP X X X X

Delete Trajectory Prediction

DTP X X X


Add Carrier Profile ACP X X X X

Delete Carrier Profile

DCP X X X

Query Carrier Profile QCP X X X

Service Package

Create Service Package

CSP X X X X

Delete Service Package

DSP X X X

Query Service Package QSP X X X

Service Package Cancelled

SPC X X X

Table 3-2 difference of Implemented service management operations andTest tracking operations

9


4. Test Result

4-1. Interface test•The structure of service management data was XML-based

text files. These were transferred as attached files on e-mails using the protocol SMTP between UMR-1 and CSSXP.

•The rules of exchanged e-mails are as follows:

No. Item Rules

1 Subject: The following subjects are accepted.SLESMSleServiceManagementsleSmResponsesleExceptionMessagesleSmError

2 Content-Type: text/plain

3 Body of message: Not limited

4 Character: ISO-2022-jp or ASCII

5 Attached file: Only one file per one message

Table 4‑1 Rules of E-mail Structure

10


SM Service Operations JPL JAXAInterface

testResult

Service Agreement

Query Service Agreement QSA X X X good


Add Trajectory Prediction ATP X X X good

Delete Trajectory Prediction DTP X X X good

Query Trajectory Prediction QTP X N/A -


Add Carrier Profile ACP X X X good

Delete Carrier Profile DCP X X X good

Query Carrier Profile QCP X X X good

Add Event Profile AEP N/A -

Delete Event Profile DEP N/A -

Query Event Profile QEP N/A -

Service Package

Create Service Package CSP X X X good

Delete Service Package DSP X X X good

Select Alternate Scenario SAS X N/A -

Apply New Trajectory ANT X N/A -

Query Service Package QSP X X X good

Replace Service Package RSP X N/A -

Service Package Cancelled SPC X X X good

Service Package Modified SPM N/A -

Table 4-2 result of Interface test

11


4-1-1 Security This section shows the method of security implementation from the technical

point of view, and these was based on the agreement between JAXA/Tsukuba and JPL.

a. SCOPE JAXA suggested an assumption to satisfy the following items.

spoofing defacing sniffing

At first we considered within the range of W3C of Recommendation (red-1) appendix, based on that conditions, and we proposed the following coverage of security in the prototype.

Items Implement Content of security

E-Mail Security(i.e. Encryption , Digital Signature)

not apply All parameters are to be written in the attached file, and any parameter information is not set to the mail text at all.

XML Encryption Syntax and Processing

apply XML is encrypted using AES128 and RSA (Ver. 1.5).The data leakage to the third person can be prevented by the encryption.As it is not possible to decrypt by the third person, the defacing and the spoofing can be prevented.The public keys are exchanged each other beforehand.

XML Signature Syntax and Processing

not apply

XML Key Management Specification

not apply

Table 4-3 Implementation of Encryption

12


b. IMPLEMENTATION FOR XML ENCRYPTION

In the XML encryption, the following methods were used. XML data was encrypted using Symmetric Key. The encrypt key was generated by AES128 (128bit of the AES

method) at every XML making. The encrypt key was wrapped by using the public key (RSA version

1.5) which were exchanged each other beforehand, and was stored in KeyInfo.

The Key Encrypted Key (KEK) was mutually generated as a symmetric key beforehand. Only public keys were exchanged each other beforehand. The receiver decrypts using a private key.

Public Key

Private Key

Public Key

Public Key

Private Key

Public Key

J AXA/TACC NASA/J PL

Generate key (RSA)

Generate key (RSA)

Exchange “Public Key”

Store Store

Figure 4-1 Exchange of “Public Key”

13


Sender

1.Generate symmetric key (AES 128). 2.“Cipher Data” was encrypted by using “Encrypt Key” from XML data. 3.“KeyInfo” was encrypted by using receiver’s “Public Key” from “Encrypt Key”. 4.“Encrypted XML” was generated from “CipherData” and “KeyInfo”.Receiver 5.“KeyInfo” and “Cipher Data” were detected from received “Encrypted XML”. 6.“Encrypt Key” was decrypted by using “Private Key” from “KeyInfo”.

7.XML data was decrypted from “Cipher Data” by using “Encrypt Key”.

Figure 4‑2 Process Flow of Encrypted XML data Exchange

XML

Encrypted XML

Receiver

Receiver’s Public Key

Receiver’s Private Key

Sender

Encrypted XML

XML

Encrypt Key (AES128bit)

1

2

5

6

Cipher Data

KeyInfo

3

4

Encrypt Key (AES128bit)

Cipher Data

KeyInfo

7

14


c. SCOPE OF XML ENCRYPTION

In the XML encryption, the scope of encryption was all items excluded SleSmDocument and SleSmMessageSet. Both items of SleSmDocument and SleSmMessageSet were not encrypted in order to make the access control efficient.

This section shows the samples of encryption, in which the name space and the contents of data are omitted.

NOTE: Apache XML security was used in the prototype as a middleware for encryption. We encrypted in the prototype by the form that didn't omit “xenc”, because it

was necessary for the name space of the encryption tag in apache XML security. The version of Apache XML security which were used in JAXA/TACC and NASA/JPL

was 1.4.1.

15


<sleSmDocument><sleSmVersionRef>0.3.0</sleSmVersionRef><sleSmMessageSet> <sleSmCreatorName>UMR-1</sleSmCreatorName> <serviceAgreementRef>SA1</serviceAgreementRef> <createServicePackageInvocation> : : </createServicePackageInvocation></sleSmMessageSet></sleSmDocument>

1) For Invocation, Acknowledgement, Successful return and Failed return

<sleSmDocument><sleSmVersionRef>0.3.0</sleSmVersionRef><sleSmMessageSet> <sleSmCreatorName>UMR-1</sleSmCreatorName> <serviceAgreementRef>SA1</serviceAgreementRef> <xenc:EncryptedData> : : </xenc:EncryptedData></sleSmMessageSet></sleSmDocument>

16


<sleSmDocument><sleSmVersionRef>0.3.0</sleSmVersionRef><sleSmExceptionResponse> : :</sleSmExceptionResponse></sleSmMessageSet></sleSmDocument>

2) For sleSmExceptionResponse

<sleSmDocument><sleSmVersionRef>0.3.0</sleSmVersionRef><xenc:EncryptedData> : :</xenc:EncryptedData></sleSmMessageSet></sleSmDocument>

NOTE: The sleSmExceptionResponse.unrecoginzedMessageSetResponse

was not encrypted, considering the case that the receiver did not recognize the sender or the service agreement was not recognized.

The sleSmExceptionResponse.invalidMessageResponse was encrypted.

17


4-1-2 Data Compression ATP operation went out of control by limiting data communication at JAXA since volume of the OEM, which

was exchanged at ATP operation, was a large amount of data (this time it was greater than 5 Mbytes). Therefore, we conducted data compression of the OEM to reduce the data volume.

This section shows the method of data compression which was used for transmission of the much volume data between JAXA/Tsukuba and JPL.

a. DATA TYPE

The following data was always compressed between JAXA/Tsukuba and JPL. Data Type: Trajectory Prediction Message Type: Orbit Data Message ODM Type: Orbit Ephemeris Message (OEM) File Type: Text SM operation: Add Trajectory Prediction (ATP) b. IMPLEMENTATION FOR DATA COMPRESSION JAXA/UMR-1(UM) stored the OEM text into bilateralTrajectoryData of ATP invocation. bilateralTrajectoryFormatId: ZipOEMTxt Compress: Zip Encodeing : Base64

18


4. Test Result

4-2. Test Tracking Test Tracking was scheduled from End of February in 2008. This testing was performed with DSN network and Test facilities. The desired time for testing is shown in the table 4-4.

Test Case Operations Time Date Result

Test Case 1 Service Management 0100-0130 Feb 28, 2008 (DOY059)

succeeded

Transfer Service 1200-1515 *1 Mar 1, 2008 (DOY061)

succeeded

Test Case 2 Service Management 0100-0200 Feb 28, 2008 (DOY059)

Succeeded


Succeeded

Test Case 3 Service Management 1500-1600 Mar 3, 2008 (DOY063)

Succeeded


succeeded

Table 4-4 Test Tracking Result

NOTE: *1) The start/end time were the duration from BOA(=BOT-45min.) to EOA(=EOT+15min).

19


DateResource

Feb 28 Feb 29 Mar 1 Mar 2 Mar 3 Mar 4 Mar 5 Mar 6

DOY 059 DOY 060 DOY 061 DOY 062 DOY 063 DOY 064 DOY 065 DOY 066

SLE-SM

DSN Pass

SLE Transfer(Only RAF)

Test Case 1

Test Case 2

Test Case 3

Pass#1

Trk#1 Trk#2

Acq#1Acq#2

Pass#2

Trk#3

Acq#3

Pass#3

Trk#4

Acq#4

6 Oprs

2 Oprs

2 Oprs

Figure 4-3 Test Tracking TIMELINE

20


ACP

Test Case

Resource

SLE-SM

CSSXP(JPL)

DSN Pass

Test Case 1

QSA ATP

UMR-1(JAXA)

CSP

SLE Transfer

(Only RAF)

Feb 28(DOY 059)

Pass-1

TDS(JPL)

JAXA/Sagamihara

March 1(DOY 061)

ACPACP

TransferService

TransferService

ServiceUse

BOA BOT13:00

EOT15:00

EOA

SpaceLink

Acquisition#1

Pass#1

Figure 4-4 Test case 1 TIMELINE

21


Test Case

Resource

SLE-SM

CSSXP(JPL)

DSN Pass

Test Case 2

SpaceLink

TransferService

UMR-1(JAXA)

CSP

SLE Transfer

(Only RAF)

Pass-23

TDS(JPL)

JAXA/Sagamihara

TransferService

ServiceUse

Feb 28(DOY 059) March 3(DOY 063)

Acquisition#23

BOA BOT13:00

EOT14:35

EOA

Pass#2


22


Test Case

Resource

SLE-SM

CSSXP(JPL)

DSN Pass

Test Case 3

ATP

UMR-1(JAXA)

CSP

SLE Transfer

(Only RAF)

Pass-3

TDS(JPL)

JAXA/Sagamihara

Mar 4 (DOY 064) March 6(DOY 066)

TransferService TransferService

TransferService

ServiceUse

TransferService

ServiceUse

BOA BOT20:50

EOT21:04

BOT21:47

EOT22:15

EOA

SpaceLink SpaceLink

Acquisition#31

Acquisition#42

Pass#3

The occultation

UMR-1 generated two acquisition requests in one service package for SELENE operation.


2008 spring ccsds meeting ( washington, usa ) smwg 1 ccsds service management validation test quick...

Documents

service packagecspxxx

service packagedspxxx

service provider prototype

ccsds service managementr

test tracking test tracking

sle sm serviceuser prototype

test procedure

test tracking slide