In one embodiment, a method is provided. The method includes receiving a data packet via an ingress interface of the network device. The method also includes determining whether the data packet comprises an Internet Protocol version 4 (IPV4) or an Internet Protocol version 6 (IPV6) packet. The method further includes in response to determining that the packet comprises an IPV4 packet, identifying a first entry in an adjacency table. The first entry is associated with an address prefix. The address prefix is associated with first Internet Protocol (IP) address of the data packet. The first entry indicates a next hop for the data packet. The adjacency table comprises a second entry associated with the address prefix. The method further includes forwarding the packet to the next hop indicated by the first entry in the adjacency table, via an egress interface of the network device.

In one embodiment, a method is provided. The method includes receiving a data packet via an ingress interface of the network device. The method also includes determining whether the data packet comprises an Internet Protocol version 4 (IPV4) or an Internet Protocol version 6 (IPV6) packet. The method further includes in response to determining that the packet comprises an IPV4 packet, identifying a first entry in an adjacency table. The first entry is associated with an address prefix. The address prefix is associated with first Internet Protocol (IP) address of the data packet. The first entry indicates a next hop for the data packet. The adjacency table comprises a second entry associated with the address prefix. The method further includes forwarding the packet to the next hop indicated by the first entry in the adjacency table, via an egress interface of the network device.

Provided are a BIER packet forwarding method and apparatus, a device and a storage medium. The BIER packet forwarding method is applied to a packet sending node and includes: setting node information of a BIER forwarding neighboring node in a BIFT forwarding entry; in a case of determining according to the node information that the BIER forwarding neighboring node has a capability of processing a target packet format, encapsulating a BIER packet according to the target packet format; and sending an encapsulated BIER packet to the BIER forwarding neighboring node.

A packet forwarding method is disclosed. The method includes: After an edge node in a trusted domain receives an SRv6 packet whose destination address is a BSID, the edge node may verify the packet based on a BSID in the packet and a destination field in an SRH of the packet. If the packet passes the verification, the edge node forwards the packet. If the packet fails the verification, the edge node discards the packet. Not only a node outside the trusted domain is required to access the trusted domain by using the BSID, but also the packet entering the trusted domain needs to be verified with reference to the target field in the segment routing header.

A packet forwarding method is disclosed. The method includes: After an edge node in a trusted domain receives an SRv6 packet whose destination address is a BSID, the edge node may verify the packet based on a BSID in the packet and a destination field in an SRH of the packet. If the packet passes the verification, the edge node forwards the packet. If the packet fails the verification, the edge node discards the packet. Not only a node outside the trusted domain is required to access the trusted domain by using the BSID, but also the packet entering the trusted domain needs to be verified with reference to the target field in the segment routing header.

Embodiments of this application describe an in-situ flow detection-based packet processing method. After receiving a first packet encapsulated by using a first bearer protocol, a first node may obtain, based on the first packet, a second packet encapsulated by using a second bearer protocol. A first packet header of the first packet includes first in-situ flow detection information, and a packet header of the second packet also includes the first in-situ flow detection information. It can be learned that, when re-encapsulating the first packet by using the second bearer protocol, the first node does not remove the first in-situ flow detection information, but adds the first in-situ flow detection information to the packet encapsulated by using the second bearer protocol. Therefore, even if the first bearer protocol and the second bearer protocol are deployed in a detection domain, the first in-situ flow detection information is not removed due to re-encapsulation of the packet, and may be transmitted across the entire detection domain.

Methods and systems anchor hypertext transfer protocol (HTTP) level communication in an information-centric networking (ICN) network. Both content requests and responses to servers within the ICN network and to servers located outside the ICN network, in an IP network for example, are disclosed. Communication may be between two IP capable only devices at the HTTP level, one connected to an ICN network while the other one is connected either to an ICN or IP network. The disclosed namespace 200 enables IP based HTTP communication within the ICN network. An information-centric networking (ICN) network attachment point (NAP) or border gateway (BGW) may receive an HTTP request packet and encapsulate the received HTTP request packet. The ICN NAP/BGW may then forward the HTTP request packet towards the local ICN network servers. The HTTP request packet may be published to a named content identifier (CID) that may be determined through a hash function of a fully qualified domain name (FQDN). The ICN NAP may receive a HTTP response packet for a subscribed information item, which may be included in a named rCID. The named rCID may be determined through a hash function of a uniform resource locator (URL). Instead of using the hash of a URL and an FQDN directly, a separate scope identifier, which may be a root identifier, may be chosen for HTTP-over-ICN communication for the overall ICN namespace. The scope identifier may include a particular structure for the ICN namespace being built up. Using a root identifier may allow for separating HTTP-over-ICN communication from other ICN communication, for example, for operational or migration reasons. Under the root scope identifier, there may be two sub-scope identifiers, a first sub-scope identifier (I) for communication within the ICN network and a second sub-scope identifier (O) for communication to IP addresses outside the ICN network. The ICN may be based on the PURSUIT publish-subscribe architecture or on the Named Data Networking (NDN) project and the like.

Methods and systems are provided for latency-oriented router. An incoming packet is received on a first interface. The type of the incoming packet is determined. Upon the detection that the incoming packet belongs to latency-critical traffic, the incoming packet is duplicated into one or more copies. Subsequently, the duplicated copies are sent to a second interface in a delayed fashion where the duplicated copies are spread over a time period. The duplicated copies are received and processed at the second interface.

Methods and systems are provided for latency-oriented router. An incoming packet is received on a first interface. The type of the incoming packet is determined. Upon the detection that the incoming packet belongs to latency-critical traffic, the incoming packet is duplicated into one or more copies. Subsequently, the duplicated copies are sent to a second interface in a delayed fashion where the duplicated copies are spread over a time period. The duplicated copies are received and processed at the second interface.

A routing system can provide a Dynamic-Hybrid Forwarding Information Base (DHFIB). A control component of the routing system can build a routing table that includes routing information (e.g., prefixes, addresses, etc.) for use by a first routing component. The routing table can be ordered or ranked based on traffic information from the first routing component. Then, the control component can create the DHFIB from the routing table, wherein the DHFIB is a portion of the routing table and related to the first routing component. As such, the portion of the routing table selected for the DHFIB can be the set of prefixes in the routing table that represent the most frequently routed or most important prefixes in the routing table. Finally, the control component can forward the DHFIB to the first routing component to allow the routing component to route communications.