NDN (Named Data Networking) mobile support method based on protocol non-perceptual forwarding

Abstract

The invention discloses an NDN mobile support method based on protocol non-perception forwarding, and relates to the technical field of network mobile support. The invention aims to solve the problem that NDN mobile support cannot be realized on the POF at present. The method comprises the steps that a controller monitors an online event of a POF switch, and when the POF switch is online, an initial flow table rule is issued; the NDN message is acquired from the local NFD, a front header is added to the NDN message, and the NDN message with the front header is sent to the POF switch; a flow table assembly line on the POF switch matches and forwards the NDN message with the front header according to a flow table rule; and acquiring the NDN message with the NDN front header from the switch POF, deleting the NDN front header, and sending the NDN message to the local NFD. The method is used for realizing mobile support of the NDN in the POF.

Description

Technical Field

[0001] The present invention relates to the field of network mobility support technology, and in particular to an NDN mobility support method based on protocol-unaware forwarding. Background Art

[0002] Software Defined Network (SDN) is a new network architecture that decouples the control plane from the forwarding plane and unifies the control plane into a programmable controller, so that the configuration and expansion of the network can be defined by the software on the controller, which has higher flexibility. POF is an improved version of OpenFlow, the current mainstream SDN implementation technology. This technology implements a set of protocol-independent data plane instruction sets and defines the corresponding southbound protocol, so that the forwarding work of the data plane is independent of the specific network protocol, giving the data plane programmability, thereby supporting the forwarding of new network protocol data. Named Data Networking (NDN) is a data-centric stateful network protocol. The message of this protocol uses variable-length TLV encoding, and the offset position and length of the name field required for routing in the message are not fixed. At the same time, NDN requires the forwarder to maintain stateful structures such as the pending interest table (PIT) and the forwarding information base (FIB) during the forwarding process. NDN naturally supports the mobility of data requesters (consumers), while the mobility of data owners (producers) requires additional mechanism support. After a consumer moves, it only needs to resend the request to obtain data at the new location, while after a producer moves, an additional mechanism is needed to let all nodes in the network know its new location so that requests can be forwarded to its new location. Therefore, implementing NDN mobile support on POF is a research focus in this field.

[0003] At present, there are the following difficulties in implementing NDN mobile support on POF: First, existing SDN technologies such as POF only support protocols with fixed field structures and do not have the ability to process variable-length TLV encoding. Second, existing SDN technologies such as POF do not support the maintenance of state information during forwarding. Third, existing SDN technologies such as POF rely on the central controller to issue forwarding rules. The central controller has a high latency and cannot quickly update the forwarding rules, resulting in long latency and more packet loss after the producer moves. Therefore, NDN mobile support cannot be implemented on POF at present. Summary of the invention

[0004] The purpose of the present invention is to solve the problem that NDN mobile support cannot be implemented on POF at present, and proposes an NDN mobile support method based on protocol-unaware forwarding.

[0005] An NDN mobile support method based on protocol-unaware forwarding, comprising:

[0006] Step 1: The controller monitors the POF switch online event. When the POF switch is online, the initial flow table rules are issued;

[0007] Step 2: Obtain the NDN message from the local NFD, add a prefix header to the NDN message, and send the NDN message with the prefix header to the POF switch;

[0008] Step 3: The flow table pipeline on the POF switch matches and forwards the NDN message with the prefix header according to the flow table rules;

[0009] Step 4: Obtain the NDN message with the NDN header from the switch POF, delete the NDN header, and send the NDN message to the local NFD.

[0010] Furthermore, the step 2 of adding a preamble to the NDN message is specifically as follows:

[0011] First, obtain the NDN message from the local NFD and add a blank NDN header structure before the NDN message;

[0012] The NDN front-end header structure includes: a packet type field type, a packet inbound port field packet_in_port, a packet outbound port field out_port, and several name summary fields name_hash;

[0013] Then, set the type field in the NDN header to UNPROCESSED;

[0014] Among them, UNPROCESSED indicates the message that has not been processed by the NDN state maintenance module in the POF switch;

[0015] Then, extract the name from the NDN message, split it into name components, calculate the hash value of each name component, and fill it into several name_hash fields of the NDN header in sequence;

[0016] Then, the field values ​​of the packet_in_port field and the packet_out_port field in the NDN header are set to 0;

[0017] Finally, the value of the type field in the Ethernet frame header of the NDN message is set to 0x8625.

[0018] Furthermore, the message type field type value includes: UNPROCESSED, INTEREST, DATA and CONTROL_APPLY;

[0019] Among them, INTEREST represents the NDN interest packet processed by the NDN state maintenance module; DATA represents the NDN data packet processed by the NDN state maintenance module; CONTROL_APPLY represents the control message.

[0020] Furthermore, the flow table pipeline on the POF switch in step 3 matches and forwards the NDN message with the pre-header according to the flow table rule, specifically:

[0021] Step 31: The NDN message with the NDN front header enters the POF switch, and determines whether the NDN message is an NDN modal message. If so, the message entry port field in the NDN front header is set to the port where the NDN message is received, and then step 32 is executed; otherwise, the message is discarded and the process ends;

[0022] Step 32: Match the type field in the NDN header of the NDN message. If the value of the type field is INTEREST and the out_port field is 0xffff, execute step 33; otherwise, forward the NDN message according to the preset rule;

[0023] Step 33: Use several name summary fields in the NDN front header of the NDN message to match the preset value. If the several name summary fields in the NDN front header of the NDN message are the same as the preset value, set the message type field type to UNPROCESSED, and forward the NDN message according to the preset port.

[0024] Furthermore, the step 31 of determining whether the NDN message is an NDN modal message is specifically as follows:

[0025] The method of judging whether the NDN message is an NDN modal message is specifically as follows: judging whether the value of the type field in the Ethernet frame header of the NDN message is 0x8625, which indicates that the NDN message is an NDN modal message; otherwise, it indicates that the NDN message is not an NDN modal message.

[0026] Furthermore, in step 32, the type field in the NDN front header of the NDN message is matched. If the value of the type field is INTEREST and the out_port field is 0xffff, step 33 is executed; otherwise, the NDN message is forwarded according to the preset rules, which are specifically:

[0027] a. If the value of the type field is UNPROCESSED, the current NDN message is forwarded to the NDN state maintenance module on the current POF switch;

[0028] b. If the value of the type field is INTEREST and the out_port field is 0xffff, execute step 33;

[0029] c. If the value of the type field is INTEREST and the out_port field is 0x0000-0xfffe, set the type field in the NDN header to UNPROCESSED, and then forward the NDN message according to the port indicated by the out_port field in the NDN header;

[0030] d. If the value of the type field is DATA, set the type field in the NDN header to UNPROCESSED, and then forward the current message according to the port indicated by the out_port field in the NDN header;

[0031] e. If the value of the type field is CONTROL_APPLY, the CONTROL_APPLY message is reported to the controller.

[0032] Furthermore, the NDN state maintenance module on the POF switch has the following specific processing steps:

[0033] A1. Parse the NDN message with NDN header.

[0034] If the message type field in the NDN header is UNPROCESSED, the type and name of the NDN message are further obtained. If the message type is INTEREST, the current NDN message is recorded as an INTEREST packet, and then A2 is executed; if the NDN message type is DATA, the NDN message is recorded as a DATA packet, and then A6 is executed;

[0035] If the message type field in the NDN front header is CONTROL_APPLY, execute A10;

[0036] A2, check whether there is a DATA packet corresponding to the current INTEREST packet in CS, if so, execute A11; otherwise, execute A3;

[0037] A3. Check whether there is an entry corresponding to the current INTEREST packet in the PIT. If so, add the port corresponding to packet_in_port in the NDN header to the suspended interface set of the entry corresponding to the current INTEREST packet and go to step A12; otherwise, go to A4.

[0038] A4. Add an entry corresponding to the INTEREST packet to the PIT, add the port corresponding to the packet_in_port in the preamble header to the suspended interface set corresponding to the name of the INTEREST packet, and proceed to execute A5.

[0039] A5. Search the FIB for the name of the current INTEREST packet. If it does not exist, execute A13. If it does exist, execute A14.

[0040] A6, store the current DATA packet to CS, and then execute A7;

[0041] A7, check whether there is an entry corresponding to the current DATA packet in PIT, if not, go to A12; otherwise, go to A8;

[0042] A8, determine whether the DATA packet is a mobile support message, if it is, go to A9; otherwise, go to A15;

[0043] A9. Remove the mobility support tag in the name of the mobility support message to obtain the mobility prefix, extract the validity period of the mobility support message, and extract the IINTEREST packet entry port corresponding to the DATA packet in the PIT, and insert the mobility prefix, the mobility support message validity period and the IINTEREST packet entry port corresponding to the DATA packet into the FIB;

[0044] If the outgoing port indicated by the mobility support message is different from the existing port of the same name item in the FIB, then all interest packets with the name prefix of the mobility prefix in the PIT are taken out, the out_port in the NDN front header is set to the new port indicated by the mobility support message, and added to the set of messages to be sent; at the same time, a CONTROL_APPLY message is generated and added to the set of messages to be sent, and the process goes to A15; if the outgoing port indicated by the mobility support message is the same as the existing port of the same name item in the FIB, then a CONTROL_APPLY message is directly generated and added to the set of messages to be sent, and the process goes to A15;

[0045] A10. According to the name of CONTROL_APPLY, the table entry corresponding to the name of CONTROL_APPLY is searched in the FIB and deleted, and then the process ends.

[0046] A11, discard the original DATA packet and extract the DATA packet with the same name from CS, use the DATA packet with the same name extracted from CS to fill the fields in the NDN front header, and enter A16;

[0047] A12, discard the original message and end the process;

[0048] A13, set the type field in the NDN header of the message to INTEREST, set the out_port field in the NDN header of the message to 0xffff, and go to A16;

[0049] A14, set the type field in the NDN header of the message to INTEREST, set the out_port field in the NDN header of the message to the forwarding exit in the corresponding entry in the FIB, and proceed to A16;

[0050] A15, set the type field in the NDN header of the message to DATA; set the out_port field to the forwarding exit in the entry corresponding to the DATA packet in the PIT, and proceed to A16;

[0051] A16. If the previous NDN modal message has been discarded, all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 2. If the previous NDN modal message has not been discarded, the updated NDN modal message and all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 3.

[0052] Furthermore, the A11 uses the DATA packet with the same name taken out from the CS to fill the fields in the NDN front header, specifically:

[0053] The type field is set to DATA; the out_port field is set to the interface corresponding to the packet_in_port field of the DATA packet with the same name taken out from CS, and packet_in_port is set to 0;

[0054] The name_hash field is set as follows:

[0055] Extract the name from the DATA packet with the same name, split it into name components, calculate the hash value of each name component, and fill them into the name_hash field of the NDN prefix header of the DATA packet with the same name in sequence.

[0056] Further, the determination of whether the DATA packet is a mobile support message is specifically as follows:

[0057] Extract the name component of the DATA packet, and search for the mobile support tag "32=KITE" in the name component of the DATA packet. If there is a mobile support tag "32=KITE", it means that the current DATA packet is a mobile support message; otherwise, it means that the current DATA packet is not a mobile support message.

[0058] Furthermore, if the value of the type field is CONTROL_APPLY, the CONTROL_APPLY message is reported to the controller, specifically:

[0059] a1. Parse the control message and extract several name hash fields and outgoing port fields in the NDN front header;

[0060] a2. Extract the validity period and timestamp of the CONTROL_APPLY message and calculate the remaining validity period ttl of the forwarding rule;

[0061] a3. Generate a flow table rule that matches the name hash field value extracted in a2 and has a remaining validity period of ttl, and send the rule to the switch that submitted PacketIn.

[0062] a4. Instruct the POF switch to send the CONTROL_APPLY message to the NDN state maintenance module.

[0063] The beneficial effects of the present invention are:

[0064] The present invention implements NDN producer mobility support in a network where POF switches and ordinary network nodes are mixed, allowing switches and controllers in the POF architecture to work together so that the network can support the mobility of NDN producers. The present invention designs a pipeline flow table to match messages, uses messages to match flow tables in sequence, and sets and forwards messages according to the rules in the flow table, so that NDN mobility support can be implemented on POF. At the same time, the present invention implements the FIB table and interest packet retransmission on the NDN state maintenance module, reduces the delay experienced between the producer's movement and the receipt of a new request, and reduces the packet loss rate during the producer's movement. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 This is a control message structure diagram. DETAILED DESCRIPTION

[0066] Specific implementation method 1: The specific process of this implementation method is an NDN mobile support method based on protocol-unaware forwarding:

[0067] Step 1: The controller monitors the POF switch online event. When the POF switch is online, the initial flow table rules are issued;

[0068] Step 2: Get the NDN message from the local NFD, add a header to the NDN message, and send the NDN message with the header to the POF switch:

[0069] First, obtain the NDN message from the local NFD and add a blank NDN header structure before the NDN message;

[0070] The NDN front-end header structure includes: a message type field (type), a message inbound port field (packet_in_port), a message outbound port field (out_port), and several name summary fields (name_hash);

[0071] The message type field (type) indicates the type of the NDN or control message being carried. NDN messages are divided into two types: interest packets and data packets. The establishment of the forwarding rules of the mobile support mechanism requires the switch to pass relevant information to the controller so that the controller can issue flow table rules. The switch communicates with the controller by generating special messages, called control messages. The values ​​of the message type field (type) include:

[0072] UNPROCESSED: Messages not processed by the NDN state maintenance module;

[0073] INTEREST: NDN interest packet processed by the NDN state maintenance module;

[0074] DATA: NDN data packet processed by the NDN state maintenance module;

[0075] CONTROL_APPLY: Control message generated by the NDN maintenance state module in the mobility support mechanism and submitted to the controller.

[0076] This field is represented by a one-byte length, and the four types are encoded in sequence as 0, 1, 2, and 3.

[0077] It should be noted that the NDN state maintenance module is a processing module in the switch;

[0078] The packet entry port field (packet_in_port) indicates the port number of the switch through which the packet enters. The POF switch uses 2 bytes to encode the port number, and the length of this field is also 2 bytes, which is consistent with the port value of the switch. After the switch receives a message from other forwarding nodes (ordinary networks), it sets the value of this field to the port number of the received message. This field is used to maintain the state information of NDN. The switch should store the entry port of the interest packet after receiving the interest packet, and forward the data packet to this port after receiving the corresponding data packet.

[0079] The message outgoing port field (out_port) indicates the port from which the switch should send the message. When a data packet arrives, if the switch has received the corresponding interest packet, it will set this field according to the interest packet arrival port in the NDN status information to indicate the forwarding of the data packet. If the forwarding rule established by the mobile support mechanism on the switch can determine the outgoing port of the interest packet, then the forwarding of the relevant interest packet will also be indicated through this field. The length of this field is 2 bytes, which is consistent with the port encoding of the POF switch.

[0080] The several name summary fields enable the forwarding rules of NDN to be expressed as flow table matching rules of SDN. All data in NDN is named, and the request (interest packet) contains the name of the requested data. The forwarding node determines the forwarding of the interest packet according to the name matching forwarding information. The values ​​of the several name summary fields are specifically as follows: first, each component of the NDN name is split out, and each name component is mapped to a one-byte length through a hash algorithm, and then filled into each name summary field in turn. In order to reduce conflicts, the length or number of the name summary fields can be increased, which can be set specifically according to actual network requirements.

[0081] Then, the type field in the NDN header is set to UNPROCESSED; the name is extracted from the NDN message, split into name components, and the hash value of each name component is calculated and filled into several name_hash fields in the NDN header in sequence; the values ​​of other fields in the header are set to 0; the value of the type field in the Ethernet frame header of the message is set to 0x8625;

[0082] Finally, the NDN message with the NDN prefix header is sent from the Ethernet connected to the POF switch to the POF switch;

[0083] In this step, in order to allow NDN messages to flow transparently in a network composed of ordinary network nodes and POF switches, NDN header processing is implemented. The NDN header processing process runs on the ordinary network forwarding node directly connected to the POF switch, which is responsible for adding and deleting the NDN header. The module running the NDN header processing method monitors the port of the local NFD and the Ethernet card connected to the POF switch to perform message conversion in both directions.

[0084] Step 3: The flow table pipeline on the POF switch matches and forwards the NDN message with the pre-header according to the flow table rules, specifically:

[0085] Step 31: The NDN message with the NDN header enters the POF switch, and the NDN message is matched with the Ethernet distribution table Table0 to determine whether the current message is an NDN modal message. If so, the entry interface of the NDN message in the NDN header is set to the port where the message is received, and then step 32 is executed; otherwise, the process ends and the message is discarded;

[0086] The Ethernet distribution table Table0 is used to identify NDN packets and set the entry interface of the packets. This table is the first flow table matched after the packet enters the switch, and is responsible for the distribution of the modality. If the Ethernet type field of the packet has a specific value, it jumps to the flow table related to the NDN modality for further processing.

[0087] Table0

[0088]

[0089] Step 32: Use the type field in the NDN header of the NDN message to match the message type in the state distribution table 1:

[0090] a. If the value of the type field is UNPROCESSED, forward the current NDN message to the NDN state maintenance module on the same POF switch;

[0091] b. If the value of the type field is INTEREST and the out_port field is 0xffff, execute step 33;

[0092] c. If the value of the type field is INTEREST and the out_port field is 0x0000-0xfffe, set the type field in the NDN header to UNPROCESSED, and then forward the current message according to the port indicated by the out_port field in the NDN header;

[0093] If the current message is forwarded to the switch, re-execute step 3; if the current message is forwarded to other network nodes, execute step 4;

[0094] d. If the value of the type field is DATA, set the type field in the NDN header to UNPROCESSED, and then forward the current message according to the port indicated by the out_port field in the NDN header;

[0095] e. If the value of the type field is CONTROL_APPLY, the CONTROL_APPLY message is reported to the controller and the process ends;

[0096] Report the CONTROL_APPLY message to the controller. The specific processing flow of the controller is as follows:

[0097] a1. Parse the control message and extract several name hash fields and outgoing port fields in the NDN front header;

[0098] a2. Extract the validity period and timestamp in the CONTROL_APPLY message and calculate the remaining validity period ttl of the forwarding rule;

[0099] a3. Generate a flow table rule that matches the name hash field value extracted by a2 and has a remaining validity period of ttl, and send the rule to the switch that submitted PacketIn to update Table2.

[0100] a4. Instruct the POF switch to send the CONTROL_APPLY message to the NDN state maintenance module.

[0101] The state distribution table Table1 determines whether to forward or jump to other flow tables for further matching based on the different values ​​of the type and field.

[0102] Table 1

[0103]

[0104] Step 33: Use several name summary fields in the NDN front header of the NDN message to match the preset name_hash field in the forwarding information table table2. If a match is found, set the type field in the NDN front header to UNPROCESSED, and then forward the message according to the port indicated by the corresponding table entry in table2, and the process ends; otherwise, the process ends directly.

[0105] The forwarding information table Table2 is used to store NDN forwarding rules. This table matches several name summary fields. The default table entries are set at startup.

[0106] Table 2

[0107]

[0108] In this step, the flow table pipeline on the POF switch matches and decides how to forward the message according to the flow table rules. There are several flow tables on the POF switch. After the message enters, it first matches the flow table numbered 0, and performs corresponding actions according to the rules that successfully match in the flow table. The actions may include modifying the message, jumping to other flow table matches, forwarding the message according to a certain port, discarding the message, reporting to the controller, etc.

[0109] Step 4: Obtain the NDN message with the NDN header from the switch POF, delete the NDN header, and send the NDN message to the local NFD.

[0110] Specific implementation method 2: The specific processing flow of the status maintenance module on the POF switch is as follows:

[0111] A1. Parse the NDN message with NDN header.

[0112] If the message type field in the NDN header is UNPROCESSED, the type and name of the NDN message are further obtained. If the message type is INTEREST, the current NDN message is recorded as an INTEREST packet, and then A2 is executed; if the NDN message type is DATA, the NDN message is recorded as a DATA packet, and then A6 is executed;

[0113] If the message type field in the NDN front header is CONTROL_APPLY, execute A10;

[0114] A2. Check whether there is a Data package corresponding to the current Intersset package in CS. If so, execute A11; otherwise, execute A3;

[0115] A3. Check whether there is an entry corresponding to the current Interest packet in the PIT. If so, add the port corresponding to packet_in_port in the NDN header to the suspended interface set of the entry corresponding to the current Interest packet and go to step A12; otherwise, go to step A4.

[0116] A4. Add the entry corresponding to the Interest packet to the PIT, add the port corresponding to the packet_in_port in the front header to the suspended interface set corresponding to the name of the Interest packet, and proceed to execute A5;

[0117] A5. Search the name of the current Interest packet in the FIB of the NDN state maintenance module. If the name does not exist, execute A13. If the name does exist, execute A14.

[0118] A6. Store the current Data package in CS;

[0119] A7, check whether there is an entry corresponding to the current Data package in the PIT, if not, go to A12; otherwise, go to A8;

[0120] A8, determine whether Data is a mobile support message, if yes, go to A9; otherwise, go to A15;

[0121] The specific steps of determining whether Data is a mobile support message are:

[0122] Extract the name component of the DATA packet, and search for the mobility support tag "32=KITE" in the name component. If there is such a mobility support tag, it indicates that it is a mobility support message; otherwise, it indicates that the current DATA packet is not a mobility support message;

[0123] A9. Remove the mobility support tag from the name of the mobility support message to obtain the mobility prefix, extract the prefix of the mobility support message (the remaining part of the name of the mobility support message after removing the mobility support tag), the validity period of the mobility support message, and extract the corresponding Interest entry port in the PIT, and insert the mobility support message and validity period information into the FIB;

[0124] If the outgoing port indicated by the mobility support message (the interest entry port obtained in the PIT) is different from the existing port of the same-named item in the FIB, then all interest packets with the name prefix of the mobility prefix in the PIT are taken out, and the out_port in the NDN front header is set to the new port indicated by the above mobility support message, and added to the set of messages to be sent; at the same time, a CONTROL_APPLY message is generated and added to the set of messages to be sent, and enter A15; if the outgoing port indicated by the mobility support message is the same as the existing port of the same-named item in the FIB, a CONTROL_APPLY message is directly generated and added to the set of messages to be sent, and enter A15;

[0125] The CONTROL_APPLY message includes: Ethernet frame header, NDN header, validity period, and timestamp;

[0126] A10. According to the name of CONTROL_APPLY, the table entry corresponding to the name of CONTROL_APPLY is searched in the FIB and deleted, and then the process ends.

[0127] A11. Extract the packet_in_port field of the INTEREST packet (the INTEREST packet that hits the CS) and discard the INTEREST packet. Take out the DATA packet with the same name as the INTEREST packet from the CS, and then fill in the fields in the NDN header of the DATA packet with the same name as the INTEREST packet. Enter A16:

[0128] The type field is set to DATA; the out_port field is set to the interface corresponding to the packet_in_port field of the INTEREST packet, and the packet_in_port field is 0;

[0129] The specific method for setting the name_hash field is:

[0130] Extract the name from the DATA packet with the same name as the INTEREST packet, split it into name components, calculate the hash value of each name component, and fill it into the name_hash field of the NDN header of the DATA packet with the same name as the INTEREST packet in sequence;

[0131] A12, (Interest packet hits PIT / Data packet does not hit PIT) discard the original message. End the process, that is, do not send any message;

[0132] A13, (the Interest packet does not hit the PIT and does not hit the FIB) Set the type field in the NDN front header of the original message to INTEREST, set the out_port field in the NDN front header of the original message to 0xffff, and go to A16;

[0133] A14, set the type field in the NDN header of the message to INTEREST, set the out_port field in the NDN header of the message to the forwarding exit in the corresponding entry in the FIB, and proceed to A16;

[0134] A15, set the type field in the NDN header of the message to DATA; set the out_port field to the forwarding exit in the entry corresponding to the DATA packet in the PIT, and proceed to A16;

[0135] A16. If the previous NDN modal message has been discarded, all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 2. If the previous NDN modal message has not been discarded, the updated NDN modal message and all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 3.

[0136] The NDN state maintenance module exchanges messages with the flow table pipeline on the same POF switch through shared memory. The flow table pipeline receives NDN modal messages. For messages from other forwarding nodes (type is UNPROCESSED), the flow table pipeline sets the packet_in_port field in the NDN header to the port where the message is received and sends it to the NDN state maintenance module.

[0137] After the NDN producer moves, it will exchange interest-data with the fixed point in the network through the mobile support message. In this data request, the forwarding node on the path where the message passes must set the routing rules to the mobile producer. The NDN state maintenance module identifies the mobile support data packet, extracts the relevant information and reports it to the controller, waiting for the controller to send the new forwarding rules to the flow table. The structure of the control message is as follows: Figure 1 shown.

[0138] If the NDN state maintenance module receives an interest packet requesting data from a mobile producer before the controller sends down the flow table, the NDN state maintenance module will search for a match in the FIB. If a match is found, the interest packet will be forwarded according to the port instructions stored in the FIB. After the controller sends down the flow table to the flow table pipeline of the switch, the NDN state maintenance module should clear the corresponding table entry in the FIB so that subsequent interest packets are matched and forwarded in the flow table. To achieve this feature, the controller will instruct the switch to send the control message back to the NDN state maintenance module after sending down the flow table. After receiving the message, the NDN state maintenance module will search for a match in the FIB. If a match is found, the entry will be deleted.

[0139] The interest packet retransmission mechanism is implemented in the NDN state maintenance module. At the intersection of the new forwarding path and the old forwarding path, the switch retransmits the pending interest packet after receiving the TD, which can reduce the number of packet losses caused by movement and reduce the time required to restore the service. If the new TD indicates a different forwarding port than the previous one, the NDN state maintenance module will take out the pending interest packets from the PIT and forward them to the new interface, thereby reducing the number of PIT timeouts, reducing packet losses and reducing the time required to restore the service.

[0140] Embodiment: In order to verify the beneficial effects of the present invention, the present invention carried out the following experiments:

[0141] The present invention uses a POF soft switch, and the switch process runs on a Linux host. Ordinary network forwarding nodes and end nodes use NFD to forward NDN messages. The controller uses ONOS and runs on a Linux host.

[0142] The pre-header processing module and NND state maintenance module in the present invention are implemented as C++ programs. As independent processes, the former runs on a common repeater directly connected to the POF switch, and the latter runs on the POF switch. The POF controller and switch are managed by ONOS. The controller program uses the JAVA interface provided by ONOS to be implemented as an ONOS App, and calls the southbound interface provided by ONOS to send the flow table to the POF switch.

[0143] The front-end processing module listens to the Ethernet card connected to the POF and the UDP interface connected to the local NFD through the socket, and handles the message conversion in both directions. The NDN state maintenance module communicates with the flow table pipeline of the POF switch through the shared memory interface provided by dpdk to exchange messages. The controller App and the POF switch communicate using the POF southbound interface protocol, which is implemented through the ONOS programming interface.

[0144] The present invention can support non-stuttering mobile video live broadcast applications in a network topology where POF switches and ordinary forwarding nodes are mixed, achieving performance indicators of switching delay (the time from the producer moving to receiving a new request) <100ms and packet loss rate <5%.

Claims

1. A NDN mobile support method based on protocol-aware forwarding, characterized in that The specific process of the method is: Step 1: The controller monitors the POF switch online event. When the POF switch is online, the initial flow table rules are issued; Step 2: Obtain the NDN message from the local NFD, add a prefix header to the NDN message, and send the NDN message with the prefix header to the POF switch; Step 3: The flow table pipeline on the POF switch matches and forwards the NDN message with the prefix header according to the flow table rules; Step 4: Obtain the NDN message with the NDN header from the switch POF, delete the NDN header, and send the NDN message to the local NFD.

2. According to claim 1, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: The step 2 of adding a preamble to the NDN message is as follows: First, obtain the NDN message from the local NFD and add a blank NDN header structure before the NDN message; The NDN front-end header structure includes: a packet type field type, a packet inbound port field packet_in_port, a packet outbound port field out_port, and several name summary fields name_hash; Then, set the type field in the NDN header to UNPROCESSED; Among them, UNPROCESSED indicates the message that has not been processed by the NDN state maintenance module in the POF switch; Then, extract the name from the NDN message, split it into name components, calculate the hash value of each name component, and fill it into several name_hash fields of the NDN header in sequence; Then, the field values ​​of the packet_in_port field and the packet_out_port field in the NDN header are set to 0; Finally, the value of the type field in the Ethernet frame header of the NDN message is set to 0x8625.

3. According to claim 2, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: The message type field type value includes: UNPROCESSED, INTEREST, DATA and CONTROL_APPLY; Among them, INTEREST represents the NDN interest packet processed by the NDN state maintenance module; DATA represents the NDN data packet processed by the NDN state maintenance module; CONTROL_APPLY represents the control message.

4. According to claim 3, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: The flow table pipeline on the POF switch in step 3 matches and forwards the NDN message with the pre-header according to the flow table rules, specifically: Step 31: The NDN message with the NDN front header enters the POF switch, and determines whether the NDN message is an NDN modal message. If so, the message entry port field in the NDN front header is set to the port where the NDN message is received, and then step 32 is executed; otherwise, the message is discarded and the process ends; Step 32: Match the type field in the NDN header of the NDN message. If the value of the type field is INTEREST and the out_port field is 0xffff, execute step 33; otherwise, forward the NDN message according to the preset rule; Step 33: Use several name summary fields in the NDN front header of the NDN message to match the preset value. If the several name summary fields in the NDN front header of the NDN message are the same as the preset value, set the message type field type to UNPROCESSED, and forward the NDN message according to the preset port.

5. According to claim 4, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: The step 31 of determining whether the NDN message is an NDN modal message is specifically as follows: The method of judging whether the NDN message is an NDN modal message is specifically as follows: judging whether the value of the type field in the Ethernet frame header of the NDN message is 0x8625, which indicates that the NDN message is an NDN modal message; otherwise, it indicates that the NDN message is not an NDN modal message.

6. According to claim 5, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: In step 32, the type field in the NDN header of the NDN message is matched. If the value of the type field is INTEREST and the out_port field is 0xffff, step 33 is executed; otherwise, the NDN message is forwarded according to the preset rules, which are as follows: a. If the value of the type field is UNPROCESSED, the current NDN message is forwarded to the NDN state maintenance module on the current POF switch; b. If the value of the type field is INTEREST and the out_port field is 0xffff, execute step 33; c. If the value of the type field is INTEREST and the out_port field is 0x0000-0xfffe, set the type field in the NDN header to UNPROCESSED, and then forward the NDN message according to the port indicated by the out_port field in the NDN header; d. If the value of the type field is DATA, set the type field in the NDN header to UNPROCESSED, and then forward the current message according to the port indicated by the out_port field in the NDN header; e. If the value of the type field is CONTROL_APPLY, the CONTROL_APPLY message is reported to the controller.

7. The NDN mobile support method based on protocol-unaware forwarding according to claim 6 is characterized in that: The NDN state maintenance module on the POF switch has the following specific processing steps: A1. Parse the NDN message with NDN header. If the message type field in the NDN header is UNPROCESSED, the type and name of the NDN message are further obtained. If the message type is INTEREST, the current NDN message is recorded as an INTEREST packet, and then A2 is executed; if the NDN message type is DATA, the NDN message is recorded as a DATA packet, and then A6 is executed; If the message type field in the NDN front header is CONTROL_APPLY, execute A10; A2, check whether there is a DATA packet corresponding to the current INTEREST packet in CS, if so, execute A11; otherwise, execute A3; A3. Check whether there is an entry corresponding to the current INTEREST packet in the PIT. If so, add the port corresponding to packet_in_port in the NDN header to the suspended interface set of the entry corresponding to the current INTEREST packet and go to step A12; otherwise, go to A4. A4. Add an entry corresponding to the INTEREST packet to the PIT, add the port corresponding to the packet_in_port in the preamble header to the suspended interface set corresponding to the name of the INTEREST packet, and proceed to execute A5. A5. Search the FIB for the name of the current INTEREST packet. If it does not exist, proceed to A13. If it exists, execute A14; A6, store the current DATA packet to CS, and then execute A7; A7, check whether there is an entry corresponding to the current DATA packet in PIT, if not, go to A12; otherwise, go to A8; A8, determine whether the DATA packet is a mobile support message, if it is, go to A9; otherwise, go to A15; A9. Remove the mobility support tag in the name of the mobility support message to obtain the mobility prefix, extract the validity period of the mobility support message, and extract the IINTEREST packet entry port corresponding to the DATA packet in the PIT, and insert the mobility prefix, the mobility support message validity period and the IINTEREST packet entry port corresponding to the DATA packet into the FIB; If the outgoing port indicated by the mobility support message is different from the existing port of the same name item in the FIB, then all interest packets with the name prefix of the mobility prefix in the PIT are taken out, the out_port in the NDN front header is set to the new port indicated by the mobility support message, and added to the set of messages to be sent; at the same time, a CONTROL_APPLY message is generated and added to the set of messages to be sent, and the process goes to A15; if the outgoing port indicated by the mobility support message is the same as the existing port of the same name item in the FIB, then a CONTROL_APPLY message is directly generated and added to the set of messages to be sent, and the process goes to A15; A10. According to the name of CONTROL_APPLY, the table entry corresponding to the name of CONTROL_APPLY is searched in the FIB and deleted, and then the process ends. A11, discard the original DATA packet and extract the DATA packet with the same name from CS, use the DATA packet with the same name extracted from CS to fill the fields in the NDN front header, and enter A16; A12, discard the original message and end the process; A13, set the type field in the NDN header of the message to INTEREST, set the out_port field in the NDN header of the message to 0xffff, and go to A16; A14, set the type field in the NDN header of the message to INTEREST, set the out_port field in the NDN header of the message to the forwarding exit in the corresponding entry in the FIB, and proceed to A16; A15, set the type field in the NDN header of the message to DATA; set the out_port field to the forwarding exit in the entry corresponding to the DATA packet in the PIT, and proceed to A16; A16. If the previous NDN modal message has been discarded, all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 2. If the previous NDN modal message has not been discarded, the updated NDN modal message and all messages in the message set to be sent are sent to the flow table pipeline of the same POF switch, and the process returns to step 3.

8. According to claim 7, a NDN mobile support method based on protocol-unaware forwarding is characterized in that: A11 uses the DATA packet with the same name taken out from CS to fill the fields in the NDN front header, specifically: The type field is set to DATA; the out_port field is set to the interface corresponding to the packet_in_port field of the DATA packet with the same name taken out from CS, and packet_in_port is set to 0; The name_hash field is set as follows: Extract the name from the DATA packet with the same name, split it into name components, calculate the hash value of each name component, and fill them into the name_hash field of the NDN prefix header of the DATA packet with the same name in sequence.

9. The NDN mobile support method based on protocol-unaware forwarding according to claim 8, characterized in that: The step of determining whether the DATA packet is a mobile support message is as follows: Extract the name component of the DATA packet, and search for the mobile support tag "32=KITE" in the name component of the DATA packet. If there is a mobile support tag "32=KITE", it means that the current DATA packet is a mobile support message; otherwise, it means that the current DATA packet is not a mobile support message.

10. The NDN mobile support method based on protocol-unaware forwarding according to claim 9, characterized in that: If the value of the type field is CONTROL_APPLY, the CONTROL_APPLY message is reported to the controller, specifically: a1. Parse the control message and extract several name hash fields and outgoing port fields in the NDN front header; a2. Extract the validity period and timestamp of the CONTROL_APPLY message and calculate the remaining validity period ttl of the forwarding rule; a3. Generate a flow table rule that matches the name hash field value extracted in a2 and has a remaining validity period of ttl, and send the rule to the switch that submitted PacketIn. a4. Instruct the POF switch to send the CONTROL_APPLY message to the NDN state maintenance module.

Images