GBT 42649-2023 空间数据与信息传输系统 利克莱德传输协议（LTP）

GB/T42649—2023空间数据与信息传输系统[ISO21080:2016,Spacedataandinformationtransfersystems—Licklidertransmissionprotocol(LTP)forCCSDS,NEQ]国家标准化管理委员会国家市场监督管理总局发布国家标准化管理委员会IGB/T42649—2023 Ⅲ 12规范性引用文件 13术语和定义 1 3 4 45.2架构元素 55.3LTP协议提供的业务 56LTP协议通用规定 76.1段 76.2客户端业务请求 6.3协议内部处理流程 6.4客户端业务通知 6.5状态转换图 6.6LTP协议安全认证 7LTP协议在空间数据与信息传输系统应用的补充规定 7.1LTP协议运行在空间链路之上 7.2LTP协议运行在UDP协议之上 7.3LTP协议域的取值范围 7.4空间任务中LTP协议引擎标识符的使用 7.5空间任务中的LTP协议扩展 7.6LTP协议安全 7.7业务数据聚合 8LTP协议业务接口 8.1用户接口 8.4LTP协议业务原语 9LTP协议对存储和下层通信的要求 9.1对可靠存储业务的要求 9.2对下层通信业务的要求 ⅡGB/T42649—2023 10.2网络管理需求 附录A(规范性)使用空间包或封装包业务作为LTP协议的下层通信业务 附录B(规范性)LTP协议管理信息库 41 43ⅢGB/T42649—2023本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定本文件参考“ISO21080:2016《空间数据与信息传输系统面向CCSDS的利克莱德传输协议请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国宇航技术及其应用标准化技术委员会(SAC/TC425)提出并归口。GB/T42649—2023(IRTF)于2002年成立了容延迟网络研究组(Delay-TolerantNetworkingResearchGroup,DTNRG),负责开展网络架构与协议的研究与设计工作。针对超长往返时延和可能出现频繁中断的空间链路，空间数据系统咨询委员会(CCSDS)在RFC5326的了CCSDS734.1-B-1《CCSDSRecommendedStandardforLickliderTransmissionProtocol》,即ISO21080:2016《空间数据与信息传输系统面向CCSDS的利克莱德传输协议(LTP协议)》。该标准仅对RFC5326的技术调整和补充规定进行了重点阐述。LTP协议配合ISO21323:2016《空间数据为保证技术内容的完整性，本文件对ISO21080:2016采取了非等效采用，重点参考并加入了1GB/T42649—2023空间数据与信息传输系统利克莱德传输协议(LTP协议)本文件规定了利克莱德传输协议(以下简称LTP协议)的数据单元格式、协议流程、业务说明等内容，对LTP协议在空间数据与信息传输系统应用进行了补充规定，主要包括下层通信协议和业务的适本文件适用于在通信时延长、可能频繁中断的空间链路上提供可选的可靠数据传输。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB/T17967信息技术开放系统互连基本参考模型OSI服务定义约定GB/T42041—2022航天术语空间数据与信息传输RFC5246传输层安全协议[TheTransportLayerSecurity(TLS)Protocol]GB/T2900.54、GB/T17967与GB/T42041—2022界定的以及下列术语和定义适用于本文件。子系统内的活动元素，是为特定对象定义一组能力(不包括任何正在使用的额外能力)的具体化。协议数据单元protocoldataunit;PDU由协议规定的数据结构。由协议规定的数据结构中的用户数据域。3.4引擎标识符engineID唯一标识一个特定LTP协议引擎的一个整数，该引擎属于由正在通信的LTP协议引擎组成的某个闭集。2GB/T42649—20233.53.6[来源：GB/T42041—2022,3.4.14,有修改]3.73.83.93.12块尾endofblock;EOB检查点checkpoint3GB/T42649—20233.153.16自定界数值self-delimitingnumericvalue;SDNV3.173.18在LTP协议引擎间传送段时由LTP协议调用的通信协议。4缩略语AAL:额外预期延迟(AdditionalAnticipatedLatency)APID:应用进程标识(ApplicationProcessIdentifier)BP:束协议(BundleProtocol)CAR:发给块接收方的取消确认段(Cancel-AcknowledgementsegmenttoblockReceiver)CAS:发给块发送方的取消确认段(Cancel-AcknowledgementsegmenttoblockSender)CAx:取消确认段(Cancel-Acknowledgementsegment,generic)CP:检查点(Checkpoint)CR:来自块接收方的取消段(CancelsegmeCx:取消段(Cancelsegment,generic)CP,检查点(Checkpoint)DCCP:数据报拥塞控制协议(DatagramCongestionControlProtocol)DTN:容延迟网络(Delay-TolerantNetworking)EOB:块尾(EndofBlock)EORP:红部结尾(EndofRed-part)EPI:封装协议标识(EncapsulationProtocolIdentifier)IANA:互联网号码分配机构(InternetAssignedNumbersAuthority)IETF:互联网工程任务组(InternetEngineeringTaskForce)LTP:利克莱德传输协议(LickliderTransmissionProtocol)MIB:管理信息库(ManagementInformationBase)RA:报告确认(ReportAcknowledgement)RFC:征求意见书(RequestforComRS:报告段(ReportSegment)SANA:空间编号分配机构(SpaceAssignedNumberAuthority)SDA:业务数据聚合(ServiceDataAggregation)4GB/T42649—2023SDU:业务数据单元(ServiceDataUnit)SNMP:简单网络管理协议(SimpleNetworkManagementProtocol)TCP:传输控制协议(TransmissionControlProtocol)UCP:下层通信协议(SnderlyingCommunicationProtocol)UDP:用户数据报协议(UserDatagramProtocol)5.1.1在行星际通信等典型场景中，LTP协议主要在具有超长消息往返时间和/或频繁连接中断的链路上提供“远距离”可靠传输业务，同时也支持非可靠传输业务。空间数据与信息传输系统对LTP协议a)在一条点到点链路(也称一跳链路)上可靠交付上层协议(如BP协议)的PDU;b)可将多个上层PDU聚合成一个LTP协议的SDU。5.1.2LTP协议的可靠数据交付是通过红部交付业务实现的，该业务将在本文件第6章中描述。把多5.1.3LTP协议是一种工作在网际互联协议(例如BP协议)和各种数据链路协议之间的协议。LTP(例如BP)N+1层PDUsN+1层PDUs(N层服务提供者)N层PDUsN-1层服务接口N层PDUs(例如封装包)LTP(N层服务提供者)(例如BP)N+1层PDUsLTPN+1层N-1层的对等实体的可扩展性以及在空间链路上与其他协议的交互。5GB/T42649—20235.2架构元素LTP协议架构视图见图2,下面给出了具体说明。a)LTP协议引擎工作在独立的空间数据系统中，负责执行LTP协议流程并提供LTP协议业b)LTP协议引擎通过调用系统提供的下层通信业务和可靠存储实现数据收发和链路中断期间c)客户端业务实例确定应用数据的传输模式(可靠或非可靠),通过LTP协议引擎的业务接口调d)LTP协议的操作依赖于管理信息库(MIB)中的信息，包括本地引擎和远程引擎的配置信息客户端服务实例客户端服务实例LTP协议引擎存储图2LTP协议架构视图b)第二部分为“绿部”,由非可靠传输的数据组成，不需要确认和重传；这是一种非可靠传输业务。块中哪些数据属于红部、哪些属于绿部，由LTP协议客户端业务实例控制。一个要求完全可靠传送的客户端业务实例应指明全部数据以“红色”(可靠)数据方式发送。在本文件中，发送/接收绿部数据断，在中断期间，LTP协议维护的重传计时器将被暂停。6GB/T42649—2023客户端服务实例客户端服务实例LTP协议引擎LTPLTP协议引擎下层通信协议下层通信协议下层通信协议5.3.2基本传输业务示例图4给出了一次同时包含红部(可靠)和绿部(非可靠)的LTP协议块传输操作。在图中，发送方产生了一个异步检查点(第三个红色段),接收方为此回复了一个报告段。包含EORP的段和第二个绿部RRRRRRGGGRCP.EORPCP,EORPRRRRRGGRR标引序号说明：RA—报告确认段；EOB——块尾；图4LTP协议交互概览7通过LTP协议SDA进行传输和报告可减少对多个小的红色LTP协议块进行确认的开销。图5展示了SDA情况下LTP协议的操作，SDA具体内容见第7章。协议客户端接收SDA客户端RRRRRRR标引序号说明：RRRRRk2RS——报告段；EORP——红部结尾；日R2—包含发往客户端服务标识符Y的数据△R2E的LTP协议块；X,R—发往客户端服务标识符X的LTP协议SDA容器；包含多个LTP协议SDA容器的LTP协议块。图5采用业务数据聚合(SDA)的传输空间应用中的每个LTP协议引擎都具有唯一的引擎标识符。在每个LTP协议引擎所在的系统中，地址查询功能可以利用MIB中的信息实现。这个查询功能可以实现引擎标识符和LTP协议使用的下层通信协议所需的信息之间的转换，实际中可能是IP地址、无线电设备缓冲器、APID、虚拟信道编号或其他具体实施机制。6LTP协议通用规定6.1.1.1一个完整LTP协议段的结构如图6所示，每个LTP协议段包含：8GB/T42649—2023版本号段类型标志控制字节会话标识头部头部扩展计数尾部扩展计数扩展头部扩展段内容尾部尾部扩展6.1.1.2根据所携带内容的性质，LTP协议段有以下四b)报告段从接收方发往发送方，并c)报告确认段从发送方发往接收方，并确认收到的报告段。它携带所确认的报告段的序列号。令对等实体启动会话取消处理流程，并携带一个单字节的原因码(见表4)指示会话取消的原2)段类型标志(4bits):见6.1.2.2中具体描述。b)会话标识符(SessionID),在发送方和接收方之间所有传输中唯一标识该段所属的会话，它包括以下内容。1)会话发起者(SDNV):发送方的引擎标识符。2)会话号(SDNV):通常是一个随机数(出于防范拒绝服务攻击的原因),由发送方生成。3)会话号的格式和解析是LTP协议发送方的私有事项；LTP协议的唯一强制要求是，由9GB/T42649—2023LTP协议引擎发起的每个会话应由会话标识符唯一标识。6.1.2.2段类型标志(SegmentTypeFlags)段头部中控制字节的最后4bits是指示段性质的标志。按照最高有效位优先(MSB)顺序，这些标a)CTRL(Control)为0时表示该段为数据段，1时为控制段。b)EXC(Exception)为0的数据段是红部段；EXC为1的数据段是绿部段。对于控制段，将EXC标志设置为1表示该段属于会话取消活动。c)Flag1和Flag0同时为1的数据段(无论是红部还是绿部)都是EOB。d)Flag1和Flag0同时为0的数据段(无论是红部还是绿部)表示数据没有任何附加的协议e)Flag1和Flag0中任一标志位非0的任何红部数据段都是一个检查点。f)Flag1为1的任何红部数据段都表示EORP。6.1.2.3段类型代码(SegmentTypeCodes)码说明见表1。表1段类型代码说明代码段性质00000红色数据，非{检查点，EORP或EOB)00011红色数据，检查点，非(EORP或EOB}00102红色数据，检查点，EORP,非EOB00113红色数据，检查点，EORP,EOB01004绿色数据，非EOB01015绿色数据，未定义01106绿色数据，未定义01117绿色数据，EOB10008报告段10019报告确认段1010控制段，未定义1011控制段，未定义1100来自块发送方的取消段1101发给块发送方的取消确认段1110来自块接收方的取消段1111发给块接收方的取消确认段GB/T42649—2023表2段类掩码说明助记符说明001检查点001001红部结尾；红部大小=偏移量十长度0111000报告段；带有接收声明1001报告确认段1100来自块发送方的取消段1101发给块发送方的取消确认段1110来自块接收方的取消段1111发给块接收方的取消确认段110取消段(通用)111取消确认段(通用)扩展域允许在基本LTP协议段中包含零个或多个功能扩展，每个扩展都以类型-长度-值(TLV)扩展域的第一个字节表示在段中出现的扩展的数量。高4位表示头部中扩展TLV的数量(头部在段内容的后面)。即每个段在其头部可能有0个～15个扩展TLV,在其尾部中可能有0个～15个扩注：头部扩展之后立即接尾部扩展是合法的；例如，由于一个CAx段没有内容，它可以在头部扩展之后立即接尾部每个扩展由一个确定扩展类型的8bits标签(tag),接着一个SDNV形式的长度(length)参数以及图7扩展TLV示意图GB/T42649—2023表3LTP协议扩展标签对应含义说明扩展标签含义LTP协议认证扩展LTP协议cookie扩展0x02-0xAF未分配0xB0-0xBF保留0xC0-0xFF私有/实验用途注：由于扩展标签空间中的最后四分之一是用于实验用途的，LTP协议实现时这些标签有可能出现碰撞。6.1.3.1数据段(DS)数据段的内容主要包括客户端业务数据，以及使接收客户端业务实例能接收并使用该数据的元数据。a)客户端业务标识符(SDNV):客户端业务标识符用于标识该段将被接收方交付的上层业务，其功能类似于TCP协议端口号。如果目的地有多个客户端业务实例，客户端业务自身应基于编码在传输的块中的信息实现复用。b)偏移量(SDNV):偏移量指示段客户端业务数据在会话已发送的块中的位置。它是段客户端业务数据的第一个字节在块中对应位置之前的字节数。c)长度(SDNV):后续客户端业务数据的长度，以字节为单位。d)如果数据段是一个检查点，为了支持有效的重传，应额外包含检查点序列号和报告序列号。非检查点数据段在头部中应没有这两个域，而且头部后应紧接客户端业务数据。e)检查点序列号(SDNV):检查点序列号在一个会话中唯一标识块发送方发出的每一个检查点。出于安全原因，发送方发出的第一个检查点的序列号应随机产生。发送方发出的任何后续检查点的序列号应在上一个检查点序列号上加1得到。但是，当一个CP被重传时，它的序列号应与最初传输时相同。检查点序列号不能为0。f)报告序列号(SDNV):如果一个排队待发送(见6.3.13)的检查点是为响应一个RS的接收，那么它的值应是对应RS的报告序列号值。否则，报告序列号的值应置为0。g)客户端业务数据(一组字节):段中携带的客户端业务数据是原始客户端业务块全部字节中从指定偏移量开始的一个分组的副本。6.1.3.2报告段(RS)报告段的内容包括一个或多个数据接收声明，以及声明关联的块内范围的上界和下界。它还包括a)报告序列号(SDNV):报告序列号在一个会话中唯一标识块接收方发出的每一个报告。出于安全原因，接收方发出的第一个报告的序列号应随机产生。接收方发出的任何后续RS的序列号应在上一个报告序列号上加1得到。但是，当一个RS被重传时，它的序列号应与最初传输时相同。报告序列号不能为0。b)检查点序列号(SDNV):如果报告段不是对接收检查点的响应，即异步接收报告，检查点序列号的值应为0;否则，它应是导致RS产生的检查点的序列号。GB/T42649—2023e)接收声明计数(SDNV):本报告段中数据接收声明的数量。2)长度(SDNV):接收声明的长度表明块中从指定偏移量开始的已经成功接收到的连续字接收声明应符合以下规则：从一个RS数据接收声明中可以推断隐含的客户端业务数据重传请求。但是，接收到的块的其偏移量为0且长度为6000,表明块中前6000个字节的成功接收。如果块的总长度为6000,那么该报告额外表明整个块的成功接收。如果一个报告段的范围具有下界1000和上界6000,报告中包含两个数据接收声明，一个的偏移量为0,长度为2000,另一个的偏移量为3000,长度为500,那么该报告表明块中仅有字节1000～2999和4000～4499成功接收。从中我们可以推断该块中字节3000～3999和4500～5999需要重传，但是我们无法推断前1000个字节或从块偏移量6000开始的后续数RA的内容仅有其响应的RS的报告序列号(SDNV),该域返回所确认的RS报告序列号。b)取消确认段(CAx)没有内容。表4原因码对应的助记符及其语义原因码助记符语义USR_CNCLD客户端业务取消会话UNREACH客户端业务不可达RLEXC超出重传限制MISCOLORED在大于绿部数据段块偏移量处接收到红部数据段或在小于红部数据段块偏移量处接收到绿部数据段SYS_CNCLD由系统错误导致的意外会话终止RXMTCYCEXC超出重传周期限制Reserved保留GB/T42649—2023段尾部包含一个由0个～15个扩展TLV组成的序列，TLV见6.1.2.5所述。6.2客户端业务请求6.2.1传输请求为了请求传输一个客户端业务数据块，客户端业务应向LTP协议提供以下参数：目的客户端业务标识符、目的LTP协议引擎标识符、要发送的客户端业务数据(作为一组字节)、发送数据的长度、数据中红部的长度(该值应在0到要发送的数据总长度的范围内)。在接收到来自客户端业务的有效传输请求后，LTP协议执行下列操作。a)先根据需要对要发送的一组数据进行分割，其中每个经过分割的数据都作为一个新的LTP协议数据段的客户端业务数据。用于分割数据的算法是一个本地实现问题；如果下层通信业务对数据大小约束有强制要求，这将被纳入到该算法中。b)产生的数据段中的最后一个(且仅最后一个)应标记为EOB。1)段类型表明了特定LTP协议段中的客户端业务数据是否属于块的红部。为了防止段类型歧义，每个数据段应只包含红部的数据或绿部的数据。因此，当块的红部长度为N,块的总长度为M,且N不等于M时，块的第(N+1)个字节应是一个绿部数据段中客户端业务数据的第一个字节。2)这意味着在红部边界处，LTP协议可能发送小于链路MTU大小的段。出于带宽效率的原因，在实现上也可以选择将整个段(红部边界处于其中)标记为红部，从而使落在该段内的绿部数据也被视为红部。标记为EORP段。此外，可以把EORP之前的零个或多个包含红部数据的数据段(由某个算法选择，这是一个本地实现问题)额外标记为CP,并作为额外的自主检查点(见6.1.2.3)。d)所有数据段都会被添加到一个绑定到目的引擎的(概念上的)应用数据队列中，以便后续传输。e)最后，一个会话启动通知(见6.4.1)会被送回到请求传输的客户端业务。6.2.2取消请求为了请求取消一个会话，无论是作为相关块的发送方还是接收方，客户端业务应提供要取消的会话的标识符。一旦接收到来自客户端业务的有效取消请求，LTP协议执行下列操作。b)接下来，如果发送方取消会话(即在取消请求提供的会话标识符中的发送方部分是本地LTP协议引擎标识符)。1)如果此会话中之前已排队准备发送的所有数据段还未出队实际发送(即如果目的引擎根2)否则，应将一个带有原因码USR_CNCLD(见表4)的CS段(由块发送方取消)加入队列并发送到目的LTP协议引擎，该目的LTP协议引擎是在启动此会话的传输请求中指定的。c)否则接收方取消会话。1)如果没有绑定到发送方的传输队列集(可能是因为本地LTP协议引擎正运行在一个单收GB/T42649—20232)否则，应将一个带有原因码USR_CNCLD(见表4)的CR段(由块接收方取消)加入队列并发送到块发送方。6.3.1启动传输处理流程：由一个链路状态提示的到达触发，该链路状态提示表明启动向指定远程LTP协议引擎的传输。响应：开始向链路状态提示中指定的LTP协议引6.3.2启动检查点计时器响应：计算在接收该CP段时产生的RS段的预期到达时间，并为该到达时间启动一个倒计时器。响应：计算响应该RS段接收的RA(报告确认)段的预期到达时间，并为该到达时间启动一个倒计时器。但是，和6.3.2一样，如果已知远程LTP协议引擎已停止传输(见6.3.54),则该计时器将立即暂处理流程：由一个链路状态提示的到达触发，该链路状态提示表明停止向指定远程LTP协议引擎传输。响应：停止从绑定到LTP协议引擎的流量队列向下层通信系统出队交付段，该LTP协议引擎由链路状态提示指定。6.3.5暂停计时器处理流程：由一个链路状态提示的到达触发，该链路状态提示表明指定远程LTP协议引擎停止向本地LTP协议引擎传输。通常，这一事件是根据事先已知的远程引擎传输计划推断的。a)确认段将响应的初始段的发送时间与到达远程引擎的单向光时间之和，加N秒的“额外预期b)N由具体实现方式确定。c)如果名义远程引擎确认发送时间大于或等于当前时间，即确认段可能在远程引擎暂停传输期注：当LTP协议部署在深空飞行器中时，到远程引擎的单向光时间可能非常大，而N(包含处理和排队延迟)可能相对较小。N可以作为一个网络管理参数，2s可能是一个合理的默认值。又如，当LTP协议被部署在一个地面“数据骡子”环境时，单向光时间延迟实际上接近于零，而N是根据数据骡子的循环路线计划动态计算的一个函数。GB/T42649—2023处理流程：由一个链路状态提示的到达触发，该链路状态提示表明指定远程LTP协议引擎开始向本地LTP协议引擎传输。通常，这一事件是根据事先已知的远程引擎传输计划推断的。下列流程计算发送延迟间隔。a)名义远程引擎确认发送时间计算如下：确认段将响应的初始段的发送时间与到远程引擎的单向光时间之和，再加上N秒的AAL。b)如果名义远程引擎确认发送时间大于当前时间，即远程引擎在确认段提交发送之前就恢复了a)如果该CP段排队等待发送的次数已经超过了网络管理为本地LTP协议引擎设置的检查点因码RLEXC(见表4)的CS被添加到概念上的应用数据队列中，同时一个传输会话取消通知(见6.4.5)被发送回请求传输的客户端业务。b)如未超限，一个该CP段的新副本将被添加到绑定目的LTP协议引擎的概念上的应用数据队列中准备发送。b)接收到一个冗余的重传检查点(表示之前已为该CP段发送过一个或多个RS段)。响应：如果任何受影响的RS段排队等待发送的次数已经超过网络管理为本地LTP协议引擎设置码RLEXC(见表4)的CR段将排队发送到发起会话的LTP协议引擎，同时一个接收会话取消通知(见6.4.6)被发送到(在该会话中接收的每个数据段中都标识的)客户端业务；如未超限，每个受影RS段的一个新副本将排队发送到发起会话的LTP协议引擎。处理流程：由一个CP段的到达触发，此时该会话的EORP已被接收(确保块的红部的大小是已知的；这包括CP段本身是EORP段的情况),并且这个会话中正在传输的所有块红部数据已被接收。GB/T42649—20236.3.11发送接收报告a)一个CP段的初次接收(检查点序列号表明该CP是新的);么受影响的会话将被取消：“取消会话”处理流程(见6.3.19)被调用，产生一个带有原因码RLEXC(见表4)话取消通知(见6.4.6)被发送到(在该会话中接收的每个数据段标识的)客户端业务。个可能的限制在于，为任何单个会话能够产生的接收报告的最大数量。1)报告的上界应当是检查点数据段的上界(偏移量和长度之和),以减少不必要的重传。况下，该报告的下界应当是报告段的下界，触发的检查点本身就是其响应，以减少不必要1)报告的上界应是该会话迄今接收到的所有红部数据段中的最大上界。2)对于尚未产生其他主接收报告的会话，产生的第一个异步接收报告的下界应为零。后续c)在所有情况下，如果确定了报告范围的适用下界大于或等于适用上界(如由于自主检查点的无加到绑定发起会话LTP协议引擎的内部操作流量队列。报告的第一个RS段的下界应是接6.3.12表明传输完成明，表明该部分的红部已全部接收。GB/T42649—2023响应：首先，发布一个与RS段具有相同报告序列号的RA段，并添加到绑定接收方的内部操作流量队列中。如果RS段是冗余的，如指定的会话未知(如该RS段是在会话已经完成或取消之后接收的)或者接收的RS段的报告序列号和一个已经接收并处理的RS段相同，则无须采取进一步的动作。否a)如果报告的检查点序列号不是零，则删除与指定检查点段关联的倒计时器。b)如果段接收声明指示报告段范围内的数据接收不1)如果该会话中传输问题的数量超过了网络管理为本地LTP协议引擎设置的限制，则该段所属的会话将被取消：调用取消会话处理流程(见6.3.19),一个带有原因码RLEXC(见表4)的CS被添加到(启动此会话的传输请求中指定的)传输队列中，并且一个传输会话取消通知(见6.4.5)将被发送回请求该传输的客户端业务。对传输问题的一个可能的限制在于可以为任意会话产生的重传CP段的最大数量。2)如果该会话中传输问题的数量没有超过任何限制，接收声明中表明的全部未成功接收的块数据将被封装进新数据段，这些数据段将被添加到绑定接收方的传输队列。最后一个(且仅最后一个)数据段应被标记为CP段，该CP段携带一个新的CP序列号和接收的RS段的报告序列号。其中新CP序列号可以通过在已使用的最后一个CP序列号上递增获得。响应：删除与初始RS段(由RA段的报告序列号标识)关联的倒计时器。如果此会话不存在与RS响应：对于接收Cx段后将产生的CAx段，计算该CAx段的预期到达时间并为该预期到达时间启动一个倒计时器。然而，如果已知远程LTP协议引擎已停止传输(见6.3.5),则该计时器将立即暂停，响应：如果该Cx段排队等待传输的次数超过了网络管理为本地LTP协议引擎设置的取消重传限制，则该段所属的会话将被取消：调用处理流程(见6.3.20)。否则，取消段的副本[保留相同的原因码(见表4)]将排队发送到适当的LTP协议引擎。GB/T42649—20231)如果接收到的段是CS段，则产生一个CAS(发给块发送方的取消确认)段，并将其添加到绑定发送方的内部操作流量队列；2)如果接收到的段是CR段，则产生一个CAR(发给块接收方的取消确认)段，并将其添加到绑定接收方的内部操作流量队列。被发送到客户端业务(该会话中接收的每个数据段中都标识了该客户端业务)。处理流程：由以上描述的其他处理流程之一内部触发。6.3.20关闭会话处理流程：由以上描述的其他处理流程之一内部触发。响应：删除与会话关联的任何剩余倒计时器。删除会话状态记录(SSR|RSR),该会话不再存在。优先处理流程按照下列操作执行。b)如果数据段中标明的客户端业务在本地LTP协议引擎上不存在，则因该数据段到达触发的下述所有内部处理流程将按照以下流程执行：2)否则，如果数据段包含来自块红部的数据，一个带有原因码UNREACH(见表4)的CR应码UNREACH(见表4)的CR也应当入队发送给数据发送方；然而，需要注意，如果块接收方知道该绿部数据的发送方正以一种“信标”(单发)方式工作，不必发送CR。无论以上GB/T42649—2023何种情况，已接收的数据段都会被丢弃。6.3.22处理错色段处理流程：由以下两种情况之一触发。a)一个红部数据段的起始块偏移量高于同一个会话中任何先前接收的绿部数据段的偏移量。b)一个绿部数据段的块偏移低于同一个会话中任何先前接收的红部数据段的块偏移。匹配任一上述检查的段的到达违反了协议要求，即所有红部数据为块前缀，所有绿部数据为块后缀。响应：直接丢弃接收到的数据段。调用取消会话处理流程(见6.3.19),一个带有原因码MISCOL-ORED(见表4)的CR段入队并准备发送给数据发送方，给客户端业务发送一个接收会话取消通知注：如果没有为发送方绑定传输队列集(可能因为本地LTP协议引擎正运行在单收设备上),或者如果接收方知道6.3.23处理系统错误状况在LTP协议会话生命周期中，可能发生意外的操作系统错误情况(特别是对于长期存在的LTP协议会话)。一个例子是，系统面临严重的内存紧张，迫使LTP协议会话进入类似于TCP协议选择性确认违约的场景。但是，与TCP协议选择性确认机制中接收报告是建议性的不同，LTP协议接收报告是有约束力的，已经发出的接收声明是不能违约的。响应：在任何这种不可恢复的系统错误状况下，首先调用取消会话处理流程(见6.3.19)。一方面，如果在发送端观察到错误状况，一个带有原因码SYS_CNCLD(见表4)的CS段应当入队并发送给接收方，同时给客户端业务发送一个传输会话取消通知(见6.4.5);另一方面，如果在接收端观察到错误状况，具有相同原因码SYS_CNCLD(见表4)的CR段应当入队并发送给发送方，同时给客户端业务发送一个接收会话取消通知(见6.4.6)。注1:如果没有为发送方绑定传输队列集(可能因为本地LTP协议引擎运行在单收设备上),或者如果接收方知道注2:其他可能导致一个LTP协议实现启动会话取消处理流程的特定于实现的限制是最大重传周期数的说明a)重转周期的定义：LTP协议发送方的一个重传周期包括两个相关的事件，从发送方发送所有未完成的适用，但对应于CP段的接收和响应这些CP的所有RS段的发送。b)资源紧张的情况：重传的CP和RS段仍然是原来的重传周期的一部分。此外，如果一个接收报告无法适配单个受数据链路MTU大小限制的RS段，单个CP段可能导致生成多个RS段；一个接收报告的所有RS段和该CP段都属于同一个重传周期。当存在严重信道错误情况下，在红部传输成功完成之前，情况。6.4客户端业务通知会话启动通知返回一个新创建会话的会话标识符。a)在发送方，会话启动通知告知客户端业务传输会话启动。客户端业务在收到该通知后，可以释20GB/T42649—2023b)在接收端，该通知表明一个新接收会话的开始，同时，当第一个携带新会a)传输会话的会话标识符；b)包含在数据段中的客户端业务数据字节组；c)从块起始位置开始的数据段内容偏移量；d)数据段内容的长度；f)源LTP协议引擎标识符。6.4.3红部成功接收a)传输会话的会话标识符；b)构成块的红部的客户端业务数据字节组；c)块中红部的长度；e)源LTP协议引擎标识符。6.4.4传输会话完成块的红部。6.4.5传输会话取消a)传输会话的会话标识符；b)启动取消序列的Cx段中发送或接收的原因码(见表4)。误或本地LTP协议引擎中的资源终止条件。无法保证目的客户端业务实例接收到数据块的任何部分。a)传输会话的会话标识符；b)解释取消的原因码(见表4)。误或本地LTP协议引擎中的资源耗尽情况。该会话不再产生后续交付通知。初始传输完成通知中包含传输会话的会话标识符。GB/T42649—2023该通知告知客户端业务，一个块的所有段(包括红部和绿部)已经传输。该通知仅表明初始传输已完成；对所有丢失的红部数据段重传仍然是必要的。6.5状态转换图6.5.1状态转换图说明本条将给出供LTP协议实现参考的发送方与接收方状态转换图。图8为发送方的状态转换图，图9为接收方状态转换图。矩形块“会绿化输”是状态转换图中的状态，而“(已取消(”形状表示指向的指针或状态转换序列的占位符。在以下发送方和接收方的状态转换图中使用了表2以及下述的助记符：——RDS(RegularRedDataSegment):常规红部数据段，即非{CP|EORP|EOB}的普通红色数——GDS(RegularGreenDataSegment):常规绿部数据段，即非EOB的普通绿色数据段。接收CR;无红色部分全绿传输已取消己关闭块传输请求有红色部分重传重传红部传输CP到期绿部传输重传绿部传输CP到期重传重传CP到期红部确认完成户动CP计时器FORP、FOB];CS时器到期，CS已发送重传CS,CSi计时器到期，已取消重传据没有完全按收红部重传启动CP计时器超出重传限制范国中的完全接收重传丢收到冗余RS超出重传限制图8LTP协议发送方状态转换图GB/T42649—2023已取消已关阳RS取消传输取消传输重传红部按收绿部按收收到[收到[RDS,CPl:发送EORP,E0BI:重传接收重传接收RDS,CP]:发送接收取消传输重传取消传输RCRR已取消重传取消传输图9LTP协议接收方状态转换图6.5.2发送方状态转换图当LTP协议发送方处于任何状态时，都可能从本地客户端业务接收异步取消请求(CR)。如果发程(见6.3.19),LTP协议发送方从其当前状态转移到取消传输处理序列中，使用原因码USR_CNCLD(见表4)启动会话取消。从“取消传输”标记开始，带有适当原因码(USR_CNCLD或RLEXC,见表4)的CS段入队发送到LTP协议接收方，发送方进入“CS已发送”状态。当接收到一个表明CS段开始传输的链路状态提示时，执行启动取消计时器处理流程(见6.3.15)。当LTP协议发送端从接收端接收到遵循重传取消段处理流程(见6.3.16)。态。根据启动取消计时器处理流程(见6.3.15),在收到指示实际传输开始的链路状态提示时，启动CS计时器。6.5.2.2来自LTP协议接收方CR段异步取消请求的处理当LTP协议发送方处于图8中任何一种状态时，也可能从LTP协议接收方以CR段的形式接收到异步取消请求。当接收到这样一个CR段时，调用确认取消处理流程(见6.3.17),即LTP协议发送23GB/T42649—2023方发送一个CAR段作为响应并返回到“已关闭”状态。在收到块传输请求前，LTP协议发送方一直保持“已关闭”状态。当接收到请求时，如果块中没有在“已关闭”状态，LTP协议发送方可能会收到一个RS段(如果会话关闭前发送的最后一个RA段丢失了或LTP协议接收方过早地重传了RS段),在这种情况下，它将重传一个对应的RA段并保持在“已关闭”状态。如果接收方通过发出一个CR段取消会话，接收方可能重传CR段(要么是因为过早重传，或是因为对应的CAR段丢失了)。在这种情况下，LTP协议发送方重传确认的CAR段，并保持“已在“全绿传输”状态下，根据链路MTU大小将块分段为多个绿色LTP协议数据段，这些数据段入 队发往远程引擎。其中最后一个段被标记为EOB,LTP协议发送方将其入队传输后返回“已关闭”状态。6.5.2.5带有红部的传输处理大小形成的多个红色数据段入队传输。LTP协议发送方可以选择将一些红色的数据段标记为异步检查点；当接收到指示异步检查点传输的链路状态提示后，调用启动检查点计时器处理流程(见6.3.2)。如果块传输请求包含绿部，LTP协议发送方将最后一个红色数据段标记为CP和EORP,并将其入队传输，随后进入“绿部传输”状态。但是，如果块传输请求完全是红色的，最后一个红色数据段被标记为CP、EORP和EOB,LTP协议发送方直接进入“等待红部确认”状态。在上述两种状态转换中，在接收到表明CP段开始传输的链路状态提示后执行启动检查点计时器处理流程(见6.3.2)。在“绿部传输”状态下，块的绿部被分段为绿色数据段，并入队发送到LTP协议接收方；块的最后一个绿色段被额外标记为EOB,LTP协议发送方将其入队发送后进入LTP协议发送方进入“等待红部确认”状态后将一直保持在该状态，直到LTP协议接收方确认接生中断。a)可能从LTP协议接收方收到一个RS(响应先前传输的CP段或为了加速重传而异步发送)。LTP协议发送方进入从“重传”标记开始的状态转换序列，必要时按照重传数据处理流程(见1)如果RS段有一个非零的CP序列号，取消相应的CP计时器。然后，确认该RS段的RA2)如果RS段是由LTP协议接收方冗余传输的(可能是因为最后传输的RA段丢失或RS段计时器在接收方过早到期),则LTP协议发送方不再执行其他操作并返回中断状态。3)类似的，如果RS段范围内的所有红色数据都报告为已接收，无须额外操作，LTP协议发24GB/T42649—2023送方返回中断状态。b)以前设置的CP计时器可能到期。现在LTP协议发送方遵循从CP标记开始的状态转换序1)如果已经超过了网络管理为会话设置的CP重传限制，LTP协议发送者将继续“取消传输”(使用原因码RLEXC,见表4),如取消传输状态转换序所示。2)否则，如果还没有超过重传限制，CP段将入队重传，L收到表明段开始传输的链路状态提示时再次开始启动检查点计时器处理流程(见6.3.2)。异步取消请求的处理方式类似于在LTP协议发送方中的处理方式。a)如果取消请求是由本地客户端业务实例发出的，并且LTP协议接收方还未处于“CR已发送”个带有原因码USR_CNCLD(见表4)的CR段。LTP协议接收方也可能在“已关闭”状态下接收一个重传的CS段丢失了，或者LTP协议发送方的CS计时器过早到期了)。在这种情况下，准备重传一个CAS。数据短接收处理过程包括以下内容。序列，将带有原因码UNREACH(见表4)的Cx段发送给LTP协议发送方。开始的状态转换序列，将一个带有原因码MISCOLORED(见表4)的Cx段发往LTP协议发送方。状态。RA段。如此，在RA段中提到的报告序列号对应的RS计时器将按照暂停RS计时器内部程序(见6.3.14)取消。25GB/T42649—2023对于同时也标记为CP或CP+EORP的红色数据段，将遵循重传RS(见6.3.8)或发送接收报告 (见6.3.11)处理流程，一个响应的RS段入队并发往发送方。采用哪种处理流程取决于该CP段是否为重传(与CP段中检查点序列号相对应的RS段是以前发出的)。然后LTP协议接收方返回到“数据段接收”状态。如果块传输完全为红色，并且段被标记为CP、EORP和EOB,则LTP协议接收方进入“等待红部接收”状态。在所有情况下，在接收到表明RS段开始传输的链路状态提时器内部处理流程(见6.3.3)。成功接收后进入“已关闭”状态。“等待红部接收”状态下，在接收到每个红部数据段时，都要检查它是否具有比已接收的所有绿部数据段更高的块偏移。如是，则调用处理错色段处理流程(见6.3.22),并遵循从“取消传输”标记开始的状态转换序列；一个带有原因码MISCOLORED协议接收方可以接收重传的红色数据段。当接收到标记为CP的红色数据段时，它根据重传RS(见6.3.8)或发送接收报告(见6.3.11)内部处理流程，分别对响应的RS段进行入队传输。采取哪个内部处理流程取决于该CP是否是一个重传。当收到一个表明RS段开始传输的链路状态提示时，调用启动RS计时器内部处理流程。如果收到了一个RA段，则该报告段对应的RS计时器将被取消。LTP协议接收方将一直保持该状下列事件的发生中断。始的状态转换序列，执行内部处理流程重传RS(见6.3.8)。b)检查会话中发送的RS数量是否超过了网络管理设置的重传限制。如是，则应当将一个具有原因码RLEXC(见表4)的CR段发送给LTP动RS计时器内部处理流程(见6.3.3),启动相关的RS计时器。在从“取消传输”标记开始的状态转换序列中，具有给定原因码(见表4)的CR段(取决于如何进入状态序列)入队传输。当接收到表明实际传输的链路状态提示后，按照启动取消计时器内部程序(见6.3.15)启动CR计时器。GB/T42649—20231)检查每个会话中CR段的数量是否超过了网络管理为其设置的重传限制。如果超出了重2)否则，在接收到一个表明实际传输的链路状态提示后，准备重传一个CR段，6.6.2LTP协议认证扩展域定义LTP协议认证需要三个新的扩展域，前两个由LTP协议段头部扩展域携带，第三个由段尾部段头部扩展域中携带的两个域连接到一起形成扩展域的值，其中左侧的字节代表密码套件(ciphersuite),剩余的字节代表密钥标识符(KeyID)。KeyID域是可选的。如果扩展域仅由一2)KeyID:一个可选的密钥标识符，其解释不在本文件的范围内(即实现者应把这些KeyID域当作原始字节)。如果任何会话使用LTP协议认证，那么该会话的第一个段中包含b)LTP协议认证尾部扩展域。有一个AuthVal域可能不会被验证。由于LTP协议是一个对等(peer-to-peer)的协议，大多就可以认为LTP协议认证有效。AuthVal值。1)扩展域(ext):值为0x11,其最高有效和最低有效半字节值均为1,表明分别有一个头部扩2)扩展标签(tag):0x00代表LTP协议认证；GB/T42649—20234)一个一字节的加密套件(c-s);6)尾部扩展(未显示):应包含AuthVal。exttagsdnvcsk-id图10LTP协议认证头部示例6.6.3LTP协议认证采用的密码套件本文件中的密码套件由具体任务确定。涉及国际合作可按照RFC5246相关要求执行，并把所有算法选项“硬编码”到单个密码套件数中。这意味着本版LTP协议认证头部扩展最多可以支持256个潜在的密码套件。7LTP协议在空间数据与信息传输系统应用的补充规定7.1LTP协议运行在空间链路之上当用于支持空间任务并跨多个空间链路时，应把LTP协议部署在每条单独的空间数据链路上，并且应在每条空间数据链路的末端时终止LTP协议。注1:LTP协议本身不是为了跨连续的多条具有异构特性的空间数据链路实现通信而设计的。注2:当与提供多跳数据传送的下层通信业务(如UDP协议)一起使用时，可能需要在下层网络中跨多跳扩展LTP协议连接。特别是对于通过地面因特网传输的LTP协议段。7.2LTP协议运行在UDP协议之上本文件允许在部署到专用网络时将UDP协议用作LTP协议的下层通信业务。在UDP协议上实现LTP协议应使用“Itp-deepspace”UDP协议端口号(十进制1113)。注1:如果将LTP协议部署在UDP协议上，那么就LTP协议而言，UDP协议路径将作为单个虚拟数据链路。在这种情况下，因为LTP协议和UDP协议都不要求拥塞控制机制，设计师可考虑控制网络拥塞的方法。LTP协议实现可以提供速率控制、拥塞控制或其他机制，以减少共享网络中的拥塞。另一种方法是在DCCP上部署LTP协议，而不是直接在UDP协议上。注2:独立成对的发送方/接收方可以选择其他端口号用于通信。但是，由于网络管理/调试设备和软件默认LTP7.3LTP协议域的取值范围LTP协议的域值范围具体包括以下要求。a)发送LTP协议引擎选择的会话号应当在[1,22—1]范围内。b)在6.1.2.1中对会话标识符和会话号要求的基础上，本文件对于面向空间应用的LTP协议实现建议采用顺序会话号。原因包括以下内容。1)绿部数据在LTP协议中非可靠传输。会话包含绿部数据的情况下，包含EOB的绿部数据段可能未交付目的地，因此，发送LTP协议引擎无法知道LTP协议接收方是何时关闭2)LTP协议不要求下层系统按序交付。LTP协议的PDU可能出现乱序。如果发送方重用况下，当下层系统无法保证按序交付，LTP协议应当不重用LTP协议会话标识符。协议28GB/T42649—2023之外的机制可能确定何时可以重用LTP协议会话标识符。3)确保会话号在异常(如系统重新启动)中的唯一性不在本协议的范围内。4)确保航天器异常(如系统重置)中LTP协议会话号的唯一性可能很困难。如果存在此类异常中仍能维持的持久存储器，则可以使用它来存储已使用的LTP协议会话号。如果没有此类存储，则在异常之后需要调用其他机制，以确定哪些LTP协议会话号可供将来使用。这种机制可能包括基于时间的编号选择或基于LTP协议外部机制的编号管理。c)一致性实现所使用的初始检查点序列号的值应在[1,2⁴-1]范围内，且应当随机选择。d)如果给定会话的检查点序列号的值超过2²,则会话发送方应当使用原因码SYS_CNCLD(见表4)取消会话。e)一致性实现所使用的初始报告序列号的值应在[1,2⁴-1]范围内，且应当随机选择。f)如果给定会话的报告序列号的值超过22,会话接收方应使用原因码SYS_CNCLD(见表4)取注：上述要求c)和d)使得在32位处理器上实现LTP协议变得更容易，并且也为LTP协议的空间实现提供了一定程度的位效率，得到的每个域的允许值的完整范围能够以SDNV的形式最多编码为5个字节。将初始报告和序列号的值限制在[1,2¹-1]范围内可确保初始值适合两字节SDNV。7.4空间任务中LTP协议引擎标识符的使用LTP协议引擎标识符由具体任务明确。国际合作任务中采用SANA统一分配的号码资源。7.5空间任务中的LTP协议扩展在传输具有LTP协议扩展的段时，LTP协议实现可根据任务定义的LTP协议扩展标签指定的值注：在国际合作任务中，LTP协议实现可使用表3中IANA注册表分配的LTP协议扩展标签。7.6LTP协议安全本文件定义了可用于确保发送LTP协议引擎身份的认证机制。密钥材料的管理是通过LTP协议节点的管理信息库实现的。注1:确定何时调用特定安全机制的安全策略不在本文件的范围内。b)如果一个实现提供LTP协议认证业务，该实现使用的加密套件由任务明确。国际合作任务中，应当确认使用的加密套件与表5IANA注册表中的LTP协议加密套件一致。c)如果从特定对等实体接收数据需要LTP协议认证，则管理信息库应当包含要与该对等实体一起使用的密钥材料。注2:LTP协议认证机制旨在保护接收方免受恶意发送方的拒绝服务攻击。每个发送LTP协议引擎可以使用单个密钥向所有对等实体验证自己。d)根据LTP协议通用规定，如果使用认证，7.7业务数据聚合7.7.1LTP协议业务数据聚合业务概述由于LTP协议确认至少是以“块”粒度发出的，所以LTP协议生成的肯定和否定的确认流量可以29GB/T42649—2023调整LTP协议段的大小，可以粗略地控制对应于损坏/丢失的段而重传的数据量。但是，根据定义，每个LTP协议块只包含一个客户端业务数据单元。对LTP协议客户端SDU大小设置一个下限以增加块大小，从而最小化确认的通信量是不合理的。本条定义了一个标准的LTP协议业务数据聚合客户端业务，LTP协议客户端可以向该业务交付任意大小的客户端数据单元，该业务可将小的客户端数据单元聚合为业务数据单元，其大小通常不小于某些确定的最小LTP协议块红部大小。LTP协议客户端可以与SDA交互，而不是与LTP协议本身交互。SDA根据需要将客户端数据单元聚合为业务数据单元，将那些可能聚合了的业务数据单元交给LTP协议进行传输，获取LTP协议接收到的可能聚合了的业务数据单元，必要时从这些业务数据单元中提取各个客户端数据单元，并将接收到的客户端数据单元交给客户端。只有需要绝对可靠传输的客户端数据单元才可以交给SDA,即交给SDA的每个客户端数据单元7.7.2LTP协议业务数据聚合说明7.7.2.1LTP协议SDA数据SDA数据主要包括两部分。a)聚合SDA业务数据单元：SDA传递给LTP协议的客户端业务数据单元。每个聚合的业务数据单元由一个或多个SDA客户端数据容器组成。b)SDA客户端数据容器：通过LTP协议SDA传输的客户端数据的封装。一个SDA客户端数据容器包含目的客户端业务标识符和数据。SDA业务要求如下。a)LTP协议SDA应向客户提供LTP协议业务说明(见第8章)中定义的Transmission.request、InitialTransmissionCompletion.indication和RedPartReception.indication原语；b)SDA业务只接受Transmission.request请求，其中数据的红部的长度等于待传输数据的总长度。注1:业务对其他请求采取的行动属实现问题。注2:任何数据丢失，如部分SDAPDU是通过绿色数据发送的，就可能会造成接收方无法恢复全部客户端数据单元。一个尝试缓存并对绿色数据段重新排序以重建它们所携7.7.2.3SDA处理流程7.7.2.3.1客户端业务标识符SDA传递给LTP协议的客户端业务标识符应为“2”,表示“LTP协议业务数据聚合”。7.7.2.3.2客户端业务数据下面给出了客户端业务数据的说明。a)SDA传递给LTP协议的客户端业务数据单元应为单个聚合的SDA业务数据单元。每个聚合的SDA业务数据单元应是一个或多个SDA客户端数据容器的串联。每个SDA客户端数据容器应包括：1)单个SDNV,包含客户端在Transmission.request原语中传递给SDA的LTP协议客户端GB/T42649—20232)在这同一个Transmission.request原语中，客户端把单个完整的客户端数据单元传递注1:聚合SDA业务单元中包含不同SDA容器具有不同的客户端业务标识符。注2:SDA业务数据单元中的客户端数据单元的长度不受LTP协议数据段长度的任何限制，其中部分业务数据将c)发送LTP协议引擎可以对SDA业务数据单元的红色长度施加上限。注3:SDA确定红色长度限制的机制是一个实现问题。当从LTP协议引擎接收到一个TransmissionSessionStart.indication/ReceptionSessionStart.indi-在接收到一个来自客户端的Transmission.request原语时，SDA应当将客户端业务标识符和客户a)达到长度限制。1)对于为指示的远程LTP协议引擎保留并准备在下一个聚合的SDA业务数据单元中发送据单元尺寸门限，那么SDA应当向该LTP协议引擎提交一个Transmission.request2)如上所述，该原语的业务数据单元应当是为指示的远程LTP协议引擎聚合的SDA业务4)要装进Transmission.request对应的业务数据单元中的SDA客户端数据容器应从SDA1)如果当前时间与最早时间之差超过了为某个远程LTP协议引擎配置的业务数据单元聚间是指一个SDA客户端数据容器被保留以包含进将发往该远程LTP协议引擎的下一个2)该原语的业务数据单元应当是如上所述发往指示的远程LTP协议引擎的聚合SDA业务4)发往LTP协议的Transmission,request原语中包含的SDA客户端数据容器应当从SDAc)完成初始传输。GB/T42649—2023当从LTP协议引擎接收到一个TransmissionSessionCompletion.indication原语时，SDA应为SDA业务数据单元中的每个SDA客户端数据容器发出一个TransmissionSessionCompletion.indication原语。当SDA从LTP协议接收方引擎接收到TransmissionSessionCancellation.indication原语时，要执行的过程是一个实现问题，但特别是SDA不应为SDA业务数据单元中的任何SDA客户端数据容器发出TransmissionSessionCompletion.indication原语。当从LTP协议引擎接收到RedPartReceipt.indication时，SDA应从业务数据中提取所有SDA客户端数据容器，并以RedPartReceipt.indication原语将封装的客户端数据单元传递给指定的客户端。从业务数据中提取SDA客户端数据容器的方式取决于每个容器开始处注明的客户端业务标识符，但除此以外都是实现问题。当从发送LTP协议引擎接收到ReceptionSessionCancellation,indication原语时，SDA应该为取消的LTP协议业务的业务数据中的每个SDA客户端数据容器发送一个ReceptionSessionCancellation.indication;每个此类指示都应被交付给由客户端数据容器的客户端业务标识符认证的客户端。8LTP协议业务接口8.1用户接口LTP协议可向客户端提供以下业务，调用方式由具体实现确定：a)发起一次数据传输；b)取消正在进行的数据传输；c)接收来自一个远程实体的数据传输。LTP协议业务应使用以下所有请求原语：b)取消传输请求：CancelTransmission.request;c)取消接收请求：CancelReception.req8.2.2指示原语LTP协议业务应交付以下指示原语：a)传输会话启动指示：TransmissionSessionStart.indication;GB/T42649—2023f)传输会话取消指示：TransmissionSessionCancellation,indica8.3参数DESTINATIONCLIENTSERVICEIDNUMBER,该参数标识(N+1)层业务。提供N层业务8.3.2源LTP协议引擎标识符SOURCELTP协议ENGINEID,该参数作为块发送方LTP协议引擎的标识符。DESTINATIONLTP协议ENGINEID,该参数作为块接收方的LTP协议引擎的标识符。GREENPARTBYTES/REDPARTBYTES,该参数指由LTP协议传递到目的LTP协议客户端GB/T42649—2023的绿部(红部)数据。END-OF-BLOCKINDICATIONS,该参数是RedPartReception和GreenPartReception指示包括规范中仅表示为一个指示。8.4LTP协议业务原语8.4.1传输请求(Transmission.request)LTP协议客户端使用Transmission.request原语请求将一系列字节传递到目的客户端业务。该原语包含以下参数：Transmission.request(destinationclientserviceID,destinationLTPengineID,clientservicedatatosend,lengthofthered-partofthedata)LTP协议客户端可以随时生成Transmission.request。收到Transmission,request使LTP协议引擎启动数据传输。Transmission.request导致向应用传递TransmissionSessionStart.indication,以便随后可以唯一地标识该传输。8.4.2取消传输请求(CancelTransmission.request)LTP协议业务客户端发出CancelTransmission.request原语，以请求取消块传输。该原语包含以下参数：CancelTransmission.request(sessionID)GB/T42649—2023LTP协议客户端可以随时生成CancelTransmission.request。停止。CancelReception.request(sessionID)停止。TransmissionSessionStart.indication(sessionID)sionSessionStart.indication。接收transmissionssessionstart.indication后的响应取决于应用。GB/T42649—20238.4.5接收会话启动指示(ReceptionSessionStart.indication)在接收方，ReceptionSessionStart.indication原语被用于指示开始一个新的接收会话。该原语包含以下参数：ReceptionSessionStart,indication(sessionID)8.4.5.3生成时间在接收方，当接收到携带新会话标识符的第一个数据段时，LTP协议引擎生成ReceptionSession-Start.indication。收到该原语后的响应取决于应用。8.4.6绿部段到达指示(GreenPartSegmentArrival,indication)在LTP协议接收方，使用GreenPartSegmentArrival.indication原语向业务客户端指示已接收到包含绿色(不可靠)数据的段，并应将接收到的数据传递给业务客户端。该原语包含以下参数：GreenPartSegmentArrival.indication(ses