1
2008 Spring CCSDS meeting ( Washington, USA )SMWG
CCSDS Service Management Validation Test Quick Report
12. March 2008JAXA
YAGI Nobuhiro/SUZUKI Kiyohisa
2
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
SM Service Operations JPL JAXAInterface
TestTest
tracking
Service AgreementQuery Service
AgreementQSA X X X X
Trajectory Prediction
Add Trajectory Prediction
ATP X X X X
Delete Trajectory Prediction
DTP X X X
Configuration Profile
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
SM Service Operations JPL JAXAInterface
testResult
Service Agreement
Query Service Agreement QSA X X X good
Trajectory Prediction
Add Trajectory Prediction ATP X X X good
Delete Trajectory Prediction DTP X X X good
Query Trajectory Prediction QTP X N/A -
Configuration Profile
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
<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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
<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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
Transfer Service 1200-1450 *1 Mar 3, 2008 (DOY063)
Succeeded
Test Case 3 Service Management 1500-1600 Mar 3, 2008 (DOY063)
Succeeded
Transfer Service 1950-2230 *1 Mar 6, 2008 (DOY066)
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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
Figure 4-5 Test case 2 TIMELINE
22
2008 Spring CCSDS meeting ( Washington, USA )SMWG
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.
Figure 4-6 Test case 3 TIMELINE
Top Related