Method and apparatus for implementing service function chain
Claim Score by NHIP
Abstract
A method and device for implementing a Service Function Chain (SFC) are provided. The method is applied to a node on the SFC, and the method includes that: SFC information is encapsulated in an Internet Protocol version 6 (IPv6) of an IPv6 packet; and the IPv6 packet is sent according to the SFC information. After the IPv6 packet containing the SFC information is received, the SFC information is parsed; and an IPv6 address of a next-hop node of a Service Function Path (SFP) is acquired as a destination address, and the IPv6 packet is sent to the destination address.

Term
Projected expiry 24 February 2036.
- Priority
- Filed
- Published
- Today
- Projected expiry
20 claims: 3 independent, 17 dependent
- 1Broadest claimClaim Score 86, broad(NHIP)A method for implementing a Service Function Chain (SFC), applied to a node on the SFC, the method comprising:encapsulating SFC information in an Internet Protocol version 6 (IPv6) header of an IPv6 packet;andsending the IPv6 packet according to the SFC information.
- 11A method for implementing a Service Function Chain (SFC), applied to a node on the SFC, the method comprising:after receiving an Internet Protocol version 6 (IPv6) packet containing SFC information, parsing the SFC information;andacquiring an IPv6 address of a next-hop node of a Service Function Path (SFP) as a destination address, and sending the IPv6 packet to the destination address.
- 20A device for implementing a Service Function Chain (SFC), applied to a node on the SFC and comprising:a sender;a processor;anda memory storing instructions executable by the processor;wherein the processor is arranged to encapsulate SFC information in an Internet Protocol version 6 (IPv6) header of an IPv6 packet;andwherein the sender is arranged to send the IPv6 packet according to the SFC information.
Independent claims3
303 paragraphs in 6 sections, as filed
TECHNICAL FIELD
The disclosure relates to, but is not limited to, the technical field of communications.
BACKGROUND
The Service Function Chain (SFC) technology integrates all services and virtualizes a service overlay layer to form its own service topology for decoupling from an underlying network and breaking through restrictions of a structure of the underlying network.
An SFC architecture, as shown in <figref idref="DRAWINGS">FIG. 1-1</figref>, includes the following components: a classifier, a Service Function Forwarder (SFF), a Service Function (SF) and a Network Service Header (NSH) proxy. The classifier is responsible for classifying traffic and performing NSH encapsulation on the traffic according to a result of the classification, that is, a subsequent Service Function Path (SFP) of a packet is determined at the classifier, and then the packet is further encapsulated at a service overlay layer and forwarded to a next-hop SFF through an overlay technology; after receiving the packet, the next-hop SFF decapsulates the service overlay layer, parses the received packet containing an NSH, and forwards the packet to a corresponding SF for processing according to information in the NSH; the SF is responsible for performing corresponding SF processing on the received packet, and after processing, further updating the NSH and forwarding the updated packet to its own SFF; the SFF searches for corresponding transmission layer encapsulation according to the information in the NSH, performs overlay encapsulation on the NSH packet, and forwards the packet to a next-hop SFF; and the NSH proxy mainly interacts with an NSH-unware SF as a representative of the SFF. A dotted line in <figref idref="DRAWINGS">FIG. 1-1</figref> shows an SFP.
From the perspective of a control plane, an SFC classification rule, an SFC definition and an NSH are issued by an SFC controller or locally configured. From the perspective of data-plane encapsulation, the whole NSH, related to a service, of an SFC, as shown in <figref idref="DRAWINGS">FIG. 1-2</figref>, includes a base header, a service path header and a context header. The base header mainly identifies a version number, a length, a metadata type and a next protocol number; the service path header is a core, and identifies SFP related information of the whole SFC, including a Service Function Path Identifier (SPFID) (a Service Path ID (SPID) or an SPFID) and a service index, where the SFPID (the SPID or the SFPID is an SFPID) may be locally configured, or may be globally issued, and one SFPID corresponds to one respective service forwarding path; a node determines a specific SFC and SF to which a current packet should be forwarded for processing according to the SFPID and the service index; and the context header is arranged to contain context information, and is arranged to share information and transfer the information between a classifier and an SF, between SFs and between an SF and an SFF. For example, after the overlay technology of an Internet Protocol version 4Generic Routing Encapsulation (IPv4GRE) is used, a full packet format sent by a classifier is shown in <figref idref="DRAWINGS">FIG. 1-3</figref>, that is, an outer layer of an original packet is encapsulated with an NSH, an IPv4-GRE header and an Layer-2 (L2) header.
A Segment Routing (SR) technology is also a hot technology currently in the Internet Engineering Task Force (IETF). A main principle is that an ordered Segment Routing List (SR-List) is issued to a head node in an SR domain through a control plane, each piece of segment information identifies a segment a packet is to go through, and the SR-List identifies all the segments the packet is to go through. In such a manner, when the packet arrives at the head node of the SR domain, the packet may subsequently be forwarded according to the SR-List in an SR header only by adding the SR header to the packet. Furthermore, each segment may represent a segment of instructions, or a topology, or a service, and SR supports a segment with a global attribute, and also supports a segment with a local attribute of belonging to a certain node. Segments supported in a current SR technology include: an Interior Gateway Protocol (IGP) Segment Identifier (IGP-SID), a Prefix-SID, a Node-SID, an Anycast SID, an Adjacent SID (Adj-SID), a Border Gateway Protocol (BGP) Peer SID and the like. Existing SR technologies include Multiple Protocol Label Switching (MPLS)-SR, that is, during application in an IPv4 network, each segment is identified with a label, an SR-List is a stack of the labels, and is encapsulated outside an IPv4 packet header, and packet forwarding in an MPLS-SR domain is implemented according to label stack information.
As can be seen from the abovementioned technologies, from the perspective of a data layer, the SFC technology may specify an SFPID that a packet goes through according to a packet classification result, and then encapsulate an outer layer of an original packet with a layer of NSH for further forwarding to a next-hop SFF through an overlay technology, all a classifier(s), SFF(s), SF(s) and the like through which the packet passes have to support the NSH, and even for an SF not supporting the NSH, it needs to add an SSH proxy component for interworking between an SF supporting the NSH and the SF not supporting the NSH. From the perspective of a control layer, a controller is needed to additionally support management and control of an SFC domain. Therefore, deployment difficulties and deployment period of the SFC technology in an existing network are greatly increased, and a function set of the network devices is also greatly increased.
SUMMARY
The below is a summary about the subject matter described in the disclosure in detail. The summary is not intended to limit the scope of protection of the claims.
The disclosure provides a method and device for implementing an SFC, which may simply deploy and rapidly implement an SFC technology in an Internet Protocol version 6 (IPv6) network.
A method for implementing an SFC may be applied to a node on the SFC, and the method may include that:
SFC information is encapsulated in an IPv6 header of an IPv6 packet; and
the IPv6 packet is sent according to the SFC information.
Alternatively, the method further includes the following characteristics:
the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the method further includes the following characteristics:
the IPv6 header arranged to encapsulate the service forwarding path information may be an IPv6 routing header, or a newly defined IPv6 header.
Alternatively, the method further includes the following characteristics:
the service forwarding path information may include: SFP information and a service index,
wherein the service index may be arranged to identify position information of the current node in an SFP.
Alternatively, the method further includes the following characteristics:
the IPv6 header arranged to encapsulate the metadata information may be an IPv6 destination options header, or a newly defined IPv6 header.
Alternatively, the method further includes the following characteristics:
the operation that the IPv6 packet is sent according to the SFC information may include that:
an IPv6 address of a next-hop node is determined according to the acquired service forwarding path information, the IPv6 address of the next-hop node is determined as a destination address, and the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
before the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet, the method may further include that: traffic is classified; and
the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet may include that: the SFC information is encapsulated in the IPv6 header of the IPv6 packet according to a result of classification.
Alternatively, the method further includes the following characteristics:
before the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet, the method may further include that: the SFC information is acquired.
Alternatively, the method further includes the following characteristics:
the SFC information may be acquired in at least one of the following manners:
acquiring the SFC information from local configuration information, and acquiring the SFC information from global configuration information issued by a controller.
Alternatively, the method further includes the following characteristics:
the SFP information may include any one of: an SFPID, an address list of nodes on the SFP, an SID list of the nodes on the SFP or a node ID list of the nodes on the SFP.
A method for implementing an SFC may be applied to a node on the SFC, and the method may include that:
after an IPv6 packet containing SFC information is received, the SFC information is parsed; and
an IPv6 address of a next-hop node of an SFP is acquired as a destination address, and the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the method further includes the following characteristics:
the service forwarding path information may be encapsulated in an IPv6 routing header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet; and
the metadata information may be encapsulated in an IPv6 destination options header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet.
Alternatively, the method further includes the following characteristics:
the operation that the IPv6 packet is sent to the destination packet may include that:
when a next hop of the node is a destination node of the SFP, the IPv6 header encapsulated with the SFC information is stripped from the IPv6 packet, and then the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
the operation that the IPv6 packet is sent to the destination address may include that:
when the next hop of the node is not the destination node of the SFP, whether to update the SFC information contained in the IPv6 packet or not is determined according to a deployment strategy, and then the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
the operation that whether to update the SFC information contained in the IPv6 packet or not is determined according to the deployment strategy and then the IPv6 packet is sent to the destination address may include that:
when the service forwarding path information contained in the IPv6 packet is updated according to the deployment strategy, the updated service forwarding path information is parsed, the IPv6 address of the next-hop node of the updated SFP is acquired as the destination address, and the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
the service forwarding path information may include: SFP information and a service index,
wherein the service index may be arranged to identify position information of the current node in the SFP.
Alternatively, the method further includes the following characteristics:
the operation that the IPv6 packet is sent to the destination address may include that:
when the next hop of the node is not the destination node of the SFP and the SFC information includes the service forwarding path information, the service index in the IPv6 packet is updated, and then the IPv6 packet is sent to the destination address.
Alternatively, the method further includes the following characteristics:
the operation that the service index in the IPv6 packet is updated may include that:
when the service index represents information about a hop number between the current node and the destination node of the SFP, the service index in the IPv6 packet is progressively decreased.
A device for implementing an SFC may be applied to a node on the SFC, and may include:
an encapsulation module, arranged to encapsulate SFC information in an IPv6 header of an IPv6 packet; and
a sending module, arranged to send the IPv6 packet according to the SFC information.
Alternatively, the device further includes the following characteristics:
the SFC information may include at least one of the following information: service forwarding path information and metadata information.
Alternatively, the device further includes the following characteristics:
the IPv6 header arranged to encapsulate the service forwarding path information may be an IPv6 routing header, or a newly defined IPv6 header.
Alternatively, the device further includes the following characteristics:
the service forwarding path information may include: SFP information and a service index,
wherein the service index may be arranged to identify position information of the current node in an SFP.
Alternatively, the device further includes the following characteristics:
the IPv6 header arranged to encapsulate the metadata information may be an IPv6 destination options header, or a newly defined IPv6 header.
Alternatively, the device further includes the following characteristics:
the sending module may be arranged to:
determine an IPv6 address of a next-hop node according to the acquired service forwarding path information, determine the IPv6 address of the next-hop node as a destination address, and send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the encapsulation module may further be arranged to:
classify traffic, and encapsulate the SFC information in the IPv6 header of the IPv6 packet according to a result of the classification.
Alternatively, the device further includes the following characteristics:
the device may further include:
an information acquisition module, arranged to acquire the SFC information.
Alternatively, the device further includes the following characteristics:
the information acquisition module may be arranged to acquire the SFC information in at least one of the following manners:
acquiring the SFC information from local configuration information, and acquiring the SFC information from global configuration information issued by a controller.
Alternatively, the device further includes the following characteristics:
the SFC information may include any one of: an SFPID, an address list of nodes on the SFP, an SID list of the nodes on the SFP and a node ID list of the nodes on the SFP.
A device for implementing an SFC may be applied to a node on the SFC, and may include:
a packet receiving module, arranged to, after an IPv6 packet containing SFC information is received, parse the SFC information; and
a packet sending module, arranged to acquire an IPv6 address of a next-hop node of an SFP as a destination address, and send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the SFC information may include at least one of the following information: service forwarding path information and metadata information.
Alternatively, the device further includes the following characteristics:
the service forwarding path information may be encapsulated in an IPv6 routing header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet; and
the metadata information may be encapsulated in an IPv6 destination options header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet.
Alternatively, the device further includes the following characteristics:
the packet sending module may be arranged to:
when a next hop of the node is a destination node of the SFP, strip the IPv6 header encapsulated with the SFC information from the IPv6 packet, and then send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the packet sending module may be arranged to:
when the next hop of the node is not the destination node of the SFP, determine whether to update the SFC information contained in the IPv6 packet or not according to a deployment strategy, and then send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the packet sending module may be arranged to:
when the service forwarding path information contained in the IPv6 packet is updated according to the deployment strategy, parse the updated service forwarding path information, acquire the IPv6 address of the next-hop node of the updated SFP as the destination address, and send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the service forwarding path information may include: SFP information and a service index,
wherein the service index may be arranged to identify position information of the current node in the SFP.
Alternatively, the device further includes the following characteristics:
the packet sending module may be arranged to:
when the next hop of the node is not the destination node of the SFP and the SFC information includes the service forwarding path information, update the service index in the IPv6 packet, and then send the IPv6 packet to the destination address.
Alternatively, the device further includes the following characteristics:
the packet sending module may be arranged to:
when the service index represents information about a hop number between the current node and the destination node of the SFP, progressively decrease the service index in the IPv6 packet.
A computer-readable storage medium may store computer executable instructions, and the computer executable instructions may be arranged to execute any abovementioned method.
Compared with the related art, the method and device provided by embodiments of the disclosure for implementing the SFC have the advantage that the SFC information is encapsulated in the IPv6 header of the IPv6 packet and the IPv6 packet is forwarded along the SFC, so that the SFC technology may be simply deployed and rapidly implemented in an IPv6 network.
After the drawings and detailed descriptions are read and understood, the other aspects may be comprehended.
BRIEF DESCRIPTION OF DRAWINGS
<figref idref="DRAWINGS">FIG. 1-1</figref> is an architecture of an SFC technology in the related art.
<figref idref="DRAWINGS">FIG. 1-2</figref> is an NSH encapsulated on a data plane according to the SFC technology in the related art.
<figref idref="DRAWINGS">FIG. 1-3</figref> is a complete packet structure sent from a classifier component according to the SFC technology in the related art.
<figref idref="DRAWINGS">FIG. 1-4</figref> is a structure of an IPv6 routing header packet in the related art.
<figref idref="DRAWINGS">FIG. 1-5</figref> is a structure of an IPv6 routing header packet with a Routing Type=−0 in the related art.
<figref idref="DRAWINGS">FIG. 1-6</figref> is a format of an IPv6 destination option header packet.
<figref idref="DRAWINGS">FIG. 2-1</figref> is a flowchart of a method for implementing an SFC according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 2-2</figref> is a flowchart of another method for implementing an SFC according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 2-3</figref> is a structure diagram of a device for implementing an SFC according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 2-4</figref> is a structure diagram of another device for implementing an SFC according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-1</figref> is a reference structure of a packet of which an IPv6 routing header contains SFP related information according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-2</figref> is a reference format of a packet of which an IPv6 destination options header contains a metadata option according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-3</figref> is a reference format of a metadata sub-option packet extended in a metadata option packet according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-4</figref> shows multiple types of metadata sub-options defined with a reference according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-5</figref> is an SFC to be implemented according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-6</figref> is a schematic diagram of an IPv6 SFC according to example one of the disclosure.
<figref idref="DRAWINGS">FIG. 3-7</figref> is a reference format of an IPv6 routing header implemented by transmitting SFP related information through an SFPID according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-8</figref> is a schematic diagram of an IPv6 SFC according to example two of the disclosure (an SFP changes).
<figref idref="DRAWINGS">FIG. 3-9</figref> is a schematic diagram of an IPv6 SFC according to example three of the disclosure.
<figref idref="DRAWINGS">FIG. 3-10</figref> is a reference format of an IPv6 routing header implemented by transmitting SFP related information through an IPv6 global address list according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-11</figref> is a schematic diagram of an IPv6 SFC according to example four of the disclosure (a service forwarding path is updated at an intermediate node).
<figref idref="DRAWINGS">FIG. 3-12</figref> is a schematic diagram of an IPv6 SFC according to example five of the disclosure.
<figref idref="DRAWINGS">FIG. 3-13</figref> is a reference format of an IPv6 routing header implemented by transmitting SFP related information through SR according to an embodiment of the disclosure.
<figref idref="DRAWINGS">FIG. 3-14</figref> is a schematic diagram of an IPv6 SFC according to example six of the disclosure.
DETAILED DESCRIPTION
The embodiments of the disclosure will be described below in combination with the drawings in detail. It is to be noted that the embodiments in the disclosure and features in the embodiments may be freely combined without conflicts.
At present, in an IPv6 technology (RFC2460), multiple headers are defined for IPv6 headers, including a hop-by-hop options header, a routing header, a fragment header, a destination options header, an authentication header and the like.
Herein, the routing header is mainly arranged to display, at an IPv6 source node, information of intermediate nodes to be went through in a process for a specified packet to arrive at a destination node, and its format is shown in <figref idref="DRAWINGS">FIG. 1-4</figref>. Next Header refers to a protocol number of a next header, Routing Type refers to a type of the current routing header, and Segments Left (left nodes) identifies a number of nodes to be went through for arrival at a destination from the current node; and type-specific data (data corresponding to the current type) identifies data information corresponding to the type of the current routing header. In RFC2460, extension of a packet with a Routing Type of 0 is defined, and its format is shown in <figref idref="DRAWINGS">FIG. 1-5</figref>. Address[<b>1</b>] to Address[n] identify IPv6 address information of intermediate nodes to be went through for arrival at the destination.
Herein, the destination options header is mainly arranged to contain information to be processed by the destination node. An example of a header format is shown in <figref idref="DRAWINGS">FIG. 1-6</figref>, where an Options field includes options in a Type-Length-Value (TLV) format.
The embodiments of the disclosure are based on the IPv6 network, and are intended to extend an IPv6 header supported by all IPv6 network nodes by virtue of a principle of the IPv6 headers, to implement simple deployment and implementation of the SFC technology.
As shown in <figref idref="DRAWINGS">FIG. 2-1</figref>, an embodiment of the disclosure provides a method for implementing an SFC, which is applied to a node on the SFC. The method includes the following steps.
In S<b>10</b>, SFC information is encapsulated in an IPv6 header of an IPv6 packet.
In S<b>20</b>, the IPv6 packet is sent according to the SFC information.
The method may further include the following characteristics.
Alternatively, before the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet, the method may further include that:
the SFC information is acquired.
Alternatively, the SFC information may be acquired in at least one of the following manners: acquiring the SFC information from local configuration information, or acquiring the SFC information from global configuration information issued by a controller.
Alternatively, the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the service forwarding path information may include: SFP information and a service index.
Alternatively, the SFP information may include any one of: an SFPID, an address list of nodes on an SFP, an SID list of the nodes on the SFP or a node ID list of the nodes on the SFP.
The service index is arranged to identify position information of the current node in the SFP.
The SFPID is arranged to uniquely identify the SFP.
Alternatively, before the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet, the method may further include that: traffic is classified.
Accordingly, the operation that the SFC information is encapsulated in the IPv6 header of the IPv6 packet may include that: the SFC information is encapsulated in the IPv6 header of the IPv6 packet according to a result of the classification.
Alternatively, the operation that the IPv6 packet is sent according to the SFC information may include that:
an IPv6 address of a next-hop node is determined according to the acquired service forwarding path information, the IPv6 address of the next-hop node is determined as a destination address, and the IPv6 packet is sent to the destination address.
Alternatively, the IPv6 header arranged to encapsulate the service forwarding path information may be an IPv6 routing header, or a newly defined IPv6 header.
The metadata information may include at least one of the following information: mandatory context data information or optional context data information.
The mandatory context data information includes the following one or more types of data: network platform metadata, network service metadata, service platform metadata or service shared metadata.
The network platform metadata is arranged to identify network platform-level context information shared between network nodes, for example, incoming interface information and a forwarding environment. The network service metadata is arranged to identify network-layer information shared between the network nodes, for example, an ID, tenant information and the classification result. The service platform metadata is arranged to identify service platform-level context information shared between SF nodes, for example, a service strategy. The service shared metadata is arranged to identify service related context information shared between the SF nodes, for example, application information and a service processing result.
The optional context data information may be different according to different practical service scenarios.
Alternatively, the IPv6 header arranged to encapsulate the metadata information may be an IPv6 destination options header, or a newly defined IPv6 header.
As shown in <figref idref="DRAWINGS">FIG. 2-2</figref>, an embodiment of the disclosure provides a method for implementing an SFC, which is applied to a node on the SFC. The method includes the following steps.
In S<b>30</b>, after an IPv6 packet containing SFC information is received, the SFC information is parsed.
In S<b>40</b>, an IPv6 address of a next-hop node of an SFP is acquired as a destination address, and the IPv6 packet is sent to the destination address.
The method may further include the following characteristics:
Nodes on the SFP include at least one of: an SF node(s) or an SFF node(s).
Alternatively, the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the service forwarding path information may include: SFP information and a service index.
Alternatively, the SFP information may include any one of: an SFPID, an address list of the nodes on the SFP, an SID list of the nodes on the SFP or a node ID list of the nodes on the SFP.
The service index is arranged to identify position information of the current node in the SFP.
Alternatively, the service forwarding path information is encapsulated in an IPv6 routing header of the IPv6 packet, or is encapsulated in a newly defined IPv6 header of the IPv6 packet.
The metadata information is encapsulated in an IPv6 destination options header of the IPv6 packet, or is encapsulated in a newly defined IPv6 header of the IPv6 packet.
Alternatively, the operation that the IPv6 packet is sent to the destination packet may include that:
when a next hop of the node is a destination node of the SFP, the IPv6 header encapsulated with the SFC information is stripped from the IPv6 packet, and then the IPv6 packet is sent to the destination address.
Alternatively, the operation that the IPv6 packet is sent to the destination address may include that:
when the next hop of the node is not the destination node of the SFP and the SFC information includes the service forwarding path information, the service index in the IPv6 packet is updated, and then the IPv6 packet is sent to the destination address.
Alternatively, the operation that the service index in the IPv6 packet is updated may include that:
when the service index represents information about a number of hops between the current node and the destination node of the SFP, the service index in the IPv6 packet is progressively decreased.
Alternatively, the operation that the IPv6 packet is sent to the destination address may include that:
when the next hop of the node is not the destination node of the SFP, whether to update the SFC information contained in the IPv6 packet or not is determined according to a deployment strategy, and then the IPv6 packet is sent to the destination address.
Alternatively, the operation that whether to update the SFC information contained in the IPv6 packet or not is determined according to the deployment strategy and then the IPv6 packet is sent to the destination address may include that:
when the service forwarding path information contained in the IPv6 packet is updated according to the deployment strategy, the updated service forwarding path information is parsed, the IPv6 address of the next-hop node of the updated SFP is acquired as the destination address, and the IPv6 packet is sent to the destination address.
As shown in <figref idref="DRAWINGS">FIG. 2-3</figref>, an embodiment of the disclosure provides a device for implementing an SFC, which is applied to a node on the SFC and includes an encapsulation module <b>21</b> and a sending module <b>22</b>.
The encapsulation module <b>21</b> is arranged to encapsulate SFC information in an IPv6 header of an IPv6 packet.
The sending module <b>22</b> is arranged to send the IPv6 packet according to the SFC information.
The device may further include the following characteristics.
Alternatively, the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the IPv6 header arranged to encapsulate the service forwarding path information may be an IPv6 routing header, or a newly defined IPv6 header.
Alternatively, the service forwarding path information may include: SFP information and a service index.
Here, the service index is arranged to identify position information of the current node in an SFP.
Alternatively, the IPv6 header arranged to encapsulate the metadata information may be an IPv6 destination options header, or a newly defined IPv6 header.
Alternatively, the sending module <b>22</b> may be arranged to:
determine an IPv6 address of a next-hop node according to the acquired service forwarding path information, determine the IPv6 address of the next-hop node as a destination address, and send the IPv6 packet to the destination address.
Alternatively, the encapsulation module <b>21</b> may be further arranged to:
classify traffic, and encapsulate the SFC information in the IPv6 header of the IPv6 packet according to a result of the classification.
Alternatively, the device may further include an information acquisition module.
The information acquisition module may be arranged to acquire the SFC information.
Alternatively, the information acquisition module may be arranged to acquire the SFC information in at least one of the following manners:
acquiring the SFC information from local configuration information, and acquiring the SFC information from global configuration information issued by a controller.
Alternatively, the SFC information includes any one of: an SFPID, an address list of nodes on the SFP, an SID list of the nodes on the SFP or a node ID list of the nodes on the SFP.
Alternatively, the metadata information includes at least one of the following information: mandatory context data information or optional context data information.
As shown in <figref idref="DRAWINGS">FIG. 2-4</figref>, an embodiment of the disclosure provides a device for implementing an SFC, which is applied to a node on the SFC and includes a packet receiving module <b>23</b> and a packet sending module <b>24</b>.
The packet receiving module <b>23</b> is arranged to, after an IPv6 packet containing SFC information is received, parse the SFC information.
The packet sending module <b>24</b> is arranged to acquire an IPv6 address of a next-hop node of an SFP as a destination address, and send the IPv6 packet to the destination address.
The device may further include the following characteristics.
Alternatively, the SFC information may include at least one of the following information: service forwarding path information or metadata information.
Alternatively, the service forwarding path information may be encapsulated in an IPv6 routing header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet.
The metadata information may be encapsulated in an IPv6 destination options header of the IPv6 packet, or may be encapsulated in a newly defined IPv6 header of the IPv6 packet.
Alternatively, the packet sending module <b>24</b> may be arranged to, when a next hop of the current node is a destination node of the SFP, strip the IPv6 header encapsulated with the SFC information from the IPv6 packet, and then send the IPv6 packet to the destination address.
Alternatively, the packet sending module <b>24</b> may be arranged to, when the next hop of the node is not the destination node of the SFP, determine whether to update the SFC information contained in the IPv6 packet or not according to a deployment strategy, and then send the IPv6 packet to the destination address.
Alternatively, the packet sending module <b>24</b> may be arranged to, when the service forwarding path information contained in the IPv6 packet is updated according to the deployment strategy, parse the updated service forwarding path information, acquire the IPv6 address of the next-hop node of the updated SFP as the destination address, and send the IPv6 packet to the destination address.
Alternatively, the service forwarding path information includes: SFP information and a service index,
wherein the service index is arranged to identify position information of the current node in the SFP.
Alternatively, the packet sending module <b>24</b> may be arranged to, when the next hop of the node is not the destination node of the SFP and the SFC information includes the service forwarding path information, update the service index in the IPv6 packet, and then send the IPv6 packet to the destination address.
Alternatively, the packet sending module <b>24</b> may be arranged to, when the service index represents information of a number of hops between the current node and the destination node of the SFP, progressively decrease the service index in the IPv6 packet.
Implementations
As shown in <figref idref="DRAWINGS">FIG. 3-1</figref>, an embodiment of the disclosure extends a reference format of a packet of which an IPv6 routing header contains SFP related information, which includes:
Routing Type: routing header type;
here, a routing header of a type <b>5</b> is extended in the embodiment of the disclosure;
Service Index: a service index, which is identical to Segments Left;
Identifier Type: mode for identifying service forwarding path information,
here, the identification manner for the service forwarding path information may be an SFPID, or may be an address list of each node, and
SFP information: being arranged to identify experienced path information for service forwarding.
As shown in <figref idref="DRAWINGS">FIG. 3-2</figref>, an embodiment of the disclosure newly defines a metadata option to contain metadata related information on the basis of extension of an IPv6 destination options header containing the metadata related information.
Here, the metadata option is arranged to identify a context header and/or variable length optional metadata information contained in an NSH in a current SFC technology, and a reference format of the metadata option is shown in <figref idref="DRAWINGS">FIG. 3-2</figref>, which includes:
MD Option Type: identifying a metadata option type:
Opt Data Len: identifying a metadata length contained in the metadata option; and
Option Data: identifying metadata contained in the option.
Furthermore, a definition about an MD Sub-Opt is extended in the metadata option, and a reference format of the sub-option is shown in <figref idref="DRAWINGS">FIG. 3-3</figref>, which includes:
MD Sub-Opt Type: identifying a metadata sub-option type:
MD Sub-Opt Length: identifying a metadata length contained in the metadata sub-option; and
Sub-Opt Data: identifying metadata contained in the metadata sub-option.
Furthermore, the currently defined metadata sub-option, as shown in <figref idref="DRAWINGS">FIG. 3-4</figref>, includes, but not limited to:
a network platform metadata sub-option: identifying network platform-level context information shared between network nodes, for example, incoming interface information and a forwarding environment;
a network service metadata sub-option: identifying network-layer information shared between the network nodes, for example, an ID, tenant information and a classification result;
a service platform metadata sub-option: identifying service platform-level context information shared between SF nodes, for example, a service strategy;
a service shared metadata sub-option: identifying service related context information shared between the SF nodes, for example, application information and a service processing result; and
other related metadata.
As shown in <figref idref="DRAWINGS">FIG. 3-5</figref>, a service forwarding path went through by the SFC is represented as: SFF<b>1</b>->SF<b>2</b>->SFF<b>3</b>->SF<b>5</b>,
where SF<b>1</b> and SF<b>2</b> are connected to SFF<b>1</b>, SF<b>3</b> is connected to SFF<b>2</b>, SF<b>4</b> and SF<b>5</b> are connected to SFF<b>3</b>, and a classifier and each SFF and SF belong to nodes in an IPv6-SFC domain.
Example 1
As shown in <figref idref="DRAWINGS">FIG. 3-6</figref>, a packet goes through intermediate nodes SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b> when being sent from a source node S (Source) to a destination D (Destination), and a forwarding flow of the packet is as follows.
In Step <b>1</b>, the source node Source acquires information [SFF<b>1</b>,SF<b>2</b>,SFF<b>3</b>,SF<b>5</b>,Destination] about a service forwarding path to the destination node Destination and a corresponding SFPID SFPID<b>1</b>, totally 5 hops (Service Index), and meanwhile, acquires metadata related information to be transmitted and shared on the service forwarding path, where the path information and the metadata related information may be locally configured, or may be acquired from a controller, and here, the source node plays a role in encapsulating service forwarding path related information and the metadata related information.
In Step <b>2</b>, the source node parses the SFPID<b>1</b>, acquires information of a first-hop node, further parses it as a routable IPv6 address, encapsulates it in a destination address field of an IPv6 header, encapsulates the SFPID<b>1</b> corresponding to the information [SFF<b>1</b>,SF<b>2</b>,SFF<b>3</b>,SF<b>5</b>,Destination] about the service forwarding path in a routing header defined in the embodiment of the disclosure, that is, a packet format is shown in <figref idref="DRAWINGS">FIG. 3-7</figref>, 1 is subtracted from the Service Index field to obtain 4, and meanwhile, the acquired metadata related information is encapsulated in an IPv6 destination options header.
In Step <b>3</b>, the source node performs forwarding to the first-hop node SFF<b>1</b> according to a destination IPv6 address in the IPv6 header. Of course, when looking up an IPv6 routing forwarding table, the source node may find that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address, or may find that Virtual Local Area Network (VLAN) encapsulation, Virtual Extensible Local Area Network (VXLAN) encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>4</b>, after SFF<b>1</b> receives the packet, if finding that the destination is itself, the SFF<b>1</b> parses the routing header in the packet, further parses the information of the SFPID<b>1</b> and the Service Index to learn about that the current node is a first hop, further acquires information of a second-hop node SF<b>2</b>, parses the information of SF<b>2</b> as a routable IPv6 address on the SFF<b>1</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 3; meanwhile, the metadata related information in the packet is parsed to judge whether there is metadata information needed by the node SFF<b>1</b> or not, and if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SFF<b>1</b> looks up the IPv6 routing table for forwarding according to the updated destination IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination node.
In Step <b>5</b>, after SF<b>2</b> receives the packet, if finding that the destination is itself, the SF<b>2</b> parses the routing header in the packet, further parses the information of the SFPID<b>1</b> and the Service Index to learn about that the current node is a second hop, further acquires information of a third-hop node SFF<b>3</b>, parses the information of SFF<b>3</b> as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 2; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>2</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SF<b>2</b> looks up the IPv6 routing table for forwarding according to the updated destination IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>6</b>, after SFF<b>3</b> receives the packet, if finding that the destination is itself, the SFF<b>3</b> parses the routing header in the packet, further parses the information of the SFPID<b>1</b> and the Service Index to learn about that the current node is a third hop, further acquires information of a fourth-hop node SF<b>5</b>, parses the information of SF<b>5</b> as a routable IPv6 address on the SFF<b>3</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 1; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SFF<b>3</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SFF<b>3</b> looks up the IPv6 routing table for forwarding according to the updated destination IPv6 address; and it may also be found that VLAN encapsulation. VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination address.
In Step <b>7</b>, after SF<b>5</b> receives the packet, if finding that the destination is itself, the SF<b>5</b> parses the routing header in the packet, further parses the information of the SFPID<b>1</b> and the Service Index to learn about that the current node is a fourth hop, further acquires information of a fifth-hop node Destination, parses information of the Destination as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 0; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>5</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SF<b>5</b> finds that the Service Index field is 0, and strips the routing header containing the SFP related information and the destination routing header containing the metadata related information: then, the SF<b>5</b> looks up the IPv6 routing table for forwarding according to the destination Destination-IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Example 2
As shown in <figref idref="DRAWINGS">FIG. 3-8</figref>, a packet goes through intermediate nodes classifier/SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b> when being sent from a source node S (Source) to a destination D (Destination). The classifier is an inevitable node for the source node S to access the destination node D, or is a first-hop routing forwarding device; at this moment, the node performing SFP related information encapsulation and/or metadata related information encapsulation is the intermediate node classifier; and moreover, when the packet arrives at the SFF<b>3</b>, reclassification may occur to reacquire the SFP information and/or the metadata related information. A forwarding flow of the packet is as follows.
In Step <b>1</b>, the source node Source looks up an IPv6 routing table according to a destination address Destination, and finally forwards the packet to the inevitable node classifier.
In Step <b>2</b>, the node classifier acquires information [SFF<b>1</b>. SF<b>2</b>. SFF<b>3</b>, SF<b>5</b>. Destination] about a service forwarding path to the destination node Destination and corresponding identifiers SFPID<b>2</b>, totally 5 hops, and meanwhile, does not acquire the metadata related information to be transmitted and shared on the service forwarding path; the path information may be locally configured, or may be acquired from a controller, and here, the node classifier plays a role in encapsulating the SFP related information.
In Step <b>3</b>, the node classifier parses the SFPID<b>2</b>, acquires information of a first-hop node, further parses the information of the first-hop node as a routable IPv6 address, encapsulates it in a destination address field of an IPv6 header, encapsulates the SFPID<b>2</b> corresponding to the information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about the service forwarding path in a routing header defined in the embodiment of the disclosure, and subtracts 1 from the Service Index field to obtain 4.
In Step <b>4</b>, the node classifier performs forwarding to to the first-hop node SFF<b>1</b> according to a destination IPv6 address in the IPv6 header. Of course, when looking up an IPv6 routing forwarding table, the node classifier may find that tunnel encapsulation or MPLS forwarding is needed for arrival at the destination IPv6 address, or may find that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>5</b>, after SFF<b>1</b> receives the packet, if finding that the destination is itself, the SFF<b>1</b> parses the routing header in the packet, further parses the information of the SFPID<b>2</b> and the Service Index to learn about that the current node is a first hop, further acquires information of a second-hop node SF<b>2</b>, parses the information of SF<b>2</b> as a routable IPv6 address on the SFF<b>1</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 3; meanwhile, the other part of the IPv6 header is parsed, and no metadata related information is parsed; the SFF<b>1</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the SF<b>2</b>.
In Step <b>6</b>, after SF<b>2</b> receives the packet, if finding that the destination is itself, the SF<b>2</b> parses the routing header in the packet, further parses the information of the SFPID<b>2</b> and the Service Index to learn about that the current node is a second hop, further acquires information of a third-hop node SFF<b>3</b>, parses the information of SFF<b>3</b> as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 2; meanwhile, the other part of the IPv6 header is parsed, and no metadata related information is parsed; the SF<b>2</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>7</b>, after SFF<b>3</b> receives the packet, if finding that the destination is itself and meanwhile, finding that reclassification is required on the SFF<b>3</b>, the SFF<b>3</b> reacquires information [SF<b>4</b>, Destination] about a service forwarding path to the destination node Destination and corresponding identifiers SFPID<b>3</b>, totally 2 hops; meanwhile, the metadata related information to be transmitted and shared on the forwarding path is acquired; the path information and the metadata related information may be locally configured, or may be acquired from the controller; here, the node SFF<b>3</b> forwards the path related information SFPID<b>3</b> and a service index <b>2</b> according to the new service forwarding path, parses information about the first-hop node SF<b>4</b> as a routable IPv6 address on the SFF<b>3</b>, replaces the destination in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 1; in addition, the original service forwarding path related information contained in the routing header is updated with the new service forwarding path related information, and the metadata related information is encapsulated in an IPv6 destination options headers; the SFF<b>3</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the SF<b>4</b>.
In Step <b>8</b>, after SF<b>4</b> receives the packet, if finding that the destination is itself, the SF<b>4</b> parses the routing header in the packet, further parses the information of the SFPID<b>3</b> and the Service Index to learn about that the current node is a first hop, further acquires information of a second-hop node Destination, parses the information of the Destination as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 0; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>4</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SF<b>4</b> finds that the Service Index field is 0, and strips the routing header containing the SFP related information and the destination routing header containing the metadata related information; then, the SF<b>4</b> looks up the IPv6 routing table for forwarding according to the destination Destination-IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Example 3
As shown in <figref idref="DRAWINGS">FIG. 3-9</figref>, a packet goes through intermediate nodes SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b> when being sent from a source S to a destination D, all the intermediate nodes have globally reachable IPv6 address IDs. and correspond to IPv6 addresses SFF<b>1</b>-IPv6/SF<b>2</b>-IPv6/SFF<b>3</b>-IPv6/SF<b>5</b>-IPv6 respectively, and a forwarding flow of the packet is as follows.
In Step <b>1</b>, the source node Source acquires information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about a service forwarding path to the destination node Destination and the corresponding global IPv6 addresses, totally 5 hops, and meanwhile, acquires metadata related information to be transmitted and shared on the service forwarding path. The path information and the metadata related information may be locally configured, or may be acquired from a controller.
In Step <b>2</b>, the source node acquires IPv6 address information of a first-hop node SFF<b>1</b>, encapsulates it in a destination address field of an IPv6 header, encapsulates the IPv6 addresses corresponding to the information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about the service forwarding path in a newly extended routing header defined in the embodiment of the disclosure in an inverted sequence, that is, a packet format is shown in <figref idref="DRAWINGS">FIG. 3-10</figref>, subtracts 1 from the Service Index field to obtain 4, and meanwhile, encapsulates the acquired metadata related information in an IPv6 destination options header.
In Step <b>3</b>, the source node performs forwarding to implement forwarding to the first-hop node SFF<b>1</b> according to a destination IPv6 address in the IPv6 header. Of course, when looking up an IPv6 routing forwarding table, the source node may find that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>4</b>, after SFF<b>1</b> receives the packet, if finding that the destination is itself, the SFF<b>1</b> parses the routing header in the packet, further parses the information of the service forwarding path and the Service Index to learn about that the current node is a first hop, further acquires the IPv6 address of a second-hop node SF<b>2</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 3; meanwhile, the metadata related information in the packet is parsed to judge whether there is metadata information needed by the node SFF<b>1</b> or not, and if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SFF<b>1</b> looks up the IPv6 routing table for forwarding according to the destination SF<b>2</b>-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>5</b>, after SF<b>2</b> receives the packet, if finding that the destination is itself, the SF<b>2</b> parses the routing header in the packet, further parses the information of the service forwarding path and the Service Index to learn about that the current node is a second hop, further acquires the IPv6 address of a third-hop node SFF<b>3</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 2; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>2</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SF<b>2</b> looks up the IPv6 routing table for forwarding according to the destination SFF<b>3</b>-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>6</b>, after SFF<b>3</b> receives the packet, if finding that the destination is itself, the SFF<b>3</b> parses the routing header in the packet, further parses the information of the service forwarding path and the Service Index to learn about that the current node is a third hop, further acquires the IPv6 address of a fourth-hop node SF<b>5</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 1; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SFF<b>3</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SFF<b>3</b> looks up the IPv6 routing table for forwarding according to the destination SF<b>5</b>-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination address.
In Step <b>7</b>, after SF<b>5</b> receives the packet, if finding that the destination is itself, the SF<b>5</b> parses the routing header in the packet, further parses the information of the service forwarding path and the Service Index to learn about that the current node is a fourth hop, further acquires the IPv6 address of a fifth-hop node Destination, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 0; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>5</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SF<b>5</b> finds that the Service Index field is 0, and strips the routing header containing the SFP related information and the destination routing header containing the metadata related information; then, the SF<b>5</b> looks up the IPv6 routing table for forwarding according to the destination Destination-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Example 4
As shown in <figref idref="DRAWINGS">FIG. 3-11</figref>, a packet goes through intermediate nodes classifier/SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b> when being sent from a source S to a destination D, and all the intermediate nodes have globally reachable IPv6 address IDs, and correspond to IPv6 addresses classifier-IPv6/SFF<b>1</b>-IPv6/SF<b>2</b>-IPv6/SFF<b>3</b>-IPv6/SF<b>5</b>-IPv6 respectively. The classifier is an inevitable node for the source node S to access the destination node D, or is a first-hop routing forwarding device; at this moment, the node performing routing header encapsulation is the intermediate node classifier; and moreover, when the packet arrives at the SFF<b>3</b>, it is found that traffic on the SF<b>5</b> is almost saturated, and then another next-hop SF, i.e., SF<b>4</b> is selected. A forwarding flow of the packet is as follows.
In Step <b>1</b>, the source node Source looks up an IPv6 routing table according to a destination address Destination, and finally forwards the packet to the inevitable node Classifier.
In Step <b>2</b>, the node Classifier acquires information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about a service forwarding path to the destination node Destination and the corresponding global IPv6 addresses, totally 5 hops, and meanwhile, acquires metadata related information to be transmitted and shared on the service forwarding path. The path information and the metadata related information may be locally configured, and may also be acquired from a controller.
In Step <b>3</b>, the node Classifier acquires information of a first-hop node, encapsulates it in a destination address field of an IPv6 header, encapsulates the IPv6 addresses corresponding to the information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>. SF<b>5</b>, Destination] about the service forwarding path in a routing header newly extended in the embodiment of the disclosure, of which a packet format is shown in <figref idref="DRAWINGS">FIG. 18</figref>, subtracts 1 from the Service Index field to obtain 4, and meanwhile, encapsulates the acquired metadata related information in an IPv6 destination options header.
In Step <b>4</b>, the node Classifier performs forwarding to the first-hop node SFF according to a destination IPv6 address in the IPv6 header. Of course, when looking up an IPv6 routing forwarding table, the node Classifier may find that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Step <b>5</b> is the same as Step <b>4</b> in example 3.
<figref idref="DRAWINGS">FIG. 6</figref> is the same as Step <b>5</b> in example 3.
In Step <b>7</b>, after SFF<b>3</b> receives the packet, if finding that the destination is itself, the SFF<b>3</b> parses the routing header in the packet, if finding that the next hop is the SF<b>5</b> and meanwhile, finding that the traffic on the SF<b>5</b> is almost saturated by various means, reselects the next-hop SF as the SF<b>4</b>, updates the destination address in the IPv6 header to be SF<b>4</b>-IPv6, and subtracts 1 from the Service Index field to obtain 1; at this moment, the SFF<b>3</b> may select to update an SFP address list, or may select not to update it; meanwhile, the metadata related information in the packet is parsed to judge whether there is metadata information needed by the node SFF<b>3</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; the SFF<b>3</b> looks up the IPv6 routing table for forwarding according to the destination SF<b>4</b>-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>8</b>, after SF<b>4</b> receives the packet, if finding that the destination is itself, the SF<b>4</b> parses the routing header in the packet, further parses the information of the service forwarding path and the Service Index to learn about that the current node is a fourth hop, further acquires the IPv6 address of a fifth-hop node Destination, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 0; meanwhile, the metadata information in the packet is parsed to judge whether there is metadata information needed by the node SF<b>4</b> or not; if YES, the metadata information is read and used, and after use, the metadata information is updated as needed; if NO, the metadata information is not updated; furthermore, the SF<b>4</b> finds that the Service Index field is 0, and strips the routing header containing the SFP related information and the destination routing header containing the metadata related information; then, the SF<b>4</b> looks up the IPv6 routing table for forwarding according to the destination Destination-IPv6 address; and it may also be found that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Example 5
As shown in <figref idref="DRAWINGS">FIG. 3-12</figref>, a packet goes through intermediate nodes SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b> when being sent from a source S to a destination D, and all the intermediate nodes have corresponding SIDs (Segment IDs/SIDs), and correspond to IDs SFF<b>1</b>-SID/SF<b>2</b>-SID/SFF<b>3</b>-SID/SF<b>5</b>-SID respectively, wherein SFF<b>1</b>-SID and SFF<b>3</b>-SID are node SIDs, and SF<b>2</b>-SID and SF<b>5</b>-SID are service SIDs. A forwarding flow of the packet is as follows.
In Step <b>1</b>, the source node Source acquires information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about a service forwarding path to the destination node Destination and the corresponding SIDs, totally 5 hops, and meanwhile, does not acquire metadata related information corresponding to the service forwarding path. The path information and the metadata related information may be locally configured, or may be acquired from a controller, and here, the source node plays a role in encapsulating a routing header.
In Step <b>2</b>, the source node acquires information of a first-hop node, i.e. SFF<b>1</b>-SID information, further parses the SFF<b>1</b>-SID information as a routable IPv6 address, encapsulates the address in a destination address field of an IPv6 header, encapsulates the SIDs corresponding to the information [SFF<b>1</b>, SF<b>2</b>, SFF<b>3</b>, SF<b>5</b>, Destination] about the service forwarding path in a routing header defined in the embodiment of the disclosure in an inverted sequence, that is, a packet format is shown in <figref idref="DRAWINGS">FIG. 3-13</figref>, and subtracts 1 subtracted from the Service Index field to obtain 4.
In Step <b>3</b>, the source node performs forwarding to to the first-hop node SFF<b>1</b> according to a destination IPv6 address in the IPv6 header. Of course, when looking up an IPv6 routing forwarding table, the source node may find that tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address, or may find that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>4</b>, after receiving the packet, if finding that the destination is itself, the SFF<b>1</b> parses the routing header in the packet, further parses corresponding SF<b>2</b>-SID information, if finding that it is a local service SID, parses it as a routable IPv6 address on the SFF<b>1</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 3; the SFF<b>1</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address of the SF<b>2</b>-SID; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the SF<b>2</b>-SID.
In Step <b>5</b>, after SF<b>2</b> receives the packet, if finding that the destination is itself, the SF<b>2</b> parses the routing header in the packet, further parses corresponding SFF<b>3</b>-SID information as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 2; the SF<b>2</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address of the SFF<b>3</b>-SID; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
In Step <b>6</b>, after SFF<b>3</b> receives the packet, if finding that the destination is itself the SFF<b>3</b> parses the routing header in the packet, further parses corresponding SF<b>5</b>-SID information, if finding that it is a local service SID, parses the SF<b>5</b>-SID information as a routable IPv6 address on the SFF<b>3</b>, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 3; the SFF<b>3</b> looks up the IPv6 routing table for forwarding according to the parsed IPv6 address of the SF<b>5</b>-SID; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the SF<b>5</b>-SID.
In Step <b>7</b>, after SF<b>5</b> receives the packet, if finding that the destination is itself, the SF<b>5</b> parses the routing header in the packet, further parses corresponding Destination-SID information, parses the Destination-SID information as a routable IPv6 address, replaces the destination address in the IPv6 header with the address, and subtracts 1 from the Service Index field to obtain 0; the SF<b>5</b> finds that the Service Index field is 0, and strips the routing header; then, the SF<b>5</b> looks up the IPv6 routing table for forwarding according to the destination Destination-IPv6 address; and it may also be found that VLAN encapsulation, VXLAN encapsulation, tunnel encapsulation or MPLS forwarding is required for arrival at the destination IPv6 address.
Example 6
As shown in <figref idref="DRAWINGS">FIG. 3-14</figref>, a packet is sent from a source S to a destination D, a service forwarding path is Classier/SFF<b>1</b>/SF<b>2</b>/SFF<b>3</b>/SF<b>5</b>, and the destination D is not in an IPv6 SFC domain; when the packet is sent from the source S to the destination D, the packet received by the destination node Destination contains unrecognized metadata option information; and at this moment, the Destination needs to further process the received packet according to identifiers defined in Chapter REC 2460 4.2.
When highest two bits in an MD Option Type field of a metadata option are 00, the option is ignored:
when the highest two bits in the MD Option Type field of the metadata option are 01, the packet is discarded:
when the highest two bits in the MD Option Type field of the metadata option are 10, the packet is discarded, and no matter whether a destination address of the packet is a multicast address or not, an Internet Control Packet Protocol (ICMP) parameter error packet is sent to the source node to indicate that there is an unrecognized option type; and
when the highest two bits in the MD Option Type field of the metadata option are 11, the packet is discarded, and only when the destination address of the packet is not a multicast address, the ICMP parameter error packet is sent to the source node to indicate that there is an unrecognized option type.
According to the methods and devices provided by the abovementioned embodiments for implementing the SFC, the SFC information is encapsulated in the IPv6 header of the IPv6 and the IPv6 packet is forwarded along the SFC, so that the SFC technology may be simply deployed and rapidly implemented in an IPv6 network.
Those skilled in the art should know that all or part of the steps of the abovementioned embodiments may be implemented by virtue of a flow of a computer program, the computer program may be stored in a computer-readable storage medium, the computer program is executed on a corresponding hardware platform (for example, a system, equipment, a device and an apparatus), and during execution, one or combination of the steps of the method embodiments is included.
Alternatively, all or part of the steps of the abovementioned embodiments may also be implemented by virtue of an integrated circuit, these steps may form multiple integrated circuit modules respectively, or multiple modules or steps therein form a single integrated circuit module for implementation.
The devices/function modules/function units in the abovementioned embodiments may be implemented by adopting a universal computing device, and they may be concentrated on a single computing device, and may also be distributed on a network formed by multiple computing devices.
When being implemented in form of software function module and sold or used as independent products, the devices/function modules/function units in the abovementioned embodiments may be stored in a computer-readable storage medium. The abovementioned computer-readable storage medium may be a read-only memory, a magnetic disk, an optical disk or the like.
INDUSTRIAL APPLICABILITY
Disclosed are a method and apparatus for implementing a service function chain. The method is applied to a node on a service function chain. The method comprises: packaging service function chain information in an IPv6 extension header of an IPv6 message; transmitting the IPv6 message according to the service function chain information; after the IPv6 message carrying the service function chain information is received, parsing the service function chain information; and acquiring an IPv6 address of a next hop node on a service function path as a destination address, and transmitting the IPv6 message to the destination address.
Contents6
9 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US11405431B2 | Cited by | United States of America | Applicant |
| US11075842B2 | Cited by | United States of America | Applicant |
| US10949244B2 | Cited by | United States of America | Applicant |
| US11283717B2 | Cited by | United States of America | Applicant |
| US11467861B2 | Cited by | United States of America | Search report |
| US11321113B2 | Cited by | United States of America | Applicant |
| US11038782B2 | Cited by | United States of America | Applicant |
| US11301281B2 | Cited by | United States of America | Applicant |
| US11245617B1 | Cited by | United States of America | Search report |
| US11360796B2 | Cited by | United States of America | Search report |
| US11296930B2 | Cited by | United States of America | Applicant |
| US11074097B2 | Cited by | United States of America | Applicant |
| US11294703B2 | Cited by | United States of America | Applicant |
| US11086654B2 | Cited by | United States of America | Applicant |
| US11025545B2 | Cited by | United States of America | Search report |
| US11153406B2 | Cited by | United States of America | Applicant |
| US11223494B2 | Cited by | United States of America | Applicant |
| US11140218B2 | Cited by | United States of America | Applicant |
| CN112565044A | Cited by | China | Search report |
| US11558341B2 | Cited by | United States of America | Applicant |
| US11119804B2 | Cited by | United States of America | Applicant |
| US11354148B2 | Cited by | United States of America | Applicant |
| US10944673B2 | Cited by | United States of America | Applicant |
| US10659350B2 | Cited by | United States of America | Search report |
| US11528219B2 | Cited by | United States of America | Applicant |
| US10454822B2 | Cited by | United States of America | Search report |
| US11249784B2 | Cited by | United States of America | Applicant |
| US11277331B2 | Cited by | United States of America | Applicant |
| US11595250B2 | Cited by | United States of America | Applicant |
| US11611625B2 | Cited by | United States of America | Applicant |
| US10972391B2 | Cited by | United States of America | Search report |
| US11265187B2 | Cited by | United States of America | Applicant |
| US11194610B2 | Cited by | United States of America | Applicant |
| US11095546B2 | Cited by | United States of America | Search report |
| CN112751768A | Cited by | China | Search report |
| US11438267B2 | Cited by | United States of America | Applicant |
| WO2021089052A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US11036538B2 | Cited by | United States of America | Applicant |
| US11288088B2 | Cited by | United States of America | Applicant |
| US11604666B2 | Cited by | United States of America | Applicant |
| US11075839B2 | Cited by | United States of America | Search report |
| US10929171B2 | Cited by | United States of America | Applicant |
| US2021044502A1 | Cited by | United States of America | Search report |
| US2019140950A1 | Cited by | United States of America | Search report |
| US11003482B2 | Cited by | United States of America | Search report |
| US11012420B2 | Cited by | United States of America | Applicant |
| US11438257B2 | Cited by | United States of America | Applicant |
| US11609781B2 | Cited by | United States of America | Applicant |
| US11496606B2 | Cited by | United States of America | Applicant |
| US11042397B2 | Cited by | United States of America | Applicant |
| CN113691448A | Cited by | China | Search report |
| CN111200559A | Cited by | China | Search report |
| US11368387B2 | Cited by | United States of America | Applicant |
| US11412071B2 | Cited by | United States of America | Applicant |
| US11212356B2 | Cited by | United States of America | Applicant |
| US11397604B2 | Cited by | United States of America | Applicant |
7 priority claims, no other members on record
Priority claims7
| Document | Office | Kind | Date |
|---|---|---|---|
| 201510383483 | China | A | |
| 2015103834832 | China | – | |
| 2016074458 | China | W | |
| 2015103834832 | – | – | – |
| CN20151383483 | – | – | – |
| PCTCN2016074458 | – | – | – |
| WO2016CN74458 | – | – | – |
51 transactions on the USPTO file
Abandoned after 1 non-final rejection.
- Non-final rejections
- 1
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | |
|---|---|
| Email Notification | |
| Mail Abandonment for Failure to Respond to Office ActionAbandoned | |
| Aband. for Failure to Respond to O. A. | |
| Electronic Review | |
| Email Notification | |
| Email Notification | |
| Email Notification | |
| Notice of DO/EO Acceptance Mailed | |
| Mail Pre-Exam Notice | |
| Filing Receipt - Updated | |
| Application Return from OIPE | |
| Application Return TO OIPE | |
| Electronic Review | |
| Email Notification | |
| Mail Non-Final RejectionNon-final rejection | |
| Non-Final RejectionNon-final rejection | |
| Information Disclosure Statement considered | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Email Notification | |
| Application ready for PDX access by participating foreign offices | |
| PG-Pub Issue Notification | |
| Email Notification | |
| Change in Power of Attorney (May Include Associate POA) | |
| Correspondence Address Change | |
| Correspondence Address Change | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Case Docketed to Examiner in GAU | |
| Application Is Now Complete | |
| Application Dispatched from OIPE | |
| Pre-Exam Office Action Withdrawn | |
| Email Notification | |
| Email Notification | |
| Notice of DO/EO Acceptance Mailed | |
| Filing Receipt | |
| Sent to Classification Contractor | |
| FITF set to YES - revise initial setting | |
| 371 Completion Date | |
| Patent Term Adjustment - Ready for Examination | |
| Additional Application Filing Fees | |
| Translation of the international application into English | |
| Copy of the International Application | |
| Request for Foreign Priority (Priority Papers May Be Included) | |
| PTO/SB/69-Authorize EPO Access to Search Results | |
| Applicants have given acceptable permission for participating foreign | |
| Cleared by OIPE CSR | |
| Entity status set to undiscounted (initial default setting or status change) | |
| Initial Exam Team nn |
9 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Information on status: application discontinuationSTCB | STCB | |
| Information on status: application discontinuationSTCB | STCB | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 20180198705
- Publication, DOCDB
- 2018198705
- Publication, EPODOC
- US2018198705
- Application
- 15740345
- Application, DOCDB
- 201615740345
- Application, EPODOC
- US201615740345
Titles
- English
- Method and apparatus for implementing service function chain
Classification
- CPC, 10
- H04L45/38
- H04L45/74
- H04L45/50
- H04L45/306
- H04L61/6059
- H04L45/64
- H04L12/4633
- H04L45/741
- H04L41/5041
- H04L2212/00
- IPC, 4
- H04L12 721
- H04L12 723
- H04L12 715
- H04L12 46
- USPC, 1
- 001001000