CN114422432A

CN114422432A - 基于可靠传输层的可靠覆盖

Info

Publication number: CN114422432A
Application number: CN202111188893.3A
Authority: CN
Inventors: P·杜塔
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2020-10-13
Filing date: 2021-10-12
Publication date: 2022-04-29
Also published as: US11627077B2; EP3985944A1; US20220116319A1

Abstract

本文呈现了用于支持覆盖的可靠性的各种示例实施例。用于支持覆盖的可靠性的各种示例实施例可以被配置为支持覆盖分组的可靠递送。用于支持覆盖分组的可靠递送的各种示例实施例可以被配置为支持标签交换协议的覆盖分组的可靠递送。用于支持覆盖的可靠性的各种示例实施例可以被配置为支持基于可靠传输层的覆盖分组的可靠递送。可靠传输层可以使用可靠传输层协议而被提供。可靠传输层协议可以是面向连接的协议，可以被配置为支持流量控制，可以被配置为支持拥塞控制，等等。

Description

基于可靠传输层的可靠覆盖

技术领域

各种示例实施例总体上涉及通信系统，并且更具体地但非排他地涉及支持通信系统中的覆盖的可靠性。

背景技术

在很多通信网络中，各种通信技术可以被用于各种通信。

发明内容

在至少一些示例实施例中，一种装置包括至少一个处理器和包括指令集的至少一个存储器，其中该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持分组的通信，其中分组包括有效载荷、在有效载荷上的标签交换协议的报头，以及在标签交换协议的报头上的可靠传输层协议的报头。在至少一些示例实施例中，标签交换协议的报头包括标签集。在至少一些示例实施例中，该标签集被组织为标签堆栈。在至少一些示例实施例中，标签交换协议与标签交换覆盖相关联。在至少一些示例实施例中，标签交换协议包括多协议标签交换(MPLS)协议。在至少一些示例实施例中，可靠传输层协议包括面向连接的传输层协议。在至少一些示例实施例中，可靠传输层协议包括被配置为支持以下至少一项的传输层协议：流量(flow)控制或拥塞控制。在至少一些示例实施例中，可靠传输层协议包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、或传输层安全协议(TLS)协议。在至少一些示例实施例中，分组包括在标签交换协议的报头与可靠传输层协议的报头之间的控制报头。在至少一些示例实施例中，控制报头被配置为指示有效载荷和标签交换协议的报头的大小。在至少一些示例实施例中，分组包括在可靠传输层协议的报头上的网络层协议的报头。在至少一些示例实施例中，网络层协议包括互联网协议(IP)。在至少一些示例实施例中，分组包括在网络层协议的报头上的数据链路层协议的报头。在至少一些示例实施例中，数据链路层协议包括以下至少一项：以太网或点对点协议(PPP)。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备生成分组，并且通过通信设备向下一跳节点发送分组。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备接收分组并且处理该分组。在至少一些示例实施例中，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持覆盖初始帧的通信，覆盖初始帧被配置为传送一个或多个覆盖参数，一个或多个覆盖参数用于基于可靠传输层协议在通信设备与远程通信设备之间被支持的覆盖。在至少一些示例实施例中，覆盖初始帧由通信设备向远程通信设备发送或者由通信设备从远程通信设备接收。

在至少一些示例实施例中，一种非瞬态计算机可读介质存储指令集，其中该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持分组的通信，其中分组包括有效载荷、在有效载荷上的标签交换协议的报头，以及在标签交换协议的报头上的可靠传输层协议的报头。在至少一些示例实施例中，标签交换协议的报头包括标签集。在至少一些示例实施例中，该标签集被组织为标签堆栈。在至少一些示例实施例中，标签交换协议与标签交换覆盖相关联。在至少一些示例实施例中，标签交换协议包括多协议标签交换(MPLS)协议。在至少一些示例实施例中，可靠传输层协议包括面向连接的传输层协议。在至少一些示例实施例中，可靠传输层协议包括被配置为支持以下至少一项的传输层协议：流量控制或拥塞控制。在至少一些示例实施例中，可靠传输层协议包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、或传输层安全协议(TLS)协议。在至少一些示例实施例中，分组包括在标签交换协议的报头与可靠传输层协议的报头之间的控制报头。在至少一些示例实施例中，控制报头被配置为指示有效载荷和标签交换协议的报头的大小。在至少一些示例实施例中，分组包括在可靠传输层协议的报头上的网络层协议的报头。在至少一些示例实施例中，网络层协议包括互联网协议(IP)。在至少一些示例实施例中，分组包括在网络层协议的报头上的数据链路层协议的报头。在至少一些示例实施例中，数据链路层协议包括以下至少一项：以太网或点对点协议(PPP)。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备生成分组，并且通过通信设备向下一跳节点发送分组。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备接收分组并且处理该分组。在至少一些示例实施例中，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持覆盖初始帧的通信，覆盖初始帧被配置为传送一个或多个覆盖参数，一个或多个覆盖参数用于基于可靠传输层协议在通信设备与远程通信设备之间被支持的覆盖。在至少一些示例实施例中，覆盖初始帧由通信设备向远程通信设备发送或者由通信设备从远程通信设备接收。

在至少一些示例实施例中，一种方法包括通过通信设备支持分组的通信，其中分组包括有效载荷、在有效载荷上的标签交换协议的报头，以及在标签交换协议的报头上的可靠传输层协议的报头。在至少一些示例实施例中，标签交换协议的报头包括标签集。在至少一些示例实施例中，该标签集被组织为标签堆栈。在至少一些示例实施例中，标签交换协议与标签交换覆盖相关联。在至少一些示例实施例中，标签交换协议包括多协议标签交换(MPLS)协议。在至少一些示例实施例中，可靠传输层协议包括面向连接的传输层协议。在至少一些示例实施例中，可靠传输层协议包括被配置为支持以下至少一项的传输层协议：流量控制或拥塞控制。在至少一些示例实施例中，可靠传输层协议包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、或传输层安全协议(TLS)协议。在至少一些示例实施例中，分组包括在标签交换协议的报头与可靠传输层协议的报头之间的控制报头。在至少一些示例实施例中，控制报头被配置为指示有效载荷和标签交换协议的报头的大小。在至少一些示例实施例中，分组包括在可靠传输层协议的报头上的网络层协议的报头。在至少一些示例实施例中，网络层协议包括互联网协议(IP)。在至少一些示例实施例中，分组包括在网络层协议的报头上的数据链路层协议的报头。在至少一些示例实施例中，数据链路层协议包括以下至少一项：以太网或点对点协议(PPP)。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备生成分组，并且通过通信设备向下一跳节点发送分组。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备接收分组并且处理该分组。在至少一些示例实施例中，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持覆盖初始帧的通信，覆盖初始帧被配置为传送一个或多个覆盖参数，一个或多个覆盖参数用于基于可靠传输层协议在通信设备与远程通信设备之间被支持的覆盖。在至少一些示例实施例中，覆盖初始帧由通信设备向远程通信设备发送或者由通信设备从远程通信设备接收。

在至少一些示例实施例中，一种装置包括用于通过通信设备支持分组的通信的部件，其中分组包括有效载荷、在有效载荷上的标签交换协议的报头，以及在标签交换协议的报头上的可靠传输层协议的报头。在至少一些示例实施例中，标签交换协议的报头包括标签集。在至少一些示例实施例中，该标签集被组织为标签堆栈。在至少一些示例实施例中，标签交换协议与标签交换覆盖相关联。在至少一些示例实施例中，标签交换协议包括多协议标签交换(MPLS)协议。在至少一些示例实施例中，可靠传输层协议包括面向连接的传输层协议。在至少一些示例实施例中，可靠传输层协议包括被配置为支持以下至少一项的传输层协议：流量控制或拥塞控制。在至少一些示例实施例中，可靠传输层协议包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、或传输层安全协议(TLS)协议。在至少一些示例实施例中，分组包括在标签交换协议的报头与可靠传输层协议的报头之间的控制报头。在至少一些示例实施例中，控制报头被配置为指示有效载荷和标签交换协议的报头的大小。在至少一些示例实施例中，分组包括在可靠传输层协议的报头上的网络层协议的报头。在至少一些示例实施例中，网络层协议包括互联网协议(IP)。在至少一些示例实施例中，分组包括在网络层协议的报头上的数据链路层协议的报头。在至少一些示例实施例中，数据链路层协议包括以下至少一项：以太网或点对点协议(PPP)。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备生成分组，并且通过通信设备向下一跳节点发送分组。在至少一些示例实施例中，为了支持分组的通信，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备接收分组并且处理该分组。在至少一些示例实施例中，该指令集被配置为在由至少一个处理器执行时，使该装置通过通信设备支持覆盖初始帧的通信，覆盖初始帧被配置为传送一个或多个覆盖参数，一个或多个覆盖参数用于基于可靠传输层协议在通信设备与远程通信设备之间被支持的覆盖。在至少一些示例实施例中，覆盖初始帧由通信设备向远程通信设备发送或者由通信设备从远程通信设备接收。

附图说明

通过结合附图考虑以下具体实施方式，可以容易地理解本文中的教导，在附图中：

图1描绘了被配置为支持可靠MPLS覆盖的通信系统的示例实施例；

图2描绘了在多租户数据中心环境中针对网络虚拟化使用可靠MPLS覆盖的示例实施例；

图3描绘了非基于机箱的网络功能虚拟化(NFV)路由器的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用；

图4描绘了基于机箱的路由器的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用；

图5描绘了基于机箱的路由器中的内部结构的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用；

图6描绘了在基于机箱的NFV路由器中针对内部结构使用可靠MPLS覆盖的示例实施例，其中控制平面和转发平面通过网络被分开；

图7描绘了在存储区域网络中针对虚拟化光纤通道使用可靠MPLS覆盖的示例实施例；

图8描绘了被配置为支持可靠MPLS覆盖的通信系统的示例实施例；

图9描绘了MPLS覆盖分组的示例实施例，用于说明可靠传输层的(多个)报头在MPLS覆盖分组中的定位；

图10描绘了包括MPLS覆盖分组的字节流的解析的示例实施例；

图11描绘了被配置用于在MPLS覆盖分组上使用以支持可靠MPLS覆盖的MPLS控制报头(MCH)的示例实施例；

图12描绘了用于新的传输连接的MPLS覆盖初始帧(MOIF)的示例实施例；

图13描绘了用于由发起路由器使用以用于配置可靠传输连接的方法的示例实施例；

图14描绘了用于由发起路由器使用以用于支持针对新的可靠传输连接的后续动作的方法的示例实施例；

图15描绘了用于由发起路由器使用以用于针对新的可靠传输连接构建MOIF的方法的示例实施例；

图16描绘了用于当在预定义时间段内未接收到MOIF响应时由发起路由器使用的方法的示例实施例；

图17描绘了用于由发起路由器使用以处置MOIF响应的方法的示例实施例；

图18描绘了用于由接收路由器使用以用于配置可靠传输连接侦听器的方法的示例实施例；

图19描绘了用于由接收路由器使用以用于处理针对传输层连接的传入请求的方法的示例实施例；

图20描绘了用于由接收路由器使用以用于针对新的可靠传输连接执行连接后跟进的方法的示例实施例；

图21描绘了用于由接收路由器使用以用于在等待MOIF响应的同时处置MOIF的方法的示例实施例；

图22描绘了用于配置可靠MPLS覆盖的方法的示例实施例；

图23描绘了用于在可靠MPLS覆盖上传输分组的方法的示例实施例；

图24描绘了用于通过可靠传输连接来传输MPLS分组的方法的示例实施例；

图25描绘了用于处理在可靠MPLS覆盖上接收的分组的方法的示例实施例；

图26描绘了用于将可靠MPLS覆盖实现为MPLS-in-TCP的MPLS-in-TCP封装格式的示例实施例；

图27描绘了用于针对MPLS-in-TCP配置TCP连接的方法的示例实施例；

图28描绘了用于针对MPLS-in-TCP的TCP连接执行连接后跟进的方法的示例实施例；

图29描绘了用于当在针对TCP连接的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例；

图30描绘了用于配置TCP连接侦听器的方法的示例实施例；

图31描绘了用于处理传入TCP连接请求的方法的示例实施例；

图32A-32B描绘了用于在TCP连接上配置MPLS覆盖以形成MPLS-in-TCP覆盖的方法的示例实施例；

图33描绘了用于在MPLS-in-TCP上传输分组的方法的示例实施例；

图34描绘了用于在TCP连接上传输MPLS分组的方法的示例实施例；

图35描绘了用于接收和处理MPLS-in-TCP分组的方法的示例实施例；

图36描绘了用于处理来自TCP连接的TCP分段的MPLS-in-TCP分组的方法的示例实施例；

图37描绘了用于将可靠MPLS覆盖实现为MPLS-in-SCTP的MPLS-in-SCTP封装格式的示例实施例；

图38描绘了用于SCTP分组的SCTP控制块报头的示例实施例；

图39描绘了用于SCTP分组的SCTP数据块报头的示例实施例；

图40描绘了用于针对MPLS-in-SCTP配置SCTP关联的方法的示例实施例；

图41描绘了用于针对MPLS-in-SCTP的SCTP关联执行连接后跟进的方法的示例实施例；

图42描绘了用于当在针对SCTP关联的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例；

图43描绘了用于配置SCTP关联侦听器的方法的示例实施例；

图44描绘了用于处理传入SCTP关联请求的方法的示例实施例；

图45描绘了用于在SCTP关联上配置MPLS覆盖以形成MPLS-in-SCTP覆盖的方法的示例实施例；

图46描绘了用于在MPLS-in-SCTP上传输分组的方法的示例实施例；

图47描绘了用于在SCTP关联上传输MPLS分组的方法的示例实施例；

图48描绘了用于接收和处理MPLS-in-SCTP分组的方法的示例实施例；

图49描绘了用于处理来自SCTP关联的SCTP分组的MPLS-in-STCP分组的方法的示例实施例；

图50描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的MPLS-in-QUIC封装格式的示例实施例；

图51描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的针对QUIC分组的QUIC长报头的示例实施例；

图52描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的针对QUIC分组的QUIC短报头的示例实施例；

图53描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的针对QUIC分组的QUIC帧堆栈的示例实施例；

图54描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的针对QUIC分组的流(STREAM)帧的示例实施例；

图55描绘了针对QUIC分组的通用流帧格式的示例实施例；

图56描绘了复用N个MPLS覆盖分组的QUIC分组的示例实施例；

图57描绘了用于针对MPLS-in-QUIC配置QUIC连接的方法的示例实施例；

图58描绘了用于针对MPLS-in-QUIC的QUIC连接执行连接后跟进的方法的示例实施例；

图59描绘了用于当在针对QUIC连接的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例；

图60描绘了用于配置QUIC连接侦听器的方法的示例实施例；

图61描绘了用于处理传入QUIC连接请求的方法的示例实施例；

图62描绘了用于在QUIC连接上配置MPLS覆盖以形成MPLS-in-QUIC覆盖的方法的示例实施例；

图63描绘了用于在MPLS-in-QUIC上传输分组的方法的示例实施例；

图64描绘了用于在QUIC连接上传输MPLS分组的方法的示例实施例；

图65描绘了用于接收和处理MPLS-in-QUIC分组的方法的示例实施例；

图66描绘了用于处理来自QUIC分组的MPLS-in-QUIC分组的方法的示例实施例；

图67描绘了用于支持覆盖的可靠性的方法的示例实施例；以及

图68描绘了适合用于执行本文中呈现的各种功能的计算机的示例实施例。

为便于理解，本文中尽可能使用相同的附图标记表示不同附图之间共有的相同元素。

具体实施方式

本文中呈现了用于支持覆盖的可靠性的各种示例实施例。

用于支持覆盖的可靠性的各种示例实施例可以被配置为支持覆盖分组的可靠递送。用于支持覆盖分组的可靠递送的各种示例实施例可以被配置为支持标签交换协议的覆盖分组的可靠递送。标签交换协议可以是多协议标签交换(MPLS)协议或其他合适的标签交换协议。标签交换协议的覆盖分组可以使用在网络层操作的网络层协议的底层隧道而被支持。网络层协议可以是互联网协议(IP)，诸如IPv4或IPv6，在这种情况下，标签交换协议的覆盖分组可以使用IP底层隧道或任何其他合适的网络层协议而被支持。可以认为标签交换协议的覆盖分组提供标签交换覆盖，使得经由标签交换路径来交换覆盖分组的标签交换设备可以被认为在标签交换路径上是相邻的，即使标签交换设备是由底层网络(例如，基于IP底层隧道的IP网络)分开的。应当理解，在标签交换协议是MPLS的情况下，可靠覆盖可以被称为可靠MPLS覆盖。

用于支持覆盖的可靠性的各种示例实施例可以被配置为支持基于可靠传输层的覆盖分组的可靠递送。可靠传输层可以使用可靠传输层协议而被提供。可靠传输层协议可以是面向连接的协议。可靠传输层协议可以被配置为支持可靠性特征，诸如无损失传递、流量控制、拥塞控制等及其各种组合。可靠传输层协议可以包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、传输层安全(TLS)协议、或者被配置为在传输层处操作的其他可靠协议。可靠传输层可以在标签交换覆盖(例如，MPLS覆盖或其他合适的覆盖)与底层传输层(例如，IP底层或其他合适的传输层底层)之间被布置。

应当理解，虽然本文中主要关于其中通信协议层基于开放系统互连(OSI)模型(例如，OSI模型的传输层处的可靠传输层协议、OSI模型的网络层处的网络层协议等)的示例实施例而被呈现，但是本文中呈现的各种示例实施例可以与通信协议层一起使用或可以适合与通信协议层一起使用，这些通信协议层可以基于其他通信协议层模型。

应当理解，通过参考下面进一步讨论的各种附图，可以进一步理解这些和各种其他示例实施例以及支持覆盖的可靠性的优点或潜在优点。

图1描绘了被配置为支持可靠MPLS覆盖的通信系统的示例实施例。通信系统100包括一对标签交换路由器(LSR)110-A和110-B(统称为LSR 110)以及通信网络120。LSR 110支持可靠MPLS覆盖111以用于MPLS分组在LSR 110之间的可靠递送。可靠MPLS覆盖111基于LSR111-A上的可靠MPLS覆盖111-A和LSR 111-B上的可靠MPLS覆盖111-B。可靠MPLS覆盖111可以具有基于可靠传输协议(例如，TCP、SCTP、QUIC、TLS等)的可靠连接，该可靠连接建立在LSR 111-A上的可靠MPLS覆盖111-A与LSR 110-B上的可靠MPLS覆盖110-B之间以用于支持MPLS分组从LSR 110-A到LSR 110-B的可靠递送。可靠MPLS覆盖111被配置为基于在可靠MPLS覆盖111上运行的一组N个标签交换路径(表示为LSP 1-N)来支持MPLS分组从LSR 110-A到LSR 110-B的可靠递送。可靠MPLS覆盖111依赖于底层隧道119(其可以是基于互联网协议(IP)的隧道或其他合适类型的隧道)以用于支持从LSR 110-A到LSR 110-B的LSR(例如，LSR 110-A在隧道119上复用LSP，因为LSR 110-A与LSR 110-B不相邻)。可靠MPLS覆盖111允许LSR 110以可靠方式在LSP上相邻，即使LSR 111通过通信网络120被分开。应当理解，虽然主要关于特定传输方向而被呈现，但是也可以建立一组LSP以支持MPLS分组从LSR 110-B到LSR 110A的可靠递送。应当理解，可靠MPLS覆盖可以在各种上下文中使用，其中的一些关于图2到图7而被呈现。

图2描绘了在多租户数据中心(DC)环境中针对网络虚拟化(NVO)使用可靠MPLS覆盖的示例实施例。

在图2中，如上文所指示的，可靠MPLS覆盖可以被用于多租户DC环境中的NVO。通常，DC是专门针对特定需求(例如，针对企业业务需求或其他类型的需求)而被设计的云基础设施资源的池或集合。基础资源是服务器(例如，处理器(例如，CPU)、存储器(例如，RAM)，等等)、存储装置(例如，磁盘空间)，以及互连服务器和存储装置的网络(例如，带宽)。多租户DC可以在单个物理基础设施上针对多个客户(被称为租户)托管虚拟DC。虚拟DC是物理数据中心的虚拟表示，包括服务器、存储集群和很多网络组件，所有这些都驻留在由多租户DC托管的虚拟空间中。针对虚拟DC的服务器利用虚拟机(VM)被虚拟化。一个或多个VM可以在物理服务器之上运行，其中每个VM被分配物理服务器的处理器资源(例如，核心)和存储器资源(例如，RAM)的份额。物理服务器中的VM可以属于相同租户，也可以属于不同租户。在物理服务器中运行的被称为“管理程序”的薄层软件将VM与物理服务器去耦合，并且根据需要为每个VM动态地分配计算资源。存在各种解决方案以虚拟化存储装置，为简单起见，本文中不再赘述。针对租户的VM和虚拟化存储装置通过特定于租户的虚拟网络而被互连。虚拟网络可以被实现为覆盖网络，该覆盖网络位于基于IP的底层之上，该基于IP的底层互连DC中的物理资源。NVO解决方案提供层2和/或层3虚拟网络，以能够支持特定于租户的跨虚拟网络的多租用和VM移动性。因此，每个租户被提供有独立的虚拟化服务器和虚拟化存储装置岛、以及将它们互连的虚拟网络。当MPLS覆盖被部署为NVO时，MPLS覆盖的MPLS标签堆栈是标识虚拟网络的解复用器。

在图2中，都是物理服务器的服务器210和服务器220通过IP网络230被连接。在图2中，服务器210和220都被示出为已经被分开为三个层次，如下所示：(1)“硬件”层，其包括处理器、存储器(例如，RAM)、I/O端口(例如，网络接口卡(NIC)等)，(2)“管理程序”层，其管理和向VM分配硬件资源，以及(3)VM层，其包括在管理程序之上运行的VM。服务器210经由NIC217(其可以是以太网NIC)中的一个或多个端口连接到IP网络230，并且服务器220经由NIC227(其可以是以太网NIC)中的一个或多个端口连接到IP网络230。

在图2中，每个物理服务器托管两个租户，分别命名为Ten-1和Ten-2，其中“Ten”被用作“租户”的简写。VM 212和VM 222分别是托管在物理服务器210和220中的Ten-1的VM(或虚拟服务器)。VM 213和VM 223分别是托管在物理服务器210和220中的Ten-2的VM(或虚拟服务器)。

在图2中，使用MPLS覆盖240在每个租户的VM之间创建虚拟网络。为了简单起见，由于每个租户只具有两个VM，本文中的虚拟网络是点对点以太网链路。MPLS覆盖240在服务器210和220中的管理程序之间被创建。服务器210中的MPLS覆盖终止点216位于服务器210中的管理程序中。MPLS覆盖终止点216利用要被用于IP底层的IP地址而被配置，使得该地址通过IP网络230是可到达的。服务器220中的MPLS覆盖终止点226位于服务器220中的管理程序中。MPLS覆盖终止点226利用要被用于IP底层的IP地址而被配置，使得该地址通过IP网络230是可到达的。每个租户被分配网络范围的唯一MPLS标签，以被用作其MPLS覆盖中的解复用器。例如，假定Ten-1被分配标签100并且Ten-2被分配标签200。注意，本示例使用双向LSP作为租户的MPLS覆盖，并且因此，针对两个方向分配相同的标签。注意，在作为MPLS覆盖的端点进行操作方面，图2的MPLS覆盖终止点216和226可以被认为对应于图1的LSR 110。

在图2中，VM 212经由虚拟以太网端口214连接到MPLS覆盖终止点216。在MPLS覆盖终止点216中，虚拟以太网端口214被映射到MPLS覆盖标签100。类似地，VM 222经由虚拟以太网端口224连接到MPLS覆盖终止点226。在覆盖终止点226中，虚拟以太网端口224被映射到MPLS覆盖标签100。这完成了Ten-1的VM之间的点对点虚拟网络的建立。

在图2中，VM 213经由虚拟以太网端口215连接到MPLS覆盖终止点216。在MPLS覆盖终止点216中，虚拟以太网端口215被映射到MPLS覆盖标签200。类似地，VM 223经由虚拟以太网端口225连接到覆盖终止点226。在覆盖终止点226中，端口225被映射到MPLS覆盖标签200。这完成了Ten-2的VM之间的点对点虚拟网络的建立。

在图2中，MPLS覆盖240的有效载荷是层2/以太网分组，因为每个VM生成以太网分组。在Ten-1中，假定VM 212向VM 222发送分组。首先，VM 212经由虚拟以太网端口214发送以太网分组。当MPLS覆盖终止点216接收到分组时，它将MPLS标签100推送到分组上，并且然后推送隧道封装(例如，MPLS-in-IP、MPLS-in-GRE，或MPLS-in-UDP，等等)。隧道的IP报头中的源地址被设置为MPLS覆盖终止点216的IP地址，并且隧道的IP报头中的目的地地址被设置为MPLS覆盖终止点226的IP地址。由此引起的分组由MPLS覆盖终止点216发送到IP网络230。在被IP网络230路由之后，分组最终到达MPLS覆盖终止点226。MPLS覆盖终止点226解封装隧道封装，并且然后在下方查找MPLS标签100。由于标签100在MPLS覆盖终止点226中被映射到虚拟以太网端口224，因此标签100被移除，并且由此引起的以太网分组在端口224上被转发。然后该分组由VM 220接收。以相同的方式，Ten-2中的VM通过其虚拟网络彼此交换分组。因此，多个虚拟网络使用其相应MPLS覆盖标签在两个隧道端点之间被复用。

用于支持可靠MPLS覆盖的各种示例实施例可以在图2的上下文内应用以用于在多租户DC环境中针对NVO支持MPLS覆盖分组的可靠递送。例如，可靠MPLS覆盖可以防止MPLS覆盖分组的丢弃，否则在没有可靠MPLS覆盖的情况下可能会丢弃该MPLS覆盖分组(例如，防止MPLS覆盖终止点216和226之间的MPLS覆盖分组的丢弃，诸如在NIC 217和227中由于缓冲区溢出、在IP网络230中的任何路由器中(例如，由于缓冲区/队列溢出、拥塞，等等)、沿IP网络230的链路中的故障，等等)。注意，如果某些应用需要可靠性，则应用的责任是生成覆盖业务(例如，在覆盖上生成业务的基于TCP/IP的HTTP应用(提供传统的层2或层3服务)可以从由于TCP提供的可靠性而造成的损失中恢复)。还应当注意，还存在在MPLS覆盖上生成业务的应用，但不是基于针对应用提供可靠传输的协议(例如，TCP/IP，等等)，并且一些这样的应用是被设计为在可靠介质上运行的各种基础设施协议/互连(但是，在多租户DC中，介质使用MPLS覆盖被虚拟化)。这样的覆盖提供基础设施互连服务，而不是传统的层2或层3服务。注意，由于多个这样的MPLS覆盖在两个隧道端点之间的隧道上被复用，因此由MPLS覆盖使用的隧道机制可以提供可靠性。

图3描绘了非基于机箱的NFV路由器的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用。基于NFV的路由器可以在商用的现成的物理服务器(诸如，基于x86的服务器平台)上实现具有一个或多个VM的路由器平台。可以存在两种实现NFV路由器的方法：(1)非基于机箱的方法，其中整个路由器被托管在单个VM上，或者(2)基于机箱的方法，其中路由器的每个组件由分开的VM实现。在图3中，非基于机箱的NFV路由器在物理服务器上的管理程序上作为VM运行。在图3中，物理服务器300包括硬件310、管理程序320、和提供路由器331的VM 330。硬件310包括一组N个NIC(表示为NIC-1至NIC-N)，N个NIC具有与其相关联的N个端口(分别表示为与NIC-1至NIC-N相关联的端口1至端口N)。路由器331从NIC上的端口接收分组，处理分组，并且经由NIC上的端口将处理的分组转发给相关目的地。为了最佳的性能，分配给路由器331(VM 330)的NIC由路由器331直接控制(例如，使用单个根输入/输出虚拟化(SR-IOV)、PCI直通，等等)，而不需要由管理程序320进行任何调解。路由器331的控制平面和转发平面驻留在单个VM 330内。注意，由于NIC是基于以太网的，所以NFV路由器经常使用以太网作为数据链路层。

图4描绘了基于机箱的路由器的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用。在图4中，机箱400包括包括N个插槽和一个附加插槽的N+1个插槽，该N个插槽包括转发平面卡(表示为SLOT-0至SLOT-N，其分别包括表示为FWD卡1至FWD卡N的转发平面卡)，该一个附加插槽包括控制平面卡(表示为SLOT-X，其包括表示为CTRL卡的控制平面卡)。转发平面卡提供路由器的转发平面。转发平面卡包括用于传输和接收分组的端口(为清楚起见而在本文中省略)。转发平面卡实现路由器的转发平面，转发平面接收分组、处理分组、并且将分组发送给目的地。控制平面卡操作路由器的控制平面。应当理解，虽然出于冗余目的可以有多个控制平面卡，但为了简单起见，图4中仅示出了单个控制平面卡。注意，通常，存在可以连接各个卡的至少两个内部网络，每个网络的根节点(中心化实体)位于控制平面卡中。具有两个内部网络的互连的扩展视图的示例在图5中呈现。

图5描绘了基于机箱的路由器中的内部结构的示例实施例，用于能够进一步理解可靠MPLS覆盖到基于机箱的NFV路由器的应用。

在图5中，示出了基于机箱的路由器的两个内部网络的互连。

在图5中，第一网络用于交换结构，分组通过该交换结构跨卡被交换。在图5中，交换结构被托管在控制平面卡内，但也可能具有分开的交换结构卡。如果到达卡1中的端口上的分组需要由卡4中的端口发出，则在执行入口处理之后，卡1将分组发送到通向交换结构的通道，并且然后交换结构将分组中继到卡4以用于出口处理和最终传输。每个卡通过交换结构通道(交换结构网络中的链路)被连接到交换结构。

在图5中，第二网络用于卡间通信(ICC)。ICC控制在控制平面中，通过ICC通道(ICC网络中的链路)被连接到每个转发平面卡。ICC网络用于控制平面与转发平面之间的所有控制和管理消息传递。例如，控制平面对转发平面的配置是使用ICC网络来执行的。由转发平面生成的任何警报或警告都会通过ICC网络被通知给控制平面。用于检查卡之间的连接性的心跳作为ICC消息被交换。

注意，交换结构和ICC网络两者都是无损的，这意味着，分组/消息通常可以可靠地传输而没有任何丢弃。

应当理解，尽管主要关于使用两个互连网络来呈现，但也可以使用多于两个互连网络。

应当理解，关于图4和5呈现的路由器机箱可以被虚拟化，以提供基于机箱的NFV路由器，如关于图6呈现的。

图6描绘了在基于机箱的NFV路由器中针对内部结构使用可靠MPLS覆盖的示例实施例，其中控制平面和转发平面通过网络被分开。

在图6中，如上所指示的，可靠MPLS覆盖可以被用于其中控制平面和转发平面通过网络被分开的基于机箱的NFV路由器。

在图6中，每个卡由VM模拟，并且每个VM驻留在分开的物理服务器中以最小化单个故障点。此处，术语“控制平面服务器”被用于表示托管用于控制平面卡的VM的物理服务器，术语“转发平面服务器x”被用于表示托管用于转发平面卡x的VM的物理服务器。

在图6中，控制平面和转发平面VM通过IP网络被分开。VM可以位于局域网(LAN)内，例如，位于同一IP子网内。然而，此处，VM通过IP网络被分开，因为这是在VM被连接在LAN内的情况下也可以满足要求的超集情况。

在图6中，每个转发平面VM使用NIC-1来模拟用于分组接收和传输的端口。为了最佳的性能，NIC-1由转发平面VM直接控制(例如，使用SR-IOV、PCI直通，等等)，而不需要由管理程序进行任何调解。每个转发平面服务器使用NIC-2上的端口以连接到IP网络。控制平面服务器使用NIC-1上的端口以连接到IP网络。VM之间的ICC和交换结构通道被建立作为跨IP网络的MPLS覆盖。MPLS覆盖终止点位于管理程序中。每个转发平面服务器与控制平面服务器之间有两个MPLS覆盖——一个MPLS覆盖用于ICC通道，一个MPLS覆盖用于交换结构通道。每个覆盖被建立作为双向LSP，该双向LSP在两个方向上(即，从转发平面卡到控制平面卡，反之亦然)使用相同的MPLS标签。例如，假设覆盖用于ICC通道的MPLS标签是标签100并且覆盖用于交换结构通道的MPLS标签是标签200。

在图6中，为了为覆盖创建针对覆盖的IP底层，每个覆盖终止点在连接到IP网络的NIC上的其相应端口上创建IP地址，使得IP地址由IP网络可路由。转发平面服务器x处的覆盖终止点上的IP地址表示为“F-IPx”，控制平面服务器处的覆盖终止上的IP地址表示为“C-IP”。每个转发平面服务器处的覆盖终止点配置有一个底层隧道，该底层隧道的目的地IP地址为C-IP。控制面服务器处的覆盖终止点配置有N个底层隧道，每个底层隧道通往一个转发面服务器。例如，通往转发平面服务器1、服务器2、……、服务器N的底层隧道的目的地IP地址分别为F-IP1、F-IP2、……、F-IPN。

在图6中，转发平面VM使用两个虚拟端口连接到其本地覆盖终止点——一个虚拟端口用于ICC通道，一个虚拟端口用于交换结构通道。在覆盖终止点内，ICC通道的端口被映射到MPLS标签100，交换结构通道的端口被映射到MPLS标签200。这两个标签都在通往控制平面服务器的IP底层隧道上被复用。

在图6中，针对每个转发平面VM，控制平面VM利用两个虚拟端口连接到其本地覆盖终止点——一个虚拟端口用于ICC通道，一个虚拟端口用于交换结构通道。因此，控制平面VM与其本地覆盖终止点之间总共有2N个虚拟端口。在本地覆盖终止点内：(1)通往转发平VM的ICC通道的端口被映射到MPLS标签100和通往转发平面服务器的IP底层隧道，以及(2)通往转发平面VM的交换结构通道的端口被映射到MPLS标签200和通往转发平面服务器的IP底层隧道。应当理解，针对ICC和交换结构的MPLS覆盖形成两个虚拟网络，这是如上描述的NVO的情况。

在图6中，作为示例，从模拟卡1的转发平面VM到控制平面VM的任何ICC消息将首先在其用于ICC通道的虚拟端口上被发送。当本地覆盖终止点接收到该消息时，它推送MPLS标签100，然后是隧道封装，隧道封装使用其中源IP地址为F-IP1并且目的地IP地址为C-IP的IP报头。然后分组经由NIC-2中的端口被发送到IP网络。当控制平面服务器中的覆盖终止点接收到分组时，它执行以下动作：(1)基于隧道封装中的源IP地址来标识源转发平面服务器，(2)移除隧道封装，(3)查找MPLS标签100，并且基于标签100解复用包含ICC消息的分组，并且移除标签，(4)基于标识的源转发平面服务器，查找控制平面VM的虚拟端口，该虚拟端口被映射到转发平面VM的ICC通道，以及(6)在虚拟端口上转发ICC消息。ICC消息由控制平面VM中的ICC控制模块接收。

在图6中，作为示例，要在交换结构通道上从模拟卡1的转发平面VM发送到控制平面VM的任何分组将首先在其用于通道的虚拟端口上被发送。当本地覆盖终止点接收到该消息时，它推送MPLS标签200，然后是隧道封装，隧道封装使用其中源IP地址为F-IP1并且目的地IP地址为C-IP的IP报头。然后分组经由NIC-2中的端口被发送到IP网络。当控制平面服务器中的覆盖终止点接收到分组时，它执行以下操作：(1)基于隧道封装中的源IP地址来标识源转发平面服务器，(2)移除隧道封装，(3)查找MPLS标签200，并且基于标签200解复用包含用于交换结构的分组的分组，并且移除标签，(4)基于标识的源转发平面服务器，查找控制平面VM的虚拟端口，该虚拟端口被映射到转发平面VM的交换结构通道，以及(6)在虚拟端口上转发分组。该分组由控制平面VM中的交换结构接收。

注意，如果物理服务器仅托管单个转发平面或控制平面VM，则为了最佳的性能，还可以在相应VM内实现覆盖终止点，以避免在通道上传输和接收分组的同时与管理程序进行上下文切换。在这种情况下，转发平面服务器中的NIC-2将直接由转发平面VM控制(例如，使用SR-IOV、PCI直通等)。控制平面服务器中的NIC-1也是如此。

用于支持可靠MPLS覆盖的各种示例实施例可以在图6的上下文内应用以用于支持针对基于机箱的NFV路由器的MPLS覆盖分组的可靠递送，其中控制平面和转发平面通过网络被分离(例如，以防止NIC丢弃ICC或交换结构分组(在控制平面服务器和转发平面服务器两者处)或在IP网络内)。

图7描绘了在存储区域网络(SAN)中针对虚拟化光纤通道(FC)使用可靠MPLS覆盖的示例实施例。

在图7中，如上所指示的，可靠MPLS覆盖可以被用于SAN中的虚拟化FC。FC是一种高速数据传输协议，其提供原始数据块的有序的无损传输，主要被用于将计算机数据存储连接到DC中的SAN中的服务器。SAN是一个可以由连接到SAN的多个服务器访问/共享的基于块的存储设备池的网络。FC中的可靠性由其数据链路层提供，数据链路层称为FC-1(FC-0是物理层，其通常是高速光纤)。

在图7中，FC业务在多租户DC中的MPLS覆盖740上传输。该示例使用两个租户进行描述，分别表示为Ten-1和Ten-2。服务器720是经由FC链路760直接附接到SAN 750的物理服务器。服务器720经由FC卡724上的端口与FC链路760接口。服务器720托管运行多租户SAN控制器722的功能的VM。对SAN 750的任何访问请求都是通过SAN控制器722进行的。为了实现多租户，SAN 750被逻辑分区，以呈现为多个独立SAN。Ten-1和Ten-2的逻辑SAN分别作为SAN751和SAN 752被映射到SAN 750上。SAN控制器722维护租户特定逻辑数据块到SAN 750中的物理数据块的映射。出于安全原因需要这种逻辑分区和映射，使得租户的任何错误访问不会破坏另一租户的数据。服务器710托管用于Ten-1和Ten-2的VM，分别表示为VM 712和VM713。VM运行一些租户特定服务器应用。VM 712访问SAN 751并且VM 713访问SAN 752。

在图7中，VM 712和713以及相关联的SAN 751-752分别位于通过IP网络730被物理地分离的远程站点中。由于VM移动性(例如，VM可以通过连接VM的虚拟网络跨远程站点移动)、远程磁盘访问、磁带备份和实时镜像，物理分离是可能的。类似于图7中的模型，还可以通过IP网络互连多租户FC SAN的孤岛以在单个FC结构中形成统一的SAN。在图7中，想法是，通过以SAN 750上的FC结构750和FC设备不知道其间存在IP网络730的方式承载FC业务来将VM 712和713互连到相关联的SAN 751和752。

在图7中，为了模拟VM 712和713分别直接连接到其SAN 751和752，VM 712和713与SAN控制器722之间的FC链路760的分段需要被虚拟化。这种虚拟化可以如下实现。首先，在运行在IP网络730之上的服务器710和720中的管理程序之间创建MPLS覆盖740。服务器710和720的管理程序分别托管MPLS覆盖终止点717和727，并且MPLS覆盖终止点717和727配置有从IP网络730可路由的唯一IP地址。MPLS覆盖终止点717和727分别经由NIC卡714和723访问IP网络730。其次，每个租户被分配有唯一的MPLS标签(例如，Ten-1被分配有标签100，Ten-2被分配有标签200)。第三，用于Ten-1的VM 712经由虚拟FC端口715(其被映射到MPLS覆盖终止717中的标签100)被连接到MPLS覆盖终止717，并且用于Ten-2的VM 713经由虚拟FC端口716(其被映射到MPLS覆盖终止717中的标签200)被连接到MPLS覆盖终止717。第四，SAN控制器722分别通过用于Ten-1和Ten-2的两个虚拟FC端口725和726被连接到MPLS覆盖终止727。在MPLS覆盖终止727中，FC端口725被映射到标签100，而FC端口726被映射到标签200。

在图7中，VM 712通过虚拟FC端口715向SAN 750发送FC分组。当MPLS覆盖终止717接收到FC分组时，MPLS覆盖终止717推送MPLS标签100作为属于Ten-1的业务的解复用器。然后通过添加IP底层封装，MPLS分组被发送到远程MPLS覆盖终止727。当分组到达MPLS覆盖终止727时，MPLS覆盖终止727弹出IP底层封装以及MPLS标签100，并且将由此引起的FC分组转发给映射到标签100的虚拟FC端口725。SAN控制器722在分配给Ten-1的虚拟FC端口725上接收FC分组，因此控制器经由FC链路760将所需要的FC分组发送到SAN 751。以相同的方式，VM713访问SAN 752。

用于支持可靠MPLS覆盖的各种示例实施例可以在图7的上下文中应用以用于针对SAN中的虚拟化FC支持MPLS覆盖分组的可靠递送(例如，对由NIC进行的或IP网络内的FC分组丢弃具有鲁棒性)。

应当理解，虽然关于图2-7呈现用于可靠MPLS覆盖的使用的特定上下文，但是可靠MPLS覆盖可以用于各种其他类型的上下文。例如，类似于FC，可靠MPLS覆盖可以被用于跨存储系统的Infiband业务的可靠传输。例如，可靠MPLS覆盖可以被用于PCI Express(PCIe)总线的虚拟化以支持PCIe业务的可靠传输。例如，类似于FC，可靠MPLS覆盖可以用于非易失性存储器快速(NVMe)业务的可靠传输以访问固态驱动器上的存储。应当理解，这样的应用可以概括为可以使用可靠MPLS覆盖的DC中的多租户分布式输入输出(I/O)。例如，当租户中的VM池形成服务器集群(例如，网格计算)时，VM通过网络被物理地分离，则集群/网格中的互连可以实现为MPLS覆盖以实现服务器集群业务的可靠传输。通常，可以有多种类型的分布式应用跨越租户的VM，其中应用业务需要通过MPLS覆盖在VM之间可靠地传输。应当理解，可靠MPLS覆盖可以被用在各种其他类型的上下文中。

图8描绘了被配置为支持可靠MPLS覆盖的通信系统的示例实施例。

通信系统800包括一对LSR 810(包括LSR 810-A和LSR 810-B(统称为LSR 810))和被配置为支持LSR 810之间的通信的IP网络824。

LSR 810支持数据链路层813(说明性地，基于LSR 810-A上的数据链路层813-A和LSR 810-B上的数据链路层813-B)、在数据链路层813之上的IP层814(说明性地，基于LSR810-A上的IP层814-A和LSR 810-B上的IP层814-B)、在IP层814之上的可靠传输层815(说明性地，基于LSR 810-A上的可靠传输层815-A和LSR 810-B上的可靠传输层815-B)、以及在可靠传输层815之上的MPLS覆盖816(说明性地，基于LSR 810-A上的MPLS覆盖816-A和LSR810-B上的MPLS覆盖816-B)。LSR 810上的数据链路层813、IP层814、可靠传输层815和MPLS覆盖816可以分别形成在LSR 810上配置的通信协议栈的一部分的所有(例如，基于OSI模型或一个或更多其他合适的协议栈模型)。LSR 810被配置为使用IP之上的可靠传输层来提供可靠MPLS覆盖，从而支持MPLS覆盖分组的可靠递送。

MPLS覆盖816被配置为作为支持MPLS分组在LSR 810之间的可靠递送的可靠MPLS覆盖进行操作。MPLS覆盖816的可靠性基于可靠传输层815。MPLS覆盖816的可靠性基于建立在可靠传输层815处的可靠连接825。可靠传输层815是面向连接的并且保证了MPLS覆盖分组在LSR 810之间的可靠递送(例如，任何MPLS覆盖分组在IP层814的IP底层隧道中在一对源和目的地地址之间的可靠递送)。可靠传输层815还可以支持可靠性特征，诸如流量控制、拥塞控制等，以及其各种组合。可靠传输层815支持在LSR 810之间建立的可靠连接825。可靠连接825被配置为支持MPLS分组在LSR 810之间的可靠递送。即使LSR 810通过IP网络824被分开，可靠连接825也被配置为以可靠方式支持MPLS分组在LSR 810之间的可靠递送，以支持可靠MPLS覆盖816。

可靠传输层815和相关联的可靠连接825可以基于可靠传输协议。可靠传输层815和相关联的可靠连接825可以基于可靠传输协议，诸如TCP、SCTP、QUIC、TLS等。注意，使用TCP作为可靠传输层815(例如，TCP是MPLS分组的“隧道”层)的可靠MPLS覆盖在本文中可以表示为“MPLS-in-TCP”。注意，使用SCTP作为可靠传输层815(例如，SCTP是MPLS分组的“隧道”层)的可靠MPLS覆盖在本文中可以表示为“MPLS-in-SCTP”。注意，使用QUIC作为可靠传输层815(例如，QUIC是MPLS分组的“隧道”层)的可靠MPLS覆盖在本文中可以表示为“MPLS-in-QUIC”。注意，使用TLS作为可靠传输层815(例如，TLS是MPLS分组的“隧道”层，其中TLS运行在实际上提供可靠传输信道的TCP之上)的可靠MPLS覆盖在本文中可以表示为“MPLS-in-TLS”。应当理解，虽然主要关于在可靠传输层815使用特定可靠传输协议来提供可靠连接825进行呈现，但是可以在可靠传输层815使用各种其他可靠传输协议来提供可靠连接825。

应当理解，虽然主要关于支持可靠连接825上的单个MPLS覆盖(说明性地，在MPLS覆盖816之间)进行呈现，但是多个MPLS覆盖可以通过IP网络824在LSR 810之间在可靠连接825和相关联的IP底层隧道上被复用。

各种示例实施例被配置为提供用于可靠MPLS覆盖的操作的框架，该可靠MPLS覆盖使用可靠传输层中的连接进行隧道传输。被设计为隧道传输MPLS覆盖分组的任何可靠传输层都可以被配置为遵循框架的规范。在至少一些示例实施例中，框架可以被配置为实现MPLS-in-TCP。在至少一些示例实施例中，框架可以被配置为实现MPLS-in-SCTP。在至少一些示例实施例中，框架可以被配置为实现MPLS-in-QUIC。在至少一些示例实施例中，框架可以被配置为实现MPLS-in-TLS。应当理解，可以使用各种其他可靠传输协议来提供可靠MPLS覆盖。

应当理解，虽然主要关于使用单个可靠传输层来支持可靠MPLS覆盖进行呈现，但是可靠MPLS覆盖可以利用多个可靠传输层。例如，由于MPLS覆盖可以承载来自多个应用的业务，其中一个或多个应用需要可靠性而一个或多个应用不需要可靠性，因此需要可靠性的一个或多个应用可以使用一个或多个可靠传输层来支持，而不需要可靠性的一个或多个应用可以使用一个或多个其他传输层来支持，这些其他传输层不一定被实现为如本文中呈现的可靠传输层。

应当理解，在可靠MPLS覆盖上发送的应用特定分组可以根据可靠MPLS覆盖的要求或期望而独立于可靠传输层的使用而被适配以提供MPLS覆盖的可靠传输。

应当理解，虽然本文中主要关于提供用于支持可靠MPLS覆盖的数据平面能力来呈现对可靠MPLS覆盖的支持，但是也可以基于各种控制平面能力来支持可靠MPLS覆盖，这些控制平面能力可以被利用以用于支持可靠MPLS覆盖。例如，在使用可靠传输层来提供可靠MPLS覆盖依赖于LSR能够访问与远程LSR的能力有关的某些信息(例如，远程LSR从可靠传输协议报头中解封装MPLS分组的能力的知识、MPLS覆盖终止的知识等、以及其各种组合)的情况下，各种控制平面能力可以被用于在LSR上配置这样的信息(例如，使用关于LSR的信息的手动配置、在LSR之间动态广告或发送信息等，以及其各种组合)。

图9描绘了MPLS覆盖分组的示例实施例，用于说明可靠传输层的(多个)报头在MPLS覆盖分组中的定位。MPLS覆盖分组900包括数据链路报头901、在数据链路报头901下方的IP报头902、在IP报头902下方的可靠传输报头903、在可靠传输报头903下方的可选的MPLS控制报头904、在可选的MPLS控制报头904下方的MPLS标签堆栈905、以及在MPLS标签堆栈905下方的有效载荷906。数据链路报头901是IP网络中的分组的下一跳的数据链路层报头。IP报头902是IP底层的IP报头。可靠传输报头903包括来自可靠传输层的一个或多个报头。MPLS标签堆栈905是MPLS覆盖的MPLS标签堆栈。有效载荷1506是在可靠MPLS覆盖上传输的有效载荷或应用分组。MPLS控制报头(MCH)904是可选的，并且在可靠传输连接是面向流时被包括，即在可靠传输连接可靠地传输字节流时。在这种情况下，接收LSR需要找出接收的字节流中的MPLS覆盖分组。为了在字节流中划分MPLS覆盖分组，当LSR发送MPLS覆盖分组时，它将MCH 904推送到分组中的MPLS标签堆栈905之上。MCH 904至少包括指示MPLS覆盖分组的大小的字段。接收LSR将字节流中的前4个八位字节(字节)解析为MCH 904，并且基于其长度字段来确定MPLS覆盖分组的结束字节。这在图10中示出。

图10描绘了包括MPLS覆盖分组的字节流的解析的示例实施例。字节流被处理为4个八位字节的序列，其中每个字用其第一八位字节的序列号被索引。当LSR从可靠传输连接接收到这个字节流时，它将字0解析为MCH，其中大小字段指示20个八位字节。因此，字4-20构成第一MPLS覆盖分组。然后，字24必须是下一分组的MCH，其中大小字段指示28个八位字节。因此，字28-52构成第二MPLS覆盖分组。然后，字56必须是下一分组的MCH，以此类推。

图11描绘了被配置用于在MPLS覆盖分组上使用以支持可靠MPLS覆盖的MCH的示例实施例。如图11所示，MCH 1100是包括长度字段、标志字段和保留字段的4个八位字节报头。长度字段是一个16位字段，其以八位字节数来表示封装的MPLS覆盖分组的长度。该字段可以容纳大小高达65535B的MPLS覆盖分组。标志字段是一个8位字段，其中每一位指示一个标志。可以理解，可以定义和使用零个或多个标志。如果未使用标志，则发送方将该字段设置为0，接收方忽略该字段。保留字段是8位字段，其可以被用于各种目的。如果该字段未使用，则发送方将该字段设置为0，接收方忽略该字段。在面向流的可靠传输连接上发送分组之前，MCH 1100被推到MPLS覆盖分组之上。应当理解，虽然主要关于字段的特定数目、类型和布置来呈现，但是MCH 1100可以包括各种其他数目、类型或布置的字段(包括可以被设计和使用的各种自定义字段)。

图12描绘了用于新的传输连接的MPLS覆盖初始帧(MOIF)的示例实施例。

MOIF 1200是特殊的帧，当新的传输连接被建立时，该帧可以被往返发送，从发起传输连接的LSR到接收连接请求的LSR并且返回到发起传输连接的LSR。MOIF 1200的使用是可选的。MOIF 1200使得能够传输由两个LSR处的MPLS覆盖层共享的关键参数(如果有)，并且在通过传输连接发送MPLS覆盖业务支持传输连接的健全性(例如，诸如数据完整性和性能测量，诸如延迟、时延等)。注意，如果支持和使用MOIF，则管理员可以在参与连接的LSR中配置MOIF的要求。

MOIF 1200包括MPLS标签字段、序列号字段、确认号字段、时间戳字段、可选参数字段和校验和字段。MPLS标签字段是32个八位字节的字段，其使用被保留以指示该帧是MOIF帧的值被编码。例如，标签值0(或任何其他合适的值)可以被用于指示MOIF帧。被用于指示MOIF帧的特殊值不会被分配用于任何其他目的，诸如用于MPLS覆盖的标签。序列号字段包括由发起MOIF的LSR发出的随机数。确认字段包括由接收MOIF并且将更新后的MOIF发送回发起MOIF的LSR的LSR编码的确认号。例如，接收MOIF并且将更新后的MOIF发送回发起MOIF的LSR的LSR可以将在序列号字段中接收的序列号递增一以提供确认号。时间戳字段包括由发起MOIF的LSR插入的时间戳。时间戳指示发送MOIF的时间。该字段用于测量MOIF的一个或多个参数(例如，往返时间(RTT)、时延等)。可选参数字段是可变长度字段，其可以被用于对各种可选参数进行编码。校验和字段包括MOIF中所有先前字段的校验和。校验和用于验证分组的健全性。

应当理解，虽然主要关于特定数目、类型和布置的字段来呈现，但是MOIF 1200可以包括各种其他数目、类型或布置的字段(包括可以被设计和使用的各种自定义字段)。

图13描绘了由发起路由器使用以配置可靠传输连接的方法的示例实施例。方法1300被配置为由发起可靠传输连接的LSR使用以支持到远程LSR的可靠传输的配置以用于MPLS覆盖分组的隧道传输。注意，如果传输协议被设计为在客户端服务器范例中操作，则方法1300可以由扮演客户端角色的LSR执行(例如，在客户端服务器范例中，客户端发起连接建立请求，服务器侦听传入连接请求并且响应于客户端接受或拒绝连接请求。应当理解，虽然主要呈现为串行执行，但是方法1300的框的至少一部分可以同时或以不同于图13中呈现的顺序执行。方法1300的输入包括：(1)可用于连接的一个或多个远程IP地址(例如，被配置为侦听连接请求的远程LSR的一组IP地址)，以及(2)连接参数，连接参数定义用于连接的一组参数，连接参数例如与延迟/超时、拥塞、有效载荷的分段/重组(MPLS)等相关。在框1301，方法1300开始。框1302在LSR中选择可以用于发送和接收隧道业务的本地IP地址，然后方法1300进行到框1304。框1304确定要用于新的连接的本地标识符，然后方法1300进行到框1306。框1306利用本地标识符从本地IP地址到远程IP地址中的一个远程IP地址建立传输协议连接，以指定该连接将承载MPLS分组，然后方法1300进行到框1308。框1308检查连接是否成功。如果连接成功，则方法1300进行到框1310，否则方法1300进行到框1312。框1312声明配置连接的失败，然后方法1300进行到框1399，在框1399，方法1300结束。框1310对新的连接执行某些后续动作(例如，发起MOIF等)，直到传输连接准备好被MPLS覆盖使用，然后方法1300进行到框1399，在框1399，方法1300结束。在框1399，方法1300结束。

图14描绘了由发起路由器使用以用于支持新的可靠传输连接的后续动作的方法的示例实施例。方法1400可以用于提供图13的方法1300的框1310。应当理解，虽然主要呈现为串行执行，但是方法1400的框的至少一部分可以同时或以不同于图14中呈现的顺序执行。方法1400的输入包括：(1)操作性传输连接(表示为连接)，以及(2)用于操作性传输连接的参数(表示为连接参数)。例如，连接参数可以包括与延迟/超时、拥塞、有效载荷的分段/重组(MPLS)等相关的参数。注意，连接参数可能不适用于某些传输协议类型，因此，在某些情况下，连接参数可以被认为是可选的。在框1401，方法1400开始。框1402检查是否提供有连接参数。如果提供有连接参数，则方法1400进行到框1404，否则方法1400进行到框1406。框1404将输入的连接参数应用于新的连接，然后方法1400进行到框1406。框1406可以基于传输协议类型执行各种其他动作，例如连接的进一步调节，然后方法1400进行到框1408。框1408检查MOIF的要求是否在LSR中被配置。如果MOIF的要求在LSR中被配置，则方法1400进行到框1410，否则方法1400进行到框1499，在框1499，方法1400结束。框1410构建MOIF并且填充必要的字段，然后方法1400进行到框1412。框1412通过传输连接发送MOIF，然后方法1400进行到框1414。框1414等待来自对等LSR的MOIF响应。注意，实现可以等待至少90秒(或任何其他合适的时间长度)以用于MOIF响应。为了等待，LSR可以在其期望MOIF响应的持续时间内启动定时器，并且将定时器与传输连接相关联(尽管可以理解，其他机制是可以预期的)。从框1414，方法1400进行到框1499，在框1499，方法1400结束。在框1499，方法1400结束。

图15描绘了用于由发起路由器使用以用于针对新的可靠传输连接构建MOIF的方法的示例实施例。方法1500可以用于提供图14的方法1400的框1410。应当理解，虽然主要呈现为串行执行，但是方法1500的框的至少一部分可以同时或以不同于图15中呈现的顺序执行。在框1501，方法1500开始。框1502创建空的MOIF，这意味着，MOIF的所有字段都归零，然后方法1500进行到框1504。框1504将MPLS标签的值设置为指示分组是MOIF分组的特殊值，将S位设置为1(因为没有更多标签跟随)，并且根据实现的选择来设置EXP和TTL值。方法1500然后进行到框1506。框1506将序列号字段设置为随机值，然后方法1500进行到框1508。框1508将时间戳字段设置为LSR中的当前时间，然后方法1500进行到框1510。框1510填充可选参数(如果有)(该框是特定于实现的)，然后方法1500进行到框1512。框1512计算MOIF中所有先前字段的校验和，并且将结果填充到校验和字段中，然后方法1500进行到框1599。在框1599，方法1500结束。

图16描绘了当在预定义时间段内未接收到MOIF响应时由发起路由器使用的方法的示例实施例。方法1600可以被用于提供图14的方法1400的框1414。应当理解，虽然主要呈现为串行执行，但是方法1600的框的至少一部分可以同时或以不同于图16中呈现的顺序执行。方法1600的输入包括关于MOIF等待定时器到期的通知。在框1601处，方法1600开始。框1602检索与定时器相关联的传输连接，然后方法1600进行到框1604。框1604关闭传输连接，然后方法1600进行到框1699。在框1699处，方法1600结束。

图17描绘了用于由发起路由器使用以处理MOIF响应的方法的示例实施例。应当理解，虽然主要呈现为串行执行，但是方法1700的框的至少一部分可以同时或以不同于图17中呈现的顺序执行。方法1700的输入包括MOIF分组。注意，接收的分组是MOIF分组的确定可以作为传送连接上MPLS覆盖分组的通用处理的一部分来进行(例如，如关于图25的方法2500的框2502-2514所呈现的)。在框1701处，方法1700开始。框1702检查LSR是否已经在等待来自对等LSR的MOIF响应(例如，MOIF等待定时器是否正在运行)。如果LSR已经在等待来自对等LSR的MOIF响应，则方法1700进行到框1704，否则方法1700进行到框1718以作为无效分组进行处理。框1718关闭传输连接。框1704停止MOIF等待定时器，然后方法1700进行到框1706。框1706计算MOIF分组中除校验和字段之外的所有字段的校验和，然后方法1700进行到框1708。框1708检查计算的校验和是否等于分组中的校验和字段的值。如果计算的校验和等于分组中的校验和字段的值，则方法1700进行到框1710，否则方法1700进行到框1718以处理错误的MOIF分组。框1718关闭传输连接。框1710检查MOIF分组中的确认号字段中的值是否等于序列号字段中的值加1。如果MOIF分组中的确认号字段中的值等于序列号字段中的值加1，则方法1700进行到框1718以处理错误的MOIF分组，否则方法1700进行到框1712。框1718关闭传送连接。框1712通过从LSR中的当前时间戳递减MOIF分组中的时间戳字段中的值来计算MOIF分组的RTT。RTT提供有关通往远程LSR的隧道的时延的概念。从框1712，方法1700进行到框1714。框1714处理MOIF分组中的可选参数(如果有)，然后方法1700进行到框1716。框1716将连接标记为准备好隧道传输MPLS覆盖业务，然后方法1700进行到框1799，在那里方法1700结束。在框1700处，方法1700结束。

图18描绘了用于由接收路由器使用以用于配置可靠传输连接侦听器的方法的示例实施例。注意，LSR可以配置可靠传输层来侦听对要用于MPLS覆盖的传入连接的请求。注意，这可以由配置MPLS覆盖的任何LSR使用。应当理解，虽然主要呈现为串行执行，但是方法1800的框的至少一部分可以同时或以不同于图18中呈现的顺序执行。在框1801处，方法1800开始。框1802配置具有隧道传输MPLS覆盖的能力的传输层，然后方法1800进行到框1804。框1804开始侦听对本地IP地址池中的任何IP地址的传入连接请求(例如，以管理方式挑选)。在框1899处，方法1800结束。

图19描绘了用于由接收路由器使用以用于处理对传输层连接的传入请求的方法的示例实施例。应当理解，虽然主要呈现为串行执行，但是方法1900的框的至少一部分可以同时或以不同于图19中呈现的顺序执行。方法1900的输入包括具有以下参数的连接请求：(1)源IP地址(发送请求的远程LSR的IP地址)，(2)目的地IP地址(LSR的本地IP地址),(3)连接参数(连接请求中的传输协议特定参数)。在框1901处，方法1900开始。框1902评估连接参数以检查连接是否可以被允许。如果连接不能被允许，则方法1900进行到框1912，否则方法1900进行到框1904。框1912在传输层中使用适当方法拒绝连接(例如，传输协议中根据方法到远程LSR的拒绝通知)，然后方法1900进行到框1999，在框1999处，方法1900结束。框1904检查连接参数是否指示用户为MPLS。如果连接参数没有将用户指示为MPLS，则方法1900进行到框1914，否则方法1900进行到框1906。框1914按照相关联的用户来处理连接请求，然后方法1900进行到框1999，在那里方法1900结束。框1906检查来自远程LSR(即，来自源IP地址)的连接是否被允许。注意，有多种因素决定LSR是否应允许传入连接。例如，LSR可以采用一种方法来发现可以参与与LSR的MPLS覆盖的所有潜在远程LSR。如果不允许来自远程LSR的连接，则方法1900进行到框1912，否则，方法1900进行到框1908。框1912在传输层中使用适当方法拒绝连接(例如，传输协议中根据方法到远程LSR的拒绝通知)，然后方法1900进行到框1999，在框1999处，方法1900结束。框1908接受连接请求(这意味着，连接的状态是基于传输层的语义而被创建的，传输层可以使用连接参数中的某些元素，也可以包括源和目的地IP地址)，然后方法1900进行到框1910。框1910对新的连接执行某些后续动作，然后方法1900进行到框1999，在那里方法1900结束。

图20描绘了用于由接收路由器使用以用于针对新的可靠传输连接执行连接后跟进的方法的示例实施例。注意，方法2000可以由接收对可靠传输连接的连接请求的LSR执行。应当理解，虽然主要呈现为串行执行，但是方法2000的框的至少一部分可以同时或以不同于图20中呈现的顺序执行。在框2001，方法2000开始。框2002检查LSR是否需要MOIF。如果LSR需要MOIF，则方法2000进行到框2004，否则方法2000进行到框2099，在框2099处，方法2000结束。框2004等待来自对等LSR的MOIF。应当理解，LSR可以等待MOIF达任何合适的时间量(例如，90秒或任何其他合适的时间量)。应当理解，LSR可以使用各种机制来控制等待MOIF(例如，LSR可以在其期望MOIF响应的持续时间内启动定时器，并且将定时器与传输连接相关联)。从框2004，方法2000进行到框2099，在框2099，方法2000结束。如果LSR未能在预定义时间段内接收到MOIF(例如，在框2004处设置的超时到期)，则LSR执行图16的方法1600(因此，处理在发起和接收LSR两者中是常见的)。在框2099处，方法2000结束。

图21描绘了用于由接收路由器使用以用于在等待MOIF响应的同时处理MOIF的方法的示例实施例。注意，方法2100可以在图20的方法2000的框2004中LSR等待响应时使用。应当理解，虽然主要呈现为串行执行，但是方法2100的框的至少一部分可以同时或以不同于图21中呈现的顺序执行。方法1700的输入包括MOIF分组。注意，接收的分组是MOIF分组的确定可以作为传输连接上MPLS覆盖分组的通用处理的一部分来进行(例如，如关于图25的方法2500的框2502-2514所呈现的)。在框2101处，方法2100开始。框2102检查LSR是否已经在等待来自对等LSR的MOIF响应(例如，检查MOIF等待定时器是否正在运行)。如果LSR已经在等待来自对等LSR的MOIF响应，则方法2100进行到框2104，否则方法2100进行到框2120以将该分组作为无效分组进行处理。框2120关闭传输连接。框2104停止MOIF等待定时器，然后方法2100进行到框2106。框2106计算MOIF分组中除校验和字段之外的所有字段的校验和，然后方法2100进行到框2108。框2108检查计算出的校验和是否等于分组中的校验和字段的值。如果计算出的校验和等于分组中的校验和字段中的值，则方法2100进行到框2110，否则方法2100进行到框2120以处理错误的MOIF分组。框2120关闭传输连接。框2110将MOIF分组中的确认号字段中的值设置为等于序列号字段中的值加1，然后方法2100进行到框2112。框2112处理MOIF分组中的可选参数(如果有)，然后方法2100进行到框2114。框2114计算MOIF中所有先前字段的校验和，并且将结果更新到校验和字段中，然后方法2100进行到框2116。框2116将更新的MOIF分组发送回对等LSR，然后方法2100进行到框2118。框2118将连接标记为准备好隧道传输MPLS覆盖业务，然后方法2100进行到框2199，在那里方法2100结束。

图22描绘了用于配置可靠MPLS覆盖的方法的示例实施例。注意，LSR可以使用方法2200来建立通往远程LSR的可靠MPLS覆盖。应当理解，虽然主要呈现为串行执行，但是方法2200的框的至少一部分可以同时或以不同于图22中呈现的顺序执行。方法2200的输入包括：(1)LSP(MPLS覆盖)的传出MPLS标签，(2)LSP的远程LSR中的IP地址，以及(3)传输参数，其定义LSP要求的隧道的一组参数(例如，与延迟/超时、拥塞、分段和重组等相关)。在框2201处，方法2200开始。框2202检查是否存在与远程LSR的可靠传输连接(例如，由其他MPLS覆盖使用)。如果不存在与远程LSR的现有可靠传输连接，则方法2200进行到框2214，否则方法2200进行到框2204。框2204获取与远程LSR的第一可靠传输连接(例如，由其他MPLS覆盖使用)，然后方法2200进行到框2206。框2206将输入传输参数转换为在连接中配置的等效项，然后方法2200进行到框2208。框2208检查由覆盖请求的参数是否与连接的参数匹配。如果由覆盖请求的参数与连接的参数匹配，则方法2200进行到框2224，否则方法2200进行到框2210。框2210针对MPLS覆盖检查是否有更多与远程LSR的现有可靠传输连接。如果有更多连接，则方法2200进行到框2212，否则方法2200进行到框2214。框2212获取与远程LSR的下一可靠传输连接，然后返回到框2206以针对下一连接重复后续框。当需要新的传输连接时到达的框2214确定要使用的可靠传输层类型。例如，如果LSR支持支持MPLS覆盖的多种类型的可靠传输层，则可以在多种类型的可靠传输层之间进行挑选。注意，可以评估各种因素以在多种类型的可靠传输层之间进行选择。从框2214，方法2200进行到框2216。框2216将传输参数(输入)转换为挑选的传输层的语义(即，连接参数)，然后方法2200进行到框2218。框2218针对MPLS覆盖配置与远程LSR的新的可靠传输连接。传输连接是使用连接参数配置的。框2218可以通过图16的方法1600来实现。从框2218，方法2200进行到框2220。框2220检查连接是否已经成功建立。如果连接尚未成功建立，则方法2200进行到框2222，否则方法2200进行到框2222。框2222声明并且处理配置MPLS覆盖的失败。框2224分配LSP标识符以在LSR中唯一地标识MPLS覆盖。LSP标识符绑定传输连接、(多个)传出标签和与MPLS覆盖相关联的其他参数。从框2224，方法2200然后进行到框2226。框2226将LSP的传出MPLS标签设置为LSP标识符的传出标签，然后方法2200进行到框2228。框2228将传输连接设置为与LSP标识符相关联的隧道，然后方法2200进行到框2299，在那里方法2200结束。在框2299处，方法2200结束。

图23描绘了用于在可靠MPLS覆盖上传输分组的方法的示例实施例。注意，方法2300可以由LSR执行以在可靠MPLS覆盖上传输分组。应当理解，虽然主要呈现为串行执行，但是方法2300的框的至少一部分可以同时或以不同于图23中呈现的顺序执行。方法2300的输入包括：(1)要传输的分组(例如，如图6的示例中的FC分组、ICC或交换结构分组等)，以及(2)标识LSP或覆盖的LSP标识符。在框2301处，方法2300开始。框2302通过LSP标识符来检索LSP的传出标签的状态，方法2300进行到框2304。框2304获取为传出标签而配置的隧道，即，可靠传输层连接，然后方法2300进行到框2306。框2306将LSP的传出标签推送到分组上，然后方法2300进行到框2308。框2308针对分组根据需要设置推送标签中的S位、EXP和TTL字段。例如，如果分组在推送LSP的传出标签之前已经有另一标签，则S位设置为0，否则S位设置为1。TTL和EXP值可以由为LSP而配置的策略来设置。例如，如果策略要求对LSP上的所有分组使用一致的EXP值，则设置配置的EXP值。如果策略具有基于分组的本机报头中的某些字段的EXP值的映射，则设置映射的EXP值。从框2308，方法2300进行到框2310。框2310确定在将传输报头推送到分组上时要由连接使用的动态参数。注意，这样的动态参数可以是传输报头中的熵相关字段，IP网络中的中转路由器可以使用这些字段来计算ECMP上的负载平衡分组的散列值。从框2310，方法2300进行到框2312。框2312在连接上发送MPLS分组、以及传输报头的动态参数。从框2312，方法2300进行到框2399，在那里方法2300结束。在框2399处，方法2300结束。

图24描绘了用于通过可靠传输连接来传输MPLS分组的方法的示例实施例。注意，方法2400可以用于实现图23的方法2300的框2312。应当理解，虽然主要呈现为串行执行，但是方法2400的框的至少一部分可以同时或以不同于图24中呈现的顺序执行。方法2400的输入包括：(1)要传输的MPLS分组，以及(2)(多个)传输层报头的动态参数。在框2401处，方法2400开始。框2402调节MPLS分组，这意味着，可靠传输层根据连接状态来准备分组(例如，如果分组需要进一步分段，则将分组分段成多个分段、根据需要对分段应用拥塞控制和/或流量控制等、以及其各种组合)。从框2402，方法2400进行到框2404。框2404检查分组的一个或多个分段是否准备好要被发送。例如，由于拥塞、流量控制等，可能不发送分段。如果分段没有准备好要被发送，则分段将在稍后拥塞被清除时被发送，然后方法2400进行到框2499，在框2499处，方法2400结束。如果分段准备好要被发送，则方法2400进行到框2406。框2406推送传输层的一个或多个报头。报头中的字段根据连接参数被填充，例如指示有效载荷类型为MPLS的字段和连接的标识符。根据需要，动态参数(输入)被填充到(多个)报头中。方法2400然后进行到框2408。框2408将IP报头推送到分组上。根据传输层连接的本地和远程IP地址，IP报头中的源地址和目的地地址被填充。协议字段(如果是IPv4报头)或下一报头字段(如果是IPv6报头)被设置以指示传输层类型。方法2400然后进行到框2410。框2410执行路由查找以获取IP报头中的目的地地址，这导致针对分组的下一跳，然后方法2400进行到框2412。框2412将数据链路层报头推送到分组上，这是在链路上将分组发送到下一跳所必需的。方法2400然后进行到框2414。框2414将分组发送到下一跳，然后方法2400进行到框2499，在那里方法2400结束。

图25描绘了用于处理在可靠MPLS覆盖上接收的分组的方法的示例实施例。注意，方法2500可以用于实现图23的方法2300的框2312。应当理解，虽然主要呈现为串行执行，但是方法2500的框的至少一部分可以同时或以不同于图25中呈现的顺序执行。方法2500的输入包括：(1)连接上的传输层分组(例如，由LSR的传输层接收，在顶部具有(多个)传输层特定报头)，以及(2)连接。在框2501，方法2500开始。框2502检查MPLS是否是连接的用户应用。如果MPLS不是连接的用户应用，则方法2500进行到框2524，否则方法2500进行到框2504。框2524处理非MPLS应用的传输层分组。框2504按照传输协议的规范来对传输层分组执行传输层处理，然后方法2500进行到框2506。框2506检查传输协议是否是面向流的。在面向流的协议中，整个MPLS分组的字节可能不会在传输层分组中一起到达(即，分组的块可以在多个传输分组上到达)，否则传输协议可以是面向数据报的，使得传输层分组承载整个MPLS分组。当针对特定传输协议实现方法2500时，则可能不需要框2506，因为协议是面向流的还是面向数据报的是协议固有的。如果框2506中的检查结果确定传输协议是面向流的，则方法2500进行到框2508，否则方法2500进行到框2514。框2508将接收的流的前4个八位字节解析为MCH，然后方法2500进行到框2510。框2510检查接收的流是否至少具有在MCH中的长度字段中指定的数目的八位字节，即，至少具有整个下一MPLS分组。如果流不具有整个分组，则方法2500进行到框2599，在框2599处，方法2500结束，否则方法2500进行到框2512。框2512从接收的流中提取在MCH的长度字段中指定的数目的八位字节加上构成由MCH封装的MPLS分组的4个八位字节，然后移除MCH以生成MPLS分组，然后方法2500进行到框2514。框2514检查MPLS分组是否是MOIF。如果MPLS分组是MOIF，则方法2500进行到框2516，否则方法2500进行到框2518。框2516处理MOIF分组。如果LSR是连接的发起者，则框2516可以通过图17的方法1700实现，否则框2516可以通过图21的方法2100实现。从框2516，方法2500进行到框2520。框2518将分组作为MPLS分组进行处置，然后方法2500进行到框2520。框2520检查传输协议是否是面向连接的。该检查类似于框2506。如果传输协议是面向连接的，则方法2500进行到框2522，否则方法2500进行到框2599，在框2599，方法2500结束(因为整个MPLS分组被处理)。框2522检查在传输层协议的有效载荷中是否还有更多字节待处理。如果传输层协议的有效载荷中有更多字节待处理，则方法2500返回到框2508以处理下一MPLS分组(如果有)。如果传输层协议的有效载荷中没有更多字节待处理，则该方法进行到框2599，在那里方法2500结束。

各种示例实施例被配置为使用TCP作为用于MPLS覆盖分组的隧道传输的可靠传输层。这提供了作为MPLS-in-TCP的可靠MPLS覆盖的实现。

图26描绘了用于将可靠MPLS覆盖实现为MPLS-in-TCP的MPLS-in-TCP封装格式的示例实施例。MPLS-in-TCP封装格式2600包括有效载荷、在有效载荷之上的MPLS标签堆栈、在MPLS标签堆栈之上的MCH、在MCH之上的TCP报头、在TCP报头之上的IP报头和在IP报头之上的数据链路报头。TCP报头(即，由MPLS覆盖用作隧道的TCP连接的TCP报头)包括许多字段(至少一些字段将在下面进一步讨论)。

TCP报头包括源端口字段，该源端口字段包括TCP连接的本地标识符。

TCP报头包括目的地端口字段，该目的地端口字段包括新的端口号以指示TCP隧道有效载荷是MPLS分组。例如，值6637可以用于指示TCP隧道的有效载荷为MPLS分组。注意，如果在IETF中标准化，则该值可以保留在由IANA维护的TCP端口号注册表中。注意，实现可以使用任何未使用的备选端口号来将有效载荷指示为MPLS分组。例如，TCP中的端口号可以跨参与MPLS覆盖的LSR以管理方式而被配置，以将有效载荷指示为MPLS分组。

TCP报头包括各种其他字段，这些字段将根据TCP连接的配置和动态参数进行设置。

注意，由于TCP是面向流的协议，MPLS分组(即，有效载荷和MPLS标签堆栈)由MCH封装。

图27描绘了用于针对MPLS-in-TCP配置TCP连接的方法的示例实施例。方法2700可以基于图13中呈现的通用方法1300。应当理解，虽然主要呈现为串行执行，但是方法2700的框的至少一部分可以同时或以不同于图27中呈现的顺序执行。方法2700的输入包括：(1)远程LSR的IP地址，以及(2)TCP连接参数。注意，当LSR发现新的TCP需要被建立连接以隧道传输MPLS覆盖分组时，LSR会确定要与其建立TCP连接的远程LSR的IP地址，并且确定关于新的TCP连接以下信息(例如，TCP连接参数、QoS信息，等等)。在框2701处，方法2700开始。框2702选择可以用于发送和接收隧道业务的配置的本地IP地址，然后方法2700进行到框2704。框2704分配要用于新的连接的本地TCP端口号，使得该号码当前未被现有TCP连接使用，然后方法2700进行到框2706。框2706将本地TCP端口绑定到MPLS作为其有效载荷/应用，然后方法2700进行到框2708。框2708生成从本地IP地址处的本地端口到远程IP地址处的端口号MPLS(例如，6637)的TCP连接请求。如果TCP连接请求被拒绝，则LSR应当采取行动以限制用于建立连接的不必要的重复尝试。例如，LSR可以在尝试重新建立连接之前等待60秒。从框2708，方法2700进行到框2710。框2710检查远程LSR是否接受TCP连接请求(即，成功)。如果远程LSR接受TCP连接请求，则方法2700进行到框2712，否则方法2700进行到框2714。框2714声明配置连接的失败，然后方法2700进行到框2799，在框2799处，方法2700结束。框2712执行连接后跟进。注意，框2712可以通过图28中的方法来实现，该方法是基于图14中定义的框架。从框2712，方法2700进行到框2799，在那里方法2700结束。在框2799处，方法2700结束。

图28描绘了用于针对MPLS-in-TCP的TCP连接执行连接后跟进的方法的示例实施例。注意，方法2800可以由发起TCP连接的LSR执行。方法2800可以用于提供图27的方法2700的框2712。方法2800可以基于图14中定义的框架。应当理解，虽然主要呈现为串行执行，但是方法2800的框的至少一部分可以同时或以不同于图28中呈现的顺序执行。方法2800的输入包括：(1)操作性TCP连接，以及(2)针对TCP连接的TCP连接参数。在框2801处，方法2800开始。框2802将输入的TCP连接参数应用于新的连接，然后方法2800进行到框2804。框2804检查MOIF的要求是否在LSR中被配置。如果MOIF的要求在LSR中被配置，则方法2800进行到框2806，否则方法2800进行到框2899，在框2899处，方法2800结束。框2806构建MOIF并且填充必要的字段。注意，框2806可以通过图15的方法1500来实现。从框2806，方法2800进行到框2808。框2808通过TCP连接发送MOIF，然后方法2800进行到框2810。框2810等待来自对等LSR的MOIF响应。注意，实现可以等待至少90秒(或任何其他合适的时间长度)以用于MOIF响应。为了等待，LSR可以在其期望MOIF响应的持续时间内启动定时器，并且将定时器与传输连接相关联(尽管可以理解，其他机制是可以预期的)。从框2810，方法2800进行到框2899，在框2899处，方法2800结束。在框2899处，方法2800结束。

图29描绘了用于当在针对TCP连接的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例。注意，发起LSR在预定义时间段内未能接收到MOIF响应的情况可以被确定，其中在图28的框2810处设置的超时在MOIF响应没有被接收的情况下到期。应当注意，在TCP连接上接收的分组是MOIF响应的确定可以作为图36的通用处理的一部分来执行。注意，当发起LSR从对等LSR接收到MOIF响应时，发起LSR可以执行图17的方法1700。应当理解，虽然主要呈现为串行执行，但是方法2900的框的至少一部分可以同时或以不同于图29中呈现的顺序执行。方法2900的输入包括关于MOIF等待定时器到期的通知。在框2901处，方法2900开始。框2902检索与定时器相关联的TCP连接，然后方法2900进行到框2904。框2904关闭TCP连接，然后方法2900进行到框2999。在框2999处，方法2900结束。

图30描绘了用于配置TCP连接侦听器的方法的示例实施例。注意，LSR可以使用方法3000来侦听针对MPLS-in-TCP的TCP连接请求(例如，侦听针对作为用户协议的MPLS的新的TCP连接请求)。注意，MPLS-in-TCP连接侦听器可以由配置MPLS覆盖的任何LSR实现。方法3000可以基于图18中呈现的通用方法1800。应当理解，虽然主要呈现为串行执行，但是方法3000的框的至少一部分可以同时或以不同于图30中呈现的顺序执行。在框3001处，方法3000开始。框3002打开用于MPLS的TCP端口(例如，6637)，然后方法3000进行到框3004。框3004将该端口绑定到LSR中的本地IP地址，然后开始在该地址上侦听端口的传入连接请求。从框3004，方法3000进行到框3099，在那里方法3000结束。在框3099处，方法3000结束。

图31描绘了用于处理传入TCP连接请求的方法的示例实施例。注意，传入连接请求可以在MPLS的TCP端口上被接收。方法3100可以基于图19中呈现的通用方法1900。应当理解，虽然主要呈现为串行执行，但是方法3100的框的至少一部分可以同时或以不同于图31中呈现的顺序执行。方法3100的输入包括具有以下关联参数的连接请求：(1)源IP地址，其是发送连接请求的远程LSR的IP地址，(2)目的地IP地址，其是本地连接请求被发送到的该LSR的IP地址，(3)源端口，其是远程LSR处的TCP端口，以及(4)目的地端口，其是连接请求被发送到的该LSR的TCP端口。在框3101处，方法3100开始。框3102检查目的地端口是否在LSR中的TCP中打开。如果目的地端口没有打开，则方法3100进行到框3112，否则方法3100进行到框3104。框3112使用适当的TCP机制拒绝连接(例如，TCP中根据方法到远程LSR的拒绝通知)。从框3112，方法3100进行到框3199，在框3199处，方法3100结束。框3104检查TCP目的地端口是否是MPLS(例如，6637)。如果TCP目的地端口不是MPLS，则方法3100进行到框3114，否则方法3100进行到框3106。框3114根据与端口关联的类型来处理连接请求，然后方法3100进行到框3199，在框3199处，方法3100结束。框3106检查来自远程LSR(例如，来自源IP地址)的连接是否被允许。应当理解，可以使用各种因素来确定LSR是否应当允许传入连接。例如，LSR可以采用一种方法来发现可以参与与LSR的MPLS覆盖的所有潜在远程LSR。如果来自远程LSR的连接不被允许，则方法3100进行到框3112，否则方法3100进行到框3108。框3112使用适当的TCP机制拒绝连接(例如，TCP中根据方法到远程LSR的拒绝通知)。从框3112，方法3100进行到框3199，在框3199处，方法3100结束。框3108接受TCP连接请求，这意味着，TCP连接的状态是以元组{源IP地址，目的地IP地址，源端口，目的地端口}为关键字而被创建的，方法3100然后进行到框3110。框3110执行连接后跟进，然后方法3100进行到框3199，在框3199处，方法3100结束。注意，框3110可以通过图20的方法2000而被实现，如果被配置为接收MOIF，则使LSR等待来自对等LSR的MOIF。注意，在连接上接收的分组是MOIF的确定是作为TCP连接上的MPLS覆盖分组的通用处理的一部分来进行的(例如，使用图36的方法3600的框3602-3612)。注意，如果LSR在预定义时间段内未能接收到MOIF(例如，在图20中的框2004处设置的超时到期)，则LSR可以执行图29的方法2900(即，处置在发起和接收LSR两者中是常见的)。注意，当从对等LSR接收到MOIF时，则LSR可以执行图21的方法2100。

应当理解，虽然主要针对其中LSR通过使用MPLS的公知TCP端口(例如，6637或其他合适的端口)侦听新的TCP连接请求来接受和建立TCP连接的示例实施例来呈现，但是LSR还可以接受并且建立与MPLS的公知TCP端口之外的其他TCP端口号(例如，网络管理员为MPLS而配置的端口号)的TCP连接。

注意，可以支持同时建立TCP连接。如果两个对等LSR同时向对方发送TCP连接请求，则形成两个TCP连接。在此，连接建立在两个连接上进行，从而导致在LSR之间形成两个TCP隧道。

图32A-32B描绘了用于在TCP连接上配置MPLS覆盖以形成MPLS-in-TCP覆盖的方法的示例实施例。注意，当LSR准备与远程LSR建立MPLS-in-TCP覆盖时，它确定要与其建立TCP连接的远程LSR的IP地址，然后确定TCP连接参数和TCP连接的QoS信息。方法3200可以基于图22中呈现的通用方法2200。应当理解，虽然主要呈现为串行执行，但是方法3200的框的至少一部分可以同时或以不同于图32中呈现的顺序执行。方法3200的输入包括LSP/覆盖的传出MPLS标签、LSP/覆盖的远程LSR的IP地址、以及覆盖所需要的TCP连接参数。在框3201处，方法3200开始。框3202检查是否存在针对MPLS覆盖而建立的与远程LSR的现有TCP连接。如果没有针对MPLS覆盖而建立的与远程LSR的现有TCP连接，则方法3200进行到框3214，否则方法3200进行到框3204。框3204获取与远程LSR的TCP连接，该连接是针对MPLS覆盖而被建立的，然后方法3200进行到框3206。框3206检索TCP连接的TCP连接参数，然后方法3200进行到框3208。框3208检查由覆盖请求的参数是否与TCP连接的TCP连接参数匹配。如果由覆盖请求的参数与TCP连接的参数匹配，则方法3200进行到框3218，否则方法3200进行到框3210。框3210针对MPLS覆盖检查是否有更多与远程LSR的现有TCP连接。如果有更多TCP连接，则方法3200进行到框3212，否则方法3200进行到框3214。框3212获取已经针对MPLS覆盖而被建立的与远程LSR的下一TCP连接，然后方法3200返回到框3206以针对下一TCP连接重复后续框。当新的TCP连接被需要时，框3214到达。框3214针对MPLS覆盖配置与远程LSR的新的TCP连接。TCP连接是使用输入的TCP连接参数配置的。框3214通过图27中的方法实现。然后方法进行到框3216。框3216检查TCP连接是否成功建立。如果TCP连接尚未成功建立，则方法3200进行到框3224，否则方法3200进行到框3218。框3224声明并且处理配置MPLS覆盖的失败。框3218分配LSP标识符以在LSR中唯一地标识MPLS覆盖。LSP标识符绑定TCP连接、(多个)传出标签、以及与MPLS覆盖相关联的其他参数。从框3218，方法3200进行到框3220。框3220将LSP/覆盖的传出MPLS标签设置为LSP标识符的传出标签，然后方法3200进行到框3222。框3222将TCP连接设置为与LSP标识符相关联的隧道，然后方法3200进行到框3299，在那里方法3200结束。在框3299处，方法3200结束。

图33描绘了用于在MPLS-in-TCP上传输分组的方法的示例实施例。方法3300可以基于图23中呈现的通用方法2300(不同之处在于，框2310可以不被实现，因为MPLS-in-TCP分组中没有TCP报头的动态参数)。应当理解，虽然主要呈现为串行执行，但是方法3300的框的至少一部分可以同时或以不同于图33中呈现的顺序执行。方法3300的输入包括要被传输的分组和标识LSP或MPLS覆盖的LSP标识符。在框3301处，方法3300开始。框3302通过LSP标识符来检索LSP的传出标签的状态，方法3300进行到框3304。框3304获取为LSP标识符而配置的TCP隧道，即，可靠传输层连接，方法3300然后进行到框3306。框3306将LSP的传出标签推送到分组上，然后方法3300进行到框3308。框3308针对分组根据需要设置推送标签中的S位、EXP和TTL字段。例如，如果分组在推送LSP的传出标签之前已经有另一标签，则S位设置为0，否则S位设置为1。TTL和EXP值可以由为LSP而配置的策略来设置。例如，如果策略要求对LSP上的所有分组使用一致的EXP值，则设置配置的EXP值。如果策略具有基于分组的本机报头中的某些字段的EXP值的映射，则设置映射的EXP值。从框3308，方法3300进行到框3310。框3310在TCP连接上发送MPLS分组。在框3310之后，该方法终止。

图34描绘了用于在TCP连接上传输MPLS分组的方法的示例实施例。方法3400可以被用于提供图33的方法3300的框3310，并且可以基于图24中呈现的通用方法2400(不同之处在于，TCP报头没有动态参数)。应当理解，虽然主要呈现为串行执行，但是方法3400的框的至少一部分可以同时或以不同于图34中呈现的顺序执行。方法3400的输入包括要被传输的MPLS分组。在框3401处，方法3400开始。框3402调节MPLS分组，这意味着，TCP层根据连接状态来准备分组(例如，如果分组需要进一步分段，则将分组分段成多个分段、根据需要对分段应用拥塞控制和/或流量控制等、以及其各种组合)。从框3402，方法3400进行到框3404。框3404检查分组的一个或多个TCP分段是否准备好要被发送。例如，由于拥塞、流量控制等，TCP分段可能没有准备好要被发送。如果TCP分段没有准备好要被发送，则TCP分段将在稍后拥塞被清除时被发送，然后方法3400进行到框3499，在框3499处，方法3400结束。如果TCP分段准备好要被发送，则方法3400进行到框3406。框3406将TCP报头推送到(多个)分段。TCP报头中的源端口和目的地端口字段根据连接参数被填充。从框3406，方法3400然后进行到框3408。框3408将IP报头推送到分组上。IP报头中的源地址和目的地地址根据TCP连接的本地和远程IP地址被填充(地址由框3406提供)。协议字段(如果是IPv4报头)或下一报头字段(如果是IPv6报头)被设置为一个值(例如，6或其他合适的值)以将有效载荷指示为TCP。从框3408，方法3400进行到框3410。框3410对IP报头中的目的地地址执行IP路由表查找，这导致分组的下一跳，然后方法3410进行到框3412。框3412将数据链路层报头推送到分组上，这是在链路上将分组发送到下一跳所需要的，然后方法3400进行到框3414。框3414在线路上将分组发送到下一跳，然后方法3400进行到框3499，在那里方法3400结束。

图35描绘了用于接收和处理MPLS-in-TCP分组的方法的示例实施例。应当理解，虽然主要呈现为串行执行，但是方法3500的框的至少一部分可以同时或以不同于图35中呈现的顺序执行。方法3500的输入包括在线路上接收的MPLS-in-TCP分组。

在框3501，方法3500开始。

框3502解析并且处理在分组之上的数据链路报头，然后方法3500进行到框3504。

框3504检查数据链路层是否指示分组是本地的，这意味着，执行方法3500的该LSR是分组在其上到达的数据链路的终止点。例如，如果数据链路报头是以太网报头，并且如果以太网报头中的目的地MAC地址是LSR本地的，则以太网链路终止于LSR。如果分组在数据链路层是本地的，则方法3500进行到框3506，否则方法3500进行到框3524。框3524在数据链路层作为非本地分组来执行分组的所需要的处理，这可以导致在数据链路层处进一步转发分组，然后方法3500进行到框3599，在框3599处，方法3500结束。

当LSR是数据链路的末端时，框3506从分组中移除数据链路报头，然后方法3500进行到框3508。框3508检查由数据链路报头指示的有效载荷是否是IP。例如，如果数据链路报头是以太网报头，则其Ethertype字段指示有效载荷类型。如果以太网报头有VLAN标签，则最后的VLAN标签中的Ethertype字段指示有效载荷类型。如果有效载荷是IP，则方法3500进行到框3510，否则方法3500进行到框3526。框3526将分组作为非IP分组进行处置，然后方法3500进行到框3599，在那里方法3500结束。

框3510基于其IP报头在IP层中处理IP分组。例如，在IP路由表中查找IP报头的目的地地址，以对IP分组做出转发决策。从框3510，方法3500进行到框3512。框3512检查目的地地址是否是本地的(例如，IP路由表查找是否与作为LSR中本地配置的IP地址的目的地地址匹配)。如果目的地地址不是本地的，则方法3500进行到框3528，否则方法3500进行到框3514。框3528将分组作为非本地IP分组进行处理，诸如通过将分组转发到与来自IP路由表查找的匹配路由条目相关联的下一跳，然后方法3500进行到框3599，在框3599处，方法3500结束。

框3514从IP分组中移除IP报头，因为它是本地分组，然后方法3500进行到框3516。框3516检查分组是否是TCP分段(例如，如果IP报头是IPv4，则检查IPv4报头中的协议字段是否描设置为6(TCP)，或者如果IP报头是IPv6，则检查IPv6报头中的下一报头字段是否设置为6(TCP))。如果分组不是TCP分段，则方法3500进行到框3530，否则方法3500进行到框3518。框3530处置相应IP协议类型的分组，然后方法3500进行到框3599，在那里方法3500结束。

框3518基于IP报头中的源和目的地IP地址(例如，地址在框3514中IP报头移除之后沿流被传递)并且基于TCP报头中的源和目的地端口来查找与TCP分段相关联的TCP连接。从框3518，方法3500进行到框3520。框3520检查是否找到匹配的TCP连接。如果没有找到匹配的TCP连接，则方法3500进行到框3532，否则方法3500进行到框3522。框3532将分组作为错误分组丢弃，然后方法3500进行到框3599，在那里方法3500结束。

框3522对TCP分段执行TCP层处理，如果TCP连接绑定到MPLS，则处理来自在连接中接收的字节流的MPLS分组。从框3522，方法3500进行到框3599，在那里方法3500结束。

在框3599处，方法3500结束。

图36描绘了用于处理来自TCP连接的TCP分段的MPLS-in-TCP分组的方法的示例实施例。方法3600可以被用于提供图35的方法3500的框3522，并且可以基于图25中呈现的通用方法2500。应当理解，虽然主要呈现为串行执行，但是方法3600的框的至少一部分可以同时或以不同于图36中呈现的顺序执行。方法3600的输入包括在TCP连接上接收的TCP分段和TCP连接的指示。注意，在TCP连接上接收的TCP分段可以被LSR的TCP层在顶部利用TCP报头来接收。注意，TCP是面向流字节的协议，因此整个分组的字节可能不会在连接中一起到达(即，分组的块可以在多个TCP分段上到达)。注意，TCP连接可以由元组{IP报头中的源IP地址，IP报头中的目的地IP地址，TCP报头中的源端口，TCP报头中的目的地端口}指示。在框3601处，方法3600开始。框3602检查TCP连接的目的地端口是否被绑定到MPLS。如果TCP连接的目的地端口没有被绑定到MPLS，则方法3600进行到框3620，否则方法3600进行到框3604。框3620处置针对非MPLS应用的TCP分段，然后方法3600进行到框3699，方法3600结束。框3604对TCP分段执行TCP相关处理。例如，如果这不是连接期望的下一TCP分段，则该TCP分段可以在内部排队，直到所有先前TCP分段都被接收和处理，可以针对处理的TCP分段发送确认，等等。在此，为简单起见，假定输入的TCP分段是连接期望的下一分段，TCP报头从TCP分段中被移除，并且TCP分段的有效载荷被附加到接收的字节流中。从框3604，方法3600进行到框3606。框3606将接收的流的前4个八位字节解析为MCH，然后方法3600进行到框3608。框3608检查接收的流是否至少具有在MCH中的长度字段中指定的数目的八位字节(例如，至少具有整个下一MPLS分组)。如果流不具有整个分组，则方法3600进行到框3699，在框3699处，方法3600结束，否则方法3600进行到框3610。框3610从接收的流中提取在MCH的长度字段中指定的数目的八位字节加上构成由MCH封装的MPLS分组的4个八位字节，然后移除MCH以生成MPLS分组。从框3610，方法3600进行到框3612。框3612检查分组是否是MOIF。如果分组是MOIF，则方法3600进行到框3614，否则方法3600进行到框3616。框3616将分组作为MPLS分组进行处理，然后方法3600进行到框3618。注意，如果LSR是连接的发起者，则框3614可以通过图17的方法1700实现，否则方法3614可以通过图21的方法2100实现。从框3614，方法3600进行到框3618。框3618检查TCP分段中是否有更多字节要被读取。如果在TCP分段中有更多字节要被读取，则方法3600返回到框3606以处理其有效载荷中的下一MPLS分组，否则方法3600进行到框3699，在那里方法3600终止。

注意，封装的MPLS分组的顶部标签是下游分配的还是上游分配的可以根据各种标准而被确定。例如，如果隧道目的地IP地址是单播地址，则顶部标签可以是下游分配的。例如，如果隧道目的地IP地址是IP多播地址，则特定隧道中所有封装的MPLS分组都在堆栈的顶部处具有下游分配的标签，或者特定隧道中所有封装的MPLS分组都在堆栈的顶部处具有上游分配的标签标签。针对特定隧道确定这一点的方法可以以各种方式执行。在没有关于特定隧道的任何知识的情况下，可以假定标签是上游分配的。

注意，中间路由器在接收到TCP封装的分组之后，可以基于TCP分组的五元组(即，源IP地址、目的地IP地址、源端口、目的地端口和协议)的散列值来平衡这些分组。注意，由于复用在TCP隧道上的MPLS覆盖共享相同的五元组，跨覆盖的分组通常无法被负载平衡。如果需要在MPLS覆盖之间进行负载平衡，则多路径TCP(MP-TCP)可以被用作可靠传输层。

注意，为了提供MPLS-in-TCP分组的高效交换，可以使用某些TCP连接参数(例如，TCP选择性确认(SACK)选项、TCP窗口缩放选项、保护包装序列号(PAWS)能力、TCP_NODELAY选项等、以及其各种组合)。选择性确认选项允许接收器在单个ACK中确认多个丢失分组，从而实现更快恢复。LSR可以协商在MPLS的TCP连接上使用TCP SACK，并且使用它从丢失分组和TCP序列号空间中的漏洞中更快地恢复。TCP窗口缩放选项允许接收器通告大于16位限制的TCP窗口大小。有必要允许长胖网络中的数据填充可用管道。这也表示在与TCP连接的(带宽*延迟)乘积相匹配的TCP发送方上进行缓冲。LSR使用本地可用机制来设置与可用本地缓冲区资源和预期吞吐量相匹配的窗口大小。PAWS能力可以被用于确保TCP序列号不会在超时窗口内回绕。TCP_NODELAY选项可以被用于禁用Nagle算法。应当理解，可以使用各种其他TCP连接参数来提供MPLS-in-TCP分组的有效交换。

各种示例实施例被配置为使用SCTP作为用于MPLS覆盖分组的隧道传输的可靠传输层。这提供了作为MPLS-in-SCTP的可靠MPLS覆盖的实现。一般而言，SCTP是一种由IETF标准化的计算机网络通信协议，其运行在传输层并且作用类似于TCP。可以理解，SCTP可以被表征为面向消息的，这意味着，它传输消息序列(每个消息是一组字节)，而不是像TCP那样传输不间断的字节流。在SCTP中，就像在UDP中一样，发送方在一个操作中发送一个消息，而该消息在一个操作中被传递到接收应用进程。相比之下，TCP是面向流的协议，其可靠且有序地传输字节流。SCTP应用将它们要以消息(字节组)传输的数据提交给SCTP传输层。SCTP将消息和控制信息放入分开的块(数据块和控制块)中，每个块由块报头标识。SCTP可以将一个消息分成多个数据块，但每个数据块仅包括来自一个消息的数据。SCTP将块捆绑成SCTP分组。提交给IP层的SCTP分组包括分组报头、SCTP控制块(根据需要)、之后是SCTP数据块(在可用时)。在SCTP中，两个端点之间的连接称为“关联”，因此本文中使用该标准术语。SCTP中的术语“流”是指SCTP并行传输应用的若干独立流的能力(例如，将网页图像与网页文本一起传输)。本质上，SCTP的多流传输能力涉及将应用内的若干独立数据流捆绑成单个SCTP连接。独立的块的流可以在单个SCTP消息中被捆绑在一起，其中流的有效载荷可以被打包成消息中的一个或多个数据块，并且每个数据块使用流标识符被编码，基于流标识符，其有效载荷的流被标识。还注意，在SCTP中，一个端点可以使用多个IP地址，这使得能够跨端点之间的多个可用路径喷射SCTP分组。当SCTP被用于隧道MPLS覆盖分组时，则端点是LSR。

图37描绘了用于将可靠MPLS覆盖实现为MPLS-in-SCTP的MPLS-in-SCTP封装格式的示例实施例。

MPLS-in-SCTP封装格式3700包括有效载荷、在有效载荷之上的MPLS标签堆栈、在MPLS标签堆栈之上的SCTP报头、在SCTP报头之上的IP报头和在IP报头之上的数据链路报头。注意，由于SCTP是面向数据报的协议，因此MCH不需要封装MPLS有效载荷，因此MCH不是MPLS-in-SCTP封装格式3700的堆栈的一部分。SCTP报头是用于MPLS覆盖用作隧道的SCTP关联。注意，在图37中，仅以概念形式描述SCTP分组。没有单个SCTP报头，而是存在若干SCTP特定报头散布在SCTP分组中。在图37中，有效载荷、MPLS标签堆栈和SCTP报头组成“SCTP分组”，以用于MPLS分组的可靠隧道传输。

一般来说，SCTP分组包括两个基础部分：公共报头(占据前12个字节)和一堆块(占据分组的剩余部分)。公共报头包括源端口字段、目的地端口字段、验证标签字段和校验和字段。源端口是发送方的端口号，接收方使用该端口号结合源IP地址来标识该SCTP分组所属的SCTP关联。目的地端口是接收方的端口号，其用于将STCP分组解复用到SCTP的正确应用(即，SCTP的上层)。验证标签在SCTP关联的建立期间在对等方之间协商，以验证分组的发送方。校验和对SCTP分组使用CRC32算法以确保数据完整性。每个块以块报头开始，该块报头包括一字节的类型标识符(针对SCTP定义了15种块类型，至少还有5种由附加扩展定义)、八个标志位和2字节的长度字段，并且数据组成块的其余部分。块类型可以大致分为控制块和数据块，控制块和数据块的报头格式分别在图38和图39中给出。

图38描绘了用于SCTP分组的SCTP控制块报头的示例实施例。SCTP控制块报头3800承载与SCTP分组相关的控制信息，并且遵循TLV(类型长度值)格式。参数类型字段指示控制信息的类型，因此，长度和值在SCTP规范中指定。

图39描绘了用于SCTP分组的SCTP数据块报头的示例实施例。SCTP数据块报头承载来自使用SCTP的应用(上层)的实际数据。在单个SCTP分组中承载多个数据块的能力支持在用户应用内复用多个流。来自流的有效载荷可以在SCTP分组中的一个或多个块中发送。数据块报头中的流标识符字段被用于将SCTP分组中的数据块多路解复用到用户应用中的流。

注意，SCTP的各个方面可以被配置为支持MPLS分组在SCTP上的可靠递送隧道传输。

公共报头中的目的地端口字段包括新的端口号，以指示SCTP隧道有效载荷是MPLS分组。例如，值6640可以被用于指示SCTP隧道的有效载荷是MPLS分组，但应当理解，可以使用任何其他合适的可用值。注意，最终被用于指示SCTP隧道的有效载荷是MPLS分组的值可以保留在由IANA维护的名称和传输协议端口号注册表中。注意，如果不使用标准化值，则SCTP中的端口号可以跨参与MPLS覆盖的LSR以管理方式而被配置，以指示有效载荷是MPLS分组。

可以由LSR为SCTP关联上的MPLS覆盖分配唯一的流标识符(ID)。在这种情况下，MPLS覆盖分组可以作为SCTP分组内的独立数据块被发送。这表示，来自多个MPLS覆盖的分组可以在单个SCTP分组上被复用。由于MPLS覆盖彼此独立，因此将每个覆盖配置为独立流还可以消除共享SCTP关联的覆盖之间的队头(HOL)阻塞。

流ID空间可以是LSR本地的，因此每个LSR可以从其本地空间中独立分配未使用流ID。通过SCTP关联发送MPLS覆盖分组的LSR在SCTP分组中的对应数据块中使用其分配的流ID。针对接收LSR，接收的数据块的流ID与对应MPLS覆盖之间没有相关性，因为LSR基于数据块的有效载荷中MPLS分组的MPLS标签堆栈来标识覆盖。流ID值0将不会被用于传输MPLS覆盖的MPLS分组，并且可以由两个LSR保留，以用于在SCTP关联上复用的MPLS覆盖的批量管理。批量管理的一种用法是MOIF，MOIF将在具有流ID 0的数据块中被发送。

注意，SCTP的各种其他方面可以被配置为支持MPLS分组在SCTP上的可靠递送隧道传输。

图40描绘了用于针对MPLS-in-SCTP配置SCTP关联的方法的示例实施例。方法4000可以基于图13中呈现的通用方法1300。应当理解，虽然主要呈现为串行执行，但是方法4000的框的至少一部分可以同时或以不同于图40中呈现的顺序执行。方法4000的输入包括远程LSR的IP地址。注意，当LSR发现新的SCTP关联需要被建立以隧道传输MPLS覆盖分组时，LSR确定要进行与其的SCTP关联的远程LSR的IP地址，并且确定关于新的SCTP关联的信息(例如，QoS信息，其被用于封装SCTP分组的IP报头中的适当QoS标记)。在框4001处，方法4000开始。框4002挑选可以被用于发送和接收隧道业务的一个或多个配置的本地IP地址，然后方法4000进行到框4004。框4004分配要被用于新的关联的本地SCTP端口号，使得该号码当前未被现有SCTP关联使用，然后方法4000进行到框4006。框4006将本地SCTP端口绑定到MPLS作为其有效载荷/应用，然后方法4000进行到框4008。框4008生成从本地端口和本地IP地址中的一个本地IP地址针对到远程IP地址处的MPLS(6640)端口号的SCTP关联请求。SCTP关联请求是承载SCTP的INIT块的消息。INIT块主要包括关联允许的入站和出站流的最大数目的信息、以及要被用于关联的本地IP地址列表。入站或出站流的最大数目可以被设置为要通过SCTP关联隧道传输的MPLS覆盖的最大数目。如果先验不知道要支持的MPLS覆盖的最大数目，则入站流数目字段和出站流数目字段都可以设置为最大允许值，即65535(因为字段为16位大小)。注意，如果SCTP关联请求被远程LSR拒绝，则LSR应当采取行动以限制用于建立SCTP关联的不必要的重复尝试。例如，LSR可以在尝试重新建立关联之前等待60秒。从框4008，方法4000进行到框4010。框4010检查远程LSR是否接受SCTP关联请求(意味着成功)。如果远程LSR接受SCTP关联请求，则该LSR将接收到来自远程LSR的INIT ACK。如果远程LSR接受SCTP关联请求，则方法4000进行到框4012，否则方法4000进行到框4014。框4014声明SCTP关联配置的失败，然后方法4000进行到框4099，在那里方法4000结束。框4012根据需要执行关联后跟进，然后方法4000进行到框4099，在那里方法4000结束。在框4099处，方法4000结束。

图41描绘了用于针对MPLS-in-SCTP的SCTP关联执行连接后跟进的方法的示例实施例。注意，方法4100可以由发起SCTP关联的LSR执行。方法4100可以被用于提供图40的方法4000的框4012。方法4100可以基于图14中定义的框架。应当理解，虽然主要呈现为串行执行，但是方法4100的框的至少一部分可以同时或以不同于图41中呈现的顺序执行。方法4100的输入包括SCTP关联。在框4101处，方法4100开始。框4102检查MOIF的要求是否在LSR中被配置。如果MOIF的要求在LSR中被配置，则方法4100进行到框4104，否则方法4100进行到框4199，在框4199，方法4100结束。框4104构建MOIF并且填充必要的字段。注意，该框可以通过图15的方法1500来实现。从框4104，方法4100进行到框4106。框4106通过SCTP关联发送MOIF。MOIF作为SCTP分组中数据块的有效载荷发送，其中数据块用流ID 0编码。从框4106，方法4100进行到框4108。框4108等待来自对等LSR的MOIF响应。注意，实现可以等待至少90秒(或任何其他合适的时间长度)以用于MOIF响应。为了等待，LSR可以在其预期MOIF响应的持续时间内启动定时器，并且将定时器与SCTP关联相关联(尽管可以理解，其他机制是可以预期的)。注意，当发起LSR接收到来自对等LSR的MOIF响应时，它可以执行图17的方法1700。注意，在连接上接收的分组是MOIF的确定可以作为关联上MPLS覆盖分组的通用处理的一部分来进行(例如，基于图49的方法4900的框4902-4914)。从框4108，方法4100进行到框4199，在那里方法4100结束。在框4199处，方法4100结束。

图42描绘了用于当在针对SCTP关联的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例。注意，发起LSR在预定义时间段内未能接收到MOIF响应的情况可以被确定，其中在图41的框4108处设置的超时在MOIF响应没有被接收的情况下到期。应当注意，在SCTP关联上接收的分组是MOIF响应的确定可以作为在关联上接收的MPLS覆盖分组的通用处理的一部分来执行(例如，基于图49的方法4900的框4902-4914)。注意，当发起LSR从对等LSR接收到MOIF响应时，发起LSR可以执行图17的方法1700。应当理解，虽然主要呈现为串行执行，但是方法4200的框的至少一部分可以同时或以不同于图42中呈现的顺序执行。方法4200的输入包括关于MOIF等待定时器到期的通知。框4202检索与定时器相关联的SCTP关联，然后方法4200进行到框4204。框4204关闭SCTP关联，然后方法4200进行到框4299，在那里方法4200结束。在框4299处，方法4200结束。

图43描绘了用于配置SCTP关联侦听器的方法的示例实施例。注意，LSR可以使用方法4300来侦听针对MPLS-in-SCTP的SCTP关联请求(例如，侦听针对作为用户协议的MPLS的新的SCTP关联请求，例如通过在为MPLS(6640)分配的SCTP端口上侦听)。注意，MPLS-in-SCTP关联侦听器可以由配置MPLS覆盖的任何LSR实现。方法4300可以基于图18中呈现的通用方法1800。应当理解，虽然主要呈现为串行执行，但是方法4300的框的至少一部分可以同时或以不同于图43中呈现的顺序执行。在框4301处，方法4300开始。框4302打开用于MPLS的SCTP端口(例如，6640)，然后方法4300进行到框4304。框4304将该端口绑定到为SCTP关联而选择的LSR中的本地IP地址集，然后开始在任一IP地址上侦听端口的传入关联请求(例如，具有INIT块的SCTP消息)。在框4399处，方法4300结束。

图44描绘了用于处理传入SCTP关联请求的方法的示例实施例。注意，传入关联请求可以在MPLS的SCTP端口上接收。方法4400可以基于图19中呈现的通用方法1900。应当理解，虽然主要呈现为串行执行，但是方法4400的框的至少一部分可以同时或以不同于图44中呈现的顺序执行。方法4400的输入包括具有以下关联参数的关联请求：(1)源IP地址，其是发送关联请求的远程LSR的IP地址，(2)目的地IP地址，其是本地关联请求被发送至的该LSR的IP地址，(3)源端口，其是远程LSR处的SCTP端口，以及(4)目的地端口，其是关联请求被发送至的该LSR的SCTP端口。在框4401处，方法4400开始。框4402检查目的地端口是否在LSR中的SCTP中打开。如果目的地端口在LSR中的SCTP中没有打开，则方法4400进行到框4414，否则方法4400进行到框4404。框4414使用适当的SCTP机制拒绝关联请求(例如，使用SCTP中根据方法到远程LSR的拒绝通知)。例如，LSR可以将SCTP消息与ABORT块一起发送回发送方以拒绝SCTP关联请求。从框4414，方法4400进行到框4499，在那里方法4400结束。框4404检查SCTP目的地端口是否是MPLS(例如，6640)。如果SCTP目的地端口不是MPLS，则方法4400进行到框4412，否则方法4400进行到框4406。框4412根据与端口关联的有效载荷协议类型来处理SCTP关联请求，然后方法进行到框4499，在那里方法4400结束。框4406检查是否允许来自远程LSR(例如，来自源IP地址)的SCTP关联请求。注意，可以使用各种因素来确定LSR是否应当允许传入SCTP关联。例如，LSR可以采用一种方法来发现可以参与与LSR的MPLS覆盖的所有潜在远程LSR及其本地IP地址集。如果不允许SCTP关联请求，则方法4400进行到框4414，否则方法4400进行到框4408。框4414使用适当的SCTP手段拒绝关联请求，即，SCTP中根据方法到远程LSR的拒绝通知，诸如使用ABORT控制块向发送方发送SCTP消息。该方法在框4414之后终止。框4408接受SCTP关联请求，这意味着，SCTP关联的状态是以元组{远程IP地址集，本地IP地址集，源端口，目的地端口}为关键字而被创建的，然后方法4400进行到框4410。框4410执行关联后跟进(如果有)，然后方法4410进行到框4499，在那里方法4400结束。框4410可以通过图20的方法2000来实现，如果被配置为接收MOIF，则使LSR等待来自对等LSR的MOIF。注意，在SCTP关联上接收的分组是MOIF的确定可以作为对关联上的MPLS覆盖分组的通用处理的一部分来进行(例如，使用图49的方法4900的框4902-4914)。注意，如果LSR在预定义时间段内未能接收到MOIF(例如，在图20中的框2004处设置的超时到期)，则LSR可以执行图42的方法4200(即，处理在发起和接收LSR两者中是常见的)。注意，当从对等LSR接收到MOIF时，则LSR可以执行图21的方法2100。

图45描绘了用于在SCTP关联上配置MPLS覆盖以形成MPLS-in-SCTP覆盖的方法的示例实施例。注意，为了在SCTP关联上配置MPLS覆盖，LSR可以在与远程LSR的SCTP关联上为MPLS覆盖分配唯一的非零流ID。针对传输LSR，流ID空间是LSR本地的，因此每个LSR可以从其本地空间独立分配未使用流ID，并且通过SCTP关联发送MPLS覆盖分组的LSR在SCTP分组中对应数据块中使用其分配的流ID。针对接收/远程LSR，接收的数据块的流ID与对应MPLS覆盖之间没有相关性，因为LSR基于数据块的有效载荷中MPLS分组的MPLS标签堆栈来标识覆盖。应当理解，虽然主要呈现为串行执行，但是方法4500的框的至少一部分可以同时或以不同于图45中呈现的顺序执行。方法4500的输入包括LSP/覆盖的传出MPLS标签和LSP/覆盖的远程LSR的IP地址。在框4501，方法4500开始。框4502针对MPLS-in-SCTP检查是否存在与远程LSR的现有SCTP关联。如果针对MPLS-in-SCTP不存在与远程LSR的现有SCTP关联，则方法4500进行到框4512，否则方法4500进行到框4504。框4504针对MPLS-in-SCTP检索与远程LSR的第一SCTP关联，然后方法4500进行到框4506。框4506检查在SCTP关联中是否存在至少一个未使用非零流ID可用。如果在SCTP关联中存在至少一个未使用非零流ID可用，则该SCTP关联可以被用于覆盖，然后方法4500进行到框4516。如果SCTP关联中没有至少一个未使用非零流ID可用，则该SCTP关联不能被用于覆盖，然后方法4500进行到框4508。框4508针对MPLS-in-SCTP检查是否有更多与远程LSR的SCTP连接。如果针对MPLS-in-SCTP有与远程LSR的更多SCTP连接，则方法4500进行到框4510，否则方法4500进行到框4512。框4512针对MPLS-in-SCTP检索与远程LSR的下一SCTP关联，然后方法4500返回到框4506以评估下一SCTP关联作为被用于覆盖的隧道的可行性。框4512针对MPLS-in-SCTP配置与远程LSR的新的SCTP关联。注意，框4512可以通过图33的方法3300来实现。从框4512，方法4500进行到框4514。框4514检查SCTP关联是否已经成功建立。如果SCTP关联尚未成功建立，则方法4500进行到框4526，否则方法4500进行到框4516。框4526声明并且处理配置MPLS覆盖的失败，然后进行到框4599，在那里方法4500结束。框4516分配LSP标识符以在LSR中唯一地标识MPLS覆盖。LSP标识符绑定SCTP关联、(多个)传出标签和与MPLS覆盖相关联的其他参数。从框4516，方法4500进行到框4518。框4518将LSP/覆盖的传出MPLS标签设置为LSP标识符的传出标签，然后方法4500进行到框4520。框4520将SCTP关联设置为与LSP标识符关联的隧道，然后方法4500进行到框4522。框4522分配SCTP关联中未使用流ID作为要用于为覆盖交换分组的流的标识符，然后方法4522进行到框4524。框4524在LSP标识符与覆盖的流ID之间创建映射，然后方法4500进行到框4599，在那里方法4500结束。在框4599处，方法4500结束。

图46描绘了用于在MPLS-in-SCTP上传输分组的方法的示例实施例。方法4600可以基于图23中呈现的通用方法2300(不同之处在于，框2310可以不被实现，因为MPLS-in-SCTP分组中没有SCTP报头的动态参数)。应当理解，虽然主要呈现为串行执行，但是方法4600的框的至少一部分可以同时或以不同于图46中呈现的顺序执行。方法4600的输入包括要被传输的分组和标识LSP或MPLS覆盖的LSP标识符。在框4601，方法4600开始。框4602通过LSP标识符来检索LSP的传出标签的状态，方法4600进行到框4604。框4604获取为LSP标识符而配置的SCTP隧道，然后方法4600进行到框4606。框4606将LSP的传出标签推送到分组上，方法4600然后进行到框4608。框4608针对分组根据需要设置推送标签中的S位、EXP和TTL字段。例如，如果分组在推送LSP的传出标签之前已经有另一标签，则S位设置为0，否则S位设置为1。TTL和EXP值可以由为LSP而配置的策略来设置。例如，如果策略要求对LSP上的所有分组使用一致的EXP值，则设置配置的EXP值。如果策略具有基于分组的本机报头中的某些字段的EXP值的映射，则设置映射的EXP值。从框4608，方法4600进行到框4610。框4610在SCTP关联上在LSP标识符的上下文中发送MPLS分组。从框4610，方法4600进行到框4699，在框4699那里4600结束。在框4699处，方法4600结束。

图47描绘了用于在SCTP关联上传输MPLS分组的方法的示例实施例。方法4700可以被用于提供图46的方法4600的框4610，并且可以基于图24中呈现的通用方法2400(不同之处在于，框2410可以不被实现，因为MPLS-in-SCTP分组中没有SCTP报头的动态参数)。应当理解，虽然主要呈现为串行执行，但是方法4700的框的至少一部分可以同时或以不同于图47中呈现的顺序执行。方法4700的输入包括要被传输的MPLS分组和标识LSP或MPLS覆盖的LSP标识符。在框4701，方法4700开始。框4702获取映射到LSP标识符的流ID，然后方法4700进行到框4704。框4704使用MPLS分组作为其有效载荷为流ID构建SCTP数据块，然后方法4700进行到框4706。框4706检查一个或多个块是否在SCTP关联上待发送。由于SCTP可以将多个块捆绑在单个SCTP分组上，因此之前的块可能已经排队等待被发送。其次，由于拥塞、流量控制等，先前的帧也可能处于未决状态。如果没有待处理的帧，则方法4700进行到框4708，否则方法4700进行到框4710。框4708创建SCTP块的空堆栈，然后方法4700进行到框4710。框4710将数据块(包括MPLS分组)推送到SCTP块堆栈中，然后方法4700进行到框4712。框4712检查SCTP块堆栈是否准备好通过SCTP关联发送。由于拥塞、流量控制等，SCTP块堆栈可能不会立即被发送，或者LSR可能在时间窗口内等待更多帧以发送最佳大小的SCTP分组。如果SCTP块堆栈尚未准备好要被发送，则SCTP块堆栈将在稍后准备好时要被发送，因此方法4700进行到框4799，在框4799，方法4700结束(例如，直到稍后方法4700可以重新执行)。如果SCTP块堆栈准备好要被发送，则方法4700进行到框4714。框4714将关联的SCTP公共报头推送到SCTP块堆栈上。这会产生完整SCTP分组。SCTP公共报头中的源端口和目的地端口字段根据SCTP关联中的对应参数被填充。注意，框4704-4714可以由LSR中的SCTP层执行。从框4714，方法4700进行到框4716。框4716将IP报头推送到分组上。IP报头中的源地址和目的地地址按照SCTP关联中的一对本地和远程IP地址被填充(地址由框4714提供)。协议字段(如果IPv4报头)或下一报头字段(如果IPv6报头)设置为132以指示有效载荷为SCTP。从框4716，方法4700进行到框4718。框4718对IP报头中的目的地地址执行IP路由表查找，这导致分组的下一跳。注意，框4716-4718可以由LSR中的IP层执行。从框4718，方法4700进行到框4720。框4720将数据链路层报头推送到分组上，以在链路上将分组发送到下一跳，然后方法4700进行到框4722。框4722在线路上将分组发送到下一跳，然后该方法继续进行到框4700，在那里方法4700结束。在框4799处，方法4700结束。

图48描绘了用于接收和处理MPLS-in-SCTP分组的方法的示例实施例。应当理解，虽然主要呈现为串行执行，但是方法4800的框的至少一部分可以同时或以不同于图48中呈现的顺序执行。方法4800的输入包括在线路上接收的MPLS-in-SCTP分组。

在框4801处，方法4800开始。

框4802解析并且处理在分组之上的数据链路报头，然后方法4800进行到框4804。框4804检查数据链路层是否指示分组是本地的，这意味着，执行方法4800的该LSR是分组在其上到达的数据链路的终止点。例如，如果数据链路报头是以太网报头，并且如果以太网报头中的目的地MAC地址是LSR本地的，则以太网链路终止于LSR。如果分组在数据链路层是本地的，则方法4800进行到框4806，否则方法4800进行到框4824。框4824在数据链路层作为非本地分组来执行分组的所需要的处置，这可以导致在数据链路层处进一步转发分组，然后方法4800进行到框4899，在那里方法4800结束。注意，框4802-4804和框4824可以由LSR的数据链路层执行。

当LSR是数据链路的末端时，框4806从分组中移除数据链路报头，然后方法4800进行到框4808。框4808检查由数据链路报头指示的有效载荷是否是IP。例如，如果数据链路报头是以太网报头，则其Ethertype字段指示有效载荷类型。如果以太网报头有VLAN标签，则最后的VLAN标签中的Ethertype字段指示有效载荷类型。如果有效载荷是IP，则方法4800进行到框4810，否则方法4800进行到框4826。框4826将分组作为非IP分组进行处置，然后方法4800进行到框4899，在那里方法4800结束。注意，框4806-4808可以由LSR的数据链路层执行。

框4810基于其IP报头在IP层中处理IP分组。例如，可以在IP路由表中查找IP报头的目的地地址，以对IP分组做出转发决策。从框4810，方法4800进行到框4812。框4812检查目的地地址是否是本地的(例如，IP路由表查找是否与作为LSR中本地配置的IP地址的目的地地址匹配)。如果目的地地址不是本地的，则方法4800进行到框4828，否则方法4800进行到框4814。框4828将分组作为非本地IP分组进行处置，例如通过将分组转发到与来自IP路由表查找的匹配路由条目相关联的下一跳，然后方法4800进行到框4899，在那里方法4800结束。注意，框4810-4812和4828可以由LSR的IP层执行。

框4814从IP分组中移除IP报头，因为它是本地分组，然后方法4800进行到框4816。框4816检查分组是否是SCTP分组(例如，如果IP报头是IPv4，则检查IPv4报头中的协议字段是否设置为132(SCTP)，或者如果IP报头是IPv6，则检查IPv6报头中的下一报头字段是否设置为132(SCTP))。如果分组不是SCTP分组，则方法4800进行到框4830，否则方法4800进行到框4818。框4830处理相应IP协议类型的分组，然后方法4800进行到框4899，在那里方法4800结束。注意，框4814-4816可以由LSR的IP层执行。

框4818基于IP报头中的源和目的地IP地址(例如，地址在框4814中IP报头移除之后沿流被传递)并且基于SCTP公共报头中的源和目的地端口来查找SCTP分组的SCTP关联。从框4818，方法4800进行到框4820。框4820检查是否找到匹配的SCTP关联。如果没有找到匹配的SCTP关联，则方法4800进行到框4832，否则方法4800进行到框4822。框4832将分组作为错误分组丢弃，然后方法4800进行到框4899，在那里方法4800结束。

框4822对SCTP分组执行SCTP层处理，如果SCTP关联被绑定到MPLS，则处理来自在SCTP分组中接收的数据块的MPLS分组。从框4822，方法4800进行到框4899，在框4899那里4800结束。

在框4899处，方法4800结束。

图49描绘了用于处理来自SCTP关联的SCTP分组的MPLS-in-SCTP分组的方法的示例实施例。方法4900可以被用于提供图48的方法4800的框4822，并且可以基于图25中呈现的通用方法2500。应当理解，尽管主要呈现为串行执行，但是方法4900的框的至少一部分可以同时或以不同于图49中呈现的顺序执行。方法4900的输入包括在SCTP关联上接收的SCTP分组和SCTP关联的指示。注意，在SCTP关联上接收的SCTP分组可以被LSR的SCTP层在顶部使用SCTP公共报头而被接收。注意，SCTP关联可以由元组{IP报头中的源IP地址，IP报头中的目的地IP地址，SCTP公共报头中的源端口，SCTP公共报头中的目的地端口}指示。在框4901处，方法4900开始。框4902检查SCTP公共报头中的目的地端口是否绑定到MPLS。如果SCTP公共报头中的目的地端口没有被绑定到MPLS，则方法4900进行到框4928，否则方法4900进行到框4904。框4928处理非MPLS应用的SCTP分组。框4904处理SCTP公共报头，然后方法4900进行到框4906。框4906解析SCTP分组中的第一块，然后方法4900进行到框4908。框4908检查块是否是数据块。如果块不是数据块(这意味着它是控制块)，则方法4900进行到框4922，否则方法4900进行到框4910。框4922使用SCTP处理控制块，然后方法4900进行到框4924。框4910读取数据块并且将数据移交给MPLS覆盖层，然后方法4900进行到框4912。框4912检查数据块的流ID是否是0。如果数据块的流ID不是0，则方法4900进行到框4920，否则方法4900进行到框4914。框4920在MPLS覆盖层将数据作为MPLS分组进行处置。有效载荷中MPLS分组的MPLS标签堆栈标识MPLS有效载荷所属的MPLS覆盖。从框4920，方法4900进行到框4924。框4914检查数据是否是MOIF分组。如果数据不是MOIF分组，则该分组不是期望的(即，期望MOIF分组具有流ID 0)，然后方法4900进行到框4918，否则方法4900进行到框4916。框4918使用适当的SCTP方法关闭SCTP关联(通知远程LSR关闭的原因，诸如通过在SCTP分组中发送SHUTDOWN控制块)，然后方法4900进行到框4999，在框4999处，方法4900结束。框4916处理MOIF分组。如果LSR是连接的发起者，则框4916可以通过图17的方法1700实现，否则框4916可以通过图21的方法2100实现。从框4916，方法4900进行到框4924。注意，框4914-4920可以由MPLS覆盖层执行，这是SCTP关联的应用。框4924检查SCTP分组中是否有更多块。如果SCTP分组中没有更多块，方法4900进行到框4999，在那里方法4900结束，否则方法进行到框4926。框4926解析SCTP分组中的下一块并且返回到框4908以针对下一块重复后续框。在框4999处，方法4900结束。

注意，一旦中间路由器在接收到SCTP封装的分组，就可以基于SCTP分组的五元组(即，IP报头中的源IP地址、IP报头中的目的地IP地址、SCTP公共报头中的源端口、SCTP公共报头中的目的地端口、和IP报头中的协议/下一报头字段)的散列值来平衡这些分组。如果需要在MPLS覆盖之间进行负载平衡，则可以在SCTP关联中的两个LSR处使用IP地址池，然后分配IP地址池以跨IP地址池发送MPLS覆盖分组。

各种示例实施例被配置为使用QUIC作为用于MPLS覆盖分组的隧道传输的可靠传输层。这提供了作为MPLS-in-QUIC的可靠MPLS覆盖的实现。

QUIC是一种计算机网络通信协议，其运行在传输层并且作用类似于TCP和SCTP。QUIC被设计为一种高性能的可靠传输协议，并且与其前身TCP、SCTP等有一些根本性的差异。QUIC通过在UDP上在两个端点之间建立多个复用连接(称为流)来提高面向连接的应用的性能。QUIC中流的概念类似于SCTP，它允许多个数据流独立地到达端点，因此独立于涉及其他流的分组损失。如果任何TCP分组延迟或丢失，这解决了TCP中遇到的队列头阻塞延迟。QUIC还减少了连接和传输延迟、以及每个方向的带宽估计以避免拥塞。注意，QUIC与TCP或SCTP的根本区别在于，QUIC是一种用户空间传输协议，它允许快速修改协议，而无需等待系统升级。在QUIC连接中，流可以随时启动。任一端点都可以从流开始，流可以是双向的或单向的。QUIC继承了TCP字节流数据模型，所以从应用的角度来看，它是一个面向流的协议。传统的传输层协议(诸如，TCP和SCTP)基于元组{源IP地址，目的地IP地址，源端口号，目的地端口号}标识连接；然而，在QUIC中，每个连接都用数字连接标识符(ID)标识。每个端点独立地选择连接ID并且在连接建立期间通告它。当端点向对等方发送QUIC分组时，端点使用由对等方通告的连接ID来对QUIC报头进行编码。连接ID的主要功能是确保较低协议层(UDP、IP)的寻址变化不会导致QUIC连接的分组被递送到错误的端点。每个端点使用实现特定(也可能是部署特定)方法来选择连接ID，该方法将允许具有该连接ID的分组被路由回端点并且在接收时由端点标识。此外，QUIC提供有效载荷的加密和认证，这使得MPLS-in-QUIC适用于安全且可靠的MPLS覆盖。QUIC基本上在其过程中嵌入TLS(传输层安全)方法。在连接建立期间，QUIC包括TLS握手过程以协商安全密钥，以在QUIC分组中对有效载荷进行加密和认证，然后，使用这些密钥，连接上每个QUIC分组的有效载荷都被加密，使用TLS过程被认证。当QUIC被用于隧道传输MPLS覆盖分组时，端点是LSR。

图50描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的MPLS-in-QUIC封装格式的示例实施例。

MPLS-in-QUIC封装格式5000包括有效载荷、在有效载荷之上的MPLS标签堆栈、在MPLS标签堆栈之上的MCH、在MPLS标签堆栈之上的QUIC报头、在QUIC报头之上的UDP报头、在UDP报头之上的IP报头、以及在IP报头之上的数据链路报头。针对可靠MPLS覆盖分组的参考模型，UDP报头和QUIC报头属于可靠递送层，因为QUIC运行在UDP之上。可靠性内置于QUIC中，并且UDP报头仅提供基础传输服务。UDP报头中的目的地端口号字段设置为80，这是由IANA针对QUIC分配的端口号。注意，除非另有说明，否则对“QUIC分组”的引用是指其中UDP报头未被包括在分组中的分组。在图50中，有效载荷、MPLS标签堆栈、MCH和QUIC报头组成“QUIC分组”，以用于MPLS分组的可靠隧道传输。QUIC报头是由MPLS覆盖用作隧道的QUIC关联的报头。在图50中，QUIC报头以概念形式描述，因为它不是单个报头，而是散布在跨QUIC分组中的一组报头。注意，元组{MPLS标签堆栈，有效载荷}的多个流散布在跨QUIC分组中。

通常，QUIC分组包括三个基础部分，包括QUIC长报头(其示例格式在图51中呈现)或QUIC短报头(其示例格式在图52中呈现)和堆栈QUIC帧(其示例格式在图53中呈现)。

图51描绘了用于将可靠MPLS覆盖实现为MPLS-in-QUIC的针对QUIC分组的QUIC长报头的示例实施例。QUIC长报头5100被用于在QUIC连接建立的最初几个阶段发送的分组。一旦初始阶段完成，发送方就切换到使用QUIC短报头发送分组。QUIC长报头5100包括报头格式字段、固定位字段、长分组类型字段、类型特定位字段、版本字段、DCID长度(Len)字段、目的地连接ID字段、SCID长度(Len)字段和源连接ID字段。报头格式字段是字节0(第一字节)的最高有效位(0x80)，针对长报头设置为1。固定位字段是字节0的下一位(0x40)并且设置为1。包含该位为零值的分组在版本中不是有效分组，并且将被丢弃。长分组类型(T)字段是字节0的下两个位(掩码为0x30)，并且包括分组类型。当前定义的分组类型包括：(a)0x0＝Initial，(b)0x01＝0-RTT，(c)0x2＝Handshake，以及(d)0x3＝Retry。类型特定位(X)字段包括字节0的低四位(掩码为0x0f)并且是类型特定的。版本字段是跟在第一字节之后的32位字段。该字段指示正在使用的QUIC版本，并且确定如何解释其余的协议字段。DCID Len字段是跟在版本之后的字节，并且包括跟在版本之后的目的地连接ID字段的以字节为单位的长度。该长度编码为8位无符号整数。在QUIC版本1中，该值不超过20。接收到值大于20的版本1长报头的端点将丢弃分组。服务器可以能够从其他QUIC版本中读取更长的连接ID，以便正确形成版本协商分组。目的地连接ID字段跟在DCID Len之后，长度在0到20个字节之间。SCID Len字段是跟在目的地连接ID之后的字节，并且包括跟在目的地连接ID之后的源连接ID字段的以字节为单位的长度。该长度编码为8位无符号整数。在QUIC版本1中，该值不超过20个字节。接收到值大于20的版本1长报头的端点将丢弃分组。服务器可以能够从其他QUIC版本中读取更长的连接ID，以便正确形成版本协商分组。源连接ID字段跟在SCID Len之后，长度在0到20个字节之间。

图52描绘了用于将可靠MPLS覆盖实现为针对MPLS-in-QUIC的QUIC分组的QUIC短报头的示例实施例。在连接协商的最初几个阶段之后使用QUIC短报头5200。QUIC短报头包括报头格式字段、固定位字段、自旋位字段、保留位字段、密钥阶段字段、分组号长度字段、目的地连接ID字段、分组号字段和受保护有效载荷字段。报头格式字段是字节0的最高有效位(0x80)，针对短报头设置为0。固定位字段是字节0的下一位(0x40)，并且设置为1。包含该位为零值的分组在版本中不是有效分组，并且将被丢弃。自旋位字段是字节0的第三最高有效位(0x20)，并且是延迟自旋位。保留位(R)字段是字节0的下两个位(掩码为0x18)并且被保留。这些位使用报头保护来保护。在保护之前包含的值设置为0。端点将接收到这些位具有非零值的分组，在移除分组和报头保护之后，作为PROTOCOL_VIOLATION类型的连接错误。仅在移除报头保护之后丢弃这样的分组会使端点暴露于攻击之下。密钥阶段(K)字段是字节0的下一位(0x04)，指示密钥阶段，它允许分组的接收者标识用于保护分组的分组保护密钥。分组号长度(P)字段是字节0的最低有效两位(掩码为0x03)，并且包括分组号的长度，编码为无符号的两位整数，以字节为单位的长度比分组号字段小1。即，分组号字段的长度为该字段的值加1。目的地连接ID字段包括由分组的预期接收者选择的连接ID。分组号字段的长度为1到4个字节。分组号具有与分组保护分开的机密性保护。分组号字段的长度编码在分组号长度字段中。受保护有效载荷字段被配置为使得带有QUIC短报头的分组总是包括1-RTT受保护有效载荷。注意，短报头分组的报头格式位字段和连接ID字段是与版本无关的。其余字段特定于选择的QUIC版本。

图53描绘了用于将可靠MPLS覆盖实现为针对MPLS-in-QUIC的QUIC分组的QUIC帧堆栈的示例实施例。在移除QUIC长或短报头之后，QUIC分组的有效载荷包括一系列完整帧。注意，并非所有分组类型都包括帧。包括帧的分组的有效载荷将包括至少一个帧，并且可以包括多个帧和多种帧类型。注意，帧适合单个QUIC分组，并且通常不会跨越多个分组。如图53所描绘的，每个帧都以帧类型开始，帧类型指示其类型，然后是附加的类型相关字段。QUIC定义了几种帧类型，其中一种是流帧(类型8)，流帧在QUIC连接中承载流的数据。流帧的格式在图54中给出。

图54描绘了用于将可靠MPLS覆盖实现为针对MPLS-in-QUIC的QUIC分组的流帧的示例实施例。流帧5400包括流ID字段、偏移字段、长度字段和流数据字段。流ID字段包括可变长度整数，以指示流的流ID。偏移字段包括可变长度整数，以指定该流帧中数据在流中的字节偏移。当OFF位设置为1时，该字段存在。当偏移字段不存在时，偏移为0。长度字段包括可变长度整数，以指定该流帧中的流数据字段的长度。流数据字段包括来自要被递送的指定流的字节。当流数据字段的长度为0时，流帧中的偏移是将要发送的下一字节的偏移。流中的第一字节的偏移为0。在流上递送的最大偏移(偏移和数据长度的总和)不超过2^(62-1)，因为无法提供该数据的流量控制信用。接收到超过该限制的帧将被视为FRAME_ENCODING_ERROR或FLOW_CONTROL_ERROR类型的连接错误。

注意，在QUIC连接建立期间，端点协商将在QUIC上传输的应用协议。

在至少一些实施例中，QUIC通过使用TLS的应用层协议协商(ALPN)来执行应用协商(因为QUIC在连接建立期间嵌入了TLS握手)。顾名思义，ALPN是一个TLS扩展，它在TLS握手中引入了对应用协议协商的支持。针对通过QUIC支持多个应用协议的实例，该扩展允许应用层协商将通过QUIC连接使用哪个应用协议。在TLS中，ALPN扩展类型(“application_layer_protocol_negotiation(16)”)可以被定义如下：

(“application_layer_protocol_negotiation(16)”)扩展的“extension_data”字段包括“ProtocolNameList”值。“ProtocolNameList”包括客户端通告的协议列表，按优先级降序布置。协议由IANA注册的不透明的非空的字节字符串命名。过程如下：(1)客户端在连接建立消息中附加新的ProtocolNameList字段，包括支持的应用协议列表，(2)服务器检查ProtocolNameList字段，并且返回ProtocolName字段，以指示选择的协议，作为其响应的一部分，并且(3)服务器可以仅使用单个协议名称进行响应，并且如果它不支持客户端请求的任何协议名称，则它可以挑选中止连接。因此，一旦连接完成，安全隧道就被建立，并且客户端和服务器就将使用哪个应用协议达成一致，它们可以立即开始通信。目前支持的应用协议名称如下：(a)HTTP/1.1[HTTP]＝>"http/1.1"、(2)SPDY/1[SPDY/1]＝>"spdy/1"、(3)SPDY/2[SPDY/2]＝>"spdy/2"、和(4)SPDY/3[SPDY/3]＝>"spdy/3"。

在至少一些实施例中，QUIC通过使用多层协议协商(MLPN)来执行应用协商。在连接建立期间，在端点之间进行协商以通过QUIC连接复用多个用户协议，而不管它们的网络层。这种协商由TLS中引入的MLPN机制执行，因为QUIC在连接建立期间嵌入了TLS握手。协商的协议可以在QUIC分组中作为新的GENERIC_STREAM帧的有效载荷被传输。注意，MLPN机制可以被定义如下。针对TLS定义了新的扩展类型(“multi_layer_protocol_negotiation(20)”)，它可以被端点包括以在连接建立期间协商多协议支持。

(“multi_layer_protocol_negotiation(16)”)扩展的“extension_data”字段包含“MultiLayerProtocolList”值。“LayerName”包括协议层的名称。协议层由不透明的非空的字节字符串命名。不包括空字符串并且不截断字节字符串。可以使用以下层名称：(1)数据链路层＝“dlink”，(2)网络层＝“network”。(3)传输层＝“transport”，(4)具有标准化TCP端口的应用层协议＝“app/tcp”，(5)具有标准化SCTP端口的应用层协议＝“app/sctp”，以及(6)具有标准化UDP端口的应用层协议＝“app/udp”。“ProtocolList”包括16位值的列表，其中每个值标识一个协议。协议的值取决于协议列表适用的层。可以使用以下协议的逐层值。针对“dlink”，可以使用以下协议值：(a)以太网＝1，(b)PPP(点对点协议)＝2，(c)HDLC(高级数据链路控制)＝3，(d)IEEE 802.11无线LAN＝4，(e)LLDP(链路层发现协议)＝5，以及(f)帧中继＝6。针对“network”，可以使用标准化的以太网类型值(使得所有现有网络层协议自动适用于该扩展)。针对“transport”，可以使用标准化协议类型值(使得所有现有传输层协议、以及网络层的其他用户协议都自动适用于该扩展)。针对“app/tcp”，可以使用应用协议的标准化TCP端口号。针对“app/udp”，可以使用应用协议的标准化UDP端口号。针对“app/sctp”，可以使用应用协议的标准化SCTP端口号。在QUIC连接建立期间MLPN的使用可以以下各项执行：(1)在连接建立消息中，客户端发送MultiLayerProtocolList，其包括它打算通过QUIC连接传输的协议列表，(2)服务器检查MultiLayerProtocolList，重置服务器不打算在连接中支持的协议，并且返回更新后的MultiLayerProtocolList，以指示所选择的协议，作为其响应的一部分，以及(3)如果服务器不支持客户端的任何协议请求，则它可以挑选中止连接。因此，一旦连接完成，安全隧道就被建立，并且客户端和服务器就将使用哪些协议达成一致，它们可以立即开始通信。

图55描绘了QUIC分组的通用流帧格式的示例实施例。通用流帧格式5500包括类型字段、标志字段、层字段、协议ID字段、流ID字段、偏移字段、长度字段和流数据字段。

类型字段是一个8位字段，它是任何QUIC帧的公共字段，用于指示帧的类型。当前的QUIC规范定义了值为0x00-0x1e的帧类型。应当理解，可以分配任何可用值(例如，0x20等)来指示GENERIC_STREAM帧。注意，如果在IETF中标准化，则用于指示GENERIC_STREAM帧的值可以保留在IANA中的QUIC协议注册表中。

标志字段是一个4位字段，可以承载多个标志，包括报头位、OFF(偏移)位、LEN(长度)位和FIN位。

报头位(0x8)字段在有效载荷(流数据字段)是面向数据报的(例如，以太网、IP等)时适用。在设置时，表示流数据从数据报的开头(即，协议包的报头)开始。如果未设置报头位，则表示流数据承载协议分组的片段。这也表示，在单个帧上打包多个数据报。由于QUIC中的流按顺序递送帧，因此不需要指示片段相针对原始分组的偏移。

OFF位(0x4)字段设置为指示存在偏移字段。当OFF位设置为1时，存在偏移字段。当OFF位设置为0时，偏移字段不存在，并且流数据从偏移0开始(即，该帧包括流的第一字节，或不包括数据的流的结尾)。

LEN位(0x2)字段设置为指示存在长度字段。如果LEN位设置为0，则长度字段不存在，并且流数据字段扩展到分组的结尾。如果LEN位设置为1，则存在长度字段。

FIN位(0x1)字段在包括流的最终大小的帧上设置。设置该位之上该帧标志着流的结束。

层类型字段是一个4位字段，指示帧中承载的协议分组的层级。注意，可以定义以下值：(1)0x01＝数据链路层，(2)0x02＝网络层，(3)0x03＝传输层(注意，这也包括在网络层上运行的任何非传输协议，(4)0x04＝具有TCP端口的应用层，这表示，它包括具有标准化TCP端口号的任何应用协议，(5)0x05＝具有UDP端口的应用层，这意味着，它包括具有标准化TCP端口号的任何应用协议，以及(6)0x06＝具有SCTP端口的应用层，这表示，它包括具有标准化TCP端口号的任何应用协议。可以理解，可以使用任何其他合适的值。

协议ID字段是一个16位字段，指示层类型中的协议。这些值取决于层类型字段。

例如，当层类型为数据链路层(0x01)时，该字段中的值可以定义如下：(a)以太网＝1，(b)PPP(点对点协议)＝2，(c)HDLC(高级数据链路控制)＝3，(d)IEEE 802.11无线LAN＝4，(e)LLDP(链路层发现协议)＝5，以及(f)帧中继＝6。可以理解，未被包括在上述列表中的其他数据链路层协议可以被分配在7-65535范围内的值。应当理解，可以使用其他合适的值。

例如，当层类型是网络层(0x02)时，该字段中的值可以根据IANA中定义的Ethertypes的标准化值来设置。应当理解，可以使用其他合适的值。

例如，当层类型为传输层(0x03)时，该字段中的值可以根据IP号的标准化值设置。应当理解，可以使用其他合适的值。

流ID字段包括可变长度整数以指示流的流ID。

偏移字段是可变长度整数，用于指定该GENERIC_STREAM帧中的数据在流中的字节偏移。当OFF位设置为1时，该字段存在。当偏移字段不存在时，偏移为0。

长度字段是可变长度整数，用于指定该GENERIC_STREAM帧中流数据字段的长度。该字段在LEN位被设置为1时出现。当LEN位被设置为0时，流数据字段会消耗分组中的剩余字节。

流数据字段是可变长度字段，包括来自指定流的要递送的字节。如果设置了报头位，则在以太网分组的情况下，它以以太网报头开始，在IPv4分组的情况下，它以IP报头开始，以此类推。

各种示例实施例可以被配置为支持用于MPLS-in-QUIC的以下方法。

用于支持MPLS-in-QUIC的各种示例实施例可以被配置为使得在连接建立期间，充当客户端的LSR通过在MultiLayerProtocolList中至少包括以下协议来使用MLPN来协商MPLS-in-QUIC：具有LayerProtocolList->layer_name"network"的LayerProtocolList条目和包括MPLS的Ethertype值(例如，0x8847)的LayerProtocolList->protocols。

用于支持MPLS-in-QUIC的各种示例实施例可以被配置为使得每个MPLS覆盖作为QUIC连接中的独立流被传输。来自MPLS覆盖的分组作为GENERIC_STREAM帧的有效载荷被承载，其中帧中的“层”字段使用值0x02(网络层)被编码，协议ID字段使用MPLS的以太网类型值(例如，0x8847)被编码。“流ID”字段使用分配给MPLS覆盖的流ID被编码。标志字段中的报头位可以被设置为0以指示有效载荷是面向流的，因为MCH被包括在流中，它在有效载荷中划分MPLS分组；然而，在根据定义的规则来设置报头位以在有效载荷中划分MPLS分组的情况下，实现也可以排除MCH。使用这种方法，可以通过两个LSR之间的QUIC连接来复用两个LSR之间的多个MPLS覆盖。注意，流ID空间是LSR本地的，因此每个LSR可以从其本地空间中独立分配未使用流ID。通过QUIC连接发送MPLS覆盖分组的LSR在QUIC分组中的对应数据块中使用其分配的流ID。注意，针对接收LSR，接收的数据块的流ID与对应MPLS覆盖之间没有相关性，因为LSR基于数据块的有效载荷中MPLS分组的MPLS标签堆栈来标识覆盖。还应当注意，流ID值0期望不会用于传输MPLS覆盖的MPLS分组，因为它可以由两个LSR保留，以用于在QUIC连接上复用的所有MPLS覆盖的批量管理(例如，用于管理MOIF或执行其他管理功能)。

图56描绘了用于复用N个MPLS覆盖分组的QUIC分组的示例实施例。注意，图56的QUIC分组5600实现了图50的概念格式。在图56中，流ID分别被分配有整数值1至N。

各种示例实施例包括用于为MPLS-in-QUIC配置QUIC连接的方法。当LSR发现需要与远程LSR建立新的QUIC连接以建立MPLS覆盖分组隧道传输时，LSR：(1)确定要与其建立QUIC连接的远程LSR的至少一个IP地址(注意，在QUIC连接的生命周期内，QUIC分组可以在LSR处的IP地址池中的任何一对IP地址之间交换)，并且(2)确定QoS信息，QoS信息可以用于封装QUIC分组的IP报头中的适当的QoS标记。

图57描绘了用于针对MPLS-in-QUIC配置QUIC连接的方法的示例实施例。方法5700可以基于图16中呈现的通用方法1600。应当理解，虽然主要呈现为串行执行，但是方法5700的框的至少一部分可以同时或以不同于图57中呈现的顺序执行。在框5701，方法5700开始。框5702选择可以用于发送和接收隧道业务的一个或多个配置的本地IP地址，然后方法5700进行到框5704。框5704分配要用于新的连接的本地连接ID，使得该号码当前未被另一现有QUIC连接使用，方法5700然后进行到框5706。框5706构建MLPN以包括在嵌入在连接请求中的TLS消息中。MLPN包括对“网络”层中协议ID MPLS(＝0x8847)的支持，然后方法5700进行到框5708。框5708生成带有从本地IP地址中的一个本地IP地址到远程IP地址的连接ID的QUIC连接请求。QUIC连接请求是QUIC分组，它承载用于加密握手和MLPN的数据。QUIC连接请求通过UDP分组发送。在UDP分组中，本地端口号设置为任意随机值，目的地端口号设置为80、443、或为整个网络以管理方式选择的值，以将QUIC标识为用户协议。注意，如果QUIC连接请求被远程LSR拒绝，则LSR应当采取行动以限制用于建立连接的不必要的重复尝试。例如，LSR可以在尝试重新建立连接之前等待60秒。从框5708，方法5700进行到框5710。框5710检查远程LSR是否接受QUIC连接请求(意味着成功)。如果远程LSR接受QUIC连接请求(成功)，则该LSR将接收到来自远程LSR的握手，该握手包括远程LSR为连接分配的连接ID。如果远程LSR接受QUIC连接请求(成功)，则方法5700进行到框5712，否则方法5700进行到框5714。框5714声明配置连接的失败，然后方法5700进行到框5799，在框5799处，方法5700结束。框5712执行连接后跟进(如果有)，然后方法5700进行到框5799，在那里方法5700结束。在框5799处，方法5700结束。

图58描绘了用于针对MPLS-in-QUIC的QUIC连接执行连接后跟进的方法的示例实施例。注意，方法5800可以由发起QUIC连接的LSR执行。方法5800可以被用于提供图57的方法5700的框5712。方法5800可以基于图14中呈现的通用方法1400。应当理解，虽然主要呈现为串行执行，但是方法5800的框的至少一部分可以同时或以不同于图58中呈现的顺序执行。方法5800的输入包括已经开始运行的QUIC连接。在框5801处，方法5800开始。框5802检查MOIF的要求是否在LSR中被配置。如果MOIF的要求在LSR中被配置，则方法5804进行到框5804，否则方法5800进行到框5899，方法5800结束。框5804构建MOIF并且填充必要的字段。注意，框5804可以通过图60的方法6000来实现。从框5804，方法5800进行到框5806。框5806通过QUIC连接发送MOIF。MOIF作为QUIC分组中GENERIC_STREAM帧的有效载荷发送，其中流ID字段中的值被编码为0。层类型字段编码为网络层的值0x02，协议ID编码为MPLS的值0x8847。从框5806，方法5800然后进行到框5808。框5808等待来自对等LSR的MOIF响应。例如，LSR可以等待MOIF响应至少90秒或任何其他合适的时间长度。为了等待，LSR可以在其期望MOIF响应的持续时间内启动定时器，并且将定时器与QUIC连接相关联。从框5808，方法5800然后进行到框5899，在框5899处，方法5800结束。注意，当发起LSR接收到来自对等LSR的MOIF响应时，它可以执行图17的方法1700。应当注意，在连接上接收的分组是MOIF的确定可以作为QUIC连接上MPLS覆盖分组的通用处理的一部分来进行，这在图66的方法6600的框6602-6618中描述。在框5899处，方法5800结束。

图59描绘了当在针对QUIC连接的预定义时间段内未接收到MOIF响应时使用的方法的示例实施例。注意，发起LSR在预定义时间段内未能接收到MOIF响应的情况可以被确定，其中在图58的框5808处设置的超时在没有接收到MOIF响应的情况下到期。应当理解，虽然主要呈现为串行执行，但是方法5900的框的至少一部分可以同时或以不同于图59中呈现的顺序执行。方法5900的输入包括关于MOIF等待定时器到期的通知。在框5901，方法5900开始。框5902检索与定时器的QUIC连接，然后方法5900进行到框5904。框5904关闭QUIC连接，然后方法5900进行到框5999，在那里方法5900结束。在框5999处，方法5900结束。

图60描绘了用于配置QUIC连接侦听器的方法的示例实施例。注意，LSR可以使用方法6000来侦听针对MPLS-in-QUIC的QUIC连接请求(例如，侦听针对作为用户协议的MPLS的新QUIC连接请求)。注意，MPLS-in-QUIC连接侦听器可以由配置MPLS覆盖的任何LSR实现。方法6000可以基于图18中呈现的通用方法1800。应当理解，虽然主要呈现为串行执行，但是方法6000的框的至少一部分可以同时或以不同于图60中呈现的顺序执行。在框6001处，方法6100开始。框6002打开UDP端口80、443或网络范围的以管理方式配置的值以将QUIC标识为用户协议，然后方法6000进行到框6004。框6004将端口绑定到为QUIC连接而挑选的LSR中的本地IP地址集，然后开始在任一IP地址上侦听端口的传入QUIC连接请求。从框6004，方法6000进行到框6099，在那里方法6000结束。在框6099处，方法6000结束。

图61描绘了用于处理传入QUIC连接请求的方法的示例实施例。注意，传入连接请求可以在QUIC的UDP端口上接收。方法6100可以基于图19中呈现的通用方法1900。应当理解，虽然主要呈现为串行执行，但是方法6100的框的至少一部分可以同时或以不同于图61中呈现的顺序执行。方法6100的输入包括具有以下关联参数的UDP分组：(1)源IP地址，其是发送请求的远程LSR的IP地址，(2)目的地IP地址，其是本地IP分组被发送通往的该LSR的地址，(3)源端口，其是远程LSR处的UDP端口，以及(4)目的地端口，其是分组被发送到的该LSR的UDP端口。在框6101处，方法6100开始。框6102检查LSR中的UDP是否准备好在目的地IP地址处的目的地端口上接收分组。如果LSR中的UDP未准备好在目的地IP地址处的目的地端口上接收分组，则方法6100进行到框6124，否则方法6100进行到框6104。框6124丢弃分组，然后方法6100进行到框6199，在那里方法6100结束。框6104检查UDP目的地端口是否将用户协议指示为QUIC(例如，端口是80、443或以管理方式而被配置的值(如果有))。如果UDP目的地端口没有将用户协议指示为QUIC，则方法6100进行到框6118，否则方法6100进行到框6106。框6118按照与端口相关联的用户协议来处理UDP分组的有效载荷。从框6118，该方法进行到框6199，在那里方法6100结束。框6106检查是否允许来自远程LSR(例如，来自源IP地址)的QUIC分组。注意，可以使用各种因素来确定LSR是否应当允许来自IP地址的QUIC分组。例如，LSR可以采用一种方法来发现可以参与与LSR的MPLS覆盖的QUIC连接的所有潜在远程LSR及其本地IP地址集。如果不允许来自远程LSR的QUIC分组，则方法6100进行到框6124，否则方法6100进行到框6108。框6124丢弃QUIC分组，然后方法6100进行到框6199，在那里方法6100结束。框6108检查QUIC分组是否承载连接请求(例如，该确定可以根据QUIC规范做出)。如果QUIC分组承载连接请求，则方法6100进行到框6110，否则方法6100进行到框6120。框6120将该分组作为用于现有连接的QUIC分组进行处理，然后方法6100进行到框6199，在那里方法6100结束。框6110检查连接请求是否包括MLPN，如果连接请求是由远程LSR根据本文中呈现的各种实施例而做出的(例如，通过由LSR做出连接请求而实现的图57的方法5700)，则情况将如此。如果连接请求不包括MLPN，则方法6100进行到框6122，否则方法6100进行到框6112。框6122处理连接请求。框6112检查MLPN是否包括对MPLS的支持(例如，层类型“网络”和协议0x8847)。注意，如果连接请求是由远程LSR根据本文中呈现的各种实施例做出的(例如，通过由LSR做出连接请求而实现的图57的方法5700)，则将支持MPLS。如果MLPN中不支持MPLS，则方法6100进行到框6122，否则方法6100进行到框6114。框6122处理连接请求。框6114接受对新QUIC连接的请求。注意，框6114可以按照QUIC规范中新的连接的服务器过程来实现，诸如在为连接分配本地连接ID的情况下，连接的状态使用元组{本地连接ID，远程连接请求的QUIC分组中接收到的连接ID}来创建，并且LSR向远程LSR发送响应，响应具有协商的加密、认证密钥和其他连接参数。从框6114，方法6100进行到框6116。在框6116，执行连接后跟进(如果有)。注意，6116可以通过图20的方法2000来实现，如果被配置为接收MOIF，则使LSR等待来自每个LSR的MOIF。注意，在连接上接收的分组是MOIF的确定可以作为关联上MPLS覆盖分组的通用处理的一部分来进行(例如，使用图66的方法6600的框6602-6616)。注意，如果LSR未能在预定义时间段内接收MOIF(例如，在图20的方法2000中的框2004处设置的超时到期)，则LSR可以执行图59的方法5900(例如，因此，处置在发起和接收LSR两者中是常见的)。注意，当从对等LSR接收到MOIF时，LSR可以执行图21的方法2100。从框6116，方法6100进行到框6199，在那里方法6100结束。在框6199处，方法6100结束。

各种示例实施例包括用于配置由LSR到远程LSR的MPLS-in-QUIC覆盖的方法。为了配置MPLS-in-QUIC覆盖，LSR在与远程LSR的QUIC连接上为覆盖分配一个唯一非零流ID。注意，流ID空间是LSR本地的，因此每个LSR可以从其本地空间中独立分配未使用流ID。在QUIC连接中扮演客户端角色的LSR分配偶数的流ID，在QUIC连接中扮演服务器角色的LSR分配奇数的流ID。通过QUIC连接发送MPLS覆盖分组的LSR在QUIC分组中的对应GENERIC_STREAM帧中使用其本地分配的流ID。针对接收/远程LSR，接收的GENERIC_STREAM帧的流ID与对应MPLS覆盖之间没有相关性，因为LSR根据数据块的有效载荷中MPLS分组的MPLS标签堆栈来标识覆盖。

图62描绘了用于在QUIC连接上配置MPLS覆盖以形成MPLS-in-QUIC覆盖的方法的示例实施例。注意，当LSR准备与远程LSR建立MPLS-in-QUIC覆盖时，它确定要与其建立QUIC连接的远程LSR的IP地址，然后确定QUIC连接参数和QUIC连接的QoS信息。方法6200可以基于图22中呈现的通用方法2200。应当理解，虽然主要呈现为串行执行，但是方法6200的框的至少一部分可以同时或以不同于图62中呈现的顺序执行。方法6200的输入包括LSP/覆盖的传出MPLS标签和LSP/覆盖的远程LSR的IP地址。在框6201处，方法6200开始。框6202针对MPLS-in-QUIC检查是否存在与远程LSR的QUIC连接。如果针对MPLS-in-QUIC不存在与远程LSR的现有QUIC连接，则方法6200进行到框6212，否则方法6200进行到框6204。框6204针对MPLS-in-QUIC检索与远程LSR的第一QUIC连接，然后方法6200进行到框6206。框6206检查在连接中是否存在至少一个未使用非零流ID可用。如果有至少一个未使用非零流ID可用，则该连接可以用于覆盖，然后方法6200进行到框6216，否则该连接不能被用于覆盖，然后方法6200进行到框6208。6208针对检查是否有更多与远程LSR的QUIC连接。如果针对MPLS-in-QUIC有更多与远程LSR的QUIC连接，则方法6200进行到框6210，否则方法6200进行到框6212。框6212针对MPLS-in-QUIC检索与远程LSR的下一QUIC连接，然后方法6200返回到框6206以评估下一连接作为覆盖隧道的可行性。框6212针对MPLS-in-QUIC配置与远程LSR的新QUIC连接。注意，框6212可以通过图57的方法5700来实现。从框6212，方法6200进行到框6214。框6214检查连接是否已经成功建立。如果连接尚未成功建立，则方法6200进行到框6226，否则方法6200进行到框6216。框6226声明并且处理配置MPLS覆盖的失败。框6216分配LSP标识符以在LSR中唯一地标识MPLS覆盖。LSP标识符绑定QUIC连接、(多个)传出标签和与MPLS覆盖相关联的其他参数。从框6216，方法6200然后进行到框6218。框6218将LSP/覆盖的传出MPLS标签设置为LSP标识符的传出标签，然后方法6200进行到框6220。框6220将QUIC连接设置为与LSP标识符相关联的隧道，方法6200然后进行到框6222。框6222分配连接中未使用流ID作为要用于为覆盖交换分组的流的标识符。从框6222，方法6200进行到框6224。框6224在LSP标识符与覆盖的流ID之间创建映射。从框6224，该方法进行到框6299，在那里方法6200结束。在框6299处，方法6200结束。

图63描绘了用于在MPLS-in-QUIC上传输分组的方法的示例实施例。方法6300可以基于图23中呈现的通用方法2300(不同之处在于，框2310可以不被实现，因为MPLS-in-QUIC分组中没有QUIC报头的动态参数)。应当理解，虽然主要呈现为串行执行，但是方法6300的框的至少一部分可以同时或以不同于图63中呈现的顺序执行。方法6300的输入包括要传输的分组和标识LSP或MPLS覆盖的LSP标识符。在框6301处，方法6300开始。框6302通过LSP标识符来检索LSP的传出标签的状态，然后方法6300进行到框6304。框6304获取针对LSP标识符而配置的QUIC隧道，即，可靠传输层连接，然后方法6300进行到框6306。框6306将LSP的传出标签推送到分组上，然后方法630进行到框6308。框6308针对分组根据需要设置推送标签中的S位、EXP和TTL字段。例如，如果分组在推送LSP的传出标签之前已经有另一标签，则S位设置为0，否则S位设置为1。TTL和EXP值可以由为LSP而配置的策略来设置。例如，如果策略要求对LSP上的所有分组使用一致的EXP值，则设置配置的EXP值。如果策略具有基于分组的本机报头中的某些字段的EXP值的映射，则设置映射的EXP值。从框6308，方法6300进行到框6310。框6310在QUIC连接上发送MPLS分组，然后方法6300进行到框6399，在那里方法6300结束。在框6399处，方法6300结束。

图64描绘了用于在QUIC连接上传输MPLS分组的方法的示例实施例。方法6400可以用于提供图63的方法6300的框6310，并且可以基于图24中呈现的通用方法2400(不同之处在于，QUIC报头没有动态参数)。应当理解，虽然主要呈现为串行执行，但是方法6400的框的至少一部分可以同时或以不同于图64中呈现的顺序执行。方法6400的输入包括要被传输的MPLS分组和标识LSP或MPLS覆盖的LSP标识符。在框6401处，方法6400开始。框6402检索映射到MPLS覆盖的LSP标识符的流ID，然后方法6400进行到框6404。框6404使用MPLS分组作为其有效载荷为流ID构建GENERIC_STREAM帧，然后方法6400进行到框6406。框6406检查一个或多个帧是否在QUIC连接上等待被发送。由于QUIC可以将多个帧捆绑在单个QUIC分组上，因此之前的帧可能已经排队等待发送。其次，由于拥塞、流量控制等，先前的帧也可能处于未决状态。如果没有待处理的帧，则方法6400进行到框6408，否则方法6400进行到框6410。框6408创建空的帧堆栈，然后方法6400进行到框6410。框6410将GENERIC_STREAM帧(包括MPLS分组)推送到帧堆栈中，然后方法6400进行到框6412。框6412检查帧堆栈是否准备好通过QUIC连接被发送。由于拥塞、流量控制等原因，帧堆栈可能不会立即被发送，或者LSR可能在时间窗口内等待更多帧以发送最佳大小的QUIC分组。如果帧堆栈尚未准备好要被发送，则帧堆栈将在稍后准备好时被发送，因此方法6400进行到框6499，在框6499，方法6400结束(例如，直到稍后方法6400可以重新执行)。如果帧堆栈准备好要被发送，则方法6400进行到框6414。框6414将连接的QUIC报头(例如，认为适合于连接的QUIC长报头或QUIC短报头)推送到帧堆栈上。这会产生完整QUIC分组。QUIC报头中的目的地连接ID字段根据连接中协商的连接ID被填充。注意，框6404-6414可以由LSR中的QUIC层执行。从框6414，方法6400进行到框6416。框6416将UDP报头推送到QUIC分组上。UDP报头中的源端口可以是随机值，也可以是基于等价多路径(ECMP)散列的值。UDP报头中的目的地端口设置为将QUIC分组指示为其有效载荷，例如，它可以是80、443或以管理方式而被选择的网络范围值。从框6416，方法6400进行到框6418。框6418将IP报头推送到UDP分组上。IP报头中的源地址和目的地地址根据QUIC连接中的一对本地和远程IP地址被填充(地址由框6414提供)。协议字段(如果是IPv4报头)或下一报头字段(如果是IPv6报头)设置为17以指示有效载荷为UDP。从框614，方法6400进行到框6420。框6420对IP报头中的目的地地址执行IP路由表查找，这导致分组的下一跳，然后方法6400进行到框6422。注意，框6418-6420可以由LSR中的IP层执行。框6422将数据链路层报头推送到IP分组上，该IP分组用于在链路上将分组发送到下一跳。从框6422，方法6400进行到框6424。框6424在线路上将分组发送到下一跳，然后方法6400进行到框6499，在那里方法6400结束。在框6499处，方法6400结束。

图65描绘了用于接收和处理MPLS-in-QUIC分组的方法的示例实施例。方法6500可以基于图25中呈现的通用方法2500。应当理解，虽然主要呈现为串行执行，但是方法6500的框的至少一部分可以同时或以不同于图65中呈现的顺序执行。方法6500的输入包括在线路上接收的分组。在框6501处，方法6500开始。

框6502解析在处理分组之上的数据链路报头，方法6500进行到框6504。注意，框6502可以由LSR的数据链路层执行。

框6504检查数据链路层是否指示分组是本地的，这意味着，执行方法6500的该LSR是分组在其上到达的数据链路的终止点。例如，如果数据链路报头是以太网报头，并且如果以太网报头中的目的地MAC地址是LSR本地的，则以太网链路终止于LSR。如果分组在数据链路层是本地的，则方法6500进行到框6506，否则方法6500进行到框6526。框6526在数据链路层将分组作为非本地分组进行处置，这可以导致在数据链路层处进一步转发分组，然后方法6500进行到框6599，在那里方法6500结束。由于LSR是数据链路的末端，因此框6506从分组中移除数据链路报头，然后方法6500进行到框6508。注意，框6504-6506和框6526可以由数据链路层执行LSR。

框6508检查数据链路报头指示的有效载荷是否是IP。例如，如果数据链路报头是以太网报头，则其Ethertype字段指示有效载荷类型。如果以太网报头有VLAN标签，则最后的VLAN标签中的Ethertype字段指示有效载荷类型。如果有效载荷是IP，则方法6500进行到框6510，否则方法6500进行到框6528。框6528将分组作为非IP分组进行处置，然后方法6500进行到框6599，在那里方法6500结束。注意，框6508和框6526可以由LSR的数据链路层执行。

框6510基于其IP报头在IP层中处理IP分组。例如，在IP路由表中查找IP报头的目的地地址，以对IP分组做出转发决策。从框6510，方法6500进行到框6512。框6512检查目的地地址是否是本地的(例如，IP路由表查找是否与作为LSR中本地配置的IP地址的目的地地址匹配)。如果目的地地址不是本地的，则方法6500进行到框6530，否则方法6500进行到框6514。框6530将分组作为非本地IP分组进行处置，例如通过将分组转发到与来自IP路由表查找的匹配路由条目相关联的下一跳，然后方法6500进行到框6599，在那里方法6500结束。注意，框6510-6512和框6530可以由LSR的IP层执行。

框6514从IP分组中移除IP报头，因为它是本地分组，然后方法6500进行到框6516。框6516检查分组是否是UDP分组。例如，如果IP报头是IPv4，则框6516可以检查IPv4报头中的协议字段是否设置为17(UDP)，或者如果IP报头是IPv6，则框6516可以检查IPv6报头中的下一报头字段是否被设置为17(UDP)。如果分组不是UDP分组，则方法6500进行到框6532，否则方法6500进行到框6518。框6532处置相应IP协议类型的分组，然后方法6500进行到框6599，在那里方法6500结束。注意，框6514-6516可以由LSR的IP层执行。

框6518检查UDP报头中的目的地端口是否指示QUIC作为有效载荷(例如，该值是80、443或以管理方式而被分配的网络范围值以将QUIC标识为有效载荷)。如果有效载荷不是QUIC，则方法6500进行到框6534，否则方法6500进行到框6520。框6534处理相应端口的分组，然后方法6500进行到框6599，在那里方法6500结束。

框6520基于QUIC长报头或QUIC短报头中的目的地连接ID查找QUIC分组的QUIC连接，然后方法6500进行到框6522。框6522检查是否找到匹配的QUIC连接。如果没有找到匹配的QUIC连接，则方法6500进行到框6536，否则方法6500进行到框6524。框6536将分组作为错误分组丢弃，然后方法6500进行到框6599，在那里方法6500结束。

框6524对QUIC分组执行QUIC层处理。针对分组中指示MPLS作为其有效载荷的每个GENERIC_STREAM帧，它处理来自帧中流数据的MPLS分组。从框6524，方法6500进行到框6599，在那里方法6500结束。

在框6599处，方法6500结束。

图66描绘了用于处理来自QUIC分组的MPLS-in-QUIC分组的方法的示例实施例。方法6600可以用于提供图65的方法6500的框6524，并且可以基于图25中呈现的通用方法2500。应当理解，虽然主要呈现为串行执行，但是方法6600的框的至少一部分可以同时或以不同于图66中呈现的顺序执行。方法6600的输入包括为潜在的现有连接接收的QUIC分组。在框6601处，方法6600开始。框6602处理接收的分组中的QUIC短报头或QUIC长报头(以存在者为准，尽管将意识到最有可能它将是QUIC短报头)。在该框中，根据报头中的连接ID查找现有QUIC连接。从框6602，方法6600进行到框6604。框6604检查是否找到连接。如果未找到连接，则方法6600进行到框6630，否则方法6600进行到框6606。框6630丢弃分组，然后方法6600进行到框6699，在框6699，方法6600结束。框6606解析QUIC分组中的第一帧，然后方法6600进行到框6608。框6608检查该帧是否是GENERIC_STREAM帧。如果该帧不是GENERIC_STREAM帧，则方法6600进行到框6624，否则方法6600进行到框6610。框6624使用QUIC机制处理该帧，然后方法6600进行到框6626。框6610读取流数据来自GENERIC_STREAM帧的(有效载荷)，然后方法6600进行到框6612。框6612检查由GENERIC_STREAM中的层类型和协议ID字段确定的有效载荷是否指示分组是MPLS分组。如果有效载荷类型是MPLS，则方法6600进行到框6614，否则方法6600进行到框6632。框6632根据有效载荷类型来处理有效载荷。框6614检查GENERIC_STREAM中的流ID是否是0。如果GENERIC_STREAM中的流ID不为0，则方法6600进行到框6620，否则方法6600进行到框6616。框6620向MPLS覆盖层提供有效载荷层。有效载荷中MPLS分组的MPLS标签堆栈标识MPLS有效载荷所属的MPLS覆盖。从框6620，方法6600进行到框6626。框6616检查有效载荷是否是MOIF分组。如果GENERIC_STREAM帧的流ID为0并且有效载荷为MOIF，则该确定被做出。如果有效载荷不是MOIF分组，则该分组不是期望的，然后方法6600进行到框6622，否则方法6600进行到框6618。框6622使用适当的方法关闭QUIC连接(例如，通知远程LSR关闭的原因，诸如通过在连接的上下文中的QUIC分组中发送CONNECTION_CLOSE帧)，然后方法6600进行到框6699，在框6699，方法6600结束。框6618处理MOIF。注意，如果LSR是连接的发起者，则框6618可以通过图17的方法1700来实现。参考图17，否则框6618可以通过图21的方法2100实现。从框6618，方法6600进行到框6626。注意，框6614-6620可以由MPLS覆盖层执行，MPLS覆盖是QUIC连接的用户。框6626检查QUIC分组中是否有更多帧。如果QUIC分组中没有更多帧，则方法6600进行到框6699，在那里方法6600结束，否则方法600进行到框6628。框6628解析QUIC分组中的下一帧，然后方法6600返回到框6608以针对下一帧重复后续框。在框6699处，方法6600结束。

注意，中间路由器在接收到UDP封装的QUIC分组之后，可以根据UDP分组的五元组(即，IP报头中的源IP地址、IP报头中的目的地IP地址、UDP报头中的源端口、UDP报头中的目的地端口、和IP报头中的协议/下一报头字段)的散列值来平衡这些分组。如果需要在MPLS覆盖之间进行负载平衡，则可以在QUIC连接中的两个LSR处使用IP地址池，然后将其分配以跨IP地址池发送MPLS覆盖分组。

应当理解，虽然为了清楚的目的而省略了，但是本文中呈现的用于支持MPLS-in-TCP、MPLS-in-SCTP和MPLS-in-QUIC的各种示例实施例可以使用或被适配以使用以提供MPLS-in-TLS。

图67描绘了用于支持覆盖的可靠性的方法的示例实施例。应当理解，虽然主要呈现为串行执行，但是方法6700的框的至少一部分可以同时或以不同于图67中呈现的顺序执行。在框6701处，方法6700开始。框6710处，通过通信设备支持分组的通信，该分组包括有效载荷、在有效载荷上的标签交换协议的报头、和在标签交换协议的报头上的可靠传输层协议的报头。在框6799处，方法6700结束。

用于支持覆盖的可靠性的各种示例实施例可以提供各种优点或潜在优点。例如，用于支持覆盖的可靠性的各种示例实施例可以避免依赖相对不可靠的覆盖(例如，在MPLS覆盖的情况下，相对不可靠的覆盖，例如MPLS-in-IP覆盖、MPLS-in-GRE覆盖)、MPLS-in-UDP覆盖等)；然而，应当理解，至少一些这样的覆盖仍可以用于各种目的。用于支持覆盖的可靠性的各种示例实施例可以提供各种其他优点或潜在优点。

计算机6800包括处理器6802(例如，中央处理单元(CPU)、处理器、具有处理器核集的处理器、处理器的处理器核等)和存储器6804(例如，随机存取存储器、只读存储器等)。处理器6802和存储器6804可以通信连接。在至少一些示例实施例中，计算机6800可以包括至少一个处理器和包括计算机程序代码的至少一个存储器，其中至少一个存储器和计算机程序代码被配置为与至少一个处理器一起引起计算机执行本文中介绍的各种功能。

计算机6800还可以包括协作元件6805。协作元件6805可以是硬件设备。协作元件6805可以是可以被加载到存储器6804中并且由处理器6802执行以实现本文中呈现的各种功能的进程(例如，在这种情况下，协作元件6805(包括相关联的数据结构)可以存储在非瞬态计算机可读存储介质中，例如存储设备或其他合适类型的存储元件(例如，磁驱动器、光驱动器等))。

计算机6800还可以包括一个或多个输入/输出设备6806。输入/输出设备6806可以包括一个或多个用户输入设备(例如，键盘、小键盘、鼠标、麦克风、相机等)、用户输出设备(例如，显示器、扬声器等)、一个或多个网络通信设备或元件(例如，输入端口、输出端口、接收器、传输器、收发器等)、一个或多个存储设备(例如，磁带驱动器、软盘驱动器、硬盘驱动器、压缩盘驱动器等)等、以及其各种组合。

应当理解，计算机6800可以表示适合于实现本文中描述的功能元件、本文中描述的功能元件的部分等的通用架构和功能以及其各种组合。例如，计算机6800可以提供适合于实现本文中呈现的一个或多个元件的通用架构和功能(诸如网络设备(例如，路由器等)、网络控制器等)以及其各种组合。

应当理解，本文中呈现的至少一些功能可以用软件实现(例如，通过在一个或多个处理器上实现软件，用于在通用计算机上执行(例如，经由一个或多个处理器执行)，以提供专用计算机等)，和/或可以用硬件实现(例如，使用通用计算机、一个或多个专用集成电路、和/或任何其他硬件等效物)。

应当理解，本文中呈现的至少一些功能可以在硬件内实现，例如，作为与处理器协作以执行各种功能的电路系统。本文中描述的功能/元件的各部分可以被实现为计算机程序产品，其中计算机指令在被计算机处理时调节计算机的操作，使得本文中描述的方法和/或技术被调用或以其他方式被提供。用于调用各种方法的指令可以存储在固定或可移除介质(例如，非瞬态计算机可读介质)中，通过广播或其他信号承载介质中的数据流进行传输，和/或存储在按照说明进行操作的计算设备内的存储器中。

应当理解，除非另有说明(例如，使用“否则”或“或在替代方案中”)，否则本文中使用的术语“或”是指非排他性的“或”。

应当理解，虽然本文中详细示出并且描述了结合本文中呈现的教导的各种实施例，但是本领域技术人员可以容易地设计出仍然结合这些教导的很多其他不同实施例。

Claims

1.一种装置，包括：

至少一个处理器；以及

至少一个存储器，包括指令集；

其中所述指令集被配置为在由所述至少一个处理器执行时，使所述装置：

通过通信设备支持分组的通信，其中所述分组包括有效载荷、在所述有效载荷上的标签交换协议的报头以及在所述标签交换协议的所述报头上的可靠传输层协议的报头。

2.根据权利要求1所述的装置，其中所述标签交换协议的所述报头包括标签集。

3.根据权利要求2所述的装置，其中所述标签集被组织为标签堆栈。

4.根据权利要求1至3中任一项所述的装置，其中所述标签交换协议与标签交换覆盖相关联。

5.根据权利要求1至4中任一项所述的装置，其中所述标签交换协议包括多协议标签交换(MPLS)协议。

6.根据权利要求1至5中任一项所述的装置，其中所述可靠传输层协议包括面向连接的传输层协议。

7.根据权利要求1至6中任一项所述的装置，其中所述可靠传输层协议包括被配置为支持以下至少一项的传输层协议：流量控制或拥塞控制。

8.根据权利要求1至7中任一项所述的装置，其中所述可靠传输层协议包括传输控制协议(TCP)、流控制传输协议(SCTP)、快速用户数据报协议(UDP)互联网连接(QUIC)协议、或者传输层安全(TLS)协议。

9.根据权利要求1至8中任一项所述的装置，其中所述分组包括在所述标签交换协议的所述报头与所述可靠传输层协议的所述报头之间的控制报头。

10.根据权利要求9所述的装置，其中所述控制报头被配置为指示所述有效载荷和所述标签交换协议的所述报头的大小。

11.根据权利要求1至10中任一项所述的装置，其中所述分组包括在所述可靠传输层协议的所述报头上的网络层协议的报头。

12.根据权利要求11所述的装置，其中所述网络层协议包括互联网协议(IP)。

13.根据权利要求11所述的装置，其中所述分组包括在所述网络层协议的所述报头上的数据链路层协议的报头。

14.根据权利要求13所述的装置，其中所述数据链路层协议包括以下至少一项：以太网或点对点协议(PPP)。

15.根据权利要求1至14中任一项所述的装置，其中为了支持所述分组的通信，所述指令集被配置为在由所述至少一个处理器执行时，使所述装置：

通过所述通信设备生成所述分组；以及

通过所述通信设备向下一跳节点发送所述分组。

16.根据权利要求1至15中任一项所述的装置，其中为了支持所述分组的通信，所述指令集被配置当在由所述至少一个处理器执行时，使所述装置：

通过所述通信设备接收所述分组；以及

处理所述分组。

17.根据权利要求1至16中任一项所述的装置，其中所述指令集被配置为在由所述至少一个处理器执行时，使所述装置：

通过所述通信设备支持覆盖初始帧的通信，所述覆盖初始帧被配置为传送一个或多个覆盖参数，所述一个或多个覆盖参数用于基于所述可靠传输层协议在所述通信设备与远程通信设备之间被支持的覆盖。

18.根据权利要求17所述的装置，其中所述覆盖初始帧由所述通信设备向所述远程通信设备发送，或者由所述通信设备从所述远程通信设备接收。

19.一种存储指令集的非瞬态计算机可读介质，所述指令集在由装置执行时，使所述装置：

20.一种方法，包括：