本文件规定了利克莱德传输协议的数据单元格式、协议流程、业务说明等内容，对LTP协议在空间数据与信息传输系统应用进行了补充规定，主要包括下层通信协议和业务的适配、域取值范围、业务数据聚合以及协议管理信息内容等。 本文件适用于在通信时延长、可能频繁中断的空间链路上提供可选的可靠数据传输。

ICS49.140
CCSV75
中华人民共和国国家标准
GB/T42649—2023
空间数据与信息传输系统
利克莱德传输协议（LTP）
Spacedata andinformationtransfer systems-Licklider transmission protocol(LTP)[ISO 21080:2016,Space data and information transfer systems-Licklider transmission protocol (LTP) for CCSDS,NEQ2023-05-23发布
国家市场监督管理总局
国家标准化管理委员会
2023-09-01实施
规范性引用文件
术语和定义
缩略语
协议概述
架构元素
LTP协议提供的业务
6LTP协议通用规定
客户端业务请求
协议内部处理流程
客户端业务通知
状态转换图
6.6LTP协议安全认证
7LTP协议在空间数据与信息传输系统应用的补充规定7.1
LTP协议运行在空间链路之上
7.2LTP协议运行在UDP协议之上
LTP协议域的取值范围
空间任务中LTP协议引擎标识符的使用空间任务中的LTP协议扩展
LTP协议安全
业务数据聚合
8LTP协议业务接口
用户接口
8.4LTP协议业务原语
9LTP协议对存储和下层通信的要求对可靠存储业务的要求
对下层通信业务的要求
GB/T42649—2023
GB/T42649—2023
协议一致性要求
10.1LTP协议的基本要求
10.2网络管理需求
附录A（规范性）
使用空间包或封装包业务作为LTP协议的下层通信业务附录B（规范性）
参考文献
LTP协议管理信息库.
GB/T42649—2023
本文件按照GB/T1.1一2020《标准化工作导则厂第1部分：标准化文件的结构和起草规则》的规定起草。
本文件参考“ISO21080：2016《空间数据与信息传输系统面向CCSDS的利克莱德传输协议
(LTP)》起草，一致性程度为非等效。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国宇航技术及其应用标准化技术委员会（SAC/TC425)提出并归口。本文件起草单位：南京大学、北京跟踪与通信技术研究所、中国航天标准化研究所、哈尔滨工业大学（深圳）、宁德市标准化科学技术研究院、鹏城国家实验室、清华大学、北京空间飞行器总体设计部、中国科学院国家空间科学中心、西安空间无线电技术研究所、南京财经大学。本文件主要起草人：赵康健、侯冬旭、李文峰、陈运军、许冬彦、周玉霞、张钦宇、王野、詹亚峰、何熊文、黄永辉、黄磊、杨志华、刘君、徐常志、靳一、燕洪城、唐悦豪、方元、林影、杨冠男。Ⅲ
GB/T42649—2023
在无法实现连续端到端连接的极端和性能挑战环境中，为实现可互操作的通信，互联网研究任务组（IRTF）于2oo2年成立了容延迟网络研究组（Delay-TolerantNetworkingResearchGroup，DTNRG），负责开展网络架构与协议的研究与设计工作。针对超长往返时延和可能出现频繁中断的空间链路，DTNRG制定并审议通过了RFC5326《LickliderTransmissionProtocol》技术文件，成为IETF的“试验性建议”。RFC5326是LTP协议的主要协议规范文件。空间数据系统咨询委员会（CCSDS)在RFC5326的基础上结合空间任务通信的特点和要求，制定了 CCSDS 734.1-B-1《CCSDSRecommended Standard for Licklider Transmission Protocol》，即ISO21080：2016《空间数据与信息传输系统面向CCSDS的利克莱德传输协议（LTP协议）》。该标准仅对RFC5326的技术调整和补充规定进行了重点阐述。LTP协议配合ISO21323:2016《空间数据与信息传输系统CCSDS束协议规范》中的束协议共同形成空间容延迟网络核心协议为保证技术内容的完整性，本文件对ISO21080：2016采取了非等效采用，重点参考并加人了RFC5326、RFC5327中的协议规范内容，提高了LTP协议技术内容的完整性，1范围
空间数据与信息传输系统
利克莱德传输协议（LTP协议）
GB/T42649—2023
本文件规定了利克莱德传输协议（以下简称LTP协议)的数据单元格式、协议流程、业务说明等内容，对LTP协议在空间数据与信息传输系统应用进行了补充规定，主要包括下层通信协议和业务的适配、域取值范围、业务数据聚合以及协议管理信息内容等。本文件适用于在通信时延长、可能频繁中断的空间链路上提供可选的可靠数据传输规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T2900.54日
电工术语无线电通信：发射机、接收机、网络和运行GB/T17967信息技术开放系统互连基本参考模型OSI服务定义约定GB/T42041一2022航天术语空间数据与信息传输RFC5246传输层安全协议[TheTransportLayerSecurity（TLS）Protocol3术语和定义
GB/T2900.54、GB/T17967与GB/T420411一2022界定的以及下列术语和定义适用于本文件。3.1
实体entity
子系统内的活动元素，是为特定对象定义一组能力（不包括任何正在使用的额外能力）的具体化。3.2
Eprotocoldataunit;PDU
协议数据单元
由协议规定的数据结构。
注：包含协议控制信息域和用户数据域【来源：GB/T42041—20223.1.273.3
Eservicedataunit;SDU
业务数据单元
由协议规定的数据结构中的用户数据域。来源：GB/T42041—2022.3.1.283.4
引擎标识符
FengineID
唯一标识一个特定LTP协议引擎的一个整数，该引擎属于由正在通信的LTP协议引擎组成的某个闭集。
注：当LTP协议运行在容延迟网络(DTN)束协议（BP协议)之下时，在BP协议和LTP协议之间的汇聚层适配器将负责（以特定于实现的方式)在DTN端点标识符（EID)和LTP协议引擎标识符之间进行转换1
GB/T42649—2023
由上层协议（通常为BP协议)向下传递的一组连续字节（8bits)应用数据，需要由一个LTP协议客户端业务实例发送给另一个LTP协议客户端业务实例。注：块的开始部分称为“块前缀”，块的结尾部分称为“块后缀”。3.6
red-part
采用确认和重传机制，可靠传输的块前缀。［来源：GB/T42041—2022，3.4.14，有修改］3.7
green-part
不采用确认和重传机制，非可靠传输的块后缀。注：该部分可选，如果块中有绿部，它从红部结尾之后开始。［来源：GB/T42041—2022，3.4.15，有修改］3.8
session
在两个对等引擎之间为传输一个块而执行的一个LTP协议活动线程。注：一个会话中的数据流是单向的：数据流量从发送对等实体流向接收对等实体，而数据确认的流量则从接收对等实体流向发送对等实体。
sender
发送方
会话中发送数据的对等实体。
接收方
receiver
会话中接收数据的对等实体。
segment
LTP协议数据传输单元，是在一个会话期间从一个LTP协议引擎传输到另一个LTP协议引擎的数据结构。
注：LTP协议段的类型包括：数据段、报告段、报告确认段、取消段、取消确认段、3.12
endofblockEOB
被传送数据块原始数据中的最后一个数据段［来源：GB/T42041—2022,3.4.17］3.13
endofred-part;EORP
红部结尾
利克莱德传输协议中红部原始数据的最后一个数据段，表示红部的结束。来源：GB/T42041—2022，3.4.163.14
检查点checkpoint
向接收引擎请求一个接收报告的数据段，注：红部结尾数据段和任意重传中的最后一个数据段称为“强制检查点”,其他的检验点为“可选检查点”。［来源：GB/T42041—2022,3.4.18］2
客户端业务标识符
FclientserviceID
GB/T42649—2023
段在接收方将被交付的上层业务的数字标识符，其功能类似于TCP协议端口号注：如果目的地有多个客户端业务实例，客户端业务自身应基于编码在传输的块中的信息实现复用。3.16
直self-delimiting numeric value;SDNV自定界数值
二进制格式表示的一个整数值，其长度由原始数值决定。［来源：GB/T42041—2022，3.4.19，有修改］3.17
applicationprocessidentifier;APID应用进程标识
路径标识的一部分，用于标识空间包的逻辑数据路径。3.18
义underlyingcommunicationprotocol;UCP下层通信协议
在LTP协议引擎间传送段时由LTP协议调用的通信协议4
缩略语
下列缩略语适用于本文件。
AAL：额外预期延迟（AdditionalAnticipatedLatency）APID：应用进程标识（ApplicationProcessIdentifier）BP：束协议(BundleProtocol)
CAR：发给块接收方的取消确认段（Cancel-AcknowledgementsegmenttoblockReceiver）CAS：发给块发送方的取消确认段（Cancel-AcknowledgementsegmenttoblockSender）CAx：取消确认段（Cancel-Acknowledgementsegment，generic)CP：检查点（Checkpoint）
CR：来自块接收方的取消段（CancelsegmentfromblockReceiver）CS：来自块发送方的取消段（CancelsegmentfromblockSender）Cx：取消段（Cancelsegment，generic)CP，检查点（Checkpoint）
DCCP：数据报拥塞控制协议(DatagramCongestionControlProtocol)）DTN：容延迟网络（Delay-TolerantNetworking）EOB：块尾（EndofBlock）
EORP：红部结尾（EndofRed-part）EPI：封装协议标识（EncapsulationProtocolIdentifier）IANA：互联网号码分配机构（InternetAssignedNumbersAuthority）IETF：互联网工程任务组（InternetEngineeringTaskForce）LTP：利克莱德传输协议（LickliderTransmissionProtocol）MIB：管理信息库（ManagementInformationBase）PDU：协议数据单元（ProtocolDataUnit）RA：报告确认（ReportAcknowledgement）RFC：征求意见书（RequestforComments）RS：报告段（ReportSegment)
SANA：空间编号分配机构（SpaceAssignedNumberAuthority）SDA：业务数据聚合（ServiceDataAggregation）3
GB/T42649—2023
SDNV：自定界数值（Self-DelimitingNumericValue）SDU：业务数据单元（ServiceDataUnit）SNMP：简单网络管理协议（SimpleNetworkManagementProtocol）TCP：传输控制协议（TransmissionControlProtocol）UCP：下层通信协议（SnderlyingCommunicationProtocol）UDP：用户数据报协议（UserDatagramProtocol)5协议概述
5.1总则
5.1.1在行星际通信等典型场景中，LTP协议主要在具有超长消息往返时间和/或频繁连接中断的链路上提供“远距离”可靠传输业务，同时也支持非可靠传输业务。空间数据与信息传输系统对LTP协议有以下两个需求：
a）在一条点到点链路（也称一跳链路）上可靠交付上层协议（如BP协议)的PDU；b）可将多个上层PDU聚合成一个LTP协议的SDU。注：上层协议发送很多小PDU的情况下，聚合可通过避免对每个PDU的单独确认，减少确认信道的带宽需求。5.1.2LTP协议的可靠数据交付是通过红部交付业务实现的，该业务将在本文件第6章中描述。把多个上层PDU聚合成一个LTP协议的SDU（LTP协议块)是通过标准化的“业务数据聚合”客户端操作实现的，该操作将在本文件第7章中描述，5.1.3LTP协议是一种工作在网际互联协议（例如BP协议）和各种数据链路协议之间的协议。LTP协议与相邻层协议之间的关系如图1所示。在DTN网络中，LTP协议主要作为BP协议的一种可靠的汇聚层协议。LTP协议专为在空间环境包交付业务之上使用而设计，可兼容现有的和未来的包交付业务。LTP协议通常会被部署在支持封装包的空间数据链路上，因此一个LTP协议段可以被封装到单个封装包内。除了封装业务，LTP协议到数据链路的接口也可以通过空间包直接封装（附录A规定了LTP协议如何使用封装包业务和空间包业务）。LTP协议也可以在各种地面网络业务上运行，包括用于交互支持的地面网络业务。
N层服务用户
（例如BP）
N+1层PDUs
（N层服务提供者）
N层PDUs
N+1层PDUs
N层服务接口
N层PDUs
N-1层服务接口
N-1层服务提供者
（例如封装包）
N层服务用户
（例如BP）
N+1层PDUs
（N层服务提供者）
N层PDUS
图1LTP协议与相邻层协议的关系N+1层
N-1层
5.1.4LTP协议专为空间应用设计，工作在一对通过空间链路（射频或激光）直接连接的相邻星际互联网节点上。在可能的多跳路径中，本文件建议在每一条长延迟、易差错或易中断的链路终点结束LTP协议。因此，当考虑LTP协议在空间链路上的适用性时，只要考虑LTP协议的功能、对多个距离一跳的对等实体的可扩展性以及在空间链路上与其他协议的交互。4
GB/T42649—2023
注：在空间数据与信息传输系统中，LTP协议对多个对等实体的可扩展性主要受限于存储，该存储用于在连接(contacts)之间维护要向特定对等实体重传的数据。由于空间通信的稀疏性，预计不会影响对等实体数量相关的可扩展性。LTP协议在全球互联网应用中涉及的问题，例如可扩展性、拥塞控制、与TCP协议等现有协议的共存等，与本文件讨论的空间数据与信息传输系统应用无关。5.2架构元素
LTP协议架构视图见图2，下面给出了具体说明，LTP协议引擎工作在独立的空间数据系统中，负责执行LTP协议流程并提供LTP协议业a)
务，LTP协议流程和提供的业务分别在6.3和5.3中描述。LTP协议引擎通过调用系统提供的下层通信业务和可靠存储实现数据收发和链路中断期间b）
的数据存储，LTP协议对下层通信和可靠存储的要求在第9章中详细描述，客户端业务实例确定应用数据的传输模式（可靠或非可靠），通过LTP协议引擎的业务接口调c）
用LTP协议业务，包括SDA。下载标准就来标准下载网
LTP协议的操作依赖于管理信息库（MIB）中的信息，包括本地引擎和远程引擎的配置信息d)
等，附录B描述了MIB的基本要求和信息项。客户端服务实例
5.3LTP协议提供的业务
5.3.1基本传输业务
LTP协议引擎
下层通信协议
图2LTP协议架构视图
管理信息库
LTP协议提供一种数据传输业务，将块从一个LTP协议引擎移动到另一个LTP协议引擎。通常两个引擎分别位于独立的数据系统中，两个系统之间通过一条直连的空间链路相连。数据传输过程是两个LTP协议引擎之间的交互过程，如图3所示。LTP协议采用9.2中描述的下层通信业务发送和接收LTP协议段。
逻辑上，每个块由两部分组成，其中任何一部分的长度都可以为0第一部分是在LTP协议实体间可靠传输“红部”，通过确认与重传确保整个红部在接收方可靠a)
接收；这是一种可靠传输业务。第二部分为“绿部”，由非可靠传输的数据组成，不需要确认和重传；这是一种非可靠传输业务。b
块中哪些数据属于红部、哪些属于绿部，由LTP协议客户端业务实例控制。一个要求完全可靠传送的客户端业务实例应指明全部数据以“红色”（可靠)数据方式发送。在本文件中，发送/接收绿部数据的能力为可选。如果要支持绿部，应同时支持绿部数据的发送和接收。块的传输可能经历多次链路中断，在中断期间，LTP协议维护的重传计时器将被暂停。注：LTP协议不提供不同LTP协议块之间的“顺序交付”业务。如果需要顺序传输，考虑采用束协议的容延迟载荷调整（Delay-TolerantPayloadConditioning，DTPC)业务。5
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。