CN115244897A - 用于使用quic实现多主机多路径安全传输的方法和装置 - Google Patents

用于使用quic实现多主机多路径安全传输的方法和装置 Download PDF

Info

Publication number
CN115244897A
CN115244897A CN202180018559.5A CN202180018559A CN115244897A CN 115244897 A CN115244897 A CN 115244897A CN 202180018559 A CN202180018559 A CN 202180018559A CN 115244897 A CN115244897 A CN 115244897A
Authority
CN
China
Prior art keywords
quic
endpoint
connection
packetized data
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180018559.5A
Other languages
English (en)
Inventor
X·德福伊
S·拉赫曼
王重钢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
IDAC Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by IDAC Holdings Inc filed Critical IDAC Holdings Inc
Publication of CN115244897A publication Critical patent/CN115244897A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/56Routing software
    • H04L45/566Routing instructions carried by the data packet, e.g. active networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164Adaptation or special uses of UDP protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50Service provisioning or reconfiguring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本文描述了用于使用快速用户数据报协议(UDP)连接(QUIC)实现多主机多路径安全传输的方法和装置。一种由客户端端点执行的方法可以涉及向网络节点发送建立与目的地端点的QUIC连接的请求,建立该QUIC连接的请求包括流标识符(ID)。该方法可以涉及从网络节点接收包括建立与目的地端点的QUIC连接的请求的指示的响应。该方法可以涉及将内部QUIC分组化数据封装在外部QUIC分组化数据内,该内部QUIC分组化数据包括流ID。该方法可以涉及向网络节点发送外部QUIC分组化数据以基于流ID向目的地端点转发。

Description

用于使用QUIC实现多主机多路径安全传输的方法和装置
相关申请的交叉引用
本申请要求于2020年2月14日提交的美国临时申请号62/976,753的权益,该临时申请的内容以引用方式并入本文。
背景技术
存在可以基于数据路径的协议设计来改进数据交换的若干用例。例如,在一些用例中,可能需要通过应用程序和服务提供商对多个网络路径进行深度控制。在一些用例中,可能希望保持与重定位边缘服务器的连接。此外,在一些用例中,可能需要保持间歇性设备到设备对等体之间的连接。
发明内容
本文描述了用于使用快速用户数据报协议(UDP)连接(QUIC)实现多主机多路径安全传输的方法和装置。一种由客户端端点执行的方法可以涉及向网络节点发送建立与目的地端点的QUIC连接的请求,建立QUIC连接的请求包括流标识符(ID)。该方法可以涉及从网络节点接收包括建立与目的地端点的QUIC连接的请求的指示的响应。该方法可以涉及将内部QUIC分组化数据封装在外部QUIC分组化数据内,该内部QUIC分组化数据包括流ID。该方法可以涉及向网络节点发送外部QUIC分组化数据以基于流ID向目的地端点转发。
附图说明
由以下结合附图以举例的方式给出的描述可得到更详细的理解,其中附图中类似的附图标号指示类似的元件,并且其中:
图1A是示出在其中一个或多个所公开的实施方案可得以实现的示例性通信系统的系统图;
图1B是示出根据一个实施方案可在图1A所示的通信系统内使用的示例性无线发射/接收单元(WTRU)的系统图;
图1C是示出根据一个实施方案可在图1A所示的通信系统内使用的示例性无线电接入网络(RAN)和示例性核心网(CN)的系统图;
图1D是示出根据一个实施方案可在图1A所示的通信系统内使用的另外一个示例性RAN和另外一个示例性CN的系统图;
图2是示出通过应用程序和服务提供商对多个网络路径进行深度控制的示例的图;
图3是示出保持与重定位服务器的连接的示例的图;
图4是示出保持间歇性设备到设备(D2D)对等体之间的连接的示例的图;
图5是示出通过QUIC建立和保持安全多播或发布者/订户(PubSub)连接的示例的图;
图6是示出多跳多路径(MHMP)系统中的主节点和通信场景的示例的图;
图7是示出与代理的初始连接的示例的图,描绘了所涉及的节点和分组结构;
图8是示出使用QUIC的代理或间接连接的示例的图,描绘了所涉及的节点和分组结构;
图9是示出在客户端到代理段和代理到服务器段两者上使用UDP的代理或间接连接的示例的图,描绘了所涉及的节点和分组结构;
图10是示出端点之间的直接连接的示例的图,描绘了所涉及的节点和分组结构;
图11是示出使用建立多个QUIC连接的第一替代方案的间接连接引导方法的示例的第一部分的图;
图11是示出使用用UDP上QUIC(QUIC-over-UDP)连接代替QUIC上QUIC(QUIC-over-UDP)连接的第二替代方案的间接连接引导方法的示例的第二部分的图;
图12是示出使用ADD_ADDRESS的代理发现过程的示例的图;
图13A是示出服务器迁移过程的示例的第一部分的图;并且
图13B是示出服务器迁移过程的示例的第二部分的图。
具体实施方式
图1A是示出在其中一个或多个所公开的实施方案可得以实现的示例性通信系统100的示意图。通信系统100可为向多个无线用户提供诸如语音、数据、视频、消息、广播等内容的多址接入系统。通信系统100可使多个无线用户能够通过系统资源(包括无线带宽)的共享来访问此类内容。例如,通信系统100可采用一个或多个信道接入方法,诸如码分多址接入(CDMA)、时分多址接入(TDMA)、频分多址接入(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)、零尾唯一字离散傅里叶变换扩展OFDM(ZT-UW-DFT-S-OFDM)、唯一字OFDM(UW-OFDM)、资源块滤波OFDM、滤波器组多载波(FBMC)等。
如图1A所示,通信系统100可包括无线发射/接收单元(WTRU)102a、102b、102c、102d、无线电接入网络(RAN)104、核心网(CN)106、公共交换电话网(PSTN)108、互联网110和其他网络112,但应当理解,所公开的实施方案设想了任何数量的WTRU、基站、网络和/或网络元件。WTRU 102a、102b、102c、102d中的每一者可以是被配置为在无线环境中操作和/或通信的任何类型的设备。举例来说,WTRU 102a、102b、102c、102d(其中任何一者均可被称为站(STA))可被配置为传输和/或接收无线信号,并且可包括用户装备(UE)、移动站、固定或移动用户单元、基于订阅的单元、寻呼机、蜂窝电话、个人数字助理(PDA)、智能电话、膝上型计算机、上网本、个人计算机、无线传感器、热点或Mi-Fi设备、物联网(IoT)设备、手表或其他可穿戴设备、头戴式显示器(HMD)、车辆、无人机、医疗设备和应用(例如,远程手术)、工业设备和应用(例如,在工业和/或自动处理链环境中操作的机器人和/或其他无线设备)、消费型电子设备、在商业和/或工业无线网络上操作的设备等。WTRU 102a、102b、102c和102d中的任一者可互换地称为UE。
通信系统100还可包括基站114a和/或基站114b。基站114a、114b中的每一者可为任何类型的设备,其被配置为与WTRU 102a、102b、102c、102d中的至少一者无线对接以促进对一个或多个通信网络(诸如CN 106、互联网110和/或其他网络112)的访问。作为示例,基站114a、114b可为基站收发台(BTS)、NodeB、演进节点B(eNB)、家庭节点B、家庭演进节点B、下一代NodeB,诸如gNode B(gNB)、新无线电(NR)NodeB、站点控制器、接入点(AP)、无线路由器等。虽然基站114a、114b各自被描绘为单个元件,但应当理解,基站114a、114b可包括任何数量的互连基站和/或网络元件。
基站114a可以是RAN 104的一部分,该RAN还可包括其他基站和/或网络元件(未示出),诸如基站控制器(BSC)、无线电网络控制器(RNC)、中继节点等。基站114a和/或基站114b可被配置为在一个或多个载波频率上传输和/或接收无线信号,该基站可被称为小区(未示出)。这些频率可在许可频谱、未许可频谱或许可和未许可频谱的组合中。小区可向特定地理区域提供无线服务的覆盖,该特定地理区域可为相对固定的或可随时间改变。小区可进一步被划分为小区扇区。例如,与基站114a相关联的小区可被划分为三个扇区。因此,在一个实施方案中,基站114a可包括三个收发器,即,小区的每个扇区一个收发器。在一个实施方案中,基站114a可采用多输入多输出(MIMO)技术并且可针对小区的每个扇区利用多个收发器。例如,可使用波束成形在所需的空间方向上传输和/或接收信号。
基站114a、114b可通过空中接口116与WTRU 102a、102b、102c、102d中的一者或多者通信,该空中接口可为任何合适的无线通信链路(例如,射频(RF)、微波、厘米波、微米波、红外(IR)、紫外(UV)、可见光等)。可使用任何合适的无线电接入技术(RAT)来建立空中接口116。
更具体地讲,如上所指出,通信系统100可为多址接入系统,并且可采用一个或多个信道接入方案,诸如CDMA、TDMA、FDMA、OFDMA、SC-FDMA等。例如,RAN 104中的基站114a和WTRU 102a、102b、102c可实现无线电技术诸如通用移动电信系统(UMTS)陆地无线电接入(UTRA),其可使用宽带CDMA(WCDMA)来建立空中接口116。WCDMA可包括诸如高速分组接入(HSPA)和/或演进的HSPA(HSPA+)之类的通信协议。HSPA可包括高速下行链路(DL)分组接入(HSDPA)和/或高速上行链路(UL)分组接入(HSUPA)。
在一个实施方案中,基站114a和WTRU 102a、102b、102c可实现诸如演进的UMTS陆地无线电接入(E-UTRA)的无线电技术,其可使用长期演进(LTE)和/高级LTE(LTE-A)和/或高级LTE Pro(LTE-A Pro)来建立空中接口116。
在一个实施方案中,基站114a和WTRU 102a、102b、102c可实现无线电技术诸如NR无线电接入,其可使用NR来建立空中接口116。
在实施方案中,基站114a和WTRU 102a、102b、102c可实现多种无线电接入技术。例如,基站114a和WTRU 102a、102b、102c可例如使用双连接(DC)原理一起实施LTE无线电接入和NR无线电接入。因此,WTRU 102a、102b、102c所利用的空中接口可由多种类型的无线电接入技术和/或向/从多种类型的基站(例如,eNB和gNB)发送的传输来表征。
在其他实施方案中,基站114a和WTRU 102a、102b、102c可实现诸如IEEE 802.11(即,无线保真(WiFi))、IEEE 802.16(即,全球微波接入互操作性(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000EV-DO、暂行标准2000(IS-2000)、暂行标准95(IS-95)、暂行标准856(IS-856)、全球移动通信系统(GSM)、GSM增强数据率演进(EDGE)、GSM EDGE(GERAN)等无线电技术。
图1A中的基站114b可为例如无线路由器、家庭节点B、家庭演进节点B或接入点,并且可利用任何合适的RAT来促进诸如商业场所、家庭、车辆、校园、工业设施、空中走廊(例如,供无人机使用)、道路等局部区域中的无线连接。在实施方案中,基站114b和WTRU 102c、102d可实现诸如IEEE 802.11之类的无线电技术以建立无线局域网(WLAN)。在实施方案中,基站114b和WTRU 102c、102d可实现诸如IEEE 802.15之类的无线电技术以建立无线个域网(WPAN)。在又一个实施方案中,基站114b和WTRU 102c、102d可利用基于蜂窝的RAT(例如,WCDMA、CDMA2000、GSM、LTE、LTE-A、LTE-A Pro、NR等)来建立微微小区或毫微微小区。如图1A所示,基站114b可具有与互联网110的直接连接。因此,基站114b可不需要经由CN 106访问互联网110。
RAN 104可与CN 106通信,该CN可以是被配置为向WTRU 102a、102b、102c、102d中的一者或多者提供语音、数据、应用和/或互联网协议语音技术(VoIP)服务的任何类型的网络。数据可具有不同的服务质量(QoS)要求,诸如不同的吞吐量要求、延迟要求、误差容限要求、可靠性要求、数据吞吐量要求、移动性要求等。CN 106可提供呼叫控制、账单服务、基于移动位置的服务、预付费呼叫、互联网连接、视频分发等,和/或执行高级安全功能,诸如用户认证。尽管未在图1A中示出,但是应当理解,RAN 104和/或CN 106可与采用与RAN 104相同的RAT或不同RAT的其他RAN进行直接或间接通信。例如,除了连接到可利用NR无线电技术的RAN 104之外,CN 106还可与采用GSM、UMTS、CDMA 2000、WiMAX、E-UTRA或WiFi无线电技术的另一RAN(未示出)通信。
CN 106也可充当WTRU 102a、102b、102c、102d的网关,以访问PSTN 108、互联网110和/或其他网络112。PSTN 108可包括提供普通老式电话服务(POTS)的电路交换电话网络。互联网110可包括使用常见通信协议(诸如传输控制协议(TCP)、用户数据报协议(UDP)和/或TCP/IP互联网协议组中的互联网协议(IP))的互连计算机网络和设备的全球系统。网络112可包括由其他服务提供商拥有和/或运营的有线和/或无线通信网络。例如,网络112可包括连接到一个或多个RAN的另一个CN,其可采用与RAN 104相同的RAT或不同的RAT。
通信系统100中的一些或所有WTRU 102a、102b、102c、102d可包括多模式能力(例如,WTRU 102a、102b、102c、102d可包括用于通过不同无线链路与不同无线网络通信的多个收发器)。例如,图1A所示的WTRU 102c可被配置为与可采用基于蜂窝的无线电技术的基站114a通信,并且与可采用IEEE 802无线电技术的基站114b通信。
图1B是示出示例性WTRU 102的系统图。如图1B所示,WTRU 102可包括处理器118、收发器120、发射/接收元件122、扬声器/麦克风124、小键盘126、显示器/触摸板128、不可移动存储器130、可移动存储器132、电源134、全球定位系统(GPS)芯片组136和/或其他外围设备138等。应当理解,在与实施方案保持一致的同时,WTRU 102可包括前述元件的任何子组合。
处理器118可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、任何其他类型的集成电路(IC)、状态机等。处理器118可执行信号编码、数据处理、功率控制、输入/输出处理和/或任何其他功能,这些其他功能使WTRU 102能够在无线环境中工作。处理器118可耦合到收发器120,该收发器可耦合到发射/接收元件122。虽然图1B将处理器118和收发器120描绘为单独的部件,但是应当理解,处理器118和收发器120可在电子封装或芯片中集成在一起。
发射/接收元件122可被配置为通过空中接口116向基站(例如,基站114a)发射信号或从基站接收信号。例如,在一个实施方案中,发射/接收元件122可以是被配置为传输和/或接收RF信号的天线。在一个实施方案中,发射/接收元件122可以是被配置为传输和/或接收例如IR、UV或可见光信号的发射器/检测器。在又一个实施方案中,发射/接收元件122可被配置为传输和/或接收RF和光信号。应当理解,发射/接收元件122可被配置为传输和/或接收无线信号的任何组合。
尽管发射/接收元件122在图1B中被描绘为单个元件,但是WTRU 102可包括任何数量的发射/接收元件122。更具体地讲,WTRU 102可采用MIMO技术。因此,在一个实施方案中,WTRU 102可包括用于通过空中接口116传输和接收无线信号的两个或更多个发射/接收元件122(例如,多个天线)。
收发器120可被配置为调制将由发射/接收元件122传输的信号并且解调由发射/接收元件122接收的信号。如上所指出,WTRU 102可具有多模式能力。例如,因此,收发器120可包括多个收发器,以便使WTRU 102能够经由多种RAT(诸如NR和IEEE 802.11)进行通信。
WTRU 102的处理器118可耦合到扬声器/麦克风124、小键盘126和/或显示器/触摸板128(例如,液晶显示器(LCD)显示单元或有机发光二极管(OLED)显示单元)并且可从其接收用户输入数据。处理器118还可将用户数据输出到扬声器/麦克风124、小键盘126和/或显示器/触摸板128。此外,处理器118可从任何类型的合适存储器(诸如不可移动存储器130和/或可移动存储器132)访问信息,并且将数据存储在任何类型的合适存储器中。不可移动存储器130可包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储设备。可移动存储器132可包括用户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其他实施方案中,处理器118可从未物理上定位在WTRU 102上(诸如,服务器或家用计算机(未示出)上)的存储器访问信息,并且将数据存储在该存储器中。
处理器118可从电源134接收功率,并且可被配置为向WTRU 102中的其他部件分配和/或控制功率。电源134可以是用于为WTRU 102供电的任何合适的设备。例如,电源134可包括一个或多个干电池组(例如,镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li-ion)等)、太阳能电池、燃料电池等。
处理器118还可耦合到GPS芯片组136,该GPS芯片组可被配置为提供关于WTRU 102的当前位置的位置信息(例如,经度和纬度)。除了来自GPS芯片组136的信息之外或代替该信息,WTRU 102可通过空中接口116从基站(例如,基站114a、114b)接收位置信息和/或基于从两个或更多个附近基站接收到信号的定时来确定其位置。应当理解,在与实施方案保持一致的同时,该WTRU 102可通过任何合适的位置确定方法来获取位置信息。
处理器118还可耦合到其他外围设备138,该其他外围设备可包括提供附加特征、功能和/或有线或无线连接的一个或多个软件模块和/或硬件模块。例如,外围设备138可包括加速度计、电子指南针、卫星收发器、数字相机(用于照片和/或视频)、通用串行总线(USB)端口、振动设备、电视收发器、免提耳麦、
Figure BDA0003829449430000081
模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器、虚拟现实和/或增强现实(VR/AR)设备、活动跟踪器等。外围设备138可包括一个或多个传感器。传感器可为以下一者或多者:陀螺仪、加速度计、霍尔效应传感器、磁力计、方位传感器、接近传感器、温度传感器、时间传感器;地理位置传感器、测高计、光传感器、触摸传感器、磁力计、气压计、手势传感器、生物识别传感器、湿度传感器等。
WTRU 102可包括全双工无线电台,对于该全双工无线电台,一些或所有信号的发射和接收(例如,与用于UL(例如,用于发射)和DL(例如,用于接收)的特定子帧相关联)可为并发的和/或同时的。全双工无线电台可包括干扰管理单元,该干扰管理单元用于经由硬件(例如,扼流圈)或经由处理器(例如,单独的处理器(未示出)或经由处理器118)进行的信号处理来减少和/或基本上消除自干扰。在一个实施方案中,WTRU 102可包括半双工无线电台,对于该半双工无线电台,传输和接收一些或所有信号(例如,与用于UL(例如,用于传输)或DL(例如,用于接收)的特定子帧相关联)。
图1C是示出根据实施方案的RAN 104和CN 106的系统图。如上所述,RAN 104可采用E-UTRA无线电技术通过空中接口116与WTRU 102a、102b、102c通信。RAN 104还可与CN106通信。
RAN 104可包括演进节点B 160a、160b、160c,但是应当理解,RAN 104可包括任何数量的演进节点B,同时保持与实施方案一致。演进节点B 160a、160b、160c各自可包括一个或多个收发器以便通过空中接口116与WTRU 102a、102b、102c通信。在实施方案中,演进节点B 160a、160b、160c可实现MIMO技术。因此,演进节点B 160a例如可使用多个天线来向WTRU 102a传输无线信号和/或从WTRU 102a接收无线信号。
演进节点B 160a、160b、160c中的每一者可与特定小区(未示出)相关联,并且可被配置为处理无线电资源管理决策、切换决策、UL和/或DL中的用户的调度等。如图1C所示,演进节点B 160a、160b、160c可通过X2接口彼此通信。
图1C所示的CN 106可包括移动性管理实体(MME)162、服务网关(SGW)164和分组数据网络(PDN)网关(PGW)166。虽然前述元件被描绘为CN 106的一部分,但是应当理解,这些元件中的任何元件可由除CN运营商之外的实体拥有和/或运营。
MME 162可经由S1接口连接到RAN 104中的演进节点B 162a、162b、162c中的每一者,并且可用作控制节点。例如,MME 162可负责认证WTRU 102a、102b、102c的用户、承载激活/去激活、在WTRU 102a、102b、102c的初始附加期间选择特定服务网关等。MME 162可提供用于在RAN 104和采用其他无线电技术(诸如GSM和/或WCDMA)的其他RAN(未示出)之间进行切换的控制平面功能。
SGW 164可经由S1接口连接到RAN 104中的演进节点B 160a、160b、160c中的每一者。SGW 164通常可向/从WTRU 102a、102b、102c路由和转发用户数据分组。SGW 164可执行其他功能,诸如在演进节点B间切换期间锚定用户平面、当DL数据可用于WTRU 102a、102b、102c时触发寻呼、管理和存储WTRU 102a、102b、102c的上下文等。
SGW 164可连接到PGW 166,该PGW可向WTRU 102a、102b、102c提供对分组交换网络(诸如互联网110)的访问,以促进WTRU 102a、102b、102c和启用IP的设备之间的通信。
CN 106可有利于与其他网络的通信。例如,CN 106可为WTRU 102a、102b、102c提供对电路交换网络(诸如,PSTN 108)的访问,以有利于WTRU 102a、102b、102c与传统陆线通信设备之间的通信。例如,CN 106可包括用作CN 106与PSTN 108之间的接口的IP网关(例如,IP多媒体子系统(IMS)服务器)或者可与该IP网关通信。另外,CN 106可向WTRU 102a、102b、102c提供对其他网络112的访问,其他网络可包括由其他服务提供商拥有和/或运营的其他有线和/或无线网络。
尽管WTRU在图1A至图1D中被描述为无线终端,但是可以设想到,在某些代表性实施方案中,这种终端可(例如,临时或永久)使用与通信网络的有线通信接口。
在代表性实施方案中,其他网络112可为WLAN。
处于基础结构基本服务集(BSS)模式的WLAN可具有用于BSS的接入点(AP)以及与AP相关联的一个或多个站点(STA)。AP可具有至分配系统(DS)或将流量承载至和/或承载流量离开BSS的另一种类型的有线/无线网络的接入或接口。源自BSS外部并通向STA的流量可通过AP到达并且可被传递到STA。源自STA并通向BSS外部的目的地的流量可被发送到AP以被传递到相应目的地。BSS内的STA之间的流量可通过AP发送,例如,其中源STA可向AP发送流量,并且AP可将流量传递到目的地STA。BSS内的STA之间的流量可被视为和/或称为点对点流量。可利用直接链路建立(DLS)在源和目的地STA之间(例如,直接在它们之间)发送点对点流量。在某些代表性实施方案中,DLS可使用802.11e DLS或802.11z隧道DLS(TDLS)。使用独立BSS(IBSS)模式的WLAN可不具有AP,并且IBSS内或使用IBSS的STA(例如,所有STA)可彼此直接通信。IBSS通信模式在本文中有时可称为“ad-hoc”通信模式。
当使用802.11ac基础结构操作模式或相似操作模式时,AP可在固定信道(诸如主信道)上传输信标。主信道可为固定宽度(例如,20MHz宽带宽)或动态设置的宽度。主信道可为BSS的操作信道,并且可由STA用来建立与AP的连接。在某些代表性实施方案中,可例如在802.11系统中实现载波侦听多路访问/冲突避免(CSMA/CA)。对于CSMA/CA,STA(例如,每个STA)(包括AP)可侦听主信道。如果主信道被特定STA侦听/检测和/或确定为繁忙,则特定STA可退避。一个STA(例如,仅一个站)可在给定BSS中在任何给定时间传输。
高吞吐量(HT)STA可使用40MHz宽的信道进行通信,例如,经由主20MHz信道与相邻或不相邻的20MHz信道的组合以形成40MHz宽的信道。
极高吞吐量(VHT)STA可支持20MHz、40MHz、80MHz和/或160MHz宽的信道。40MHz和/或80MHz信道可通过组合连续的20MHz信道来形成。可通过组合8个连续的20MHz信道,或通过组合两个非连续的80MHz信道(这可被称为80+80配置)来形成160MHz信道。对于80+80配置,在信道编码之后,数据可通过可将数据分成两个流的段解析器。可单独地对每个流进行快速傅里叶逆变换(IFFT)处理和时间域处理。可将这些流映射到两个80MHz信道,并且可通过发射STA来传输数据。在接收STA的接收器处,可颠倒上述用于80+80配置的操作,并且可将组合的数据发送到介质访问控制(MAC)。
802.11af和802.11ah支持低于1GHz的操作模式。相对于802.11n和802.11ac中使用的那些,802.11af和802.11ah中减少了信道操作带宽和载波。802.11af支持电视白空间(TVWS)频谱中的5MHz、10MHz和20MHz带宽,并且802.11ah支持使用非TVWS频谱的1MHz、2MHz、4MHz、8MHz和16MHz带宽。根据代表性实施方案,802.11ah可支持仪表类型控制/机器类型通信(MTC),诸如宏覆盖区域中的MTC设备。MTC设备可具有某些能力,例如有限的能力,包括支持(例如,仅支持)某些带宽和/或有限的带宽。MTC设备可包括电池寿命高于阈值(例如,以保持非常长的电池寿命)的电池。
可支持多个信道的WLAN系统以及诸如802.11n、802.11ac、802.11af和802.11ah之类的信道带宽包括可被指定为主信道的信道。主信道可具有等于由BSS中的所有STA支持的最大公共操作带宽的带宽。主信道的带宽可由来自在BSS中操作的所有STA的STA(其支持最小带宽操作模式)设置和/或限制。在802.11ah的示例中,对于支持(例如,仅支持)1MHz模式的STA(例如,MTC型设备),主信道可为1MHz宽,即使AP和BSS中的其他STA支持2MHz、4MHz、8MHz、16MHz和/或其他信道带宽操作模式。载波侦听和/或网络分配向量(NAV)设置可取决于主信道的状态。如果主信道繁忙,例如,由于STA(仅支持1MHz操作模式)正在向AP传输,即使大多数可用频段保持空闲,全部可用频段也可被视为繁忙。
在美国,可供802.11ah使用的可用频段为902MHz至928MHz。在韩国,可用频段为917.5MHz至923.5MHz。在日本,可用频段为916.5MHz至927.5MHz。802.11ah可用的总带宽为6MHz至26MHz,具体取决于国家代码。
图1D是示出根据实施方案的RAN 104和CN 106的系统图。如上所指出,RAN 104可采用NR无线电技术通过空中接口116与WTRU 102a、102b、102c通信。RAN 104还可与CN 106通信。
RAN 104可包括gNB 180a、180b、180c,但是应当理解,RAN 104可包括任何数目的gNB,同时保持与实施方案一致。gNB 180a、180b、180c各自可包括一个或多个收发器以便通过空中接口116与WTRU 102a、102b、102c通信。在实施方案中,gNB 180a、180b、180c可实现MIMO技术。例如,gNB 180a、108b可利用波束成形来向gNB 180a、180b、180c传输信号和/或从gNB 180a、180b、180c接收信号。因此,gNB 180a例如可使用多个天线来向WTRU 102a传输无线信号和/或从WTRU 102a接收无线信号。在实施方案中,gNB 180a、180b、180c可实现载波聚合技术。例如,gNB 180a可向WTRU 102a(未示出)发射多个分量载波。这些分量载波的子集可在免许可频谱上,而其余分量载波可在许可频谱上。在实施方案中,gNB 180a、180b、180c可实现协作多点(CoMP)技术。例如,WTRU 102a可从gNB 180a和gNB 180b(和/或gNB180c)接收协作传输。
WTRU 102a、102b、102c可使用与可扩展参数集相关联的传输来与gNB 180a、180b、180c通信。例如,OFDM符号间隔和/或OFDM子载波间隔可因不同传输、不同小区和/或无线传输频谱的不同部分而变化。WTRU 102a、102b、102c可使用各种或可扩展长度的子帧或传输时间间隔(TTI)(例如,包含不同数量的OFDM符号和/或持续变化的绝对时间长度)来与gNB180a、180b、180c通信。
gNB 180a、180b、180c可被配置为以独立配置和/或非独立配置与WTRU 102a、102b、102c通信。在独立配置中,WTRU 102a、102b、102c可与gNB 180a、180b、180c通信,同时也不访问其他RAN(例如,诸如演进节点B 160a、160b、160c)。在独立配置中,WTRU 102a、102b、102c可将gNB180a、180b、180c中的一者或多者用作移动性锚定点。在独立配置中,WTRU 102a、102b、102c可在未许可频带中使用信号与gNB 180a、180b、180c通信。在非独立配置中,WTRU 102a、102b、102c可与gNB 180a、180b、180c通信或连接,同时也与其他RAN(诸如,演进节点B 160a、160b、160c)通信或连接。例如,WTRU 102a、102b、102c可实现DC原理以基本上同时与一个或多个gNB 180a、180b、180c和一个或多个演进节点B 160a、160b、160c通信。在非独立配置中,演进节点B 160a、160b、160c可用作WTRU 102a、102b、102c的移动性锚点,并且gNB 180a、180b、180c可提供用于服务WTRU 102a、102b、102c的附加覆盖和/或吞吐量。
gNB 180a、180b、180c中的每一者可与特定小区(未示出)相关联,并且可被配置为处理无线电资源管理决策、切换决策、UL和/或DL中的用户的调度、网络切片的支持、DC、NR和E-UTRA之间的互通、用户平面数据朝向用户平面功能(UPF)184a、184b的路由、控制平面信息朝向接入和移动性管理功能(AMF)182a、182b的路由等。如图1D所示,gNB 180a、180b、180c可通过Xn接口彼此通信。
图1D所示的CN 106可包括至少一个AMF 182a、182b、至少一个UPF 184a、184b、至少一个会话管理功能(SMF)183a、183b以及可能的数据网络(DN)185a、185b。虽然前述元件被描绘为CN 106的一部分,但是应当理解,这些元件中的任何元件可由除CN运营商之外的实体拥有和/或运营。
AMF 182a、182b可在RAN 104中经由N2接口连接到gNB 180a、180b、180c中的一者或多者,并且可用作控制节点。例如,AMF 182a、182b可负责认证WTRU 102a、102b、102c的用户、网络切片的支持(例如,具有不同要求的不同协议数据单元(PDU)会话的处理)、选择特定SMF 183a、183b、注册区域的管理、非接入层(NAS)信令的终止、移动性管理等。AMF 182a、182b可使用网络切片,以便基于WTRU 102a、102b、102c所使用的服务的类型来为WTRU102a、102b、102c定制CN支持。例如,可针对不同的用例(诸如,依赖超高可靠低延迟(URLLC)接入的服务、依赖增强型移动宽带(eMBB)接入的服务、用于MTC接入的服务等)建立不同的网络切片。AMF 182a、182b可提供用于在RAN 104和采用其他无线电技术(诸如LTE、LTE-A、LTE-A Pro和/或非3GPP接入技术,诸如WiFi)的其他RAN(未示出)之间进行切换的控制平面功能。
SMF 183a、183b可经由N11接口连接到CN 106中的AMF 182a、182b。SMF 183a、183b还可经由N4接口连接到CN 106中的UPF 184a、184b。SMF 183a、183b可选择并控制UPF184a、184b,并且配置通过UPF 184a、184b进行的流量路由。SMF 183a、183b可执行其他功能,诸如管理和分配UE IP地址、管理PDU会话、控制策略实施和QoS、提供DL数据通知等。PDU会话类型可以是基于IP的、非基于IP的、基于以太网的等。
UPF 184a、184b可经由N3接口连接到RAN 104中的gNB 180a、180b、180c中的一者或多者,gNB可向WTRU 102a、102b、102c提供对分组交换网络(诸如互联网110)的访问,以促进WTRU 102a、102b、102c与启用IP的设备之间的通信。UPF 184、184b可执行其他功能,诸如路由和转发分组、实施用户平面策略、支持多宿主PDU会话、处理用户平面QoS、缓冲DL分组、提供移动性锚定等。
CN 106可有利于与其他网络的通信。例如,CN 106可包括用作CN 106与PSTN 108之间的接口的IP网关(例如,IP多媒体子系统(IMS)服务器)或者可与该IP网关通信。另外,CN 106可向WTRU 102a、102b、102c提供对其他网络112的访问,其他网络可包括由其他服务提供商拥有和/或运营的其他有线和/或无线网络。在一个实施方案中,WTRU 102a、102b、102c可通过UPF 184a、184b经由至UPF 184a、184b的N3接口以及UPF 184a、184b与本地DN185a、185b之间的N6接口连接到DN 185a、185b。
鉴于图1A至图1D以及图1A至图1D的对应描述,本文中参照以下中的一者或多者所描述的功能中的一个或多个功能或全部功能可由一个或多个仿真设备(未展示)执行:WTRU102a至102d、基站114a至114b、演进节点B 160a至160c、MME 162、SGW 164、PGW 166、gNB180a至180c、AMF 182a至182b、UPF 184a至184b、SMF 183a至183b、DN 185a至185b和/或本文中所描述的任何其他设备。仿真设备可以是被配置为模仿本文所述的一个或多个或所有功能的一个或多个设备。例如,仿真设备可用于测试其他设备和/或模拟网络和/或WTRU功能。
仿真设备可被设计为在实验室环境和/或运营商网络环境中实现其他设备的一个或多个测试。例如,该一个或多个仿真设备可执行一个或多个或所有功能,同时被完全或部分地实现和/或部署为有线和/或无线通信网络的一部分,以便测试通信网络内的其他设备。该一个或多个仿真设备可执行一个或多个功能或所有功能,同时临时被实现/部署为有线和/或无线通信网络的一部分。仿真设备可直接耦合到另一个设备以用于测试目的和/或使用空中无线通信来执行测试。
该一个或多个仿真设备可执行一个或多个(包括所有)功能,同时不被实现/部署为有线和/或无线通信网络的一部分。例如,仿真设备可在测试实验室和/或非部署(例如,测试)有线和/或无线通信网络中的测试场景中使用,以便实现一个或多个部件的测试。该一个或多个仿真设备可为测试装备。经由RF电路(例如,其可包括一个或多个天线)进行的直接RF耦合和/或无线通信可由仿真设备用于传输和/或接收数据。
快速用户数据报协议(UDP)互联网连接(QUIC)是当前正在开发的基于UDP的流多路复用加密传输协议。可能存在使用QUIC的许多情况,诸如对于基板,包括使用代理以及本文所描述的类似者。
多路径协议可以在多个层处存在,包括在物理层、链路层和/或传输层处。具体地说,传输层多路径协议可以包括多路径传输控制协议(TCP)(MPTCP)、流控制传输协议(SCTP)和多路径QUIC(MP-QUIC)。
在本文所描述的一个或多个实施方案中,在传输层可能存在多跳(MH)多路径(MP)机制(MHMP),该多跳多路径机制可以使用QUIC及其多路径扩展(MP-QUIC)作为基础技术,因为它是安全的传输协议。MHMP传输连接的两侧处涉及的主机可以被指定为端点或对等体。端点也可以被称为终端用户、客户端端点、目的地端点、目标端点、服务器或服务器端点、用户设备、WTRU、UE、终端、主机或主机用户,并且此类术语可以在全文中可互换地使用。客户端端点可以发起连接,而另一端点可以是服务器端点。MHMP连接中的中间节点可以被称为代理节点、网络节点或转发节点。此类术语可以在全文中可互换地使用。
如全文引用的端点、代理、节点和其他系统可以能够建立路径,从而经由硬件或软件在此类路径上对数据流进行定向。除了上述可以集成在WTRU、NodeB或STA内或可操作地连接到WTRU、NodeB或STA的部件和外围设备之外,端点、服务器或用于实施或部署代理的任何节点可以包括以下中的任何者:处理器;现场可编程门阵列(FPGA);集成电路;存储体;随机存取存储器(RAM);非易失性辅助存储装置;非暂时性存储介质,诸如磁性、光学或电子存储器;天线;天线阵列;网络接口控制器;网络接口卡;调制解调器;集线器;交换机;或路由器。
MHMP传输协议的目标可以是在对等体之间建立和保持端到端(e2e)MHMP连接。e2eMHMP连接可以由端点之间的一个或多个个别流构成,该流可以称为路径连接,并且也可以更简单地称为“路径”。通过代理的路径连接可以是“间接路径”,而其他路径可以是“直接路径”。诸如MP-QUIC、MPTCP和SCTP的多路径协议可能仅具有对等体之间的直接路径,而MHMP协议可以具有直接路径和间接路径两者。
端点与代理之间的连接在本文中可以称为“代理连接”。两个代理也可以彼此连接,这可以被称为代理连接。
在一些传统情况下,多路径传输会话的端点之间的流量定向可以在网络运营商的控制下,通过部署和配置其网络中的路由设备和协议。在一些情况下,除了选择使用哪些本地网络接口(例如,WiFi或蜂窝)来建立路径连接之外,终端用户和应用程序提供商都不能直接控制流量定向。
在本文所公开的一个或多个实施方案中,在传输层处可能存在多跳多路径协议,其中终端用户通过选择代理和应用程序提供商,通过部署网络中的代理(例如,作为物理或虚拟服务器上的软件实例,或者作为虚拟网络功能VNF),可以更直接影响路径选择和使用。此方法可以实现多个用例,如表1中所概述,其示出了用于实施所公开实施方案的用例和动机的至少一些示例。
Figure BDA0003829449430000161
Figure BDA0003829449430000171
表1:用例和动机
在一些用例中,可能存在通过应用程序和服务提供商对多个网络路径进行的深度控制。云应用程序提供商(诸如Netflix、Google或Facebook)可以对其客户端连接的多路径方面施加一些控制,从而实现网络深处的路径多样性。例如,此类云应用程序提供商可以在多个数据中心、访问和转换网络中实例化代理VNF(假设此类网络提供VNF托管服务)。客户端可以最初使用支持MHMP的传输协议连接到云应用程序服务器。然后,云应用程序服务器可以通过在客户端-服务器连接上通告与客户端可以连接到的代理VNF相关联的IP地址和端口列表来实现路径多样性。或者,客户端还可以配置有或从不同信道接收与客户端可以用于连接到服务的代理VNF的IP地址和端口列表,这将因此不需要通过直接连接提供此信息。然后,客户端可以通过所提供的代理VNF与云应用程序服务器建立e2e连接。为了建立代理e2e连接,客户端可以将IP地址/端口信息传达给代理,并且另外或替代地,可以将目标应用层标识(例如,用户名、感兴趣的主题等)传达给代理。从此时开始,客户端可以通过多个MHMP连接连接到服务器,例如跨越不同的互联网自主系统,其可以由应用程序提供商基于诸如高可靠性、安全性等的标准来选择。客户端可以取决于应用程序提供商策略继续使用与云应用程序服务器的直接连接,或不使用。在此用例中,代理的主要作用可以是实现应用程序控制的路径多样性。在一些情况下,在异构网络上下文中,应用程序提供商可能无法获得对多个网络路径的此类深度控制。
此深度控制可能不意味着代替现有技术,诸如3GPP中的较低层接入定向,其中可以在WTRU与UPF之间的多个路径上发送流量流。然而,此类深度控制可以通过使应用层实体(例如,应用程序提供商或用户)能够指定多个端到端路径以发送流量来补充此类技术,其中这些路径中的每个路径本身可以使用较低层多路径技术。
图2是示出通过应用程序和服务提供商对多个网络路径进行的深度控制的图。网络可以包括终端设备或端点210,客户端应用程序可以在终端设备或端点处操作,并且提供MHMP协议功能。第一MHMP代理可以由数据中心220提供,并且第二MHMP代理可以在接入或转换网络240处提供。网络服务器230可以托管服务应用程序并提供MHMP协议功能。终端设备或端点210可以经由数据中心220与第一MHMP代理对接,并且经由接入或转换网络240与第二MHMP代理对接。第一MHMP代理和/或第二MHMP代理可以经由数据中心220和/或接入或转换网络240与网络服务器230对接。此类对接可以通过WiFi、蜂窝或任何其他无线或固定网络实现。可以存在三个间接路径和一个直接路径。这四个路径中的每个路径可以在终端设备与服务器之间端到端地建立和加密。在替代用例中,附加代理可以被链接到例如数据中心220处的MHMP代理1,以通过多个数据中心、接入或转换网络在更复杂路径上引导流量。
一些用例可以涉及保持与重定位边缘服务器的连接。在家庭或企业网络的上下文中,或在智能城市场景中,在5G或非5G网络(例如,WiFi或工业无线网络)中,连接到端点的第一边缘服务器可以迁移到第二边缘服务器,例如以保持与移动端点的低延迟或用于负载平衡。这假设在第二边缘服务器上使用不同于第一服务器IP地址的第二IP地址来呈现或创建/迁移新的应用程序实例以用于连接。第一和第二边缘服务器之间的任何状态转移(如果有的话)可以使用适当的方法来执行,诸如直接或通过客户端的应用层通信。假设多跳多路径传输协议最初在端点与第一边缘服务器之间使用,则第一边缘服务器可以通过初始连接将第二边缘服务器IP地址和端口传达到端点。然后端点可以通过第一边缘服务器(例如,一跳,使用第一边缘服务器作为代理)和/或通过直接端到端连接(例如,零跳)发起与第二边缘服务器的连接。一跳连接可以使得甚至在直接连接可能之前发起与第二服务器的通信成为可能。在某个时刻,与第一服务器的初始连接停止用于应用程序数据,并且与第二服务器的连接开始被使用,其中可以支持各种转换模式,诸如渐进式或立即式。一段时间后,端点可以关闭其通过第一边缘服务器的间接路径,并且仅保持与第二边缘服务器直接通信。在整个过程中,可以保持端点与第一/第二边缘服务器上的应用程序之间的相同逻辑传输连接。因此,此重定位过程对于端点上的客户端应用程序可以是透明的。
在一些情况下,在实时应用会话期间在边缘服务器被重定位/迁移时保持与边缘服务器的连接需要网络中的机制来维护服务器的IP地址(例如,如在数据中心中用于迁移VM)或者客户端朝向新服务器的应用层重定向(例如,蜂窝网络中的IP多媒体子系统IMS中的SIP会话连续性)。在一种方法中,可以存在本文所公开的不需要维护IP地址并且不需要应用层处的支持/感知的机制。
图3是示出保持与重定位服务器的连接的示例的图。图3的示例示出了MHMP在重定位用例中的使用。例如,连接1描绘了连接到端点2处的服务器(由元素320表示)的端点1处的客户端(由元素310表示)之间的连接。连接2描绘了在端点2与端点3处的服务器(由元素330表示)之间执行服务器迁移的路径。连接3描绘了端点2可以用作代理以迁移预先存在的连接的路径,用端点3代替端点2。连接4示出了逐渐代替间接路径的直接路径。
一些用例可能涉及保持间歇性D2D对等体之间的连接,诸如在智能城市场景中。第一WTRU端点可以通过中间节点连接到第二WTRU端点,该中间节点可以是通过MHMP传输协议托管来自应用程序提供商的VNF的边缘服务器。因此,代理上的应用程序提供商的实例可以知道此连接,并且可以决定配置接入网络(例如,5G网络)以实现这两个端点之间的D2D连接。因此,此D2D连接可以向应用程序提供商收费(例如,其可以通过用户订阅或广告协议来收回此成本)。当端点处于D2D通信的范围内时,设备可以在端点之间建立D2D链路。每个端点可以通过MHMP协议连接将其新IP地址传达给中间节点。在获知其对等体的新IP地址后,端点中的一个端点可以通过D2D连接发起新的直接路径。从那时起,端点可以通过MHMP传输连接在以下中的一者或两者上交换流量(例如,对使用该连接的应用程序透明):D2D链路以及通过网络中的中间节点。如果D2D链路丢失,则通信仍然可以通过网络中的中间节点进行。
在一些情况下,可能无法保持间歇性D2D对等体之间的相同传输连接。图4是示出用于保持间歇性D2D对等体之间的连接的示例性框架的图。如图4所示,连接1示出了分别由通过MHMP代理430连接的元素410和420表示的终端设备1和2。路径2示出请求在终端设备1与2之间启用D2D通信的MHMP代理430。连接3示出了当处于可达范围内时在终端设备1与2之间通过D2D建立新路径。
一些用例可能涉及建立和保持对等体之间的安全多播或发布订阅连接。在此类用例中,MHMP代理可以用作多播源和接收者的会合点,或者用作pubsub发布者和订户的会合点。代理可以促进所有端点之间的会话密钥共享和引导多播通信。在IP多播不可用的情况下,端点与代理之间的单播连接也可以用于分发数据流,这可以使用多个代理以可扩展方式在分层、内容传递网络(CDN)类架构中完成。
图5是示出通过QUIC建立和保持安全多播或PubSub连接的示例性框架的图。如图5所示,路径1示出了由元素510表示的端点1,其通过MHMP代理540建立作为到多播组/pubsub主题的源/发布者的连接。路径2和2'示出了分别由元素520和530表示的多个端点2和3,其建立作为到相同多播组/pubsub主题的接收者/订户的连接,从而从MHMP代理540接收其QUIC会话密钥。路径3示出了端点1在单向路径上发送流量,该单向路径可以被复制到所有接收者/订户(例如,使用在1/2/2’中建立的连接)。路径4可以表示端点1与端点2和3之间的多播路径,该多播路径可以被建立以补充或代替初始路径。
在一些情况下,MP传输协议(例如,MPTCP或MP-QUIC)可能不支持使用一个或多个显式跳(例如,在传输层可见的跳)。此外,MP传输协议可以实现由端点使用的网络接口的选择(例如,通过源IP地址的选择),但不能通过显式使用路径上的中间节点来选择此路径。这可能限制应用程序提供商和用户对路径的控制量。本文所描述的一个或多个实施方案可以实现此类控制,尤其是在现代传输协议上。在一些情况下,使用QUIC作为主要示例的现代传输协议设计可以通过加密强调较强端到端安全性,以及诸如通过多路复用强调效率和灵活性。具体地说,QUIC通过支持相同连接中的流和数据报的多路复用而超越了仅支持HTTP。因此,可能需要使得能够在包括显式跳的多个路径上建立单个多路复用且安全的端到端(例如,其中代理可能无法访问e2e分组的加密部分)传输连接。为此,可能需要解决几个关键问题。
一个问题在于,需要一种使得能够以无缝(例如,表现为正常QUIC连接)方式对安全端到端传输层QUIC连接进行代理而没有数据流量开销(例如,不建立隧道),和/或启用多个代理连接的多路复用,和/或启用将对代理进行的应用程序特定动作(例如,D2D设置、应用层ID查找、多播关键会话共享等)的方法。这个问题可能不特定于多路径传输,并且在常规(例如,非多路径)QUIC中也可能是有用的。
另一个问题可能是需要一种方法来动态地向多路径连接对等体通告代理连接(例如,在MP-QUIC中)。
另一个问题可能是多跳多路径的应用程序中的一个应用程序可能是支持服务器或客户端迁移而不会破坏传输连接。可能需要在迁移之前、期间和之后保持使用相同的安全传输连接的同时启用此特征的过程。
在一个或多个实施方案中,由于QUIC可以是安全传输协议,因此可能存在协议扩展来处理间接(例如,代理)路径,使用现有QUIC协议及其所提出的多路径扩展作为基础。也可以针对其他传输协议(诸如MPTCP+TLS、SCTP+TLS、安全SCTP等)导出类似的增强。
本文所描述的方法的核心元素可以使一个或多个节点(本文称为代理或MHMP代理)充当QUIC连接中的中介。可以通过网络运营商、应用程序或服务提供商在物理或虚拟基础设施上部署MHMP代理。例如,MHMP代理控制器应用程序实例可以部署在由接入网络或数据中心运营商提供的虚拟化基础设施平台上。代理控制器应用程序实例通常可以控制转发、封装/解封装,而那些操作在商用现货(COTS)或专用硬件(例如,物理或虚拟网络设备)中执行。代理控制器应用程序实例可以使用编程的、基于HTTP的或基于SDN的API(例如,基于OpenFlow的)来控制那些操作。代理控制器应用程序实例还可以执行应用程序特定操作(例如,如关于上面的问题所描述)。
端点(例如,QUIC端点)也可以是MHMP系统的一部分。端点可以是WTRU、UE、PC、膝上型电脑、IoT设备等,或更一般地,能够使用QUIC协议或可以如本文所描述被增强的类似协议进行通信的任何设备。在一些场景中(例如,在本文所描述的服务器迁移场景中),端点可以充当MHMP代理。
MHMP QUIC操作可以基于MP-QUIC协议的操作。可以使用QUIC和MP-QUIC作为基础协议来描述本文所描述的增强。两个端点之间的MP-QUIC连接由一个或多个路径构成。MP-QUIC路径可以是两个端点之间的单向或双向数据流。从每个端点的角度来看,流可以与4元组源/目的地IP地址和传输(例如,UDP)端口(如端点所见)相关联。例如,当在路径上应用网络地址转换(NAT)时,每个端点可以看到相同路径的不同4元组。在MHMP QUIC中,可以使用相同的路径定义。在MHMP QUIC中,每个端点可以看到相同间接路径的不同4元组,因为对于每个端点,IP和UDP层处的下一跳是MHMP代理。MHMP-QUIC支持多个同时的间接以及直接路径。
图6是示出MHMP系统中的通信场景的示例的图。该图示出了涉及MHMP代理的通信场景,如本文所定义。这些使用连接或路径(a)、(b)和(c)的主要通信场景可在本文中详细描述。在产生路径(A)的场景中,由图6的元素630表示的端点A可以发起与由元素610表示的MHMP代理P的通信。这可以创建常规QUIC连接或路径(a),其在以下段落中进一步描述的图7的示例中进一步示出。在本文所描述的过程之后,端点A可以使用连接(a)向MHMP代理P发送对朝向由元素620表示的端点B的间接连接的请求。这可能导致A与B之间的间接/代理路径连接(b),从而在A与P之间的段上使用QUIC上QUIC,这在图8中示出(例如,使用本文所描述的PACKET帧类型)并在下面的段落中进一步描述。这种类型的路径连接可以支持通过相同QUIC A-P连接多路复用多个间接/代理连接。端点A或MHMP代理P可以触发使用如本文所描述的SWITCH帧切换到无开销间接/代理路径连接。这可能导致在每个段上通过UDP转发相同的QUIC路径连接(b),如图9所示出并在下面的段落中进一步描述。可以在端点A与B之间建立直接连接(c),如图10所示出,并且在下文进一步描述。端点B可以在路径(c)上向A通告间接IP地址,如本文所描述。端点A然后可以如上所描述发起路径(b)的创建。直接和间接路径可以在相同的多路径多跳QUIC连接中共存。
可以实施附加机制,其中例如路径(a)可以用于交换密钥会话材料,从而实现端点之间的多播会话。在代理P也是端点的情况下,可以在路径(b)上交换代ID信息元素,以使得能够将应用程序实例从MHMP代理P迁移到端点B。
图7是示出与代理的典型初始连接的示例的图,示出了所涉及的网络节点和分组结构的示例。如图所示,由元素710表示的端点A可以建立与由730表示的MHMP代理P的QUIC(A-P)连接。除了QUIC连接之外,端点A还可以使用UDP连接(A上的UDP端口与P上的USDP端口之间)和/或IP连接(IP地址A与P之间)通信。例如,可以通过UDP和IP建立QUIC连接。
图8是示出使用QUIC的代理/间接连接的示例的图,描绘了所涉及的网络节点和分组结构。由元素810表示的端点A可能已经建立与由元素850表示的端点B的内部QUIC连接(A-B)。QUIC(A-B)连接可以在端点A与由元素830表示的MHMP代理P之间的外部QUIC(A-P)连接上建立。通过QUIC(A-B)连接发送的加密有效负载可以封装在PACKET帧中,如上所描述,PACKET帧可以包括标识对应于内部QUIC(A-B)连接的流的流ID。外部QUIC(A-P)连接可以向MHMP代理P承载加密的A-P有效负载,此时封装的QUIC(A-B)有效负载可以被转发到端点B。端点A和端点B可以经由IP和/或UDP进一步连接。
图9是示出在两个段上通过UDP的代理/间接连接的另一示例的图,描绘了所涉及的节点和分组结构。由元素910表示的端点A可能已经建立与由元素950表示的端点B的QUIC连接(A-B)。另外,可以经由UDP提供端点A与由元素930表示的MHMP代理P之间的连接,以及MHMP代理P与端点B之间的连接。通过QUIC连接(A-B)发送的数据可以经由第一UDP连接从端点A转发到MHMP代理P,并且再次经由第二UDP连接从MHMP代理P转发。端点A与端点B之间的路径可以进一步经由IP和/或UDP提供。
图10是示出端点之间的直接连接的示例的图,描绘了所涉及的网络节点和分组结构。如图所示,可以在由元素1010表示的端点A与由元素1020表示的端点B之间建立直接路径连接。端点A和端点B可以经由第2层协议、IP和/或UDP连接。QUIC连接(A-B)可以例如根据本文进一步描述的一个或多个机制在由端点A请求时建立。
在一些情况下,MPTCP可以支持代理,然而,MPTCP代理可以被设计为拆分TCP连接,并且通常使得MPTCP能够在一侧上在代理与客户端之间使用,而在代理与服务器之间使用常规TCP。因此,MPTCP代理位于客户端与代理之间的整个流量的路径上。此类型的连接拆分对于QUIC可能是不可能的,QUIC在多路径连接的任何给定单独路径上强制执行端到端加密。因此,本文所描述的代理类型可以不同于与MPTCP使用的代理类型(例如,其可以存在于一些路径上而不是其他路径上;在代理该连接之前,客户端与代理之间可以存在双向认证;代理上的应用程序实例可以参与代理连接设置),并且因此可以依赖于本文所描述的不同机制,并且提供不同类型的服务(例如,隐式路径选择、应用程序特定的D2D或查找、多播或pubsub通信管理)。
HTTP CONNECT可以是在某些情况下用作连接建立技术的另一代理。当使用HTTPCONNECT时,端点可以使用任何协议在通过代理的端到端TLS连接上进行通信。TLS连接可以在客户端-代理段上的第一TCP会话以及代理-服务器段上的第二TCP会话上传输。因此,HTTP CONNECT可能不适用于承载基于UDP的QUIC流量。另外,使用HTTP CONNECT,可能无法在客户端与代理之间多路复用代理连接。因此,可能需要通过代理与多个服务器通信的多个连接。最后,为了能够使用HTTP CONNECT,可能需要与代理建立完整的HTTP连接,这可能浪费客户端和代理的资源。
表2示出了问题的示例和解决这些问题的机制的示例。这些示例性机制可以对QUIC协议的增强。在表的所有情况下,可以扩展QUIC传输参数以包括相关参数,诸如此连接可以用于承载QUIC上QUIC流量的指示、用于在代理NEW_CONNECTION请求中寻址远程端点的支持协议的列表、和/或支持基于GENERATION的迁移机制的指示。
Figure BDA0003829449430000251
表2:关键问题和相关机制
在一些实施方案中,通过QUIC或MP-QUIC的代理可能存在有效的连接。例如,可以存在使用QUIC上QUIC封装方案的代理连接方法。这可以用于多于一个目的,诸如:可以通过单个代理多路复用多个服务器的多个QUIC连接(例如,在相同的客户端-代理连接上);和/或,当不需要多路复用时(例如,当单个QUIC连接被代理时),代理连接可以被切换为直接承载端到端QUIC连接而无需封装,因此将数据流量开销减少到零。在这两种情况下,端点与代理之间的流量可能看起来是常规QUIC流量。与QUIC连接上的任何其他中间节点一样,QUIC上QUIC代理可能仅对QUIC分组的未受保护字段具有可见性,例如IP报头、UDP报头和未加密的QUIC报头(包括连接ID)。MHMP代理可以实施应用程序特定的动作。
可能存在用作构建块的QUIC帧类型,该构建块用于通过QUIC或MP-QUIC过程的代理进行有效连接。在QUIC上QUIC封装方案中,可以通过外部QUIC连接(例如,通过客户端-代理连接)传输内部QUIC分组,其中分组是可以封装在UDP数据报中(例如,可以包括一个或多个QUIC帧)的QUIC的完整可处理单元。端到端QUIC连接可以封装为内部QUIC分组的单向或双向流:每个内部QUIC分组可以在PACKET帧中传输,与流ID相关联,并且在外部QUIC连接内部。当客户端端点向代理发送NEW_CONNECTION帧时,可以发起QUIC上QUIC流,NEW_CONNECTION帧标识新流,包括ID和与流相关联的其他参数。使用流ID可以在单个端点-代理连接上实现与多个端点的多个QUIC连接的多路复用。如果代理接受NEW_CONNECTION请求,则它可以将其自身配置为将内部QUIC分组转发到NEW_CONNECTION目的地/从NEW_CONNECTION目的地转发内部QUIC分组。
本文可以描述新的PACKET帧类型以承载封装的数据业务。它可以包括与DATAGRAM帧类型类似的信息元素。然而,新的帧类型可以用于区分其作为内部QUIC分组的容器的新的唯一用途。内部QUIC分组属于先前由NEW_CONNECTION帧发起的QUIC连接。PACKET帧可以至少包括以下字段:流ID(例如,可变长度整数),其是标识对应于一个e2e QUIC连接的单向流或双向流的ID,其中此ID对应于在发起流的NEW_CONNECTION帧中使用的ID;长度(例如,可变长度整数),其是存储在数据字段中的封装分组的长度;和/或数据字段(可变长度),其可以是内部QUIC分组(例如,一个或多个QUIC帧)。
本文可以描述新的NEW_CONNECTION帧类型以定义与内部QUIC分组/帧的流相关联的目的地/目标和相关参数。此帧类型可以至少包括以下字段:流ID(例如,可变长度整数),其可以是标识对应于一个内部/封装QUIC连接的双向流的ID;目标/目的地协议(例如,16位),其可以是用于寻址目的地端点的协议;目标/目的地IP地址(例如,128位或32位),其可以是目的地的IP地址(例如,端点2),或者多播IP地址也被称为多播组,在目的地地址协议为IPv4或IPv6时使用;目标/目的地应用程序标识(例如,可变长度字符串),其可以是目的地(例如,端点2)的应用层标识,在目的地协议是应用层协议时使用(例如,此可以是应用程序用户ID,诸如Netflix或Facebook用户名,其可以由代理查找以确定目的地端点的IP地址,或者此可以是代理可以用作发布-订阅方案的一部分的主题ID或字符串);目标/目的地类型(例如,2位),其可以是指示与目标/目的地IP地址或应用程序ID相关联的类型的代码,其中值可以包括“发布”、“订阅”、“双向”,并且其含义可以取决于目标/目的地协议(例如,这些值将NEW_CONNECTION的发送者标识为用于pubsub协议的发布者或订户,标识为用于多播协议的源或接收者,或者标识为能够在路径上发送/接收的常规节点);目标/目的地端口(例如,16位),其可以是用于连接到服务器的端口(例如,UDP端口);和/或代理授权字段(例如,可变长度字符串),其可以是描述用于授权代理操作的凭证的字符串(例如,可以使用与对应HTTP字段中相同的编码,诸如“basic dXNlcjpwYXNzd29yZA==”)。在相同授权字符串可以用于多个NEW_CONNECTION帧的情况下,代理授权字段可以存在于第一NEW_CONNECTION中并且在下面省略。
目标/目的地协议可以是IPv4、IPv6或应用层协议(例如,社交网络应用程序中的用户名)。根据目标/目的地协议,可以存在或可以不存在目标/目的地IP地址、端口和应用程序标识中的任一者(例如,IP地址和端口可以与IPv4/IPv6协议一起存在,并且应用程序标识和类型可以与应用层协议一起存在)。
与给定流ID相关联的PACKET帧可以作为单独的QUIC流/流(stream/flow)来处理,并且因此与其他流/流多路复用。可以对整个客户端-代理QUIC连接应用拥塞控制。
关于NEW_CONNECTION/PACKET帧类型和相关机制,QUIC堆栈实施可以使编程API可用于在主机上(例如,在代理上)运行的本地应用程序。在代理节点上运行的过程可以使用此API并注册“接收到NEW_CONNECTION”事件,将回调作为参数传递。注册范围可以用于所有、一组或一个传入连接。回调可以接收包括NEW_CONNECTION帧信息元素的参数(flowID、destProtocol、DestIP、DestAppId、DestType、DestPort、ProxyAuth)。当代理接收到NEW_CONNECTION时,它可以调用注册的回调函数并提供从NEW_CONNECTION帧提取的参数。回调函数可以例如使用ProxyAuth参数来检查客户端端点由本地策略授权,并且返回指示请求被接受或拒绝的代码。在一些示例中,回调函数可以查找在NEW_CONNECTION中传递的目的地应用程序标识(例如,使用本地或远程应用层数据库),以确定调用者被授权连接到它,并且确定代理将向其/从其转发内部流量的端点的IP地址和UDP端口。在一些示例中,代理上的本地程序可以将此API公开为外部节点的REST API(例如,应用程序提供商管理平面功能,以控制NEW_CONNECTION请求)。
可能存在用于通过QUIC或MP-QUIC过程的代理进行有效连接的SWITCH帧。具体地说,为了在可能的情况下去除封装和开销,客户端端点(相应地代理)可以向代理(相应地客户端端点)发送新的SWITCH帧,以请求从交换通过代理连接封装的e2e流量切换到直接通过UDP交换e2e流量。
新的SWITCH帧类型可以具有以下字段中的一个或多个字段:交换机类型(例如,可变长度整数),其可以是指示所需的交换机类型的代码,该代码在本文所描述的方法中可以是“从QUIC上QUIC到UDP上QUIC”,尽管它也可以采用其他值,诸如“从UDP上QUIC到QUIC上QUIC”,其可以实现本文所描述的操作的反转,或者与不同类型的封装(GTP、Geneve等)之间的切换相对应的其他值。SWITCH帧类型还可以包括消息类型(例如,位),其可以是指示帧是请求还是响应的代码;或状态(例如,固定长度整数),其可以是指示成功/失败的代码,并且可以在响应中使用。
请求者(例如,客户端端点或代理)可以发送包括SWITCH帧的分组。接收者可以决定接受或拒绝(例如,代理可以被配置为基于运营商策略始终接受或拒绝那些请求),然后在包括SWITCH帧的QUIC分组中发送回复。接收者可以在发送肯定响应之后停止在连接(例如,客户端-代理连接)上发送分组。请求者可以在接收到肯定响应之后停止在连接上发送分组。请求者在发送接收响应之后,并且接收者一旦接收到对肯定响应分组的确认,就可以开始在初始连接的UDP连接上发送未封装的端到端分组。在具有多个活动代理连接(例如,多个流ID)的连接上发送的SWITCH通常可能会被拒绝,因为在成功切换后,流ID可能不再与内部QUIC分组相关联,这可能会使多路复用在没有附加复杂性的情况下变得不可能(例如,与服务器端通信以确保在特定范围内分配连接ID,其方式类似于现有的QUIC负载平衡方法)。
SWITCH可以在内部QUIC连接的生命周期中的任何时候使用,诸如:一旦封装协议被充分良好地加密/保护(例如,一旦流量处于“1-RTT加密级别”);随后,诸如在正常QUIC上QUIC操作期间;和/或与NEW_CONNECTION请求一样早。一旦达到1-RTT加密级别,使用SWITCH就可以通过外部QUIC连接保持较早的未受保护和受0-RTT保护的分组被封装,并且因此被加密。这样,客户端与代理之间的窃听者不会看到明文分组,这隐藏了正在建立代理连接的事实。相反,SWITCH操作可以表现为连接ID的改变,该改变在QUIC协议操作中可以是常见的。因此,这使得代理操作尽可能无缝。如图11所描述和以下段落中所描述的过程可以示出此特定用例。然而,也可以更早地发送SWITCH,例如,在下面关于图11A和图11B所描述的过程中,步骤1113-1117可以在步骤1104与1105之间发生,在这种情况下,端到端连接的第一分组以及所有后续分组可以通过UDP连接在每个段客户端-代理和代理-服务器上传输。
间接连接引导方法可以用于通过QUIC或MP-QUIC过程的代理进行有效连接。这可以是使用先前描述的新帧类型引导代理的QUIC连接的过程。此方法可以用于建立作为e2eMHMP连接的一部分的间接路径连接,或者可以用于建立单个QUIC代理连接。
图11A和图11B示出了说明间接连接引导方法的示例的过程图。图11示出了例如由元素1150表示的端点1(例如,使用IP地址IP1a、IP1b等)如何通过代理1160连接到由1170表示的端点2(例如,使用IP地址IP2a、IP2b等)。为了将其与其他代理区分开,此代理可以支持PACKET/NEW_CONNECTION帧类型,并且可能支持SWITCH帧类型,并且可以是MHMP代理,即使它也可以用于非多路径QUIC。
关于图11A和图11B中所示的步骤,在1101处,端点1可以建立与代理的QUIC连接。代理可以认证客户端(例如,基于客户端提供的证书)。在一些情况下,QUIC可能仅支持客户端的服务器认证,但是可以扩展为支持服务器的客户端认证。
端点1可以进一步使用此QUIC层连接来承载HTTP/3流量,以便使用通常的基于网络的机制(网络认证(WebAuthn)、HTTP基本认证、JSON网络令牌、双因子认证方法等)登录、认证等。然而,此步骤并非在所有情况下都是必需的,并且可能对端点和代理两者施加一些处理开销。
在端点1-代理传输连接建立期间,可以交换传输参数(例如,使用QUIC传输参数扩展)。代理和/或端点1可以使用诸如传输参数ID的传输参数指示对本文所描述的新字段和相关过程的支持。
例如,具有代理操作支持的传输参数ID(例如,0x000f)可以具有或包括传输参数长度,诸如0位(例如,空参数),并且此传输参数可以指示发送者支持本文所描述的NEW_CONNECTION、PACKET、SWITCH和相关联的代理相关过程的帧类型。
例如,具有支持的代理协议的传输参数ID(例如,0x0010)可以具有传输参数长度,诸如整数的可变长度列表,并且此传输参数可以列出被支持以在NEW_CONNECTION帧中寻址远程端点的一个或多个协议(例如,IPv4、IPv6、应用层协议)。
在1102处,端点1可以向代理发送NEW_CONNECTION帧,包括先前未使用的流ID(例如,在初始请求中的0)并且指示期望的服务器端点IP地址(例如,IP2a或多播IP地址)或目的地应用程序标识(例如,应用程序特定的用户名、pubsub主题名称)、类型、端口、协议和可能的授权令牌。
在1103处,代理可以基于给定参数、来自代理运营商的本地策略以及可能与云中的后端服务的一些交互来决定是否授权NEW_CONNECTION请求。当适用时,代理可以执行应用程序特定的动作,诸如:启用端点1与端点2之间的D2D连接以授权端点1和端点2以在它们之间建立直接路径(例如,代理可以为此访问5G网络API);与客户端执行应用层认证;和/或执行NEW_CONNECTION中提供的应用程序标识的查找(如果使用应用程序标识而不是IP地址)。
在1104处,代理可以发送NEW_CONNECTION响应(例如,包括指示请求被接受的响应代码)。
在1105处,客户端端点1可以使用如本文所描述的PACKET帧,使用NEW_CONNECTION中使用的流ID,向端点2发送封装在与代理的初始QUIC连接中的初始端到端分组。
在1106处,代理可以解封装分组并将其发送到服务器端点2,有时通过UDP分组发送(例如,使用代理IP地址/UDP端口作为源IP地址/UDP端口)。
在1107处,端点2可以向初始分组发送QUIC响应(例如,按照QUIC连接建立过程)。
在1108处,代理在PACKET帧中将端点2的响应封装到初始端点1-代理连接中(例如,使用与请求中相同的流ID)。
在1109处,此端点1-端点2交换可以继续,直到在端到端QUIC连接建立过程之后建立端到端连接,在两个段上传输,其中分组在端点1-代理段上通过QUIC封装,并且在代理-端点2段上通过UDP发送。为了实现这一点,可以在MHMP代理上配置分组转发操作,例如作为将PACKET帧中使用的流ID与第二分段UDP会话4元组(例如,MHMP代理IP地址和UDP端口、端点2IP地址和UDP端口)相关联的转发表中的条目。
在1110处,此时,可以端对端地建立端点1-端点2QUIC连接,并且可以在前述两个段上传输。
图11的示例性过程可以根据不同的情况进行到步骤1111或步骤1112。
在1111处,在第一替代方案中,客户端端点1可以使用不同的流ID发送附加NEW_CONNECTION帧,以在客户端-代理QUIC连接上多路复用多个代理连接。因此,该过程可以在步骤1102-1110上循环。该过程可以在此替代方案中结束。
图11B示出了过程图的第二部分,并且描述了上文关于步骤1111所描述的步骤的替代方案。如图11B所示,在1112处,在第二替代方案中,客户端端点1可能不需要使用多路复用并决定减少代理连接的开销。在此阶段,可以在1-RTT(例如,最高)级别保护端到端连接(例如,从步骤9开始)。因此,QUIC上QUIC封装可以在连接上添加不必要的开销(例如,因为不需要多路复用)。
在1113处,端点1可以发送SWITCH消息(例如,请求,其中交换机类型“从QUIC上QUIC到UDP上QUIC”),以触发由端到端内部连接代替初始连接(在相同的基础UDP流上)。注意,替代地,代理也可以是SWITCH帧的发送者。
在1114-1115处,接收者(例如,代理)可以决定接受或拒绝SWITCH请求并且发回响应(例如,具有指示请求被接受的代码)。
在1116-1117处,端点1和代理可以通过UDP直接开始交换端到端(例如,端点1到端点2)分组。在MHMP代理上,转发操作可以被配置为例如将第一段4元组(例如,端点1IP地址和UDP端口、MHMP代理IP地址和UDP端口)与第二段4元组(例如,MHMP代理IP地址和UDP端口、端点2IP地址和UDP端口)相关联的转发表中的条目。
在步骤1118中,从此时开始,端点1与端点2之间的QUIC路径上的端到端分组可以通过代理发送,该代理可以通过每个段代理-端点1和代理-端点2上的UDP连接转发端到端分组。
代理可以用在多路径传输协议中,用于在QUIC或MP-QUIC过程中通过代理进行有效连接。MP-QUIC信令和过程可以用于建立单独的间接路径作为多路径连接的一部分。当与本文先前描述的QUIC上QUIC机制和/或基于SWITCH的机制一起使用时,这些过程可以使得能够通过代理建立单独的路径。可以类似于常规MP-QUIC调度来完成(例如,直接和间接)路径之间的流量调度。另外或替代地,MHMP-QUIC端点可以使用其关于路径的间接或直接性质的知识(例如,从本文所描述的新的ADD_ADDRESS帧类型字段已知)来影响调度策略。部署和使用代理的原因可能有所不同,可能取决于应用程序或服务提供商的目标,并且因此可能导致不同或甚至相反的策略。例如,MHMP-QUIC客户端可以在可用时使用间接路径,例如,因为它重视路径多样性而不考虑其他因素,并且保持直接路径不活动,作为备份路径。在另一示例中,在MHMP代理用于在卫星链路上建立备份路径的情况下,MHMP-QUIC客户端可在可用时使用直接路径并保持间接路径不活动作为备份。
此外,MHMP路径可以穿过多于一个代理。这可以对端点隐藏:每个代理可以决定将哪些其他代理用作下一跳,并且随后建立与其他代理的代理连接。代理可以向下一代理转发NEW_CONNECTION和SWITCH帧,并将响应中继回。因此,那些帧可以被一路转发到路径上的最后一个代理。
可以启用多播和Pubsub通信,以通过QUIC或MP-QUIC过程中的代理进行有效连接。QUIC多播协议可以使用HTTP备用服务(“Alt-Svc”)获得会话密钥。可以利用MHMP协议来补充此现有工作,以提供附加特征。例如,它可以使得能够在传输层共享会话密钥,这可能比使用HTTP Alt-Svc更有效/更动态。在诸如视频广播或pubsub点对多点消息分发(例如,MQTT)的场景中,MHMP协议还可以使得能够使用IP单播作为IP多播的补充或代替。作为代替,使用多个分布式代理以及单播可以是可扩展的并且易于部署在网络中不允许多播的部署中。作为补充,在网络的一些部分中可以允许多播,其中它可以用于提高分发效率。
多播和pubsub节点可以连接到代理并使用目标/目的地应用程序ID和目标/目的地类型来使用NEW_CONNECTION帧。多播流源/接收者可以将目的地IP地址设置为多播组,并且分别将目的地类型设置为“发布”和“订阅”。Pubsub发布者/订户可以将目的地应用程序ID设置为主题名称,并且分别将目的地类型设置为“发布”和“订阅”。
例如,在多播/pubsub节点(例如,源、接收者、发布者、订户)都具有端点1的角色的情况下,可以使用图11A和图11B中所描述的过程。在此情况下,端点2可以是虚拟端点,其可以例如托管在MHMP代理本身上。端点2的角色可以包括促进密钥分发并维护/配置QUIC流在端点之间的转发。每个多播组或pubsub主题可能需要单个端点2实例。
最初,源/发布者端点可以连接到端点2,如本文所描述。在此过程结束时,源/发布者可能能够通过QUIC连接“S”将数据流式传输到端点2(例如,如果不存在接收者/订户,则发送到端点2的流量可能被代理丢弃)。端点2/代理可以将QUIC会话密钥存储在其内部状态中,与多播组或主题名称相关联,以供将来使用。
接收者/订户还可以如本文所描述连接到端点2,直到它们发送NEW_CONNECTION。如果端点2/代理接受订阅多播组或主题名称的请求,则端点2/代理可以用SESSION_KEY帧进行回复,SESSION_KEY帧包括解密来自此多播组或主题名称的源/发布者的QUIC流量所需的密钥材料。接收者/订户可以处理此帧并利用会话密钥材料配置其与代理的QUIC连接。从此时开始,接收者/订户可以解密由源/发布者在连接“S”上发送的分组。端点2/代理可以在代理上配置转发规则,以通过与接收者/订户的现有UDP连接向接收者/订户转发连接“S”上的所有传入分组的副本。
此时,通过每个端点与MHMP代理之间的单播点对点UDP连接,在源/发布者端点与接收者/订户端点之间可以存在点对多点连接。端点2/代理可以接收流,但不修改它或发送关于它的任何数据。端点2/代理可以通过端点1-代理连接与端点1通信(例如,以提供关于订户/接收者的数目的统计数据)。源/发布者可以通告实际多播IP地址(例如,使用ADD_ADDRESS)。在接收到ADD_ADDRESS时,接收者/订户可以建立侦听多播地址的新路径。接收者/订户可以关闭或保持通过MHMP代理的单播路径作为未使用的备份。
在一些实施方案中,可以通过MP-QUIC进行代理发现。端点可以有多种方式从诸如DHCP、IPv6 ND和供应域、DNS服务发现、使用mDNS的本地发现、端口控制协议和/或任播地址的机制了解合适的代理。然而,这些方法可能适合于发现由网络运营商部署的长期代理。对于本文所描述的一些用例,可能需要更动态的方法来发现由应用程序提供商部署的代理。因此,需要端点如何了解它可以用于多路径协议中的间接路径的代理。
在此方法中,端点可以通过现有路径了解来自其远程对等体的可用间接路径。端点可以立即、在同一连接中或稍后在与下一个端点的另一个连接中使用此间接路径。
增强的ADD_ADDRESS帧类型可以用于代理发现。通常,ADD_ADDRESS帧类型可以具有若干字段,诸如可以指示(如果设置)端口字段的存在的“P”位;地址ID,其可以是用于跟踪和去除目的的通告地址的唯一标识符,其中当例如NAT改变IP地址使得两个主机看到相同路径端点的不同IP地址时,可能需要这一点;接口类型,其可以指示诸如固定(0)、WLAN(1)或蜂窝(2)的接口技术类型;IP版本,其可能与IP地址字段中的地址相关;IP地址,其可以是由发送者通告给接收者的IP地址;和/或UDP端口号,其可能与所通告的IP地址相关。
在增强/扩展的ADD_ADDRESS帧类型中,可以有几个字段,诸如:“I”位,如果设置,它可以指示代理相关字段的存在;“A”位,如果设置,则指示代理可以用于与发送端点的所有连接,并且如果未设置,则指示代理可以仅用于此多路径连接;代理IP地址,其可以是由接收端点看到的代理的IPv6或IPv4地址(例如,代理的面向公众的IP地址),并且在替代方案中,代理IP地址字段可以用代理名称字段(例如,FQDN)代替。代理IP版本,其可以指示代理IP地址字段的IP版本是IPv4还是IPv6;和/或代理端口,其可以是与代理IP地址相关联的传输层(例如,UDP)端口。这些字段可以是正常字段的补充,并且可能需要使接收此帧的端点可以通过代理发起间接路径连接,如本文先前所描述。
使用本文所描述的技术,可存在使用ADD_ADDRESS的代理发现过程。图12是示出使用本文所描述的增强ADD_ADDRESS和间接连接引导方法的代理发现过程的示例的过程图。
关于如图12所示的步骤,在1201处,由元素1250表示的端点1可以通过一个或多个路径(例如,使用用于直接路径的现有MP-QUIC过程和/或本文所描述的用于间接路径的方法)建立与由元素1270表示的端点2的多路径传输连接。此时,在端点1与端点2之间可能存在由一组直接或间接路径构成的MHMP连接。
在1202处,应用程序提供商现在可以动态地部署代理实例,或者可以更早地部署它。如图12所示,代理由元素1260表示,并且可以是MHMP代理。可以使代理的存在和IP地址/端口对端点2可用(例如,通过管理平面通信机制,可能连同关于此代理的使用条件的策略信息一起)。例如,给定代理可能对位于特定区域中的所有应用程序用户或具有特定计划的所有应用程序用户可用。
在1203处,端点2(例如,服务器)可能知道端点1(例如,客户端)可以用于此连接或用于与此服务器的所有连接的代理。此信息可以在服务器上配置、通过管理平面系统提供或使用其他方法提供。端点2可以发送包括ADD_ADDRESS帧的分组,ADD_ADDRESS帧除了通常的ADD_ADDRESS字段之外还包括要使用的代理IP地址、版本和端口,其中“I”位被设置为指示代理信息的存在,并且当适用时,“A”位被设置为指示代理可以用于与服务器的其他连接。端点2可以发送若干ADD_ADDRESS帧(例如,通过代理通告多个代理和/或多个端点2IP地址)。
在1204处,在接收到ADD_ADDRESS帧时,端点1可以用ADD_ADDRESS参数更新本地连接状态。
在1205处,在某个时刻,诸如立即或基于本地策略决策(例如,如果当前路径变得不可靠),端点1上的(例如,增强MP-QUIC)路径管理器部件决定使用来自最近接收的基于代理的ADD_ADDRESS帧中的一个ADD_ADDRESS帧的信息来发起新路径。
在1206处,端点1可以通过从ADD_ADDRESS获知的代理发起间接路径连接建立,诸如使用图11所描述的过程。
在1207处,此时,除了所有预先存在的路径之外,端点1与端点2之间的多路径连接现在可以包括通过MHMP代理的新间接路径。
在一些实施方案中,可能存在启用服务器(或客户端)迁移。此方法可以解决本文所描述的MHMP协议机制如何用于在服务器或客户端迁移期间促进应用程序连接连续性。此方法的一个优点可以是端点不需要通过外部协议(例如,DNS、应用层协议等)发现新迁移的远程端点;另一个优点可以是保持传输会话,这使得能够进行透明迁移。
在启用服务器或客户端迁移时,可能存在新的构建块,诸如新的GENERATION、STATE以及增强ADD_ADDRESS和PATHS帧类型。
一种方法可以将“代ID”与IP地址相关联并将此代ID与ADD_ADDRESS和PATHS消息中的地址相关联。代可以与一侧(例如,客户端或服务器)相关联。例如,偶数代ID可以与客户端相关联,并且奇数代ID可以与服务器相关联。默认情况下,所有客户端地址可以与第0代(“gen0”)相关联,并且所有服务器地址可以与第1代(“gen1”)相关联。gen0和gen1可以默认为当前活动的代。因此,可以默认使用所有现有消息和行为,这可以实现代机制的向后兼容性。然后可以与下一个可用的第3代(“gen3”)相关联地通告例如与不同服务器相关联的新地址。客户端可以建立通向gen3地址的路径,但是只要活动的服务器侧代仍然是gen1,就不能在它们上交换任何数据。给定路径可以与路径代ID相关联,该路径代ID由客户端代ID(例如,与此路径相关联的客户端地址的代ID)和(例如,服务器侧IP地址的)服务器代ID形成。
例如,默认情况下路径可以具有gen0-gen1路径代ID,并且在服务器迁移的情况下,新路径可以具有路径代ID gen0-gen3。新的GENERATION帧可以由当前服务器发送到客户端,以指示现在活动的路径代ID。在接收到GENERATION帧后,客户端切换所有通信(例如,从gen0-gen1路径到gen0-gen3路径)。在一些情况下,此改变可以仅针对新的应用程序连接,而它可以替代地针对所有流量立即进行:GENERATION帧的转换模式字段确定应当应用哪种行为。在切换代之前,旧服务器可以在现有的gen0-gen1路径上发出新STATE帧,以请求所有流量暂停或不活动,这可以实现例如旧服务器与新服务器之间的VM转移。可以使新服务器知道其IP地址将与非默认代相关联(例如,使用编程API)。例如,应用程序可以侦听两个端口上的传入连接:用于来自新客户端的正常连接的第一端口和用于来自从另一服务器迁移的客户端的连接的第二端口。侦听第二端口的套接字可以使用包括由此套接字使用的默认代ID的新套接字选项来创建。用于使用第二端口连接的服务器IP地址可以默认与gen3相关联。可能需要在诸如QUIC的传输协议中定义的等效机制,并且可能需要定义诸如GENERATION或STATE的帧类型。
虽然服务器迁移(例如,从gen1到gen3)可以用作本文所描述的过程中的典型示例,但是可以使用相同机制来支持客户端迁移(例如,从gen0到gen2),其中客户端和服务器的角色被交换。
新的GENERATION帧类型可以具有以下字段:服务器代ID(例如,可变长度整数),其可以是与新活动服务器一起使用的代ID(例如,奇数);客户端代ID(例如,可变长度整数),其可以是与新活动客户端一起使用的代ID(例如,偶数);转换模式(例如,可变长度整数),其可以是指示转换类型的代码,包括“仅新的应用程序事务”或“所有活动连接”;和/或重置标记(例如,位),如果设置,此标记可以将所有路径和相关联地址重置为活动代ID,并且还可以在完成迁移之后使用(例如,以将所有服务器侧IP地址代ID重置为3到1,并且将所有gen0-gen3路径重置为gen0-gen1路径)。
新STATE帧类型可以具有以下字段:服务器连接状态(例如,可变长度整数),其可以是指示服务器侧的期望连接状态的代码(ACTIVE或INACTIVE)。它可以仅由服务器改变,和/或可以在由客户端发送的STATE帧中省略。STATE帧类型还可以包括客户端连接状态(例如,可变长度整数),其可以是指示客户端侧的期望连接状态的代码(ACTIVE或INACTIVE),并且其可以仅由客户端改变并且在由服务器发送的STATE帧中省略(例如,两个对等体可以在其内部状态中保持给定路径的客户端和服务器连接状态,并且为了可用于数据流量,客户端和服务器连接状态都可以是ACTIVE)。
可以利用以下字段来增强正常ADD_ADDRESS帧类型:G位(如果设置)可以指示代ID字段是否存在;和/或代ID(例如,可变长度整数),其可以是与地址相关联的代ID。
此外,还可以利用代ID相关信息来增强PATHS帧类型。在一些情况下,PATHS帧可以包括用于所有发送和接收路径的路径描述(例如,从PATHS帧发送者的角度来看)。每个路径描述符可以包括路径ID、本地和远程地址ID。另外,对于每个路径描述符,可以通过以下字段增强PATHS帧类型:本地代ID(例如,可变长度整数),其可以是与本地IP地址相关联的代ID(例如,从PATHS帧发送者的角度来看);和/或远程代ID(例如,可变长度整数),其可以是与远程IP地址相关联的代ID(从PATHS帧发送者的角度来看)。
代ID可以替代地编码在地址ID内(例如,其可以是已经存在于MP-QUIC帧中的字段,诸如ADD_ADDRESS,并且可以用于标识地址以去除地址)。例如,由于仅需要第0、1、2和3代,并且由于地址的侧(客户端、服务器)已知,所以地址ID中的单个位可能就足够了:甚至客户端侧地址ID可以是gen0,奇数客户端侧地址ID可以是gen2,甚至服务器侧地址ID可以是gen1,奇数服务器侧地址ID可以是gen3。然而,出于本文的说明目的,可以使用代ID。
图13A和图13B是示出使用本文所描述的一种或多种技术的服务器迁移过程的示例的图。图13A和图13B都可以被认为是单个过程的一部分,在保持传输连接的同时,支持从第一服务器到第二服务器的迁移。如基本上在以上段落中所讨论的,此过程可以适于类似地处理客户端迁移。
代ID可以标识在端点上运行的实例:相同的代ID可以指相同的实例,而不同的代ID可以指不同的实例。不同的实例可能不共享应用程序或连接状态。因此,此过程的核心方面是同步从与一个实例(例如,代ID 1,第一服务器)通信到与另一实例(例如,代ID 3,第二服务器)通信的切换。
关于图13A和图13B所示的步骤,在13011处,最初,由元素1350表示的端点1(例如,客户端)可以使用具有MPMH能力的多路径协议(例如,如本文先前所描述而增强的MP-QUIC)来建立与由元素1360表示的端点2(例如,服务器)的传输连接。传输参数可以被添加到由一个或两个端点发送的现有传输参数以指示对基于GENERATION的服务器迁移的支持,并且可以与本文所描述的其他传输参数一起使用。传输参数ID可以是基于代的迁移支持(例如,0x0011),并且传输参数长度可以是某个值,诸如0位(例如,空参数)。此传输参数可以指示发送者支持新帧类型GENERATION和STATE、增强的(例如,用于代ID感知)帧类型ADD_ADDRESS和PATHS,以及本文所描述的相关迁移支持过程。
在1302处,可以在端点1与端点2之间通过一个或多个直接或间接路径存在传输连接。
在1303处,可以例如通过服务运营商的管理平面来发起服务器实例迁移。管理平面(图13A中未示)可以向端点2发信号通知迁移即将发生。
关于1304-1306,例如,在服务器实例迁移需要暂停流量的情况下,诸如在热VM迁移情况下,可能发生这些步骤。端点2可以将路径上的STATE(INACTIVE)帧发送到端点1。端点1可以例如在接收到STATE(INACTIVE)帧时停止在路径上发送数据。端点2可以例如在发送STATE(INACTIVE)帧之前停止在路径上发送数据。
在1307处,管理平面可以选择由元素1370表示的目标服务器端点3,并且协调服务器迁移,这可以包括:在端点3上创建软件实例,和/或在端点2与端点3之间迁移VM或应用程序状态。此时,端点3上的迁移实例可以侦听传入连接,但可能尚未准备好交换应用程序流量。管理平面可以为端点2提供端点3的IP地址。
关于1308-1309,端点2可以向客户端发送ADD_ADDRESS帧,每个ADD_ADDRESS帧包括端点3的IP地址,并且在一些情况下包括其他现有字段(例如,地址ID、端口、协议版本等)和作为此侧的下一个未使用的代ID的代ID值(例如,用于服务器迁移的“3”)。可以存在指定端点2作为代理的代理信息元素(例如,包括端点2的IP地址、版本、端口,其中I位被设置并且通常A位未被设置)。然而,端点2可以发送用于直接(例如,没有代理)、间接(例如,具有代理,例如端点2)或直接和间接连接的混合的ADD_ADDRESS帧。作为图13A中所示的示例,可以使用端点2本身作为代理将ADD_ADDRESS与代理信息一起发送。这对于甚至在直接通信有可能之前(例如,在预期移动性事件时)建立与端点3的通信可能是有用的。端点1可能发回确认。
在1310处,端点1在接收时可以在连接的内部状态中存储添加的地址信息(例如,包括代理信息元素(如果存在的话))。接着,端点1的路径管理器可以决定建立与那些地址的新路径连接。
在1311处,端点1可以建立一个或多个新路径,或与端点3的连接。在此示例中,这些可以是使用本文所描述的方法(例如,使用NEW_CONNECTION、PACKET和可能的SWITCH帧)建立的间接路径。由于端点1和端点3都可能已知这些路径是gen0-gen3路径,因此这些路径可能不用于承载任何数据流量。
在1312处,端点1可以具有与端点2的gen0-gen1路径连接(例如,其可用于数据流量,除非它们在步骤1304-1306中设置为不活动)和与端点3的gen0-gen3路径连接,其当前可能不用于数据流量。
在1313处,在某个时刻,(例如,管理平面)实体在服务器迁移完成时发信号通知端点2。端点3现在准备好交换应用程序流量。
关于1314-1315,端点2可以在一个或多个路径上向端点1发送GENERATION帧,包括服务器代ID值“3”。转换模式可以是“所有活动连接”或“仅新的应用程序事务”。端点1发回确认。
关于1316-1319,端点1可以实施从使用gen0-gen1路径到使用gen0-gen3路径的转换。端点1可以使用现有的gen0-gen3路径和/或发起新的gen0-gen3路径。从gen0-gen1到gen0-gen3的转换可以以不同的方式执行,这取决于所请求的转换模式、gen0-gen1路径的当前状态(例如,活动或不活动)以及应用程序服务器的行为。
在第一示例中,在VM或容器迁移的情况下,所有gen0-gen1路径连接在此时可以是不活动的(例如,自步骤1304-1306以来)。转换模式可以被设置为“所有活动连接”。在接收到后,客户端(例如,端点1)可以在一个或多个gen0-gen3路径上转发GENERATION(例如,gen0-gen3)帧,这可以通知端点3gen0-gen3路径现在可以用于数据流量。端点1可以通过gen0-gen3路径发送所有应用程序流量。在此情况下,迁移对于客户端和服务器应用程序都可以是完全透明的。
在另一示例中,gen0-gen1路径当前可以是活动的(例如,未使用步骤1304-1306)。转换模式可以被设置为“仅新的应用程序事务”。这可以例如在端点3托管无状态应用程序实例时使用,该无状态应用程序实例与数据中心中的后端数据库服务器通信。在从端点2接收到GENERATION(gen0-gen3)帧时,客户端可以在一个或多个gen0-gen3路径上转发它。这可以通知端点3,gen0-gen3路径现在可以用于应用程序流量。端点1可以继续使用现有应用程序事务的gen0-gen1路径,并将所有新事务(例如,所有HTTP GET/POST消息)的流量发送到gen0-gen3路径上。同样在此情况下,应用程序客户端和服务器可能不知道迁移,尽管应用程序服务器可以被设计为独立地处理每个请求(例如,作为无状态应用程序)。
在另一示例中,转换模式也可以被设置为“仅新的应用程序事务”。在接收到服务器迁移完成的信号后,在端点2上运行的应用程序实例可能会使所有未完成的应用程序事务失败。在从端点2接收到GENERATION(gen0-gen3)帧时,客户端可以在一个或多个gen0-gen3路径上转发它。这可以通知端点3,gen0-gen3路径现在可以用于应用程序流量。端点1上的客户端应用程序可以重试应用程序请求,因此可以在gen0-gen3路径上向端点3发送,因为这些重试可以是新的应用程序事务。在此情况下,可以使服务器迁移作为一组事务失败对客户端应用程序可见,但是这可能不需要对应用程序的重大重新设计,并且甚至可以通过正常的应用程序失败处理行为来处理。服务器应用程序可能需要针对此情况的一些支持,诸如它必须在请求(例如,来自管理平面部件)时使给定客户端的所有正在进行的事务失败。
在1320处,端点1可以具有到端点2的gen0-gen1路径,该路径可以用于正在进行的事务,或者可以未使用。端点1还可以具有到端点3的gen0-gen3路径,该路径可以用于应用程序流量。
在1321处,假设现有的gen0-gen3是通过端点2/代理的间接路径,如图所示,端点3可以使用ADD_ADDRESS通过一个或多个gen0-gen3路径向端点1通告其IP地址。端点1可以使用此信息建立与端点3的直接路径连接。一旦建立直接路径,端点1和端点3就可以停止使用间接路径。因此,端点2可能没有任何要转发的间接路径流量,并且可以去除转发条目(例如,在超时时段之后)。
在1322处,一旦端点1与端点2之间的gen0-gen1路径未被使用(例如,在正在进行的应用程序事务结束之后,或者紧接在GENERATION消息接收之后),端点1或端点2就可以关闭gen0-gen1路径。
在1323处,现在将原始端点1-端点2连接迁移到端点1与端点3之间的单路径或多路径连接中。
在1324处,为了能够在相同的过程之后执行朝向另一个服务器的另一个迁移,端点1或端点3可以将所有gen3地址重置为gen1地址(例如,gen0-gen3路径因此变为gen0-gen1路径)。一旦从两个端点的角度来看仅有的现有路径已知为gen0-gen3,就可以执行此操作。例如,可以仅终止gen0-gen3路径的端点3可以从仅包括gen0-gen3路径的端点1接收如本文所定义的增强PATHS帧。端点3然后可以向端点1发送GENERATION(例如gen0-gen1,其中重置标记被设置)。然后端点1和端点3都可以在其内部状态中将所有gen3地址设置为gen1。
对于没有流量开销或多路复用的无缝代理以及代理上的应用程序特定动作,端点可以向代理发送NEW_CONNECTION帧,以基于PACKET帧发起QUIC上QUIC代理。端点可以发送SWITCH帧以用内部QUIC连接代替封装的代理连接,这可以用无开销转发代替封装。SESSION_KEY帧可用于启用点对多点和多播。对于MP_QUIC中的代理连接的通告,端点可以发送用代理相关信息元素增强的ADD_ADDRESS帧类型。接收端点可以使用此信息来发起使用QUIC上QUIC的路径。在服务器侧和客户端侧IP地址与代ID相关联的情况下,服务器可以告知客户端使用新帧类型GENERATION和STATE以及在增强帧类型ADD_ADDRESS和PATHS上从旧代路径切换到新代路径,作为迁移过程的一部分。
尽管上文以特定组合描述了特征和元件,但是本领域的普通技术人员将理解,每个特征或元件可单独使用或以与其他特征和元件的任何组合来使用。另外,本文所述的方法可在结合于计算机可读介质中以供计算机或处理器执行的计算机程序、软件或固件中实现。计算机可读介质的示例包括电子信号(通过有线或无线连接传输)和计算机可读存储介质。计算机可读存储介质的示例包括但不限于只读存储器(ROM)、随机存取存储器(RAM)、寄存器、高速缓存存储器、半导体存储器设备、磁介质(诸如内置硬盘和可移动磁盘)、磁光介质和光介质(诸如CD-ROM磁盘和数字通用光盘(DVD))。与软件相关联的处理器可用于实现用于WTRU、UE、终端、基站、RNC或任何主计算机的射频收发器。

Claims (20)

1.一种客户端端点,所述客户端端点包括:
处理器;和
收发器:
所述处理器和所述收发器被配置为向网络节点发送建立与目的地端点的快速用户数据报协议(UDP)连接(QUIC)连接的请求,建立所述QUIC连接的所述请求包括流标识符(ID);
所述处理器和所述收发器被配置为从所述网络节点接收包括建立与所述目的地端点的所述QUIC连接的所述请求的指示的响应;
所述处理器和所述收发器被配置为将内部QUIC分组化数据封装在外部QUIC分组化数据内,所述内部QUIC分组化数据包括所述流ID;并且
所述处理器和所述收发器被配置为向所述网络节点发送所述外部QUIC分组化数据以基于所述流ID向所述目的地端点转发。
2.根据权利要求1所述的客户端端点,其中所述处理器和所述收发器被配置为向所述网络节点发送建立与另一目的地端点的另一QUIC连接的请求,建立所述另一QUIC连接的所述请求包括另一流ID。
3.根据权利要求1所述的客户端端点,其中所述处理器和所述收发器被配置为向所述网络节点发送停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的请求。
4.根据权利要求3所述的客户端端点,其中所述处理器和所述收发器被配置为从所述网络节点接收对停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的所述请求的响应。
5.根据权利要求3所述的客户端端点,其中所述处理器和所述收发器被配置为在所接收的对停止将QUIC分组化数据封装在QUIC分组化数据中的所述请求的响应被接受的条件下向所述网络节点发送UDP数据报,所述UDP数据报包括内部QUIC分组化数据以向所述目的地端点转发。
6.根据权利要求1所述的客户端端点,其中建立与所述目的地端点的所述QUIC连接的所述请求被封装在所述外部QUIC分组化数据中。
7.根据权利要求1所述的客户端端点,其中所述内部QUIC分组化数据和所述外部QUIC分组化数据被单独加密。
8.一种由客户端端点执行的方法,所述方法包括:
向网络节点发送建立与目的地端点的快速用户数据报协议(UDP)连接(QUIC)连接的请求,建立所述QUIC连接的所述请求包括流标识符(ID);
从所述网络节点接收包括建立与所述目的地端点的所述QUIC连接的所述请求的指示的响应;
将内部QUIC分组化数据封装在外部QUIC分组化数据内,所述内部QUIC分组化数据包括所述流ID;并且
向所述网络节点发送所述外部QUIC分组化数据以基于所述流ID向所述目的地端点转发。
9.根据权利要求8所述的方法,所述方法包括向所述网络节点发送建立与另一目的地端点的另一QUIC连接的请求,建立所述另一QUIC连接的所述请求包括另一流ID。
10.根据权利要求8所述的方法,所述方法包括向所述网络节点发送停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的请求。
11.根据权利要求10所述的方法,所述方法包括从所述网络节点接收对停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的所述请求的响应。
12.根据权利要求10所述的方法,所述方法包括在所接收的对停止将QUIC分组化数据封装在QUIC分组化数据中的所述请求的响应被接受的条件下向所述网络节点发送UDP数据报,所述UDP数据报包括内部QUIC分组化数据以向所述目的地端点转发。
13.根据权利要求8所述的方法,其中建立与所述目的地端点的所述QUIC连接的所述请求被封装在所述外部QUIC分组化数据中。
14.根据权利要求8所述的方法,其中所述内部QUIC分组化数据和所述外部QUIC分组化数据被单独加密。
15.一种网络节点,包括:
处理器;和
收发器;
所述处理器和所述收发器被配置为从客户端端点接收建立与目的地端点的快速用户数据报协议(UDP)连接(QUIC)连接的请求,建立所述QUIC连接的所述请求包括流标识符(ID);
所述处理器和所述收发器被配置为向所述客户端端点发送包括建立与所述目的地端点的所述QUIC连接的所述请求的指示的响应;
所述处理器和所述收发器被配置为从所述客户端端点接收封装内部QUIC分组化数据的外部QUIC分组化数据,所述内部QUIC分组化数据包括所述流ID;并且
所述处理器和所述收发器被配置为基于所述流ID向所述目的地端点转发所述内部QUIC分组化数据。
16.根据权利要求15所述的网络节点,其中所述处理器和所述收发器被配置为从所述客户端端点接收建立与另一目的地端点的另一QUIC连接的请求,建立所述另一QUIC连接的所述请求包括另一流ID。
17.根据权利要求15所述的网络节点,其中所述处理器和所述收发器被配置为从所述客户端端点接收停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的请求。
18.根据权利要求17所述的网络节点,其中所述处理器和所述收发器被配置为向所述客户端端点发送对停止将内部QUIC分组化数据封装在外部QUIC分组化数据内的所述请求的响应。
19.根据权利要求17所述的网络节点,其中所述处理器和所述收发器被配置为在对停止将QUIC分组化数据封装在QUIC分组化数据中的所述请求的所述响应被接受的条件下从所述客户端端点接收UDP数据报,所述UDP数据报包括内部QUIC分组化数据以向所述目的地端点转发。
20.根据权利要求15所述的客户端端点,其中建立与所述目的地端点的所述QUIC连接的所述请求被封装在所述外部QUIC分组化数据中。
CN202180018559.5A 2020-02-14 2021-02-16 用于使用quic实现多主机多路径安全传输的方法和装置 Pending CN115244897A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202062976753P 2020-02-14 2020-02-14
US62/976,753 2020-02-14
PCT/US2021/018185 WO2021163684A1 (en) 2020-02-14 2021-02-16 Methods and apparatuses for enabling multi-host multipath secure transport with quic

Publications (1)

Publication Number Publication Date
CN115244897A true CN115244897A (zh) 2022-10-25

Family

ID=74867644

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180018559.5A Pending CN115244897A (zh) 2020-02-14 2021-02-16 用于使用quic实现多主机多路径安全传输的方法和装置

Country Status (5)

Country Link
US (1) US11985062B2 (zh)
EP (1) EP4104416A1 (zh)
KR (1) KR20220139389A (zh)
CN (1) CN115244897A (zh)
WO (1) WO2021163684A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115152274A (zh) * 2020-02-28 2022-10-04 联想(新加坡)私人有限公司 在不同的接入网络上使用多个引导连接接入业务引导
US20230261997A1 (en) * 2020-06-26 2023-08-17 Telefonaktiebolaget Lm Ericsson (Publ) Policy provisioning to a mobile communication system
US20230083582A1 (en) 2021-09-15 2023-03-16 Cisco Technology, Inc. Policy expressions using quic connection identifiers
CN114143386A (zh) * 2021-11-23 2022-03-04 广州三七极创网络科技有限公司 一种基于quic协议的通信方法、系统、设备及存储介质
CN114244619B (zh) * 2021-12-23 2022-11-15 北京天融信网络安全技术有限公司 一种通信方法、装置、系统、电子设备及可读存储介质
US20230318969A1 (en) * 2022-03-31 2023-10-05 Lenovo (United States) Inc. Optimizing network load in multicast communications
US11870699B1 (en) 2022-06-27 2024-01-09 Ottopia Technologies Ltd. Techniques for multi-channel network congestion control

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
CN109218186B (zh) * 2017-07-05 2021-02-23 华为技术有限公司 一种多路径数据传输处理方法及网络设备
FR3096533A1 (fr) * 2019-06-28 2020-11-27 Orange Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé

Also Published As

Publication number Publication date
US20230074838A1 (en) 2023-03-09
EP4104416A1 (en) 2022-12-21
US11985062B2 (en) 2024-05-14
WO2021163684A1 (en) 2021-08-19
KR20220139389A (ko) 2022-10-14

Similar Documents

Publication Publication Date Title
US11985062B2 (en) Methods and apparatuses for enabling multi-host multipath secure transport with QUIC
CN111837371A (zh) 基于增强mptcp的应用移动性
EP3818738A1 (en) Methods and procedures for the dynamic mac address distribution in ieee 802.11 networks
JP7347507B2 (ja) 非公開ネットワーク通信の有効化
CN114557117A (zh) 5g设备与mec主机之间的mec应用程序实例的透明重定位
US11792154B2 (en) Multicast and unicast medium access control (MAC) address assignment protocol (MUMAAP)
US20210266254A1 (en) Device to device forwarding
US20220377524A1 (en) Methods and apparatus for direct discovery and communication using a wtru to wtru relay
KR20210127142A (ko) Pc5 인터페이스를 통한 v2x 유니캐스트 통신 활성화 절차
CN112425138A (zh) 将服务功能链固定到上下文特定的服务实例
CN115211156A (zh) 用于直接无线通信的安全和隐私支持
EP4275286A1 (en) Change of pc5 link identifiers between the wtru and the layer-2 wtru to wtru relay
CN112640370B (zh) 用于多播分组的层2转发的方法和装置
EP4295633A1 (en) Multiple application identifications using layer-3 relay
CN111149331B (zh) 用于边缘终止点之间通信的传输协议
CN114679494B (zh) Http响应的自组织链路本地多播传送
WO2023059888A1 (en) Multicast-broadcast traffic delivery for distributed terminals
WO2023215575A1 (en) Enabling xr service proxies
WO2019140385A1 (en) Method and architectures for handling transport layer security sessions between edge protocol points

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20240514

Address after: Delaware, USA

Applicant after: INTERDIGITAL PATENT HOLDINGS, Inc.

Country or region after: U.S.A.

Address before: Wilmington, Delaware, USA

Applicant before: IDAC HOLDINGS, Inc.

Country or region before: U.S.A.