CN115426305A - 报文处理方法、装置及系统 - Google Patents

报文处理方法、装置及系统 Download PDF

Info

Publication number
CN115426305A
CN115426305A CN202110655978.1A CN202110655978A CN115426305A CN 115426305 A CN115426305 A CN 115426305A CN 202110655978 A CN202110655978 A CN 202110655978A CN 115426305 A CN115426305 A CN 115426305A
Authority
CN
China
Prior art keywords
header
message
sff
packet
payload
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
CN202110655978.1A
Other languages
English (en)
Inventor
张永康
吴鹏
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2021/139368 priority Critical patent/WO2022252569A1/zh
Priority to EP21943921.3A priority patent/EP4333390A1/en
Publication of CN115426305A publication Critical patent/CN115426305A/zh
Priority to US18/523,432 priority patent/US20240106748A1/en
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
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/741Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种报文处理方法、装置及系统。本申请当SFF接收到一个SR封装格式的报文时,SFF修改报文的封装格式,将报文中的IP头封装于SR头的外层,将修改后的报文发送至SF。由于报文从SFF转发至SF的过程中,报文仍携带着SR头,因此,当报文后续从SF返回至SFF时,SFF能利用报文携带的SR头恢复原先的SR封装格式,从而摆脱了必须生成和维护用于保存SRH的缓存空间才能恢复SR封装格式的限制,也就避免了生成和维护用于保存SRH的缓存空间会带来的巨大资源开销,节省了资源开销。

Description

报文处理方法、装置及系统
本申请要求于2021年05月31日提交的申请号为202110604888.X、发明名称为“一种转发报文的方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域,特别涉及一种报文处理方法、装置及系统。
背景技术
业务链(service function chain,SFC)是一个有序的业务功能集合。SFC的基本原理是,让流量按照指定的顺序经过多个业务功能(service function,SF)设备,通过多个SF设备对报文依次进行处理,从而完成业务处理流程。段路由(segment routing,SR)是基于源路由的理念来转发报文的技术。基于SR转发报文的报文包括段路由头,段路由头中的段标识(segment ID,SID)列表指示了报文的转发路径。相关技术中采用动态代理的方式来支持基于SR的SFC。动态代理的方式主要包括剥离段路由头、缓存段路由头以及重新封装段路由头等步骤。具体来说,业务功能转发设备(service function forwarder,SFF)接收到一个包含段路由头的报文之后,SFF将报文中的段路由头剥离,并生成缓存空间从而保存剥离的段路由头。之后,SFF将剥离了段路由头的报文发给SF。SFF接收到SF返回的报文后,SFF从缓存空间获得之前剥离的段路由头。SFF将段路由头重新封装至SF返回的报文,继续转发重新封装的报文。采用上述动态代理的方式来支持SFC时,SFF需要生成和维护缓存空间,导致资源开销巨大。
发明内容
本申请实施例提供了一种报文处理方法、装置及系统,能够节省资源开销。
第一方面,提供了一种报文处理方法,SFF接收第一报文;SFF基于第一报文获得第二报文;SFF向SF发送上述第二报文。第一报文包括第一段路由(segment routing,SR)头、第一互联网协议(internet protocol,IP)头和第一IP载荷(IP payload),第一段路由头封装于上述第一IP头和上述第一IP载荷外层。第二报文包括第二IP头、第一IP载荷和第一段路由头,第二IP头封装于上述第一IP载荷和上述第一段路由头外层。
通过以上方法,当SFF接收到一个SR封装格式的报文时,SFF修改报文的封装格式,将报文中的IP头封装于SR头的外层,将修改后的报文发送至SF设备。由于报文从SFF转发至SF设备的过程中,报文仍携带着SR头,因此,当报文后续从SF设备返回至SFF时,SFF能利用报文携带的SR头恢复原先的SR封装格式,从而摆脱了必须生成和维护用于保存SRH的缓存空间才能恢复SR封装格式的限制,也就避免了生成和维护用于保存SRH的缓存空间会带来的巨大资源开销,节省了资源开销。
在一些实施例中,上述第一段路由头包括第一段标识(segment ID,SID),SFF保存第一对应关系,上述第一对应关系包括上述第一SID和SID类型,上述SID类型用于表示不支持段路由头,SFF基于上述第一报文获得第二报文包括:SFF根据上述第一SID和上述第一对应关系,获得上述SID类型;SFF根据上述SID类型对上述第一报文进行第一处理,获得上述第二报文,上述第一处理包括将上述第一段路由头设于上述第一IP载荷后且上述第一IP头被替换为上述第二IP头。
上述实现方式与SR协议中根据活跃SID查询本地SID表的处理逻辑匹配和兼容,因此能复用SR协议的处理逻辑,降低对SFF的要求,实现复杂度较低。
在一些实施例中,上述第一SID为基于互联网协议第6版的段路由(internetprotocol version 6for segment routing,SRv6)SID。
在一些实施例中,SFF根据上述第一SID和上述第一对应关系,获得上述SID类型包括:当SFF确定上述第一段路由头中IPv6基本头中的目的地址包括上述第一SID时,SFF根据上述第一SID和上述第一对应关系,获得上述SID类型。
在一些实施例中,上述第一SID为多协议标签交换(multi-protocol labelswitching,MPLS)标签。
在一些实施例中,SFF根据上述第一SID和上述第一对应关系,获得上述SID类型包括:
当SFF确定上述第一段路由头中标签栈的栈顶标签为上述第一SID时,SFF根据上述第一SID和上述第一对应关系,获得上述SID类型。
本实施例支持多种情况下实现业务链,下面结合情况一至情况四举例说明。
情况一、上述第一段路由头为SRv6头,上述第一IP头和上述第二IP头均为互联网协议第4版(internet protocol version 4,IPv6)IPv4头,上述第一IP载荷为IPv4载荷;或者,
通过上述情况一,支持SRv6场景中SFF接入IPv4 SF设备的情况下实现业务链。
情况二、上述第一段路由头为SRv6头,上述第一IP头和上述第二IP头均为互联网协议第6版(internet protocol version 6,IPv6)IPv6头,上述第一IP载荷为IPv6载荷。
通过上述情况二,支持SRv6场景中SFF接入IPv6 SF设备的情况下实现业务链。
情况三、上述第一段路由头为SR-MPLS头,上述第一IP头和上述第二IP头均为IPv4头,上述第一IP载荷为IPv4载荷;或者,
通过上述情况三,支持SR-MPLS场景中SFF接入IPv6 SF设备的情况下实现业务链。
情况四、上述第一段路由头为SR-MPLS头,上述第一IP头和上述第二IP头均为IPv6头,上述第一IP载荷为IPv6载荷。
通过上述情况四,支持SR-MPLS场景中SFF接入IPv6 SF设备的情况下实现业务链。
上述第二报文具有多种可能的格式,下面结合三种格式举例说明。
格式一、第二报文中IP头外层还封装有以太头(ethernet header)。
例如,第二报文还包括第一以太头,第一以太头封装于第二IP头外层。第一以太头包含1层或两层虚拟局域网(virtual local area network,VLAN)标签(VLAN tag),例如dot1q(即802.1q)或QinQ(即802.1Q-in-802.1Q,特点是包含两层802.1Q标签,一层公网标签,一层私网标签)。
通过格式一支持SFF与SF设备之间通过二层网络相连的网络部署场景。
格式二、第二报文中第二IP头为封装在最外层的报文头。
通过格式一支持SFF与SF设备之间通过IP网络相连的网络部署场景。
格式三、第二报文中IP头外层还封装有隧道头(tunnel header)。
例如,第二报文还包括第一隧道头,第一隧道头封装于第二IP头外层。第一隧道头包括而不限于虚拟扩展局域网(virtual extensible local area network,VXLAN)、通用路由封装(generic routing encapsulation,GRE)隧道、基于VXLAN通用协议(VXLANgeneric protocol encapsulation,VXLAN-GPE)、通用网络虚拟化封装(generic networkvirtualization encapsulation,GENEVE)等。
通过格式三,支持SFF与SF设备之间通过显式隧道相连的网络部署场景。
在一些实施例中,SFF向SF设备发送上述第二报文之后,SFF接收来自于上述SF设备的第三报文,上述第三报文包括第三IP头、第二IP载荷和上述第一段路由头,上述第三IP头封装于上述第二IP载荷和上述第一段路由头外层;SFF基于上述第三报文获得第四报文,上述第四报文包括上述第一段路由头、第四IP头和第三IP载荷,上述第一段路由头封装于上述第四IP头和上述第三IP载荷外层;SFF基于上述第一段路由头发送上述第四报文。
通过上述方式,支持SFF将SF设备返回的报文恢复为SR报文的封装格式,以便通过SR将SF设备业务处理后的数据按照指定路径传递到业务链中下一个节点。
上述第三报文具有多种可能的格式,下面结合三种格式举例说明。
格式一、第三报文中IP头外层还封装有以太头。
例如,第三报文还包括第二以太头,第二以太头封装于第三IP头外层。
格式二、第三报文中IP头为封装在最外层的报文头。
格式三、第二报文中IP头外层还封装有隧道头(tunnel header)。
例如,第三报文还包括第二隧道头,第二隧道头封装于第三IP头外层。
在一些实施例中,SFF基于上述第三报文获得第四报文包括:
SFF基于上述第三IP头对上述第三报文进行第二处理,获得上述第四报文,上述第二处理包括用上述第四IP头替换上述第三IP头且上述第一段路由头封装于上述第四IP头和上述第三IP载荷外层;或者,
SFF基于接收上述第三报文的接口对上述第三报文进行第二处理,获得上述第四报文,上述接收上述第三报文的接口为上述第一SID绑定的入接口,上述第二处理包括用上述第四IP头替换上述第三IP头且上述第一段路由头封装于上述第四IP头和上述第三IP载荷外层;或者,
SFF基于接收上述第三报文的接口和上述第三IP头对上述第三报文进行第二处理,获得上述第四报文,上述接收上述第三报文的接口为上述第一SID绑定的入接口,上述第二处理包括用上述第四IP头替换上述第三IP头且上述第一段路由头封装于上述第四IP头和上述第三IP载荷外层。
通过上述方式,支持SFF基于入接口或者IP头中新增信息等方式来识别特定格式的报文,提高灵活性。
在一些实施例中,上述第三IP头还包括第一长度信息,上述第一长度信息用于确定上述第三报文中上述第一段路由头的位置。
可选地,第一长度信息用于指示上述第一IP载荷的长度,或者上述第一长度信息用于指示上述第一IP载荷和上述第二IP头的长度之和。
通过在IP头中携带长度信息,SFF能利用长度信息准确地定位段路由头的位置从而进行SR封装格式的恢复,从而降低恢复SR封装格式的实现复杂度。
在一些实施例中,上述第三IP头包括标识信息,上述标识信息用于标识上述第三IP头封装于上述第二IP载荷和上述第一段路由头外层。
通过引入标识信息从而标识本实施例提供的报文封装格式,便于SFF依据IP头是否携带标识信息来判定是否进行SR封装格式的恢复,提高灵活性。
在一些实施例中,上述第三IP头包括第二选项,上述第二选项的类型字段携带上述标识信息,上述第二选项的值字段携带上述第一长度信息。
在一些实施例中,述第三IP头为IPv4头,上述第三选项为IPv4头中的选项。
在一些实施例中,上述第三IP头为包括逐跳选项头的IPv6头,上述第三选项为逐跳选项头中的选项,或者,
上述第三IP头为包括目的选项头的IPv6头,上述第三选项为目的选项头中的选项。
在一些实施例中,上述第二IP头包括标识信息,上述标识信息用于标识上述第一段路由头设于上述第一IP载荷后。
在一些实施例中,上述第二IP头还包括第二长度信息,上述第二长度信息用于指示上述第一IP载荷的长度,或者上述第二长度信息用于指示上述第一IP载荷和上述第二IP头的长度之和。
通过上述实现方式,由于SFF在IP头中携带了长度信息来记录IP载荷的长度,一方面便于SF设备在业务处理时定位IP载荷的位置,另一方面便于SFF进行了恢复SR封装格式。降低方案整体的实现复杂度。
在一些实施例中,上述第二IP头包括第一选项,上述第一选项的类型字段携带上述标识信息。
在一些实施例中,上述第一选项的值字段携带上述第二长度信息。
在一些实施例中,上述第二IP头为包括逐跳选项头的IPv6头,上述第一选项为逐跳选项头中的选项,或者,
上述第二IP头为包括目的选项头的IPv6头,上述第一选项为目的选项头中的选项。
在一些实施例中,上述第二IP头为IPv4头,上述第一选项为IPv4头中的选项。
第二方面,提供了一种报文处理方法,在该方法中,SF设备接收来自于SFF的第一报文,上述第一报文包括第一IP头、第一IP载荷和第一段路由头,上述第一IP头封装于上述第一IP载荷和上述第一段路由头外层;SF设备基于上述第一报文进行业务处理。
以上方法中,通过将报文中的IP头封装于SR头的外层,SF设备接收到报文时,能够忽略SR头进行业务处理,从而帮助不支持SR的SF设备提供业务处理服务,实现业务链。尤其是,由于报文从SFF转发至SF设备的过程中,报文仍携带着SR头,因此,当报文后续从SF设备返回至SFF时,SFF能利用报文携带的SR头恢复原先的SR封装格式,从而摆脱了必须生成和维护用于保存SRH的缓存空间才能恢复SR封装格式的限制,也就避免了生成和维护用于保存SRH的缓存空间会带来的巨大资源开销,节省了资源开销。
在一些实施例中,上述第一IP头包括标识信息,上述标识信息用于标识上述第一段路由头设于上述第一IP载荷后。
在一些实施例中,上述第一IP头还包括第二长度信息,上述第二长度信息用于指示上述第一IP载荷的长度,或者上述第二长度信息用于指示上述第一IP载荷和上述第一IP头的长度之和。
在一些实施例中,上述第一IP头包括第一选项,上述第一选项的类型字段携带上述标识信息。
在一些实施例中,上述第一IP头为IPv4头,上述第一选项为IPv4头中的选项。
在一些实施例中,上述第一IP头为包括逐跳选项头的IPv6头,上述第一选项为逐跳选项头中的选项,或者,
上述第一IP头为包括目的选项头的IPv6头,上述第一选项为目的选项头中的选项。
在一些实施例中,上述SF设备基于上述第一报文进行业务处理之后,上述方法还包括:
上述SF设备向上述SFF发送经上述业务处理后获得的第二报文,上述第二报文包括第二IP头、第二IP载荷和上述第一段路由头,上述第二IP头封装于上述第二IP载荷和上述第一段路由头外层。
在一些实施例中,上述第二IP头还包括第一长度信息,上述第一长度信息用于确定上述第二报文中上述第一段路由头的位置。
在一些实施例中,上述第二IP头包括上述第一选项。
在一些实施例中,上述第二IP头包括上述标识信息。
第三方面,提供了一种报文处理装置,该报文处理装置设于SFF(SR代理),该报文处理装置具有实现上述第一方面或第一方面任一种可选方式的功能。该报文处理装置包括至少一个单元,至少一个单元用于实现上述第一方面或第一方面任一种可选方式所提供的方法。在一些实施例中,报文处理装置中的单元通过软件实现,报文处理装置中的单元是程序模块。在另一些实施例中,报文处理装置中的单元通过硬件或固件实现。第三方面提供的报文处理装置的具体细节可参见上述第一方面或第一方面任一种可选方式,此处不再赘述。
第四方面,提供了一种报文处理装置,该报文处理装置设于SF设备,该报文处理装置具有实现上述第二方面或第二方面任一种可选方式的功能。该报文处理装置包括至少一个单元,至少一个单元用于实现上述第二方面或第二方面任一种可选方式所提供的方法。在一些实施例中,报文处理装置中的单元通过软件实现,报文处理装置中的单元是程序模块。在另一些实施例中,报文处理装置中的单元通过硬件或固件实现。第四方面提供的报文处理装置的具体细节可参见上述第二方面或第二方面任一种可选方式,此处不再赘述。
第五方面,提供了一种计算机设备,该计算机设备设置于SFF(SR代理),该计算机设备包括处理器和网络接口,该处理器用于执行指令,使得该计算机设备执行上述第一方面或第一方面任一种可选方式所提供的方法,上述网络接口用于接收或发送报文。第五方面提供的计算机设备的具体细节可参见上述第一方面或第一方面任一种可选方式,此处不再赘述。
第六方面,提供了一种计算机设备,该计算机设备设置于SF设备,该计算机设备包括处理器和网络接口,该处理器用于执行指令,使得该计算机设备执行上述第二方面或第二方面任一种可选方式所提供的方法,上述网络接口用于接收或发送报文。第六方面提供的计算机设备的具体细节可参见上述第二方面或第二方面任一种可选方式,此处不再赘述。
第七方面,提供了一种计算机可读存储介质,该存储介质中存储有至少一条指令,该指令在计算机上运行时,使得计算机执行上述第一方面或第一方面任一种可选方式所提供的方法。
第八方面,提供了一种计算机可读存储介质,该存储介质中存储有至少一条指令,该指令在计算机上运行时,使得计算机执行上述第二方面或第二方面任一种可选方式所提供的方法。
第九方面,提供了一种计算机程序产品,上述计算机程序产品包括一个或多个计算机程序指令,当上述计算机程序指令被计算机加载并运行时,使得上述计算机执行上述第一方面或第一方面任一种可选方式所提供的方法。
第十方面,提供了一种计算机程序产品,上述计算机程序产品包括一个或多个计算机程序指令,当上述计算机程序指令被计算机加载并运行时,使得上述计算机执行上述第二方面或第二方面任一种可选方式所提供的方法。
第十一方面,提供了一种芯片,包括存储器和处理器,存储器用于存储计算机指令,处理器用于从存储器中调用并运行该计算机指令,以执行上述第一方面及其第一方面任意可能的实现方式中的方法。
第十二方面,提供了一种芯片,包括存储器和处理器,存储器用于存储计算机指令,处理器用于从存储器中调用并运行该计算机指令,以执行上述第二方面或第二方面任一种可选方式所提供的方法。
第十三方面,提供了一种网络设备,该网络设备设置于SFF(SR代理),该网络设备包括:主控板和接口板。主控板包括:第一处理器和第一存储器。接口板包括:第二处理器、第二存储器和接口卡。主控板和接口板耦合。
第二存储器可以用于存储程序代码,第二处理器用于调用第二存储器中的程序代码,触发接口卡执行如下操作:接收第一报文,上述第一报文包括第一段路由头、第一IP头和第一IP载荷,上述第一段路由头封装于上述第一IP头和上述第一IP载荷外层。
第一存储器可以用于存储程序代码,第一处理器用于调用第一存储器中的程序代码执行如下操作:基于上述第一报文获得第二报文,上述第二报文包括第二IP头、上述第一IP载荷和上述第一段路由头,上述第二IP头封装于上述第一IP载荷和上述第一段路由头外层。
第二处理器还用于调用第二存储器中的程序代码,触发接口卡执行如下操作:向SF设备发送上述第二报文。
在一种可能的实现方式中,主控板和接口板之间建立进程间通信协议(inter-process communication,IPC)通道,主控板和接口板之间通过IPC通道进行通信。
第十四方面,提供了一种网络设备,该网络设备设置于SF设备,该网络设备包括:主控板和接口板。主控板包括:第一处理器和第一存储器。接口板包括:第二处理器、第二存储器和接口卡。主控板和接口板耦合。
第二存储器可以用于存储程序代码,第二处理器用于调用第二存储器中的程序代码,触发接口卡执行如下操作:接收来自于SFF的第一报文,上述第一报文包括第一IP头、第一IP载荷和第一段路由头,上述第一IP头封装于上述第一IP载荷和上述第一段路由头外层。
第一存储器可以用于存储程序代码,第一处理器用于调用第一存储器中的程序代码执行如下操作:基于上述第一报文进行业务处理。
在一种可能的实现方式中,主控板和接口板之间建立IPC通道,主控板和接口板之间通过IPC通道进行通信。
第十五方面,提供了一种系统,该系统包括上述第三方面提供的设于SFF的装置以及上述第四方面提供的设于SF设备的装置;或者,该网络系统包括上述第五方面提供的设于SFF的计算机设备以及上述第六方面提供的设于SF设备的计算机设备;或者,该网络系统包括上述第十三方面提供的设于SFF的网络设备以及上述第十四方面提供的设于SF的网络设备。
附图说明
图1是本申请实施例提供的一种SRv6报文的格式示意图;
图2是本申请实施例提供的一种SR-MPLS报文的格式示意图;
图3是本申请实施例提供的一种IPv4头的格式示意图;
图4是本申请实施例提供的一种IPv6头的格式示意图;
图5是本申请实施例提供的一种SR SFC的架构示意图;
图6是本申请实施例提供的一种SFC的典型场景的示意图;
图7是本申请实施例提供的一种报文处理方法的流程图;
图8是本申请实施例提供的一种IPv4选项的格式示意图;
图9是本申请实施例提供的一种报文处理方法的流程图;
图10是本申请实施例提供的一种报文处理方法的流程图;
图11是本申请实施例提供的一种报文处理方法的流程图;
图12是本申请实施例提供的一种报文处理方法的流程图;
图13是本申请实施例提供的一种SFF的结构示意图;
图14是本申请实施例提供的一种SF的结构示意图;
图15是本申请实施例提供的一种设备的结构示意图;
图16是本申请实施例提供的一种设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
下面对本申请实施例涉及的一些术语概念做解释说明。
(1)段路由(segment routing,SR)
SR是一种基于源路由转发模式的隧道技术。SR的一个基本设计思想是:在业务流的(SR隧道)头节点维护每条流(per-flow)的状态(即SR策略),无需在中间节点和尾节点维护每条流的状态。SR隧道的建立方式包括分布式和集中式两种方式。分布式的方式是指使用中间系统到中间系统(Intermediate system to intermediate system,IS-IS)、开放式最短路径优先(open shortest path first,OSPF)或边界网关协议(Border GatewayProtocol,BGP)发布段标识(segment ID,SID)的方式。集中式的方式是指由SDN控制器(英文:SDN controller)通过边界网关协议链路状态(border gateway protocol-linkstate,BGP-LS)或路径计算单元通信协议(path computation element communicationprotocol,PCEP)收集和计算路径的方式。头节点指定SR隧道的SID列表(SID list)的方式包括显式候选路径(explicit candidate path)和动态候选路径(dynamic candidatepath)这两种方式,详见draft-ietf-spring-segment-routing-policy-13。为了屏蔽部分网络的拓扑细节、以及规避硬件芯片MSD规格不足的问题,可以使用绑定的SID(bindingSID,BSID)将流量引入(steer)SR策略。
SR包括多协议标签交换(multi-protocol label switching,MPLS)和互联网协议第6版(internet protocol version 6,IPv6)两个数据面,分别称为SR-MPLS和SRv6。对于SRv6而言,除了具备SR的通用特点之外,与SR-MPLS相比,SRv6最为显著的地方就是支持网络编程(RFC8986),通过网络编程,使得SRv6具有非常强大的可扩展能力,可以适用于各种应用场景,例如,实现边界网关协议(border gateway protocol,BGP)或SR三层虚拟专用网络(SR layer 3virtual private network,SR L3 VPN)、以太虚拟私有网络二层虚拟专用网络(ethernet virtual private network layer 2VPN,EVPN L2 VPN)或以太虚拟私有网络三层虚拟专用网络(ethernet virtual private network layer 3VPN,EVPN L3VPN)、SFC等。
(2)SR报文
SR报文包括SR头和互联网协议(internet protocol,IP)报文。SR头封装于IP头和IP载荷外层。也就是说,按照从报文头至报文尾的顺序来看,SR报文中SR头在前,然后是IP头,然后是IP载荷。SR报文包括而不限于SRv6报文和SR-MPLS报文。
SR头通常由SR隧道的头节点添加至报文中。SR头包含SR隧道的路径信息。例如,SR头包含SR隧道中至少一个节点或至少一条链路的信息(如SID或标签等)。
SR报文中SR头包括多种情况。在SR报文为SRv6报文的情况下,SR报文中的SR头为SRv6头。SRv6头包括IPv6基本头和SRH,可选地还包括一个或多个IPv6扩展头。例如,请参考附图1,附图1是一种SRv6报文的格式示意图,SRv6头的具体格式可参考附图1。在SR报文为SR-MPLS报文的情况下,SR报文中的SR头为SR-MPLS头。例如,请参考附图2,附图2是一种SR-MPLS报文的格式示意图,SR-MPLS头的具体格式可参考附图2。
IP报文有时也称为数据报文、业务报文或原始报文。IP载荷包括业务数据。IP报文包括而不限于IPv4报文或者IPv6报文。在IP报文为IPv4报文的情况下,IP头具体为IPv4头。例如,请参考附图3,附图3是一种IPv4头的格式示意图,IPv4头的具体格式可参考附图3。
在IP报文为IPv6报文的情况下,IP头具体为IPv6头,IPv6头至少包括IPv6基本头,可选地还包括IPv6扩展头。例如,请参考附图4,附图4是一种IPv6头的格式示意图,IPv6头的具体格式可参考附图4。
(3)段路由头(segment routing header,SRH)
SRH是一种IPv6扩展头,具体是路由类型(routing type)为4的IPv6路由头(IPv6routing header)。SRH是IETF 6man WG定义的。SRH包括SID列表(SID list),SID列表用于指定IPv6报文的转发路径。SRH(RFC8754)采用的是宽松源路由模式,即,不要求转发路径上的每一跳都支持和解析SRH、也不要求SRH中的SID list包含路径上的每一跳节点。SRv6的隧道报文中可选地不包含SRH。
如附图1所示,SRH包括下一个头(next header)字段、扩展头长度(headerextended length,Hdr Ext Len)字段、路由类型(routing type)字段、剩余段数量(segments left,SL)、最后一个元素索引(last entry)字段、标志(flags)字段、tag字段和段列表(SID list)等。下面对SRH中的一些字段进行解释说明。
next header字段用于标识SRH的下一个报文头的类型。
Hdr Ext Len字段用于指示SRH的长度。
路由类型字段用于表示路由头的类型,对于SRH而言,路由类型字段的值是4。
SL用于指示到达目的节点前仍然应当访问的中间节点数量。SL字段的作用相当于一个指针,指向段列表中的活跃SID。例如,如果SRH的段列表包括5个SID,分别是SID0、SID1、SID2、SID3以及SID4,而SL取值为2,指示段列表中中的活跃SID是SID2。
最后一个元素索引(last entry)指示SID列表中最后一个元素的索引。
tag字段用于标识同组数据包。
段列表(SID list)包括一个或多个SRv6 SID。每个SRv6 SID是IPv6地址的形式,因此段列表相当于一个显式的IPv6地址栈。SRv6中段列表类似于SR-MPLS中的MPLS标签栈。
(4)IP头长度(internet header length,IHL)字段。
IHL是IPv4头其中的一个字段。IHL字段的长度是4个比特。IHL字段用于描述IP头的长度。
(5)总长度(total length)字段。
总长度字段是IPv4头其中的一个字段。总长度字段的长度是16个比特。总长度字段用于描述IP报文的总长度(包括IP头长度以及IP载荷长度)。
(6)IPv4选项
IPv4选项属于IPv4头的一部分。根据RFC791,IPv4选项总长度为40字节(byte,B)(受IHL的长度所限)。IPv4选项包括单字节选项和类型长度值(type length value,TLV)形式的选项这两种形式。TLV形式的选项包括1字节的选项类型字段、1字节的选项长度字段以及长度可变的选项数据字段(也称值字段)。
选项类型字段包括1比特的拷贝标志(copied flag)、2比特的选项分类(class)和5比特的选项编号(number)。其中选项class用来说明选项的用途,选项class的值为0时表示选项用于控制(control);选项class的值为2时表示选项用于调试和测量(debuggingand measurement);选项class的其余值保留未使用。
在RFC3692中,定义了IP协议用于实验用途的方法。在RFC4727中,则为互联网协议第四版(internet protocol version 4,IPv4)、基于IPv4的Internet控制报文协议(internet control message protocol for the IPv4,ICMPv4)、IPv6、基于IPv6的Internet控制报文协议(internet control message protocol for the IPv6,ICMPv6)、传输控制协议(transmission control protocol,TCP)或用户数据报协议(user datagramprotocol,UDP)的相关字段分配了实验参数值。
对于IPv4选项而言,选项类型30/94/158/222被保留为实验值,标准允许基于这几个选项类型进行自由扩展。
(7)段标识(segment ID,SID)
SID是SR的核心要素。在[RFC8402 Segment Routing Architecture]中,将段(segment)定义为下面的语义:A segment can represent any instruction,topologicalor service based。(一个SID能表示任意拓扑、指令或服务)。SID用来标识唯一的段。SR-MPLS中SID具有MPLS标签的形式,通常也可以称为SR-MPLS SID。SRv6中SID是IPv6地址形式,通常也可以称为SRv6SID(segment identifier)。
(8)SRv6 SID
SRv6 SID具有IPv6地址的形式。SRv6 SID的长度是128比特。SRv6 SID主要包括两个部分-定位(locator)以及功能(function),locator占据SRv6 SID的高比特位,function占据SRv6 SID的剩余部分。可选地,SRv6 SID还包括参数(arguments)。locator用于定位至发布SRv6 SID的节点。一个locator代表一个IPv6网段,该网段下的IPv6地址可作为SRv6SID分配。function代表设备的指令,这些指令在设备上预先设定,function部分用于指示SRv6 SID的发布节点进行相应的功能操作。
SRv6 SID的类型包括用于标识节点的End SID(Endpoint SID,端点SID)、用于标识三层链路的End.X SID(三层交叉连接的Endpoint SID)等等。本申请的一些实施例中,SRv6 SID的类型包括用于标识将SR报文编辑为特定格式报文这种代理(proxy)行为的SID类型。下述实例1中这种SRv6 SID的类型称为End.P4(P表示代理,4表示IPv4 VAS)。
(9)SR-MPLS SID
SR-MPLS SID具有MPLS标签的形式。SR-MPLS SID的长度是20比特。SR-MPLS SID的类型包括用于标识目的地址前缀的前缀段(prefix segment)、用于标识邻接的邻接段(adjacency segment)、用于标识节点的节点段(node segment)等。本实施例中,SR-MPLSSID的类型包括用于标识将SR报文编辑为设定格式的SID类型。
(10)不支持SR的SF(SR-unaware SF)
不支持SR的SF是指无法识别SR封装格式的SF。不支持SR的SF包括不支持SR-MPLS的SF以及不支持SRv6的SF。当不支持SR的SF接收到SR报文时,通常会由于无法识别SR封装格式而将SR报文丢弃,导致业务处理失败,因此需要为不支持SR的SF配置SF代理以实现业务链。
(11)本地SID表(local SID table)
本地SID表是使能SRv6的节点会维护的一个表。本地SID表用于保存本节点生成的SRv6SID以及SRv6 SID关联的信息。例如,本地SID表包括SRv6 SID、SID类型以及SID绑定的出接口等。
(12)业务功能链(service function chain,SFC)
SFC是一种给应用层提供有序服务的技术。SFC用来将网络设备上的服务在逻辑层面上联接起来,从而形成一个有序的服务组合。SFC通过在原始报文中添加业务链路径信息来实现报文按照指定的路径依次经过各个业务功能(service function,SF)。数据报文在网络中传递时,往往需要经过各种各样的SF,从而保证网络能够按照预先的规划为用户提供安全、快速、稳定的服务。
(13)业务功能转发设备(service function forwarder,SFF)
SFF用于将从网络中收到的报文转发到SFF关联的若干个SF上,转发的依据就是SR头封装的信息。SF处理后将报文再返回给SFF,SFF最终决定是否将报文发回网络中。
(14)SF
SF用于提供业务处理服务。SF包括而不限于防火墙(fire wall,FW)、负载均衡(load balancer,LB)、入侵防御系统(intrusion prevention system,IPS)、应用加速器、网络地址转换(network address translation,NAT)、Web应用防护系统(Web applicationfirewall,WAF,也称为网站应用级入侵防御系统)、带宽控制、病毒检测、云存储、深度包检测(deep packet inspection,DPI)、入侵检测、超文本传输协议(hyper text transferprotocol,HTTP)头部增强(HTTP header enrichment)等。在业务链中,网络流量需要按照业务逻辑所要求的既定顺序经过各个SF,从而实现所需要的业务。
根据是否可以感知SR封装,SF分为感知SR的SF(SR-aware SF)和不感知SR的SF(SR-unaware SF)。
SR-aware SF够识别收到的SR报文并对其进行处理,这种情况将SF的SID编排到业务链路径中可实现业务链。SR-unaware SF不识别SR报文,收到SR报文会将SR报文丢弃,这种场景需要配置SF代理以实现业务链。
(15)SF代理(SF proxy)
SF代理用于代替SF处理SR封装。通常情况下,SF代理的角色由SFF充当。SF代理的各种形式详见draft-ietf-spring-sr-service-programming-04的第6节。附图5示出了SR代理的通用架构。如附图5所示,当SR代理从上游节点接收到SR报文时,如果SR代理发现SF不支持SR,那么SR代理会将SR报文转换为非SR报文。之后,SR代理从与SF相连的出接口将非SR报文发送至SF。SF对接收到的非SR报文进行业务处理后,将业务处理后的非SR报文返回至SR代理。当SR代理从与SF相连的入接口接收到SF返回的非SR报文时,SR代理将非SR报文转换为SR报文,然后将SR报文转发给下游节点。
SRv6 SFC代理包括四种代理模式,其中静态代理(static proxy)和动态代理(dynamic proxy)最为常用。
静态代理方案的主要特征在于剥离和丢弃SRv6头。具体来说,当SFF接收到SRv6报文时,如果SFF采用静态代理的模式,SFF会将SRv6报文中的SRH剥离,丢弃剥离的SRH,将不包含SRH的报文转发至SF。当SFF接收到SF返回的报文后,SFF会根据静态配置的参数生成SRv6头,向SF返回的报文封装生成的SRv6头,从而恢复SRv6报文的封装格式,之后SFF继续转发封装得到的SRv6报文。
动态代理方案的主要特征在于剥离和缓存SRv6头。具体来说,当SFF接收到SRv6报文时,如果SFF采用动态代理的模式,SFF会将SRv6报文中的SRH剥离,生成用于保存SRH的动态表项,缓存生成的动态表项。SFF会将不包含SRH的报文转发至SF。当SFF接收到SF返回的报文后,SFF会访问缓存,查询缓存中的动态表项,从动态表项中获得之前剥离的SRH,向SF返回的报文封装SRv6头,转发封装得到的SRv6报文。
然而通过研究分析发现,静态代理方案和动态代理方案均存在不同程度的缺陷。
对于静态代理方案而言,由于静态代理方案中SFF直接丢弃SRv6头,将导致SRv6头包含的动态信息丢失,因而不能作为普适解决方案。例如,采用静态代理的方式会导致不支持:动态分配的SRv6虚拟专用网络(virtual private network,VPN)SID、基于网际互连协议数据流的随路OAM性能测量(in-situ Flow information Telemetry,iFit)、IPv6的网络感知应用(application-aware networking for IPv6,APN6)、网络分片(networkslicing)等。因而,静态代理的方式只适用于相对简单的、静态配置的SRv6网络。此外,静态代理的方案会导致配置十分繁琐。具体来说,由于对SF返回的报文进行SR封装恢复时,IPv6基本头以及SRH都需要SFF根据配置的参数生成,导致IPv6基本头中的很多参数(如hoplimit、源地址、目的地址)以及SRH中的很多参数(如SID列表)都需要管理员预先在SFF上配置,导致配置的工作量巨大且难度较高。
对于动态代理方案而言,虽然动态代理方案均能支持SRv6动态业务,但转发面是有状态的,也就是说需要占用大量的缓存来存储SRH,这导致实现复杂度很高,资源开销巨大,在性能方面(容量、速率、收敛等)存在比较大的压力,导致转发性能下降,无法支持大规模部署。
从业务需求来看,期望的SRv6 SFC代理行为应该同时满足如下两方面的需求。
第一方面,SRv6 SFC代理行为要支持SRv6动态业务。即,SRv6报文在SFF(代理)-->SF-->SFF(代理)转发过程中,需要保持SRv6头中携带的动态信息(非SRv6 SFC相关信息)不会丢失。
第二方面,SFF(代理)的数据面应该是无状态(stateless)。即,要尽可能避免数据面生成和维护用于缓存SRv6头的动态表项。
当前,对于IPv4 SF(即不支持IPv6的SF,通常是现网的存量设备)来说,还没有可行的方案能满足上述两方面需求。
以上针对SRv6 SFC的场景进行了分析,对于SR-MPLS SFC的场景而言,同样没有可行的方案能满足上述两方面需求。
而本申请的一些实施例中,扮演SF代理角色的SFF当接收到SR报文后,SFF将SR报文重新封装为设定格式的报文后转发给SF。本实施例提供的报文封装格式的主要特点在于,报文携带SR头,而IP头封装在外层,SR头封装在内层。可选地,这种报文还携带SFF插入的选项。比如,在SF是IPv4 SF的场景下,按照从报文头至报文尾的顺序来讲,这种报文中各个组成部分依次为:可选的隧道头、IPv4头、可选的IPv4选项(属于IPv4头的一部分)、IPv4载荷和SR头。那么,由于SR头位于IPv4载荷之后,SF在业务处理时能够忽略掉SR头,从而对SF透明,满足代理功能的基本要求。
对于上述第一方面中的需求而言,由于SFF向SF转发报文时没有丢弃报文中的SR头,SFF和SF双方在交互报文时,双方交互的报文始终携带着SR头,因此SR头包含的动态信息也就不会丢失,因此能支持SR-MPLS和SRv6的动态业务,从而满足上述第一方面的需求。举个例子,在通过业务链支持网络分片的场景下当报文在进入业务链时,头节点向报文封装一个包含网络分片的分片标识(slice ID)的SR头,以便业务链中每个SFF使用网络分片对应的资源转发报文。如果SFF向SF转发报文时丢弃SR头,会导致SR头携带的分片标识丢失,也就造成无法支持网络分片业务。而通过本实施例提供的方法,由于SFF向SF转发的报文仍包含SR头,SR头携带的分片标识也就不会丢失,因此能更好的支持网络分片业务。
对于上述第二方面中的需求而言,由于SF向SFF返回的报文中包含SR头,SF能利用报文中的SR头恢复SR封装,而不必依赖于保存SRH的动态表项,也就摆脱了必须生成和维护用于缓存SRH的动态表项的限制,因此解决了由于生成和维护动态表项会带来的一系列技术问题,比如资源开销大、性能下降、业务规模受限等,有助于实现无状态的业务链,比如管理面、控制面、数据面都是无状态的。
下面对本申请实施例的应用场景举例说明。
附图6是本申请实施例提供的一种SFC的典型场景的示意图。附图6包括流分类器(service classifier,SC)101、SFF 111、SF 112、SFF 121、SF 122以及出口节点131,附图6包含的各个设备能形成一个SFC域。下面通过(1)至(5),对附图6中各个设备的网络部署位置、典型产品形态、位置、作用、连接关系等举例说明。
(1)SC 101
SC 101部署在SFC域的边界入口。SC 101用于接收来自用户设备的业务报文,通过匹配五元组或者其他方式对业务报文进行分类,将分类后的业务报文重定向至SFC域。SC101的典型产品形态是一台网络设备,如路由器、交换机等。
在基于SR实现SFC的场景下,SC 101可选地充当SR隧道的头节点。SC 101用于将业务报文封装为SR报文,从而利用SR报文中的段路由头将业务报文引导至业务链中的各个设备。
(2)SFF 111
SFF 111用于将接收到的报文转发到SF 112,接收SF 112返回的处理后的报文,转发SF 112处理后的报文。SFF 111的典型产品形态是一台网络设备,如路由器、交换机等。
在基于SR实现SFC的场景下,如果SF 112不支持SR(即SF 112是一个SR-unaware的SF),SFF 111还用于充当SF 112的代理的角色。具体来说,SFF 111用于将接收到的SR报文封装为SF 112所支持的格式的报文,将封装后的报文转发至SF 112。SFF 111接收到SF 112返回的报文时,SFF 111还用于将SF 112返回的报文重新封装为SR报文,从而恢复SR报文的封装格式。
(3)SF 112
SF 112接入了SFF 111。SF 112用于对SFF 111发送的报文进行业务处理,将处理后的报文发送至SF 112。SF 112的典型产品形态包括而不限于服务器、主机、个人计算机、防火墙、入侵检测系统或者入侵防御系统等等。
(4)SFF 111与SF 112的连接关系
SFF 111与SF 112通过有线网络或者无线网络相连。SFF 111与SF 112之间通过网络传输彼此的报文。SFF 111与SF 112之间具体的网络连接方式包括多种情况,下面结合三种网络连接方式举例说明。
连接方式一、SFF 111与SF 112通过二层网络相连
具体地,SFF 111上的L2接口与SF 112上的L2接口相连。SFF与SF之间可选地存在一个或多个L2设备(如二层交换机)。
在连接方式一下,SFF 111与SF 112之间交互的报文携带在以太网帧中。具体地,SFF 111向SF 112发送报文的过程中,SFF 111会生成以太头,向报文封装以太头,得到以太网帧。SFF 111通过二层接口发送以太网帧。以太网帧利用以太头携带的媒体访问控制(media access control,MAC)地址等二层信息,通过二层网络转发至SF 112的二层接口。SF 112通过二层接口接收到以太网帧后,SF 112从以太网帧获得报文。SF 112向SFF 111发送处理后的报文的流程与此同理。
连接方式二、SFF 111与SF 112通过IP网络相连
在连接方式二下,SFF 111与SF 112之间交互的报文为IP报文。例如,请参考附图6,SFF 111将SRv6报文封装为IPv4报文之后,将IPv4报文通过IPv4网络转发至SF 112。
连接方式三、SFF 111与SF 112通过隧道(tunnel)相连
SFF 111与SF 112之间的隧道包括而不限于虚拟扩展局域网(virtualextensible local area network,VXLAN)、通用路由封装(generic routingencapsulation,GRE)隧道、基于VXLAN通用协议(VXLAN generic protocolencapsulation,VXLAN-GPE)、通用网络虚拟化封装(generic network virtualizationencapsulation,GENEVE)、移动IP数据封装和隧道(IP-in-IP)等等。
在连接方式三下,SFF 111与SF 112之间交互的报文包括IP报文和隧道头。按照从报文头至报文尾的顺序来讲,隧道头在先,IP报文在后。
例如,请参考附图6,SFF 111与SF 112之间交互的报文中还包括可选地隧道头。隧道头指示了在SFF 111与SF 112之间的隧道。隧道头用于在SFF 111与SF 112之间传输IPv4报文。隧道头包括而不限于VXLAN隧道头、GRE隧道头或者IP-in-IP隧道头等。在SFF 111向SF 112发送的报文中,隧道头中源地址包括SFF 111的IP地址且隧道头中目的地址包括SF112的IP地址。在SF 112向SFF 111返回的报文中,隧道头中源地址包括SF 112的IP地址且隧道头中目的地址包括SFF 111的IP地址。
SFF 121与SFF 111类似,SF 122与SF 112类似,可参考对SFF 111和SF 112的介绍。
(5)出口节点131
出口节点131部署在SFC域的边界出口。出口节点131用于将SF 112以及SF 122处理后的业务报文从SFC域转发出去。出口节点131的典型产品形态是一台网络设备,如路由器、交换机等。
在基于SR实现SFC的场景下,出口节点131可选地充当SR隧道的尾节点。SC 101用于解封装SR报文,得到业务报文。
附图6以部署2个SFF和2个SF为例进行说明。一个SFC域中部署的SFF或者SF的数量可选地更多或更少。例如,一个SFC域中部署的SFF或者SF仅为一个,又如一个SFC域中部署的SFF或者SF为几十个或几百个,或者更多数量,本实施例对SFF或者SF的数量不做限定。
附图6以一个SF接入一个SFF(即单归接入)为例进行说明。可替代地,一个SF接入两个或两个以上的SFF(即多归接入),本实施例对SF接入的SFF的数量不做限定。
以上结合附图6介绍了SFC的整体架构,下面对将附图6所示架构应用在SRv6场景下SFF接入IPv4 SF的情况下的基本流程进行说明。
SC 101接收到用户设备1发送的IPv4报文之后,SC 101生成包括IPv6基本头和SRH的SRv6头,SC 101向接收到的IPv4报文的外层封装SRv6头,得到SRv6报文。SC 101将得到的SRv6报文转发至SFF 111。其中,SRv6报文的外层为SRv6头且内层为IPv4报文。SRv6头中SRH的段列表包括SFF 111的SRv6 SID、SFF 121的SRv6 SID以及出口节点131的SID。
SFF 111接收SC 101发送的SRv6报文之后,SFF 111将SRv6报文封装为IPv4报文的格式(即IPv4头封装于SRv6头外层),将封装得到的IPv4报文转发至SF 112。SF 112接收到SFF 111发送的IPv4报文之后,根据IPv4报文中IPv4载荷进行业务处理,向SFF 111返回业务处理后的IPv4报文。SFF 111接收到SF 112返回的处理后的IPv4报文之后,SFF 111将IPv4报文重新封装为SRv6报文(即SRv6头封装于IPv4头外层),SFF 111基于SRv6头向SFF121转发SRv6报文。SFF 121和SF 122进行SFF 111与SF 112类似的步骤,
出口节点131接收到SFF 121发送的SRv6报文之后,出口节点131剥离SRv6报文中的SRv6头,得到IPv4报文。出口节点131将IPv4报文从SFC域出去,最终报文到达用户设备2。
下面对本申请实施例的方法流程举例说明。
附图7是本申请实施例提供的一种报文处理方法的流程图。附图7所示方法包括以下步骤S201至步骤S209。
附图7所示方法涉及报文从SFF转发至SF的流程以及报文从SF返回至SFF的流程。一个报文经过SFF或SF后,内容可能发生变化也可能保持不变。为了区分描述,用“第一报文”、“第二报文”“第三报文”、“第四报文”描述转发流程中不同阶段的报文。
附图7所示方法所基于的网络部署场景可选地如上述附图6所示。例如,结合附图6来看,附图7所示方法中的SFF为附图6中的SFF 111,附图7所示方法中的SF为附图6中的SF112。附图7所示方法中第一报文是附图6中SC 101发送至SFF 111的报文。附图7所示方法中第二报文是附图6中SFF 111发送至SF 112的报文。附图7所示方法中第三报文是附图6中SF112发送至SFF 111的报文。附图7所示方法中第四报文是附图6中SFF 111发送至SFF 121的报文。
附图7所示方法存在四种典型的应用场景:SRv6 SFC代理场景中SFF接入IPv4 SF、SRv6 SFC代理场景中SFF接入IPv6 SF、SR-MPLS SFC代理场景中SFF接入IPv4 SF以及SR-MPLS SFC代理场景中SFF接入IPv6 SF。当应用在SRv6 SFC代理场景中SFF接入IPv4 SF时,报文中外层SR头是SRv6头且内层IP报文为IPv4报文;当应用在SRv6 SFC代理场景中SFF接入IPv6 SF时,报文中外层SR头是SRv6头且内层IP报文为IPv6报文;当应用在SR-MPLS SFC代理场景中SFF接入IPv4 SF时,报文中外层SR头是SR-MPLS头且内层IP报文为IPv4报文;当应用在SR-MPLS SFC代理场景中SFF接入IPv6 SF时,报文中外层SR头是SR-MPLS头且内层IP报文为IPv6报文。
步骤S201、SFF接收第一报文。
第一报文是SR报文。SR的概念可参考上文术语解释部分中的(1)。第一报文具有SR头封装于IP头和IP载荷外层的格式。第一报文包括第一段路由头、第一IP头和第一IP载荷,第一段路由头封装于第一IP头和第一IP载荷外层。
可选地,结合附图6来看,第一报文中第一IP头和第一IP载荷是附图6中用户设备1生成的,第一SR头是SC 101生成并封装在第一IP头和第一IP载荷外层的。具体地,第一IP头中的源地址包括附图6中用户设备1的地址,第一IP头中的目的地址包括附图6中用户设备2的地址,第一IP载荷包括附图6中用户设备1要传输至用户设备2的业务数据。第一SR头包含路径信息,该路径信息表示IP载荷中业务数据在附图6中业务链域中的转发路径,该路径信息通过SFF 111或者SFF 121上的SID表示。例如,上层业务要求业务数据先经过SF 112的业务处理,再经过SF 122的业务处理,SC 101封装的第一SR头包括SFF 111为SF 112的代理功能分配的SID、SFF 121为SF 122的代理功能分配的SID以及出口节点131的SID,从而指示SFF 111和SFF 121将报文依次转发至SF 112和SF 122。
第一报文具体的格式存在多种可能情况,下面结合情况一至情况四这四种情况对第一报文举例说明。
情况一、第一报文中SR头是SRv6头且内层报文是IPv4报文。
具体地,第一段路由头为SRv6头,第一IP头为IPv4头,第一IP载荷为IPv4载荷。
情况二、第一报文中SR头是SRv6头且内层报文是IPv6报文。
具体地,第一段路由头为SRv6头,第一IP头为IPv6头,第一IP载荷为IPv6载荷。
在上述情况一和情况二下,第一报文例如具有附图1所示的封装格式。
情况三、第一报文中SR头是SR-MPLS头且内层报文是IPv4报文。
具体地,第一段路由头为SR-MPLS头,第一IP头为IPv4头,第一IP载荷为IPv4载荷。
情况四、第一报文中SR头是SR-MPLS头且内层报文是IPv6报文。
具体地,第一段路由头为SR-MPLS头,第一IP头为IPv6头,第一IP载荷为IPv6载荷。
在上述情况三和情况四下,第一报文例如具有附图2所示的封装格式。
步骤S202、SFF基于第一报文获得第二报文。
步骤S203、SFF向SF发送第二报文。
SFF向SF转发报文时,SFF会修改报文的封装格式。例如,第二报文中的SR头和第一报文中的SR头具有不同的携带位置。上述第一报文中SR头封装在IP头的外层,而第二报文中SR头封装在IP头的内层。
具体来说,第二报文包括第二IP头、第一IP载荷和第一段路由头,第二IP头封装于第一IP载荷和第一段路由头外层。
第二报文具体的格式存在多种可能情况,下面结合情况一至情况四这四种情况对第二报文举例说明。当第一报文属于上述步骤S201中的情况一时,第二报文属于步骤S203中的情况一;当第一报文属于上述步骤S201中的情况二时,第二报文属于步骤S203中的情况二;当第一报文属于上述步骤S201中的情况三时,第二报文属于步骤S203中的情况三;当第一报文属于上述步骤S201中的情况四时,第二报文属于步骤S203中的情况四。
情况一、第二报文中SR头是SRv6头且内层报文是IPv4报文。
具体地,第一段路由头为SRv6头,第二IP头为IPv4头,第一IP载荷为IPv4载荷。
情况二、第二报文中SR头是SRv6头且内层报文是IPv6报文。
具体地,第一段路由头为SRv6头,第二IP头为IPv6头,第一IP载荷为IPv6载荷。
情况三、第二报文中SR头是SR-MPLS头且内层报文是IPv4报文。
具体地,第一段路由头为SR-MPLS头,第二IP头为IPv4头,第一IP载荷为IPv4载荷。
情况四、第二报文中SR头是SR-MPLS头且内层报文是IPv6报文。
具体地,第一段路由头为SR-MPLS头,第二IP头为IPv6头,第一IP载荷为IPv6载荷。
可选地,在报文从SFF转发至SF的过程中,SFF修改IP头中一个或多个字段的内容。也即是,第二IP头和第一IP头存在一个或多个字段的内容不同。下面,结合下述(a)至(d)对第二IP头和第一IP头中可能具有不同内容的字段举例说明。
(a)表示IP载荷长度的字段
在一些实施例中,第二IP头和第一IP头中表示IP载荷长度的字段的内容不同。也即是,SFF会对接收到的报文中表示IP载荷长度的字段进行修改。
具体来说,第二IP头中表示IP载荷长度的字段所携带的长度包含SR头的长度,第一IP头中表示IP载荷长度字段所携带的长度不包含SR头的长度。例如,可选地第二IP头中表示IP载荷长度的字段与第一IP头中表示IP载荷长度的字段所携带的长度的差值为第一SR头的长度。
例如,在IP头为IPv4头的情况下,IP头中表示IP载荷长度的字段为总长度(totallength)字段。在IP头为IPv6头的情况下,IP头中表示IP载荷长度的字段为载荷长度(payload length)字段。
(b)表示IP头长度的字段
可选地,在SFF向第一报文中第一IP头中添加字段(如新增选项)的情况下,第二IP头和第一IP头中表示IP头长度的字段的内容不同。也即是,SFF会对接收到的报文中表示IP头长度的字段进行修改。
具体来说,第二IP头中表示IP头长度的字段所携带的长度包含SFF添加字段的长度。例如,可选地第二IP头中表示IP头长度的字段与第一IP头中表示IP头长度的字段所携带的长度的差值为SFF添加字段的长度。
例如,在IP头为IPv4头的情况下,IP头中表示IP头长度的字段为IP头长度(IHL)。
可替代地,第二IP头和第一IP头中表示IP头长度的字段的内容相同。
(c)用于对IP头进行校验的字段
可选地,在SFF向第一报文中第一IP头中添加字段(如新增选项)的情况下,第二IP头和第一IP头中用于对IP头进行校验的字段的内容不同。也即是,SFF会对接收到的报文中用于对IP头进行校验的字段进行修改。
具体来说,第二IP头中用于对IP头进行校验的字段的内容是根据第二IP头计算出来的。
第一IP头中用于对IP头进行校验的字段的内容是根据第一IP头计算出来的。
例如,在IP头为IPv4头的情况下,IP头中用于对IP头进行校验的字段为头校验(header checksum)字段。
可替代地,第二IP头和第一IP头中用于对IP头进行校验的字段的内容相同。
(d)表示报文存活时间的字段
可选地,第二IP头和第一IP头中表示报文存活时间的字段的内容不同。也即是,SFF会对接收到的报文中表示报文存活时间的字段进行修改。可替代地,第二IP头和第一IP头中表示报文存活时间的字段的内容相同。SFF是否对接收到的报文中表示报文存活时间的字段进行修改可选地根据SFF的转发策略确定。
例如,在IP头为IPv4头的情况下,IP头中表示报文存活时间的字段为生存时间(time to live,TTL)字段。在IP头为IPv6头的情况下,IP头中表示报文存活时间的字段为跳数限制(hop limit)字段。
以上通过(a)至(d)列举了一些SFF向SF转发报文时可能修改的IP头中字段。SFF修改字段的具体方式可参考下述实例1中的介绍。可选地,SFF对IP头中(a)至(d)中至少一项进行修改,且保持IP头中上述(a)至(d)之外的每个字段的内容不变。可替代地,SFF保持IP头中每个字段的内容均不变。
步骤S204、SF接收来自于SFF的第二报文。
步骤S205、SF基于第二报文进行业务处理。
具体来说,SF基于第二报文中的第二IP头和第一IP载荷进行业务处理,而忽略第二报文中的第一SR头。
可选地,SF还向SFF返回业务处理后的报文,SFF还将SF返回的报文的封装格式恢复为SR报文的格式后继续进行转发。具体地,附图7所示方法可选地还包括以下步骤S206至步骤S209。
步骤S206、SF向SFF发送经业务处理后获得的第三报文。
在一些实施例中,SFF在返回报文时保持报文的封装格式不变。具体地,第三报文中的SR头和第二报文中的SR头具有相同的携带位置。第三报文中SR头封装在IP头的内层。例如,第三报文包括第三IP头、第二IP载荷和第一段路由头,第三IP头封装于第二IP载荷和第一段路由头外层。
第三报文具体的格式存在多种可能情况,下面结合情况一至情况四这四种情况对第三报文举例说明。
情况一、第三报文中SR头是SRv6头且内层报文是IPv4报文。
具体地,第一段路由头为SRv6头,第三IP头为IPv4头,第二IP载荷为IPv4载荷。
情况二、第三报文中SR头是SRv6头且内层报文是IPv6报文。
具体地,第一段路由头为SRv6头,第三IP头为IPv6头,第二IP载荷为IPv6载荷。
情况三、第三报文中SR头是SR-MPLS头且内层报文是IPv4报文。
具体地,第一段路由头为SR-MPLS头,第三IP头为IPv4头,第二IP载荷为IPv4载荷。
情况四、第三报文中SR头是SR-MPLS头且内层报文是IPv6报文。
具体地,第一段路由头为SR-MPLS头,第三IP头为IPv6头,第二IP载荷为IPv6载荷。
可选地,在报文从SF返回至SFF的过程中,SF修改IP头的内容。也即是,上述第三IP头和第二IP头存在一个或多个内容不同的字段。可替代地,在报文从SF返回至SFF的过程中,SF不修改IP头的内容。也即是,上述第三IP头和第二IP头每个字段内容相同。
可选地,在报文从SF返回至SFF的过程中,SF修改IP载荷的内容。也即是,上述第二IP载荷和第一IP载荷存在一个或多个内容不同的字段。可替代地,在报文从SF返回至SFF的过程中,SF不修改IP载荷的内容。也即是,上述第二IP载荷和第一IP载荷每个字段内容相同。
SF是否修改IP载荷或者IP头的内容,以及SF具体修改IP载荷或者IP头中哪些字段的内容例如根据SF负责的业务确定。例如,SF负责的业务具体是目的地址转换(destination network address translation,DNAT),SF接收到SFF发送的报文后,SF对IP头中的目的地址进行了替换,并对IP载荷中TCP头或UDP头中的目的端口号进行替换,那么IP头中目的地址字段以及IP载荷中目的端口号字段的内容发生了改变,第三IP头中目的地址字段的内容是SF替换后的地址,第二IP载荷中目的端口号字段的内容是SF替换后的端口号。又如,SF负责的业务是流量过滤,SF接收到SFF发送的报文后,SF对报文中五元组与设定的过滤条件进行匹配,如果报文中五元组与过滤条件匹配,SF允许报文通过,则向SFF返回报文,同时不修改IP载荷以及IP头的内容。
步骤S207、SFF接收来自于SF的第三报文。
步骤S208、SFF基于第三报文获得第四报文。
步骤S209、SFF基于第一段路由头发送第四报文。
第四报文中SR头和第三报文中SR头具有不同的携带位置,第四报文中SR头和第一报文SR头具有相同的携带位置。第四报文中SR头封装在IP头的外层。由此可见,SFF将SFF返回的报文(第三报文)恢复至当初接收到的SR报文(第一报文)的封装格式。具体来说,第四报文包括第一段路由头、第四IP头和第三IP载荷,第一段路由头封装于第四IP头和第三IP载荷外层。
第四报文的接收端包括多种情况。可选地,SFF向业务链中下一个SFF发送第四报文。例如,结合附图6来看,SFF是附图6中SFF 111,SFF 111向SF 112发送第四报文。可替代地,SFF向业务链中出口节点发送第四报文。例如,结合附图6来看,SFF是附图6中SF 112,SF112向出口节点131发送第四报文。
第四报文具体的格式存在多种可能情况,下面结合情况一至情况四这四种情况对第四报文举例说明。当第一报文属于上述步骤S201中的情况一时,第四报文属于步骤S209中的情况一;当第一报文属于上述步骤S201中的情况二时,第四报文属于步骤S209中的情况二;当第一报文属于上述步骤S201中的情况三时,第四报文属于步骤S209中的情况三;当第一报文属于上述步骤S201中的情况四时,第四报文属于步骤S209中的情况四。
情况一、第四报文中SR头是SRv6头且内层报文是IPv4报文。
具体地,第一段路由头为SRv6头,第四IP头为IPv4头,第三IP载荷为IPv4载荷。
情况二、第四报文中SR头是SRv6头且内层报文是IPv6报文。
具体地,第一段路由头为SRv6头,第四IP头为IPv6头,第三IP载荷为IPv6载荷。
情况三、第四报文中SR头是SR-MPLS头且内层报文是IPv4报文。
具体地,第一段路由头为SR-MPLS头,第四IP头为IPv4头,第三IP载荷为IPv4载荷。
情况四、第四报文中SR头是SR-MPLS头且内层报文是IPv6报文。
具体地,第一段路由头为SR-MPLS头,第四IP头为IPv6头,第三IP载荷为IPv6载荷。
以上通过步骤S206至步骤S209介绍了SF返回报文的情况下如何对SF返回的报文进行SR封装格式的恢复。在另一些实施例中,SF不执行返回报文的步骤。例如,SF是一个防火墙,如果SF发现SFF发送的报文中存在安全威胁,则SF拦截报文,不向SFF返回报文,以便阻断攻击流量的传输。
本实施例提供的方法,当SFF接收到一个SR封装格式的报文时,SFF修改报文的封装格式,将报文中的IP头封装于SR头的外层,将修改后的报文发送至SF。由于报文从SFF转发至SF的过程中,报文仍携带着SR头,因此,当报文后续从SF返回至SFF时,SFF能利用报文携带的SR头恢复原先的SR封装格式,从而摆脱了必须生成和维护用于保存SRH的缓存空间才能恢复SR封装格式的限制,也就避免了生成和维护用于保存SRH的缓存空间会带来的巨大资源开销,节省了资源开销。
可选地,附图7所示方法具体是通过一种新定义的SID类型实现的。
具体来说,本实施例提供了一种新的SID类型,并将这种SID类型与将SR头挪到载荷之后的行为关联起来。当SFF接收到一个SR报文时,如果SFF发现SR报文中SR头中的SID与这种SID类型匹配,则会将接收到的报文中的SR头挪到载荷之后,从而改变SR报文的封装格式。
例如,第一段路由头包括第一SID,SFF保存第一对应关系,SFF基于第一报文获得第二报文包括:SFF根据第一SID和第一对应关系,获得SID类型;SFF根据SID类型对第一报文进行第一处理,获得第二报文。
第一SID是一个SR SID。第一SID例如为SRv6 SID或者MPLS标签。SFF从第一报文获得第一SID的过程包括:SFF从第一段路由头中确定活跃SID,得到第一SID。
活跃SID是指段路由头中的SID列表中当前需要被处理的SID。例如,对于SRv6而言,活跃SID是IPv6基本头中目的地址字段中的SID。又如,对于SR-MPLS而言,活跃SID是SR-MPLS头中标签栈的栈顶标签。
从第一段路由头中获得第一SID的过程例如包括:在第一段路由头为SRv6头的情况下,SFF从第一段路由头中IPv6基本头中目的地址字段获得第一SID。在第一段路由头为SR-MPLS头的情况下,SFF从第一段路由头中标签栈的栈顶标签字段获得第一SID。
第一对应关系包括第一SID和SID类型。可选地,第一对应关系是SFF本地的SID表中的一条表项。例如,请参考下表1,表1是SID表的举例说明。第一对应关系例如是SID表中10:1::1:0所在的表项。第一SID例如是10:1::1:0,第一SID对应的SID类型例如是End.P4。
表1
Figure BDA0003113647610000201
可选地,SFF具体通过查表的方式获得SID类型。例如,SFF根据第一SID查询SID表;响应于第一SID在SID表中命中第一SID对应的SID类型,SFF根据第一SID对应的SID类型对第一报文进行第一处理,获得第二报文。
第一SID对应的SID类型用于表示不支持段路由头。第一SID对应的类型例如是一种SR代理SID。
第一处理是指报文从SFF转发至SF的过程中SFF对报文的处理。第一处理包括将第一段路由头设于第一IP载荷后且第一IP头被替换为第二IP头。
可选地,第一对应关系还包括第一SID绑定的出接口或者第一SID绑定的入接口中至少一项。例如,请参考上表1,第一SID例如是10:1::1:0,第一SID绑定的入接口为接口Ethernet 1/0/0.2,第一SID绑定的出接口为接口Ethernet 1/0/0.1。
第一SID绑定的出接口用于向SF发送第一处理后的报文。例如,SFF在执行上述步骤S203时,通过第一SID绑定的出接口向SF发送第二报文。
第一SID绑定的入接口用于接收SF返回的经过业务处理后的报文。例如,SFF在执行上述步骤S207时,通过第一SID绑定的入接口接收来自于SF的第三报文。
通过以上方式,SFF对报文的处理行为与SR协议兼容,实现复杂度较低且配置简单。
可选地,当SFF接收到SF返回的报文时,SFF根据报文相关的一些信息的指示,恢复SR报文封装格式。具体如何指示SFF恢复SR报文的封装格式存在多种实现方式,下面结合实现方式(1)至实现方式(3)举例说明。
实现方式(1)基于SF返回的报文中的IP头。
以SF返回的报文中的IP头为第三IP头为例,SFF基于第三IP头对第三报文进行第二处理,获得第四报文。在一种可能的实现中,SFF判断第三IP头中是否包括标识信息,如果第三IP头包括标识信息,则SFF对第三报文进行第二处理,获得第四报文。
第二处理是指SFF对SF返回的报文的处理方式。第二处理用于恢复SR报文封装格式。第二处理包括用第四IP头替换第三IP头且第一段路由头封装于第四IP头和第三IP载荷外层。
标识信息用于标识本实施例提供的报文封装格式,即段路由头设于IP载荷后。例如,第三IP头包括的标识信息用于标识第一段路由头设于第二IP载荷后。
可选地,SF返回的报文中IP头中的标识信息是SFF之前添加至报文中的。具体来说,SFF向SF转发报文时,SFF向报文中添加标识信息,从而标识报文具有段路由头设于IP载荷后的封装格式。SFF将包含标识信息的报文发送至SF,SF接收包含标识信息的报文。在SF进行业务处理的过程中,SF保留报文中的标识信息不变。SF进行业务处理后,SF向SFF返回包含标识信息的报文,使得SFF接收到的报文包括标识信息。以SFF发送的报文中的IP头为第二IP头为例,第二IP头也包括标识信息,第二IP头中标识信息用于标识第一段路由头设于第一IP载荷后。
通过上述方式,由于SFF在上行处理时添加了标识信息,便于SFF根据返回的报文是否携带标识信息判断是否执行封装SR报文格式的处理。
标识信息在报文中的携带位置包括多种实现方式。在一种可能的实现中,标识信息携带在IP头中的一个选项中。例如,第三IP头和第二IP头均包括第一选项,第一选项携带标识信息。
携带标识信息的选项包括而不限于IPv4头中的选项以及IPv6扩展头中的选项。下面对一些用来携带标识信息的选项举例说明,参见下述方式(1-1)至方式(1-3)。
方式(1-1)在内层报文是IPv4报文的情况下,通过IPv4头中的选项携带标识信息。
例如,第三IP头和第二IP头均为IPv4头,第三IP头和第二IP头中第一选项均为IPv4头中的IPv4选项。
方式(1-2)在内层报文是IPv6报文的情况下,通过逐跳选项头这种IPv6扩展头中的选项携带标识信息。
例如,第三IP头和第二IP头均为包括逐跳选项头的IPv6头,第三IP头和第二IP头中第一选项均为逐跳选项头中的选项。
方式(1-3)在内层报文是IPv6报文的情况下,通过目的选项头这种IPv6扩展头中的选项携带标识信息。
例如,第三IP头和第二IP头均为包括目的选项头的IPv6头,第三IP头和第二IP头中第一选项均为目的选项头中的选项。
标识信息在选项中具体携带位置包括多种情况。可选地,新增一种类型的选项,通过选项的类型字段携带标识信息。也就是说,使用选项类型充当用于标识段路由头设于IP载荷后的报文封装格式的信息。例如,第一选项的类型字段携带标识信息。可替代地,通过已有选项的值字段(也称选项数据字段)携带标识信息。例如,第一选项的值字段携带标识信息。
实现方式(2)基于SF返回的报文的入接口。
例如,SFF基于接收第三报文的接口对第三报文进行第二处理,获得第四报文。在一种可能的实现中,SFF判断接收第三报文的接口是否为第一SID绑定的入接口,如果SFF接收第三报文的接口为第一SID绑定的入接口,则SFF对第三报文进行第二处理。
实现方式(3)基于SF返回的报文中的IP头和入接口。
实现方式(3)相当于实现方式(1)和实现方式(2)以且的关系结合。例如,SFF基于接收第三报文的接口和第三IP头对第三报文进行第二处理,获得第四报文。在一种可能的实现中,SFF判断第三IP头中是否包括标识信息以及接收第三报文的接口是否为第一SID绑定的入接口,如果第三IP头包括标识信息且SFF接收第三报文的接口为第一SID绑定的入接口,则SFF对第三报文进行第二处理。
在一些实施例中,在SFF向SF发送报文的过程中,SFF还向IP头添加长度信息,以便SF根据IP头中的长度信息确定IP载荷的边界。以SFF向SF发送的报文包括第二IP头、第一IP载荷和第一段路由头为例,第二IP头还包括第二长度信息,第二长度信息用于指示第一IP载荷的长度,或者第二长度信息用于指示第一IP载荷和第二IP头的长度之和。SFF在基于第二报文进行业务处理时,根据第二长度信息确定第一IP载荷的结束位置,从而忽视第一IP载荷之后的第一SR头。
在一些实施例中,SF向SFF返回的报文中的IP头包括长度信息,以便SFF根据IP头中确定SR头的位置。以SF返回的报文包括第三IP头、第二IP载荷和第一段路由头为例,第三IP头还包括第一长度信息,第一长度信息用于确定第三报文中第一段路由头的位置。第一长度信息用于指示第二IP载荷的长度,或者第一长度信息用于指示第三IP头和第二IP载荷的长度之和。
可选地,当SF接收到SFF发送的包含长度信息的报文之后,SFF不修改报文中的长度信息。例如,上述第二长度信息和第一长度信息相同。可替代地,当SF接收到SFF发送的包含长度信息的报文之后,SFF修改报文中的长度信息。例如,上述第二长度信息和第一长度信息不同。
SF是否修改报文中的长度信息例如根据SF负责的业务确定。例如,在SF的业务涉及向报文中IP载荷中添加一些内容或者删除一些内容的情况下,SF返回的报文中IP载荷的长度相对于SFF发给SF的报文而言发生了改变,那么SF会通过修改SFF发送的报文中的长度信息,来表示改变后IP载荷的长度。
具体地,在SF向IP载荷添加内容的情况下,IP载荷变长,SF会根据添加内容的长度,对SFF发送的报文中的长度信息进行修改。SF修改后的长度信息包含SF添加内容的长度。例如,第二长度信息与第一长度信息相比,第二长度信息表示的长度不仅包括第一长度信息表示的长度(如IP载荷原始的长度),还包括SF添加内容的长度,第二长度信息表示的长度相当于第一长度信息表示的长度与SF添加内容的长度之和。
在SF从报文删除内容的情况下,IP载荷变短,SF根据删除内容的长度,对SFF发送的报文中的长度信息进行修改。SF修改后的长度信息不再包含SF删除内容的长度。例如,第二长度信息与第一长度信息相比,第二长度信息表示的长度少了SF删除内容的长度,第二长度信息表示的长度相当于第一长度信息表示的长度与SF删除内容的长度之差。
举个更具体的例子,SF的业务具体是HTTP头部增强,SF向SFF发送的报文中的HTTP头中添加了用户信息和设备标识信息,使得报文中IP载荷部分变长,那么SF对报文中的长度信息进行修改,使得修改后的长度信息包含添加的用户信息和设备标识信息。
长度信息在报文中的携带位置包括多种实现方式。在一种可能的实现中,长度信息携带在IP头中的一个选项中。例如,第三IP头和第二IP头均包括第一选项,第一选项携带长度信息。携带长度信息的选项包括而不限于IPv4头中的选项以及IPv6扩展头中的选项,可参考方式(1-1)至方式(1-3)的介绍。
可选地,长度信息和标识信息携带在IP头中同一个选项中。例如,第三IP头和第二IP头均包括第一选项,第一选项携带标识信息和长度信息。例如,第一选项的类型字段携带标识信息携带标识信息,类型字段之后的值字段携带长度信息。
可选地,在附图7所示方法中SFF执行步骤S202的过程中,SFF还向报文中IP头的外层封装报文头,以便通过IP头外层的报文头将报文从SFF转发至SF。
SFF是否向IP头外层封装报文头以及具体封装哪一种报文头,与SFF与SF之间的网络连接方式有关。下面,结合SFF与SF之间的三种网络连接方式举例说明。
连接方式一、SFF与SF之间通过二层网络相连。
在采用连接方式一的情况下,在SFF向SF发送报文时,SFF还向报文中IP头的外层封装以太头。SFF发送的报文相当于以太网帧。SFF发送的报文的封装格式为:以太头+IP头+IP载荷+SR头。具体地,在内层报文是IPv4报文的情况下,SFF发送的报文的封装格式为:以太头+IPv4头(可选地包括IPv4选项)+IP载荷+SR头;在内层报文是IPv6报文的情况下,SFF发送的报文的封装格式为:以太头+IPv6基本头+可选地IPv6扩展头(可选地包括IPv6选项)+IP载荷+SR头。
以太头包含1层或两层VLAN标签(VLAN tag),例如dot1q(即802.1q)或QinQ(即802.1Q-in-802.1Q,也称Stacked VLAN或Double VLAN,特点是包含两层802.1Q标签,一层公网标签,一层私网标签)。
以上述第二报文为例,第二报文可选地还包括第一以太头,第一以太头封装于第二IP头外层。例如,请参考附图6,SFF 111向SF 112发送的报文(即第二报文)中,可选地,IP头(即第二IP头)的外层还封装有以太头(即第一以太头),以便通过二层网络将IP头、IP载荷和段路由头转发至SF 112。
连接方式二、SFF与SF之间通过三层网络相连。
具体地,SFF上的IP接口与SF上的IP接口相连。SFF与SF之间可选地存在一个或多个L3设备(如路由器或三层交换机)。
在采用连接方式二的情况下,SFF向SF发送报文中最外层的报文头可选地是IP头。
连接方式三、SFF与SF之间通过显式隧道(tunnel)相连。
在采用连接方式三的情况下,在SFF向SF发送报文时,SFF还向报文中IP头的外层封装隧道头。SFF发送的报文的封装格式为:隧道头+IP头+IP载荷+SR头。例如,在内层报文是IPv4报文的情况下,SFF发送的报文的封装格式为:隧道头+IPv4头(可选地包括IPv4选项)+IP载荷+SR头;在内层报文是IPv6报文的情况下,SFF发送的报文的封装格式为:隧道头+IPv6基本头+可选地IPv6扩展头(可选地包括IPv6选项)+IP载荷+SR头。
隧道头的具体类型例如根据SFF与SF之间隧道的类型确定。隧道头包括而不限于VXLAN头、GRE头、VXLAN-GPE头、GENEVE头等。
以上述第二报文为例,可选地,第二报文还包括第一隧道头,第一隧道头封装于第二IP头外层。例如,请参考附图6,SFF 111向SF 112发送的报文(即第二报文)中,可选地,IP头(即第二IP头)的外层还封装有隧道头(即第一隧道头),以便通过隧道将IP头、IP载荷和段路由头转发至SF 112。
以上结合三种连接方式,对从SFF至SF的报文中IP头外层可能存在的报文头进行了说明。在IP头外层存在报文头的情况下,附图7所示方法中SF在执行步骤S205时,SF可选地先终结第二报文中IP头外层的报文头(如以太头或隧道头),再进行业务处理。
可选地,在附图7所示方法中SF执行步骤S205至步骤S206的过程中,SF还向报文中IP头的外层封装报文头,以便通过IP头外层的报文头将报文从SF返回至SFF。
通常情况下,报文从SF返回至SFF的流程中SF向IP头外层封装报文头的动作,与报文之前从SFF转发至SF的流程中SFF向IP头外层封装报文头的动作,是两种对称的动作。举个例子,如果SFF转发报文时,SFF先封装隧道头再将包含隧道头的报文转发给SF,那么SF在返回报文时,SF也会先封装隧道头再将包含隧道头的报文转发给SF。下面,仍结合SF与SFF之间的三种网络连接方式,对SF在IP头之外封装的报文头举例说明。
连接方式一、SF与SFF之间通过二层网络相连。
在采用连接方式一的情况下,在SF向SFF发送报文时,SF还向报文中IP头的外层封装以太头。SF发送的报文相当于以太网帧。SF发送的报文的封装格式为:以太头+IP头+IP载荷+SR头。具体地,在内层报文是IPv4报文的情况下,SF发送的报文的封装格式为:以太头+IPv4头(可选地包括IPv4选项)+IP载荷+SR头;在内层报文是IPv6报文的情况下,SF发送的报文的封装格式为:以太头+IPv6基本头+可选地IPv6扩展头(可选地包括IPv6选项)+IP载荷+SR头。
以太头包含1层或两层VLAN tag(例如dot1q或QinQ)。
以上述第三报文为例,第三报文可选地还包括第二以太头,第二以太头封装于第三IP头外层。
连接方式二、SF与SFF之间通过三层网络相连。
具体地,SF上的IP接口与SFF上的IP接口相连。SF与SFF之间可选地存在一个或多个L3设备(如路由器或三层交换机)。
在采用连接方式二的情况下,SF向SFF发送报文中最外层的报文头可选地是IP头。
连接方式三、SF与SFF之间通过显式隧道(tunnel)相连。
在采用连接方式三的情况下,在SF向SFF发送报文时,SF还向报文中IP头的外层封装隧道头。SF发送的报文的封装格式为:隧道头+IP头+IP载荷+SR头。例如,在内层报文是IPv4报文的情况下,SF发送的报文的封装格式为:隧道头+IPv4头(可选地包括IPv4选项)+IP载荷+SR头;在内层报文是IPv6报文的情况下,SF发送的报文的封装格式为:隧道头+IPv6基本头+可选地IPv6扩展头(可选地包括IPv6选项)+IP载荷+SR头。
隧道头的具体类型例如根据SF与SFF之间隧道的类型确定。隧道头包括而不限于VXLAN头、GRE头、VXLAN-GPE头、GENEVE头等。
以上述第三报文为例,可选地,第三报文还包括第二隧道头,第二隧道头封装于第三IP头外层。
SFF向IP头外层封装的报文头与SF向IP头封装的报文头可选地部分字段的内容相同而部分字段的内容不同。以上述连接方式三为例,SFF向IP头外层封装的隧道头与SF向IP头外层封装的隧道头中,源地址字段和目的地址字段具有不同的内容,而协议类型、协议版本号等隧道头的通用字段具有相同的内容。具体地,SFF向IP头外层封装的隧道头中源地址为SFF的IP地址且目的地址是SF的IP地址。SF向IP头外层封装的隧道头中源地址为SF的IP地址且目的地址是SFF的IP地址。
以上结合三种连接方式,对从SF至SFF的报文中IP头外层可能存在的报文头进行了说明。在IP头外层存在报文头的情况下,附图7所示方法中SFF在执行步骤S208时,SFF可选地先终结第三报文中IP头外层封装的报文头(如以太头或隧道头),再根据第三报文剩余的部分获得第四报文。SFF在执行步骤S209时,SFF发送的第四报文通常不包含SF在IP头外层封装的报文头(如以太头或隧道头)。
下面结合四个实例,对上述附图7所示方法举例说明。下述四个实例中的增值业务设备(value-added service,VAS)是附图7所示方法中的SF。下述四个实例中的路由器是附图7所示方法中的SFF。VAS是SF更为通俗的说法,VAS例如:FW、DPI、NAT等设备。NAT包括源地址转换(source network address translation,SNAT)和DNAT。
实例1关于SRv6 SFC代理场景下SFF接入IPv4 VAS情况下的处理流程,实例2关于SRv6 SFC代理场景下SFF接入IPv6 VAS情况下的处理流程,实例3关于SR-MPLS SFC代理场景下SFF接入IPv4 VAS情况下的处理流程,实例4关于SR-MPLS SFC代理场景下SFF接入IPv6VAS情况下的处理流程。为了描述的简洁,实例2、实例3和实例4重点说明与实例1的区别之处,实例2、实例3和实例4与实例1相同相似的部分请参考实例1。
实例1
实例1提供了一种SRv6 IPv4业务链的实现方法。实例1中VAS(即SF)支持IPv4而不支持IPv6和SRv6。实例1中的路由器接收到的报文中外层包括SRv6头且内层包括IPv4报文。实例1中的End.P4是附图7所示方法中的第一SID对应的类型。实例1中的SRv6头是附图7所示方法中的SR头。实例1中的IPv4头是附图7所示方法中的IP头。实例1中的IPv4载荷是附图7所示方法中的IP载荷。实例1中的IPv4选项是附图7所示方法中的第一选项。
请参考附图9,附图9示出了实例1的流程图。实例1包括步骤S301至步骤S307。
步骤S301、在路由器(即具有代理功能的SFF)上静态配置End.P4 SID。End.P4是本实例定义的一种新的SRv6 SFC SID类型。End.P4用于支持编辑至IPv4封装以及恢复至SRv6封装的行为。P4表示IPv4 VAS的代理(proxy for IPv4 VAS)。
End.P4 SID的配置示例如下。以下配置示例包括三个命令行,通过这三个命令行可配置出一个End.P4 SID。该End.P4 SID的长度为128比特。该End.P4 SID包括64比特的locator和64比特的操作码(operation code,opcode)(即function)。locator为A::1。opcode为::1。
[Router]segment-routing ipv6
[Router-segment-routing-ipv6]locator test ipv6-prefix A::1 64static32
[Router-segment-routing-ipv6-locator]opcode::1end.p4 out-interfaceEthernet 1/0/0.1in-interface Ethernet 1/0/0.2
下面对上述配置的具体含义进行解释。
第一个命令行也称命令segment-routing ipv6,用于指示使能SRv6,进入segment-routing ipv6视图。
第二个命令行也称命令locator,用于指示locator的名字为test,IPv6地址前缀是A::1,IPv6地址前缀的长度是64比特,在该locator中用于静态配置SID的bit长度为32。路由器根据第二个命令行的指示,会根据A::1生成64比特的网段路由(路由中目的前缀是A::/64),将网段路由通过路由协议发布出去。在其他设备学习到该网段路由之后,当接收到一个目的地址属于网段A::/64的报文时,其他设备会根据目的地址匹配到该路由器发布的路由,因此其他设备会将报文转发至该路由器。
第三个命令行也称命令opcode,命令opcode用来配置静态SID中的opcode部分,命令locator所配置的ipv6-prefix与opcode组合起来,就构成静态SID。命令opcode配置的opcode部分的范围由locator命令的static参数决定,即,最大值是由static参数指定的bit长度决定,SID类型为end.p4,SID类型end.p4所绑定的出接口(out-interface)为Ethernet 1/0/0.1,SID类型end.p4所绑定的入接口(in-interface)为Ethernet 1/0/0.2。
可选地,基于每个VRF每个SF(per-VRF per-SF)配置和编排End.P4 SID,从而支持虚拟路由转发(virtual routing forwarding,VRF)。即,一个SID对应一个VAS,且一个SID对应一个VRF。
步骤S302、路由器在接收到活跃SID为End.P4的SRv6报文时,执行如下步骤S302-1至步骤S302-5提供的处理过程。步骤S302为End.P4的上行处理流程。路由器发现活跃SID为End.P4的过程例如是,路由器使用SRv6报文中外层的IPv6基本头中的目的地址与本地SID表(local SID table)进行匹配,确定目的地址与本地SID表中一条表项匹配,该表项中SID类型为End.P4。
步骤S302-1、路由器检查SRv6报文中内层报文是否为IPv4报文。如果内层报文不是IPv4报文,路由器丢弃该SRv6报文。
步骤S302-2、路由器检查IPv4头的选项空间是否至少存在4字节的剩余空间。如果选项空间中不存在存在4字节的剩余空间,路由器丢弃该SRv6报文。
步骤S302-3、路由器检查End.P4是否为最后一个SID(最后一个SID是指SID list[0])。如果End.P4为最后一个SID,路由器丢弃该SRv6报文。
步骤S302-4、路由器执行SRH.SL--,更新IPv6 DA=SID list[SRH.SL]。SRH.SL--是指将SRH中SL字段的内容减一。更新IPv6 DA=SID list[SRH.SL]是指将IPv6基本头中目的地址更新为SID list[SRH.SL],SID list[SRH.SL]是指SRH中SL字段在SID列表(SIDlist)中指向的SID。
例如,参见附图9,路由器接收到的报文中SRv6头中的SL字段指向SID列表中的End.P4 SID,路由器对SL字段减一后,路由器发送出去的报文中SRv6头中SL字段指向SID列表中End.P4 SID的下一个SID(即SID 1)。
步骤S302-5、路由器编辑SRv6报文:SRv6头+IPv4头+IPv4载荷→IPv4头+IPv4选项+IPv4载荷+SRv6头。即,将SRv6头挪到IPv4载荷后面,然后,在IPv4头和IPv4载荷之间插入IPv4选项。IPv4选项的具体格式请见后文。
通过执行步骤S302-5,路由器改变了报文的封装格式,将报文从SRv6的封装格式转换为IPv4的封装格式。
步骤S303、路由器根据End.P4的配置参数,路由器将编辑后的IPv4报文,经过End.P4绑定的出接口发送给VAS。
步骤S304、VAS在接收到路由器发送的上述IPv4报文时,路由器根据IPv4选项,识别出本实施例提供的特定报文格式(SRv6头在IPv4载荷之后)。然后,VAS根据IPv4选项中的载荷长度字段,确定IPv4载荷的边界。因而VAS可以忽略掉SRv6头部分,处理其余部分。
步骤S305、VAS在完成业务处理后,VAS将处理后的报文的格式保持为IPv4报文的格式,VAS将处理后的报文返回给路由器。
步骤S306、路由器从指定的入接口接收到VAS返回的IPv4报文时,如果检测到该IPv4报文存在IPv4选项,且该IPv4选项为本实施例所定义的选项,则路由器执行如下步骤S306-1至步骤S306-3提供的处理流程。步骤S306为End.P4的下行处理流程。
步骤S306-1路由器解析IPv4选项,根据IPv4选项中的载荷长度定界出SRv6头,执行SRv6头合法性校验。如果不合法,丢弃该报文;否则,路由器执行下列步骤S306-2。
同时,IPv6 DA==SIDList[SRH.SL],即IPv6基本头中目的地址为SRH中SL字段在SID表中指向的SID。
步骤S306-2路由器从输入的IPv4报文中剥掉IPv4选项,将输入的IPv4报文中封装格式恢复成SRv6报文的格式:IPv4头+IPv4选项+IPv4载荷+SRv6头→SRv6头+IPv4头+IPv4载荷。
其中,SRv6头包括IPv6头和SRH这2个报文头。IPv6头至少包括一个40B的IPv6基本头,可选地还包括一个或多个IPv6扩展头(这句话中的IPv6扩展头不含SRH这种IPv6路由扩展头)。
步骤S307、路由器根据恢复后的SRv6报文中SRH中的活跃SID继续转发。例如,参见附图9,恢复后的SRv6报文中SRH中的活跃SID为End.P4 SID的下一个SID(即SID 1)。路由器根据SID1继续转发恢复后的SRv6报文。
可选地,如果路由器和VAS采用连接方式三,即路由器和VAS之间存在隧道,路由器与VAS之间交互的报文中还包括封装在IPv4头外层的隧道头。具体地,路由器在执行上述步骤S302的过程中,路由器还会生成隧道头,向IPv4头外层添加隧道头,从而获得包含隧道头的IPv4报文。请参考附图9,路由器在执行上述步骤S303的过程中,路由器向VAS发送的IPv4报文中还包括IPv4头之前的隧道头。VAS在执行上述步骤S304的过程中,VAS会先从接收到的IPv4报文中剥离隧道头(即终结隧道头),再根据剥离隧道头后的IPv4报文进行业务处理。VAS得到业务处理后的IPv4报文之后,VAS会向业务处理后的IPv4报文重新封装隧道头。请参考附图9,VAS在执行上述步骤S305的过程中,VAS向路由器发送的IPv4报文中还包括封装在IPv4头外层的隧道头。路由器在执行上述步骤S306的过程中,路由器会先从VAS返回的IPv4报文中剥离隧道头,再执行恢复SRv6封装和转发报文的步骤。
上述隧道头的主要作用在于在路由器和VAS之间进行报文的传输。隧道头包括而不限于VXLAN头、GRE头、VXLAN-GPE头、GENEVE头等等。路由器向VAS发送的报文中,隧道头的源IP地址为路由器的IP地址且目的IP地址为VAS的IP地址。VAS向路由器返回的报文中,隧道头的源IP地址为VAS的IP地址且目的IP地址为路由器的IP地址。
如果路由器和VAS采用连接方式一,即路由器和VAS之间通过L2接口相连,路由器与VAS之间交互的报文中还包括封装在IPv4头外层的以太头,以太头和封装和终结流程与上述隧道头的封装和终结流程同理,在此不做赘述。
附图8是本实施例提供的一种IPv4选项的格式示意图。附图8所示的IPv4选项是对附图7所示方法涉及的第一选项的举例说明。具体地,附图7所示方法中步骤S203中,SFF发送的第二报文的IP头中可选地包括附图8所示的IPv4选项。附图7所示方法中步骤S206中,SF发送的第三报文的IP头中可选地包括附图8所示的IPv4选项。
附图8所示的IPv4选项包含选项类型(type)字段、选项长度(length)字段和载荷长度(payload length)字段。
选项类型字段是对附图7所示方法中标识信息所在字段的举例说明。选项类型字段的长度为1字节。选项类型字段的值为标准或私有定义。在标准化之前,选项类型字段的值可选地采用IPv4选项类型的实验值之一,以避免冲突。IPv4选项类型的实验值包括30、94、158和222。
选项长度字段的长度为1字节。选项长度字段的取值为4。
载荷长度字段是对附图7所示方法中长度信息所在字段的举例说明。例如,附图7所示方法中步骤S203中,SFF发送的第二报文的IP头中可选地包括附图8所示的载荷长度字段,且载荷长度字段的值表示第二报文中第一IP载荷的长度。附图7所示方法中步骤S206中,SF发送的第三报文的IP头中可选地包括附图8所示的载荷长度字段,且载荷长度字段的值表示第三报文中第二IP载荷的长度。载荷长度字段的长度为2字节。
在实例1中,载荷长度字段的值为路由器输入的SRv6报文中IPv4载荷部分的字节长度。
该新增的IPv4选项存在于路由器与VAS之间,而不会被传递到路由器的下游节点,且在大多数情况(VAS不改变IPv4载荷长度的情况)下,VAS无需解析该选项。因此,在部署时,选项类型可以使用IPv4选项类型的实验值,而不是必须标准化。
下面对本实施例对IPv4 VAS的需求进行分析。
IPv4 VAS需要能支持接收本实施例所定义的IPv4报文,保留新增的IPv4 option和SRv6 header的内容不变,可选地修改IPv4 payload内容。可选地,IPv4报文还包括本实施例定义的IPv4选项之外的其他IPv4选项。下表2分析了各类VAS的支持情况。
表2
Figure BDA0003113647610000281
通过上表可见,即使IPv4 VAS要解析IPv4载荷的内容,上层头也会将操作范围限制在IPv4载荷边界之内,因而无需感知新增IPv4选项。因此,大多数IPv4 VAS无需进行任何修改即可支持本实施例。
路由器在编辑和生成IPv4报文(步骤S302)时,会更新IPv4头的内容,具体参见下述步骤S302-a至步骤S302-c。步骤S302-a至步骤S302-c可选地顺序执行,或者同时执行,本实施例对步骤S302-a至步骤S302-c的时序不做限定。
步骤S302-a.路由器更新IPv4头中IP头长度(IHL)。更新后的IHL包含新增的IPv4选项的长度。例如,更新后的IHL可选地为接收到的IPv4头与新增IPv4选项的长度之和。例如,路由器接收到的SRv6报文中IPv4头的长度为N,路由器添加了长度为M的IPv4选项,则路由器将IHL字段的内容从N更新为(N+M)。
步骤S302-b.路由器更新IPv4头中总长度(total length)。更新后的IPv4头中总长度包括SRv6头的长度和新增的IPv4选项的长度。例如,更新后的IHL可选地为接收到的IPv4头、新增IPv4选项、IPv4载荷、SRv6头的长度之和。例如,路由器接收到的SRv6报文中IPv4头的长度为N、IPv4载荷的长度为P、SRv6头的长度为Q,路由器添加了M的IPv4选项,则路由器将IHL字段的内容从(N+P)更新为(N+P+M+Q)。
步骤S302-c.路由器更新IPv4头中头校验(header checksum)。具体来说,路由器在完成IPv4报文编辑时,根据编辑后的IPv4报文重新计算头校验,将IPv4头中的头校验更新为重新计算的头校验。
可选地,路由器在将IPv4报文转发给VAS的过程中,还将IPv4头中的生存时间(TTL)减一,或者路由器保持IPv4头中的TTL不变。路由器是否更新TTL可选地根据转发策略确定。
路由器接收到的IPv4头中可能包含IPv4选项。如果接收到的IPv4头中已经包含IPv4选项,则接收到的IPv4头中IPv4选项部分必须剩余至少4字节的空间,从而保证添加本实施例新增的IPv4选项之后,IPv4选项部分的总长度不超过标准规定的40字节。
VAS在将IPv4报文返回给路由器(S304和S305)时,VAS执行正常的IPv4转发流程,VAS会将IPv4头中TTL减去1。可选地,VAS修改IPv4载荷的内容,或者VAS保持IPv4载荷的内容不变。VAS是否修改IPv4载荷的内容可选地根据VAS的业务功能确定。在一些实施例中,禁止VAS解析和修改SRv6头部分的内容。
路由器在执行S306的过程中,当路由器接收到VAS返回的IPv4报文并恢复SRv6报文格式后,路由器更新IPv4头的内容,具体参见下述步骤S306-a至步骤S306-d。S306-a至步骤S306-d可选地顺序执行,或者同时执行,本实施例对步骤S306-a至步骤S306-d的时序不做限定。
步骤S306-a.路由器从VAS返回的IPv4报文中,去掉路由器之前在执行步骤S302时插入的IPv4选项。
步骤S306-b.路由器更新IPv4头中IHL。更新后的IHL不包含之前插入的IPv4选项的长度。例如,路由器从VAS接收到的IPv4头中IHL字段表示的长度为(N+M),该IPv4头包括路由器之前添加的长度为M的IPv4选项。路由器去掉长度为M的IPv4选项之后,路由器将IHL字段表示的长度从(N+M)更新为N。
步骤S306-c.路由器更新IPv4头中总长度(total length)。更新后的IPv4头中总长度不包括SRv6头的长度,且不包含之前插入的IPv4选项的长度。
例如,路由器从VAS接收到的IPv4头中总长度字段表示的长度为(N+P+M+Q),路由器去掉长度为M的IPv4选项,并将长度为Q的SRv6头移动至IPv4头的前面之后,路由器将总长度字段表示的长度为(N+P+M+Q)更新为(N+P)。
步骤S306-d.路由器更新IPv4头中头校验(header checksum)。
实例2
实例2提供了一种SRv6 IPv6业务链的实现方法。实例2中VAS支持IPv6而不支持SRv6。实例2中的路由器接收到的报文中外层包括SRv6头且内层包括IPv6报文。
请参考附图10,附图10示出了实例2的流程图。实例2的具体流程相当于将实例1中IPv4头替换为IPv6头、将IPv4载荷替换为IPv6载荷且将IPv4选项替换为IPv6选项。
实例3
实例3提供了一种SR-MPLS IPv4业务链的实现方法。实例3中VAS支持IPv4而不支持SR-MPLS。实例3中的路由器接收到的报文中外层包括SR-MPLS头且内层包括IPv4报文。
请参考附图11,附图11示出了实例3的流程图。实例3的具体流程相当于将实例1中SRv6头替换为SR-MPLS头、将实例1中SRH中的SID列表替换为标签栈、将充当活跃SID的信息从IPv6基本头中的目的地址替换为标签栈的栈顶标签。
此外,实例3与实例1中实现细节可能存在一些差异。例如,实例1中SFF在步骤S302会使用SRH中段列表中的SID更新IPv6基本头中的目的地址,而实例3中SFF在步骤S302会弹出标签栈的栈顶标签。实例1中路由器对于SRv6 SRH是从下到上进行逆序操作,而实例3中对MPLS标签栈从上到下顺序操作。实例3中新定义的SID类型可能换个名字,比如不叫End.P4而是叫Node.P4等。
实例4
实例4提供了一种SR-MPLS IPv6业务链的实现方法。实例4中VAS支持IPv6而不支持SR-MPLS。实例4中的路由器接收到的报文中外层包括SR-MPLS头且内层包括IPv6报文。请参考附图12,附图12示出了实例4的流程图。实例4的具体流程相当于将实例1中SRv6头替换为SR-MPLS头、将实例1中SRH替换为标签栈、将充当活跃SID的信息从IPv6基本头中的目的地址替换为标签栈的栈顶标签、将实例1中IPv4头替换为IPv6头、将实例1中IPv4载荷替换为IPv6载荷、将实例1中IPv4选项替换为IPv6选项。
总结上述各个实施例可以看出,本申请的一些实施例具有以下技术效果。
第一,与SR业务链静态代理(例如,End.AS)相比,配置更为简化,且支持SR动态业务。
第二,与SR业务链动态代理(例如,End.AD)相比,在支持SR动态业务的同时,在SFF上无需生成和维护缓存,极大地降低了实现复杂度,减少了设备的资源开销,具有更高的转发性能,能支持更大的业务规格。
第三,易于部署。在大多数情况下,VAS不需要感知IPv4载荷边界。因此,VAS设备无需感知本发明所定义的指定IPv4报文格式,只需要修改路由器(proxy)设备即可。因而能无缝接入现网第三方IPv4 VAS。
第四,本实施例同时适用于SR-MPLS SFC和SRv6 SFC。
第五,本实施例同时支持SFF接入IPv4 VAS的情况以及SFF接入IPv6VAS的情况。
附图13是本申请实施例提供的一种报文处理装置的结构示意图。附图13所示的报文处理装置设于SFF(SR代理),报文处理装置400包括接收单元401、获得单元402和发送单元403。可选地,报文处理装置400还包括保存单元404。
可选地,结合附图6所示的应用场景来看,附图13所示的报文处理装置400设置于附图6中的SFF 111或SFF 121。
可选地,结合附图7所示方法流程来看,附图13所示的报文处理装置400设置于附图7中的SFF。接收单元401用于支持报文处理装置400执行步骤S201。获得单元402用于支持报文处理装置400执行步骤S202。发送单元403用于支持报文处理装置400执行步骤S203。可选地,接收单元401还用于支持报文处理装置400执行步骤S207。获得单元402用于支持报文处理装置400执行步骤S208。发送单元403用于支持报文处理装置400执行步骤S209。保存单元404用于支持报文处理装置400保存第一SID和SID类型之间的对应关系。
可选地,结合附图9、附图10、附图11或者附图12来看,附图13所示的报文处理装置400设置于附图9、附图10、附图11或者附图12所示方法流程中的路由器。获得单元402用于支持报文处理装置400执行步骤S302。发送单元403用于支持报文处理装置400执行步骤S303。可选地,获得单元402用于支持报文处理装置400执行步骤S306。发送单元403用于支持报文处理装置400执行步骤S307。保存单元404用于支持报文处理装置400保存步骤S301产生的配置。
附图13所描述的装置实施例仅仅是示意性的,例如,上述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
报文处理装置400中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。
在采用软件实现的情况下,例如,上述获得单元402是由附图15中的至少一个处理器601读取存储器602中存储的程序代码后,生成的软件功能单元来实现。
在采用硬件实现的情况下,附图13中各个单元可选地由计算机一类的设备中不同硬件分别实现,下面分别结合附图15和附图16所示的硬件结构举例说明。
例如,结合附图15来看,接收单元401和发送单元403由附图15中的网络接口603实现。获得单元402由附图15中的至少一个处理器601中的一部分处理资源(例如多核处理器中的一个核或两个核)实现,或者采用现场可编程门阵列(field-programmable gatearray,FPGA)、或协处理器等可编程器件来完成。保存单元404由附图15中的存储器602实现。
又如,结合附图16来看,接收单元401和发送单元403由附图16中的接口板730上物理接口卡733实现。获得单元402由附图16中的接口板730上网络处理器732实现。保存单元404由附图16中的接口板730上的转发表项存储器734实现。
附图14是本申请实施例提供的一种报文处理装置的结构示意图。附图14所示的报文处理装置500设于SF。报文处理装置500包括接收单元501和处理单元502。可选地,报文处理装置500还包括发送单元503。
可选地,结合附图6所示的应用场景来看,附图14所示的报文处理装置500设置于附图6中的SF 112或SF 122。
可选地,结合附图7所示方法流程来看,附图14所示的报文处理装置500设置于附图7所示方法流程中的SF。接收单元501用于支持报文处理装置500执行步骤S204。处理单元502用于支持报文处理装置500执行步骤S205。发送单元503用于支持报文处理装置500执行步骤S206。
可选地,结合附图9、附图10、附图11或者附图12来看,附图14所示的报文处理装置500设置于附图9、附图10、附图11或者附图12所示方法流程中的VAS。处理单元502用于支持报文处理装置500执行步骤S304。发送单元503用于支持报文处理装置500执行步骤S305。
附图14所描述的装置实施例仅仅是示意性的,例如,上述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
报文处理装置500中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。
在采用软件实现的情况下,例如,上述处理单元502是由附图15中的至少一个处理器601读取存储器602中存储的程序代码后,生成的软件功能单元来实现。
在采用硬件实现的情况下,附图14中各个单元可选地由设备中的不同硬件分别实现,例如,结合附图15来看,接收单元501和发送单元503由附图15中的网络接口603实现。处理单元502由附图15中的至少一个处理器601中的一部分处理资源(例如多核处理器中的一个核或两个核)实现,或者采用现场可编程门阵列(field-programmable gate array,FPGA)、或协处理器等可编程器件来完成。又如,结合附图16来看,接收单元501和发送单元503由附图16中的接口板730上物理接口卡733实现。处理单元502由附图16中的接口板730上网络处理器732实现。
下面对SFF和SF的基本硬件结构举例说明。
附图15是本申请实施例提供的一种设备600的结构示意图。设备600例如为网络设备(如路由器、交换机、防火墙)、计算机设备(如服务器、主机、个人计算机、笔记本电脑或者其他终端设备)等。
可选地,附图15所示的设备600上设置有SFF(SR代理)。例如,结合附图6所示的应用场景来看,附图15所示的设备600可选地设置有附图6中的SFF 111或SFF 121。例如,结合附图7所示方法流程来看,附图15所示的设备600设置有附图7中的SFF,附图15所示的设备600用于执行附图7中SFF执行的步骤。例如,结合附图9、附图10、附图11或者附图12来看,附图15所示的设备600为附图9、附图10、附图11或者附图12中的路由器。例如,结合附图13来看,附图15所示的设备600为附图13所示的报文处理装置400。
可选地,附图15所示的设备600上设置有SF。例如,结合附图6所示的应用场景来看,附图15所示的设备600上可选地设置有附图6中的SF 112或SF 122。例如,结合附图7所示方法流程来看,附图15所示的设备600设置有附图7中的SF,附图15所示的设备600用于执行附图7中SF执行的步骤。例如,结合附图9、附图10、附图11或者附图12来看,附图15所示的设备600设置有附图9、附图10、附图11或者附图12中的VAS。例如,结合附图13来看,附图15所示的设备600设置有附图14所示的报文处理装置500。
设备600包括至少一个处理器601、存储器602以及至少一个网络接口603。
处理器601例如是通用中央处理器(central processing unit,CPU)、网络处理器(network processer,NP)、图形处理器(graphics processing unit,GPU)、神经网络处理器(neural-network processing units,NPU)、数据处理单元(data processing unit,DPU)、微处理器或者一个或多个用于实现本申请方案的集成电路。例如,处理器601包括专用集成电路(application-specific integrated circuit,ASIC),可编程逻辑器件(programmable logic device,PLD)或其组合。PLD例如是复杂可编程逻辑器件(complexprogrammable logic device,CPLD)、现场可编程逻辑门阵列(field-programmable gatearray,FPGA)、通用阵列逻辑(generic array logic,GAL)或其任意组合。
存储器602例如是只读存储器(read-only memory,ROM)或可存储静态信息和指令的其它类型的静态存储设备,又如是随机存取存储器(random access memory,RAM)或者可存储信息和指令的其它类型的动态存储设备,又如是电可擦可编程只读存储器(electrically erasable programmable read-only Memory,EEPROM)、只读光盘(compactdisc read-only memory,CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备,或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质,但不限于此。可选地,存储器602独立存在,并通过内部连接604与处理器601相连接。或者,可选地存储器602和处理器601集成在一起。
网络接口603使用任何收发器一类的装置,用于与其它设备或通信网络通信。网络接口603例如包括有线网络接口或者无线网络接口中的至少一项。其中,有线网络接口例如为以太网接口。以太网接口例如是光接口,电接口或其组合。无线网络接口例如为无线局域网(wireless local area networks,WLAN)接口,蜂窝网络网络接口或其组合等。
在一些实施例中,处理器601包括一个或多个CPU,如附图15中所示的CPU0和CPU1。
在一些实施例中,设备600可选地包括多个处理器,如附图15中所示的处理器601和处理器605。这些处理器中的每一个例如是一个单核处理器(single-CPU),又如是一个多核处理器(multi-CPU)。这里的处理器可选地指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。
在一些实施例中,设备600还包括内部连接604。处理器601、存储器602以及至少一个网络接口603通过内部连接604连接。内部连接604包括通路,在上述组件之间传送信息。可选地,内部连接604是单板或总线。可选地,内部连接604分为地址总线、数据总线、控制总线等。
在一些实施例中,设备600还包括输入输出接口606。输入输出接口606连接到内部连接604上。
可选地,处理器601通过读取存储器602中保存的程序代码610实现上述实施例中的方法,或者,处理器601通过内部存储的程序代码实现上述实施例中的方法。在处理器601通过读取存储器602中保存的程序代码610实现上述实施例中的方法的情况下,存储器602中保存实现本申请实施例提供的程序代码。处理器601实现上述功能的更多细节请参考前面各个方法实施例中的描述,在这里不再重复。
参见附图16,附图16是本申请实施例提供的一种设备700的结构示意图。设备700例如为网络设备(如路由器、交换机、防火墙等)。
可选地,附图16所示的设备700上设置有SFF(SR代理)。例如,结合附图6所示的应用场景来看,附图16所示的设备700可选地设置有附图6中的SFF 111或SFF 121。例如,结合附图7所示方法流程来看,附图16所示的设备700设置有附图7中的SFF,附图16所示的设备700用于执行附图7中SFF执行的步骤。例如,结合附图9、附图10、附图11或者附图12来看,附图16所示的设备700为附图9、附图10、附图11或者附图12中的路由器。例如,结合附图13来看,附图16所示的设备700上设置有附图13所示的报文处理装置400。
可选地,附图16所示的设备700上设置有SF。例如,结合附图6所示的应用场景来看,附图16所示的设备700可选地设置有附图6中的SF 112或SF 122。例如,结合附图7所示方法流程来看,附图16所示的设备700设置有附图7中的SF,附图16所示的设备700用于执行附图7中SF执行的步骤。例如,结合附图9、附图10、附图11或者附图12来看,附图16所示的设备700上设置有附图9、附图10、附图11或者附图12中的VAS。例如,结合附图13来看,附图16所示的设备700上设置有附图14所示的报文处理装置500。
设备700包括:主控板710和接口板730。
主控板也称为主处理单元(main processing unit,MPU)或路由处理卡(routeprocessor card),主控板710用于对设备700中各个组件的控制和管理,包括路由计算、设备管理、设备维护、协议处理功能。主控板710包括:中央处理器711和存储器712。
接口板730也称为线路接口单元卡(line processing unit,LPU)、线卡(linecard)或业务板。接口板730用于提供各种业务接口并实现数据包的转发。业务接口包括而不限于以太网接口、POS(packet over sONET/SDH)接口等,以太网接口例如是灵活以太网业务接口(flexible ethernet clients,FlexE clients)。接口板730包括:中央处理器731、网络处理器732、转发表项存储器734和物理接口卡(physical interface card,PIC)733。
接口板730上的中央处理器731用于对接口板730进行控制管理并与主控板710上的中央处理器711进行通信。
网络处理器732用于实现报文的转发处理。网络处理器732的形态例如是转发芯片。具体而言,网络处理器732用于基于转发表项存储器734保存的转发表转发接收到的报文,如果报文的目的地址为设备700的地址,则将该报文上送至CPU(如中央处理器711)处理;如果报文的目的地址不是设备700的地址,则根据该目的地址从转发表中查找到该目的地址对应的下一跳和出接口,将该报文转发到该目的地址对应的出接口。其中,上行报文的处理包括:报文入接口的处理,转发表查找;下行报文的处理:转发表查找等等。
物理接口卡733用于实现物理层的对接功能,原始的流量由此进入接口板730,以及处理后的报文从该物理接口卡733发出。物理接口卡733也称为子卡,可安装在接口板730上,负责将光电信号转换为报文并对报文进行合法性检查后转发给网络处理器732处理。在一些实施例中,中央处理器也可执行网络处理器732的功能,比如基于通用CPU实现软件转发,从而物理接口卡733中不需要网络处理器732。
可选地,设备700包括多个接口板,例如设备700还包括接口板740,接口板740包括:中央处理器741、网络处理器742、转发表项存储器744和物理接口卡743。
可选地,设备700还包括交换网板720。交换网板720也例如称为交换网板单元(switch fabric unit,SFU)。在网络设备有多个接口板730的情况下,交换网板720用于完成各接口板之间的数据交换。例如,接口板730和接口板740之间例如通过交换网板720通信。
主控板710和接口板730耦合。例如。主控板710、接口板730和接口板740,以及交换网板720之间通过系统总线与系统背板相连实现互通。在一种可能的实现方式中,主控板710和接口板730之间建立进程间通信协议(inter-process communication,IPC)通道,主控板710和接口板730之间通过IPC通道进行通信。
在逻辑上,设备700包括控制面和转发面,控制面包括主控板710和中央处理器731,转发面包括执行转发的各个组件,比如转发表项存储器734、物理接口卡733和网络处理器732。控制面执行路由器、生成转发表、处理信令和协议报文、配置与维护设备的状态等功能,控制面将生成的转发表下发给转发面,在转发面,网络处理器732基于控制面下发的转发表对物理接口卡733收到的报文查表转发。控制面下发的转发表例如保存在转发表项存储器734中。在有些实施例中,控制面和转发面例如完全分离,不在同一设备上。
接口板740上的操作与接口板730的操作一致,为了简洁,不再赘述。本实施例的设备700可对应于上述各个方法实施例中的SFF或SF,该设备700中的主控板710、接口板730和/或740例如实现上述各个方法实施例中SFF或SF所具有的功能和/或所实施的各种步骤,为了简洁,在此不再赘述。
值得说明的是,主控板可能有一块或多块,有多块的时候例如包括主用主控板和备用主控板。接口板可能有一块或多块,网络设备的数据处理能力越强,提供的接口板越多。接口板上的物理接口卡也可以有一块或多块。交换网板可能没有,也可能有一块或多块,有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下,网络设备可以不需要交换网板,接口板承担整个系统的业务数据的处理功能。在分布式转发架构下,网络设备可以有至少一块交换网板,通过交换网板实现多块接口板之间的数据交换,提供大容量的数据交换和处理能力。所以,分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。可选地,网络设备的形态也可以是只有一块板卡,即没有交换网板,接口板和主控板的功能集成在该一块板卡上,此时接口板上的中央处理器和主控板上的中央处理器在该一块板卡上可以合并为一个中央处理器,执行两者叠加后的功能,这种形态设备的数据交换和处理能力较低(例如,低端交换机或路由器等网络设备)。具体采用哪种架构,取决于具体的组网部署场景,此处不做任何限定。
本申请实施例中提及的一个或多个SF可以设置于一台或多台设备上,比如网络设备或者计算机设备上。设置有SF的设备可简称为SF设备。本申请实施例中的SF可以是设置有SF的设备或SF设备的简称。本申请实施例对此不进行限定。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分可互相参考,每个实施例重点说明的都是与其他实施例的不同之处。A参考B,指的是A与B相同或者A为B的简单变形。本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象,而不是用于描述对象的特定顺序,也不能理解为指示或暗示相对重要性。例如,第一报文和第二报文用于区别不同的报文,而不是用于描述报文的特定顺序,也不能理解为第一报文比第二报文更重要。本申请实施例,除非另有说明,“至少一个”的含义是指一个或多个,“多个”的含义是指两个或两个以上。
上述实施例可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请实施例描述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (30)

1.一种报文处理方法,其特征在于,所述方法包括:
业务功能转发设备SFF接收第一报文,所述第一报文包括第一段路由头、第一互联网协议IP头和第一IP载荷,所述第一段路由头封装于所述第一IP头和所述第一IP载荷外层;
所述SFF基于所述第一报文获得第二报文,所述第二报文包括第二IP头、所述第一IP载荷和所述第一段路由头,所述第二IP头封装于所述第一IP载荷和所述第一段路由头外层;
所述SFF向业务功能SF设备发送所述第二报文。
2.根据权利要求1所述的方法,其特征在于,所述第一段路由头包括第一段标识SID,所述SFF保存第一对应关系,所述第一对应关系包括所述第一SID和SID类型,所述SID类型用于表示不支持段路由头,所述SFF基于所述第一报文获得第二报文包括:
所述SFF根据所述第一SID和所述第一对应关系,获得所述SID类型;
所述SFF根据所述SID类型对所述第一报文进行第一处理,获得所述第二报文,所述第一处理包括将所述第一段路由头设于所述第一IP载荷后且所述第一IP头被替换为所述第二IP头。
3.根据权利要求1或2所述的方法,其特征在于,所述第一段路由头为基于互联网协议第6版的段路由SRv6头,所述第一IP头和所述第二IP头均为互联网协议第4版IPv4头,所述第一IP载荷为IPv4载荷;或者,
所述第一段路由头为SRv6头,所述第一IP头和所述第二IP头均为互联网协议第6版IPv6头,所述第一IP载荷为IPv6载荷。
4.根据权利要求1或2所述的方法,其特征在于,所述第一段路由头为段路由-多协议标签交换SR-MPLS头,所述第一IP头和所述第二IP头均为IPv4头,所述第一IP载荷为IPv4载荷;或者,
所述第一段路由头为SR-MPLS头,所述第一IP头和所述第二IP头均为IPv6头,所述第一IP载荷为IPv6载荷。
5.根据权利要求1至4中任一项所述的方法,其特征在于,所述SFF向SF设备发送所述第二报文之后,所述方法还包括:
所述SFF接收来自于所述SF设备的第三报文,所述第三报文包括第三IP头、第二IP载荷和所述第一段路由头,所述第三IP头封装于所述第二IP载荷和所述第一段路由头外层;
所述SFF基于所述第三报文获得第四报文,所述第四报文包括所述第一段路由头、第四IP头和第三IP载荷,所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;
所述SFF基于所述第一段路由头发送所述第四报文。
6.根据权利要求5所述的方法,其特征在于,所述SFF基于所述第三报文获得第四报文包括:
所述SFF基于所述第三IP头对所述第三报文进行第二处理,获得所述第四报文,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;或者,
所述SFF基于接收所述第三报文的接口对所述第三报文进行第二处理,获得所述第四报文,所述接收所述第三报文的接口为所述第一SID绑定的入接口,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;或者,
所述SFF基于接收所述第三报文的接口和所述第三IP头对所述第三报文进行第二处理,获得所述第四报文,所述接收所述第三报文的接口为所述第一SID绑定的入接口,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层。
7.根据权利要求5或6所述的方法,其特征在于,所述第三IP头还包括第一长度信息,所述第一长度信息用于确定所述第三报文中所述第一段路由头的位置。
8.根据权利要求1至7中任一项所述的方法,其特征在于,所述第二IP头包括标识信息,所述标识信息用于标识所述第一段路由头设于所述第一IP载荷后。
9.根据权利要求8所述的方法,其特征在于,所述第二IP头还包括第二长度信息,所述第二长度信息用于指示所述第一IP载荷的长度,或者所述第二长度信息用于指示所述第一IP载荷和所述第二IP头的长度之和。
10.根据权利要求8或9所述的方法,其特征在于,所述第二IP头包括第一选项,所述第一选项的类型字段携带所述标识信息。
11.根据权利要求10所述的方法,其特征在于,所述第二IP头为包括逐跳选项头的IPv6头,所述第一选项为逐跳选项头中的选项,或者,
所述第二IP头为包括目的选项头的IPv6头,所述第一选项为目的选项头中的选项。
12.一种报文处理方法,其特征在于,所述方法包括:
业务功能SF设备接收来自于业务功能转发设备SFF的第一报文,所述第一报文包括第一互联网协议IP头、第一IP载荷和第一段路由头,所述第一IP头封装于所述第一IP载荷和所述第一段路由头外层;
所述SF设备基于所述第一报文进行业务处理。
13.根据权利要求12所述的方法,其特征在于,所述SF设备基于所述第一报文进行业务处理之后,所述方法还包括:
所述SF设备向所述SFF发送经所述业务处理后获得的第二报文,所述第二报文包括第二IP头、第二IP载荷和所述第一段路由头,所述第二IP头封装于所述第二IP载荷和所述第一段路由头外层。
14.根据权利要求13所述的方法,其特征在于,所述第二IP头还包括第一长度信息,所述第一长度信息用于确定所述第二报文中所述第一段路由头的位置。
15.根据权利要求12至14任一项所述的方法,其特征在于,所述第一IP头包括标识信息,所述标识信息用于标识所述第一段路由头设于所述第一IP载荷后。
16.根据权利要求15所述的方法,其特征在于,所述第一IP头还包括第二长度信息,所述第二长度信息用于指示所述第一IP载荷的长度,或者所述第二长度信息用于指示所述第一IP载荷和所述第一IP头的长度之和。
17.根据权利要求15或16所述的方法,其特征在于,所述第一IP头包括第一选项,所述第一选项的类型字段携带所述标识信息。
18.根据权利要求17所述的方法,其特征在于,所述第一IP头为包括逐跳选项头的互联网协议第6版IPv6头,所述第一选项为逐跳选项头中的选项,或者,
所述第一IP头为包括目的选项头的IPv6头,所述第一选项为目的选项头中的选项。
19.一种报文处理装置,其特征在于,所述装置设于业务功能转发设备SFF,包括:
接收单元,用于接收第一报文,所述第一报文包括第一段路由头、第一互联网协议IP头和第一IP载荷,所述第一段路由头封装于所述第一IP头和所述第一IP载荷外层;
获得单元,用于基于所述第一报文获得第二报文,所述第二报文包括第二IP头、所述第一IP载荷和所述第一段路由头,所述第二IP头封装于所述第一IP载荷和所述第一段路由头外层;
发送单元,用于向SF设备发送所述第二报文。
20.根据权利要求19所述的装置,其特征在于,所述第一段路由头包括第一段标识SID,所述SFF还包括保存单元,所述保存单元用于保存第一对应关系,所述第一对应关系包括所述第一SID和SID类型,所述SID类型用于表示不支持段路由头,所述获得单元,用于根据所述第一SID和所述第一对应关系,获得所述SID类型;根据所述SID类型对所述第一报文进行第一处理,获得所述第二报文,所述第一处理包括将所述第一段路由头设于所述第一IP载荷后且所述第一IP头被替换为所述第二IP头。
21.根据权利要求19或20所述的装置,其特征在于,所述接收单元,还用于接收来自于所述SF设备的第三报文,所述第三报文包括第三IP头、第二IP载荷和所述第一段路由头,所述第三IP头封装于所述第二IP载荷和所述第一段路由头外层;
所述获得单元,还用于基于所述第三报文获得第四报文,所述第四报文包括所述第一段路由头、第四IP头和第三IP载荷,所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;
所述发送单元,还用于基于所述第一段路由头发送所述第四报文。
22.根据权利要求21所述的装置,其特征在于,所述获得单元,用于基于所述第三IP头对所述第三报文进行第二处理,获得所述第四报文,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;或者,基于接收所述第三报文的接口对所述第三报文进行第二处理,获得所述第四报文,所述接收所述第三报文的接口为所述第一SID绑定的入接口,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层;或者,基于接收所述第三报文的接口和所述第三IP头对所述第三报文进行第二处理,获得所述第四报文,所述接收所述第三报文的接口为所述第一SID绑定的入接口,所述第二处理包括用所述第四IP头替换所述第三IP头且所述第一段路由头封装于所述第四IP头和所述第三IP载荷外层。
23.一种报文处理装置,其特征在于,所述装置设于业务功能SF设备,包括:
接收单元,用于接收来自于业务功能转发设备SFF的第一报文,所述第一报文包括第一互联网协议IP头、第一IP载荷和第一段路由头,所述第一IP头封装于所述第一IP载荷和所述第一段路由头外层;
处理单元,用于基于所述第一报文进行业务处理。
24.根据权利要求23所述的装置,其特征在于,所述装置还包括:
发送单元,用于向所述SFF发送经所述业务处理后获得的第二报文,所述第二报文包括第二IP头、第二IP载荷和所述第一段路由头,所述第二IP头封装于所述第二IP载荷和所述第一段路由头外层。
25.根据权利要求24所述的装置,其特征在于,所述第二IP头还包括第一长度信息,所述第一长度信息用于确定所述第二报文中所述第一段路由头的位置。
26.根据权利要求23至25任一项所述的装置,其特征在于,所述第一IP头包括标识信息,所述标识信息用于标识所述第一段路由头设于所述第一IP载荷后。
27.根据权利要求26所述的装置,其特征在于,所述第一IP头还包括第二长度信息,所述第二长度信息用于指示所述第一IP载荷的长度,或者所述第二长度信息用于指示所述第一IP载荷和所述第一IP头的长度之和。
28.根据权利要求26或27所述的装置,其特征在于,所述第一IP头包括第一选项,所述第一选项的类型字段携带所述标识信息。
29.根据权利要求28所述的装置,其特征在于,所述第一IP头为包括逐跳选项头的互联网协议第6版IPv6头,所述第一选项为逐跳选项头中的选项,或者,
所述第一IP头为包括目的选项头的IPv6头,所述第一选项为目的选项头中的选项。
30.一种系统,其特征在于,所述系统包括如权利要求19至22中任一项所述的装置以及如权利要求23至29中任一项所述的装置。
CN202110655978.1A 2021-05-31 2021-06-11 报文处理方法、装置及系统 Pending CN115426305A (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2021/139368 WO2022252569A1 (zh) 2021-05-31 2021-12-17 报文处理方法、装置及系统
EP21943921.3A EP4333390A1 (en) 2021-05-31 2021-12-17 Packet processing method, apparatus and system
US18/523,432 US20240106748A1 (en) 2021-05-31 2023-11-29 Packet processing method, apparatus, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110604888 2021-05-31
CN202110604888X 2021-05-31

Publications (1)

Publication Number Publication Date
CN115426305A true CN115426305A (zh) 2022-12-02

Family

ID=84195466

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110655978.1A Pending CN115426305A (zh) 2021-05-31 2021-06-11 报文处理方法、装置及系统

Country Status (4)

Country Link
US (1) US20240106748A1 (zh)
EP (1) EP4333390A1 (zh)
CN (1) CN115426305A (zh)
WO (1) WO2022252569A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109962847A (zh) * 2017-12-14 2019-07-02 中国电信股份有限公司 业务功能链报文的封装方法和装置及计算机可读存储介质
WO2020225092A1 (en) * 2019-05-03 2020-11-12 Nokia Technologies Oy Mapping gtp-u extension headers
CN111988266A (zh) * 2019-05-24 2020-11-24 华为技术有限公司 一种处理报文的方法
CN112104552A (zh) * 2019-06-17 2020-12-18 华为技术有限公司 处理报文的方法、装置及计算机存储介质
CN112787931A (zh) * 2019-11-06 2021-05-11 华为技术有限公司 报文传输方法、代理节点及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109962847A (zh) * 2017-12-14 2019-07-02 中国电信股份有限公司 业务功能链报文的封装方法和装置及计算机可读存储介质
WO2020225092A1 (en) * 2019-05-03 2020-11-12 Nokia Technologies Oy Mapping gtp-u extension headers
CN111988266A (zh) * 2019-05-24 2020-11-24 华为技术有限公司 一种处理报文的方法
CN112104552A (zh) * 2019-06-17 2020-12-18 华为技术有限公司 处理报文的方法、装置及计算机存储介质
CN112787931A (zh) * 2019-11-06 2021-05-11 华为技术有限公司 报文传输方法、代理节点及存储介质

Also Published As

Publication number Publication date
EP4333390A1 (en) 2024-03-06
US20240106748A1 (en) 2024-03-28
WO2022252569A1 (zh) 2022-12-08

Similar Documents

Publication Publication Date Title
US11283707B2 (en) Segment routing with fast reroute for container networking
CN112787931B (zh) 报文传输方法、代理节点及存储介质
WO2021233267A1 (zh) SRv6业务链中转发报文的方法、SFF及SF设备
EP4044528A1 (en) Packet transmission method, proxy node, and storage medium
CN112953831A (zh) 一种报文转发方法及装置
CN111988266B (zh) 一种处理报文的方法
EP4075738A1 (en) Failure protection method for service function chain, device, apparatus, system, and storage medium
WO2022001835A1 (zh) 发送报文的方法、装置、网络设备、系统及存储介质
WO2021083341A1 (zh) 一种报文处理的方法、网络节点和系统
CN113472650A (zh) 报文处理方法、设备、系统及存储介质
CN112787922A (zh) 一种报文处理的方法、网络节点和系统
CN111669422B (zh) 报文的传输方法和设备
US10749710B2 (en) Service offload or bypass initiated by a service function forwarder in a service function chaining network
WO2022007702A1 (zh) 一种报文处理方法及网络设备
CN114513457A (zh) Bgp流规则路由的发布方法、网络设备及存储介质
WO2022252569A1 (zh) 报文处理方法、装置及系统
CN114422415A (zh) 在分段路由中的出口节点处理流
JP2024520119A (ja) パケット処理方法、装置、及びシステム
CN114301839A (zh) 一种组播报文传输方法及装置
WO2024001701A1 (zh) 数据处理方法、装置及系统
CN116668375B (zh) 一种报文分流方法、装置、网络设备及存储介质
WO2023125774A1 (zh) 一种vxlan报文传输方法、网络设备及系统
CN115733790A (zh) 报文转发方法、装置、设备及存储介质
CN116137632A (zh) 一种报文处理方法、装置及设备
CN117097656A (zh) 一种报文处理的方法及相关设备

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