Abstract:
A device communicates with feature peers, associated with a network, to obtain information associated with the feature peers, and receives a customer packet that includes a feature header. The device also modifies, based on the feature peer information, current condition state signaling, and other information, the feature header to create a modified customer packet, and determines, based on the feature peer information, the current condition state signaling, and the other information, which of the feature peers support a feature associated with the modified customer packet. The device further selects, from the determined feature peers, a set of feature peers for the modified customer packet to traverse, and forwards, based on the modified feature header, the modified customer packet to one of the feature peers in the selected set of feature peers.

Description:
BACKGROUND 
       [0001]    Some networks (e.g., telecommunications networks, the Internet, etc.) provide packet and/or content forwarding services and/or features. Examples of such packet/content forwarding services/features include content-related services (e.g., voice, audio, and/or video transcoding; bridging; replication; etc.); security-related services (e.g., network-based firewalls and/or application layer gateways; intrusion detection, prevention, and/or mitigation; denial of service detection, prevention, and/or mitigation; etc.); flow, rate, and quality of service (QoS)-related services (e.g., metering; policing; shaping; scheduling; coordination with higher-level signaling, policy, and configuration; etc.); accounting-related services (e.g., usage cap metering, notification, and/or enforcement; billing; etc.); administrative-related services (e.g., selective packet set capture, replication, redirection, and/or blocking; packet inspection; etc.); etc. 
         [0002]    Such packet/content forwarding services/features may be managed via a “star” or “flower” network centered on a router (or feature switch). In the star/flower arrangement, traffic to/from a user (e.g., of a service or feature) is directed into a set of feature peers by the router/feature switch. Such an arrangement may require configuration of the router, use of tunnels, and load balancing, and may result in sub-optimal performance. 
         [0003]    In one exemplary star/flower arrangement, a network management system (NMS) provisions an access control list (ACL) (e.g., of an access router) to map customer packets to routing logic, and provisions a routing table (e.g., of the access router) to determine mapping of a feature chain to a sequence of tunnels associated with a server for each (set of) features. The NMS also provisions feature servers with tunnel and subscriber information consistent with the provisioning of the access router. The access router determines data network information (e.g., Internet protocol (IP) interior gateway protocol (IGP)/border gateway protocol (BGP), virtual private network (VPN) multiprotocol (MP)-BGP, Ethernet address resolution protocol (ARP), etc.), and receives a packet from a customer (e.g., from a device associated with the customer). The access router uses the ACL to determine that the packet includes subscribed to features and directs the packet to the routing table to determine a tunnel next hop associated with a server for a first features. The first feature server returns the packet to the access router. The access router then uses the routing table to sequence the packet through a chain of tunnels configured to reach each feature server in the chain, which then return the packets to the same access router, as configured by the NMS. Finally, the access router also uses the routing table to determine when the packet has exited from the last feature server in the chain, to decapsulate the packet from the tunnel, and to direct the packet to an original destination address. The access router then forwards the packet, via the data network, towards the destination address. A similar process occurs in the reverse direction for a packet received from the network (e.g., the Internet) that is destined for a particular subscriber. 
         [0004]    However, the star/flower arrangement is expensive because, although it requires no changes to the software and/or hardware of the access router, the routers and switches are traversed twice between each feature server and the access router that connects to a user. In the star/flower arrangement, there needs to be a tunnel for each feature server per feature chain since a tunnel identification (ID) determines a next feature server or exit to the data network. Furthermore, the star/flower arrangement can increase latency if the feature servers are not near the access router that connects to the user. The star/flower arrangement requires a static configuration, in the router, of tunnel IDs and next hops; is not resilient (e.g., load balancing across the feature servers requires reconfiguration); and makes it difficult to represent more complex feature topologies than a chain topology. 
         [0005]    Packet/content forwarding services/features may also be managed via a service header-based routing arrangement. In one exemplary service header-based routing arrangement, an access router registers with a service broker, and the service broker provisions an ACL (e.g., of the access router) to map customer packets to a service routing function (e.g., associated with the access router). The service broker provisions service nodes with service header, tunnel, network, and subscriber information consistent with provisioning of the service routing function for the access router in the network. The access router determines data network information (e.g., IP IGP/BGP, VPN MP-BGP, Ethernet ARP, etc.), and receives a packet from a customer (e.g., from a device associated with the customer). The access router uses the ACL to determine that the packet includes subscribed to services and directs the packet to the service routing function. The service routing function uses local configuration and packet information to determine a service header to be inserted, encapsulates this within a tunnel header, and forwards the packet to a first service node over the tunnel. The service node decapsulates the packet from the tunnel, reviews the service header and configured information from the service broker to determine an outgoing tunnel, and forwards the packet to the next service node. Eventually, the packet returns to the access router that originally received the packet (e.g., in the case where a service topology is a chain). The service routing function (e.g., of the access router) decapsulates the packet from the tunnel, examines the service header, and determines that the next step is forwarding. The access router then forwards the packet, via the data network, toward a destination address. A similar process occurs in the reverse direction for a packet received from the network (e.g., the Internet) that is destined for a particular subscriber. 
         [0006]    The star/flower arrangement and the service header-based routing arrangement require expensive changes to the software and/or hardware of the access router in order to implement the service header insertion and processing. The service header-based routing arrangement relies on a centralized service broker to determine, download, and monitor state, and to optimize and load balance service node level routing across what could grow to be a very large set of service nodes. Centralization may limit a convergence time and responsiveness to change associated with the arrangement. Furthermore, the service header-based routing arrangement requires fault detection and restoration performance to be determined by the centralized service broker, and may not be implemented across more than one service provider. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  is a diagram of an exemplary network in which systems and/or methods described herein may be implemented; 
           [0008]      FIG. 2  is a diagram of exemplary components of a device that may correspond to one of the devices of the network depicted in  FIG. 1 ; 
           [0009]      FIGS. 3A-3C  are diagrams of exemplary interactions among components of an exemplary portion of the network depicted in  FIG. 1 ; 
           [0010]      FIGS. 4A and 4B  are diagrams of exemplary interactions among components of another exemplary portion of the network depicted in  FIG. 1 ; and 
           [0011]      FIGS. 5-8  are flow charts of an exemplary process for modifying a peer-to-peer based feature network according to implementations described herein. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0012]    The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. 
         [0013]    Implementations described herein may include systems and/or methods that may modify a peer-to-peer based feature network based on changing conditions and/or session signaling. For example, in one implementation, a feature peer (e.g., a server that provides features and/or services, such as content-related services, security-related services, etc.) may communicate with other feature peers to obtain information associated with the other feature peers, which may or may not be associated with a received packet (e.g., from a user or customer) that includes a feature header. The feature peer may modify the feature header, based on the information associated with the other feature peers, to create a modified customer packet. The feature peer may determine, based on the feature peer information, which of the other feature peers can support a feature associated with the modified customer packet. The feature peer may select a set of the other feature peers, from the determined other feature peers, for the modified customer packet to traverse. The feature peer may forward, based on the modified feature header, the modified customer packet to one of the feature peers in the set of other feature peers. 
         [0014]    As used herein, the terms “user,” “customer,” and “subscriber,” are intended to be broadly interpreted to include a user device and/or a user application or a user of a user device and/or a user application. A user application may include any operating system software and/or application software that make use of features and may be executed by a user device. 
         [0015]      FIG. 1  is a diagram of an exemplary network  100  in which systems and/or methods described herein may be implemented. As illustrated, network  100  may include a user device (UD)  110 , an access router (AR)  120 , a network management system (NMS)  130 , feature peers (FPs)  150 - 1 , . . . ,  150 - 4  (referred to collectively as “feature peers  150 ” or singularly as “feature peer  150 ”), and an application network (AN) server  160  interconnected by a network  140 . Components of network  100  may interconnect via wired and/or wireless connections. Four feature peers  150  and a single user device  110 , access router  120 , NMS  130 , network  140 , and AN server  160  have been illustrated in  FIG. 1  for simplicity. In practice, there may be more user devices  110 , access routers  120 , NMSs  130 , networks  140 , feature peers  150 , and/or AN servers  160 . Also, in some instances, one or more of the components of network  100  may perform one or more functions described as being performed by another one or more of the components of network  100 . 
         [0016]    User device  110  may include a radiotelephone, a personal communications system (PCS) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a wireless telephone, a cellular telephone, a smart phone, a personal digital assistant (PDA) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a laptop computer (e.g., with a broadband air card), a personal computer, a landline telephone, or other types of computation or communication devices. In an exemplary implementation, user device  110  may include a device that is capable of accessing features and/or services (e.g., content-related services; security-related services; flow, rate, and QoS-related services; accounting-related services; administrative-related services; etc.) provided by the other components of network  100 . 
         [0017]    Access router  120  may include one or more data transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers data. In one exemplary implementation, access router  120  may enable user device  110  to access features and/or services (e.g., content-related services; security-related services; flow, rate, and QoS-related services; accounting-related services; administrative-related services; etc.) provided by feature peers  150 . 
         [0018]    NMS  130  may include one or more server devices, or other types of computation or communication devices, that gather, process, search, and/or provide information in a manner described herein. In an exemplary implementation, NMS  130  may monitor and administer a network, such as network  100 . 
         [0019]    Network  140  may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network, such as the Public Switched Telephone Network (PSTN), a cellular network, a Wi-Fi network, an intranet, a virtual private network (VPN), the Internet, an optical fiber (or fiber optic)-based network, or a combination of networks. In one exemplary implementation, network  140  may include a peer to peer (P2P)-based feature network that supports features and/or services provided by feature peers  150 . 
         [0020]    Feature peer  150  may include one or more server devices, or other types of computation or communication devices, that gather, process, search, and/or provide information in a manner described herein. In an exemplary implementation, feature peer  150  may communicate with other feature peers  150  to obtain information associated with the other feature peers  150 , and may receive a customer packet (e.g., from user device  110  and via access router  120 ) that includes a feature header. Feature peer  150  may modify the feature header, based on the information associated with the other feature peers  150 , to create a modified customer packet. Feature peer  150  may determine, based on the feature peer information, which of the other feature peers  150  can support a feature associated with the modified customer packet. Feature peer  150  may select a set of the other feature peers  150 , from the determined other feature peers  150 , for the modified customer packet to traverse. Feature peer  150  may forward, based on the modified feature header, the modified customer packet to one of feature peers  150  in the set of other feature peers  150 . Further details of feature peers  150  are provided below in connection with, for example,  FIGS. 3A-4B . 
         [0021]    AN server  160  may include one or more server devices, or other types of computation or communication devices, that gather, process, search, and/or provide information in a manner described herein. In an exemplary implementation, AN server  160  may communicate with feature peers  150 , and may perform (e.g., on feature peers  150 ) functions, such as topology mapping to minimize cost and/or achieve optimal performance, and load balancing to balance loads on feature peers  150 . 
         [0022]    Although  FIG. 1  shows exemplary components (e.g., devices) of network  100 , in other implementations, network  100  may contain fewer, different, differently arranged, or additional components than depicted in  FIG. 1 . 
         [0023]      FIG. 2  is an exemplary diagram of a device  200  that may correspond to one or more of user device  110 , access router  120 , NMS  130 , feature peers  150 , or AN server  160 . As illustrated, device  200  may include a bus  210 , a processing unit  220 , a main memory  230 , a read-only memory (ROM)  240 , a storage device  250 , an input device  260 , an output device  270 , and/or a communication interface  280 . Bus  210  may include a path that permits communication among the components of device  200 . 
         [0024]    Processing unit  220  may include one or more processors, microprocessors, or other types of processing units that may interpret and execute instructions. Main memory  230  may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing unit  220 . ROM  240  may include a ROM device or another type of static storage device that may store static information and/or instructions for use by processing unit  220 . Storage device  250  may include a magnetic and/or optical recording medium and its corresponding drive. 
         [0025]    Input device  260  may include a mechanism that permits an operator to input information to device  200 , such as a keyboard, a mouse, a pen, a microphone, voice recognition and/or biometric mechanisms, etc. Output device  270  may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface  280  may include any transceiver-like mechanism that enables device  200  to communicate with other devices and/or systems. For example, communication interface  280  may include mechanisms for communicating with another device or system via a network. 
         [0026]    As described herein, device  200  may perform certain operations in response to processing unit  220  executing software instructions contained in a computer-readable medium, such as main memory  230 . A computer-readable medium may be defined as a physical or logical memory device. A logical memory device may include memory space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into main memory  230  from another computer-readable medium, such as storage device  250 , or from another device via communication interface  280 . The software instructions contained in main memory  230  may cause processing unit  220  to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. In one example, the software instructions may include any operating system software and/or application software that make use of features. 
         [0027]    Although  FIG. 2  shows exemplary components of device  200 , in other implementations, device  200  may contain fewer, different, differently arranged, or additional components than depicted in  FIG. 2 . In still other implementations, one or more components of device  200  may perform one or more other tasks described as being performed by one or more other components of device  200 . 
         [0028]      FIGS. 3A-3C  are diagrams of exemplary interactions among components of an exemplary portion  300  of network  100 . As illustrated, exemplary network portion  300  may include user device  110 , access router  120 , NMS  130 , network  140 , feature peers  150 , and AN server  160 . User device  110 , access router  120 , NMS  130 , network  140 , feature peers  150 , and/or AN server  160  may include the features described above in connection with, for example,  FIGS. 1 and 2 . 
         [0029]    As further shown in  FIG. 3A , access router  120  may include an access control list (ACL) table  302 , an address forwarding lookup (AFL) table  304 , and a routing table  306 . In one exemplary implementation, ACL table  302 , AFL table  304 , and routing table  306  may be provided in one or more memory devices (e.g., main memory  230 , ROM  240 , and/or storage device  250 ) associated with access router  120 . 
         [0030]    ACL table  302  may include a table of entries that map an NMS-provisioned IP source address (SA) of a packet (e.g., received from user device  110 ) to a tunnel header associated with a tunnel on which the packet may be routed to a feature peer. In one example, ACL table  302  may include an IP SA field, a tunnel header field, and a variety of entries associated with the IP SA field and the tunnel header field. Further details of ACL table  302  are provided below in connection with, for example,  FIG. 4A . 
         [0031]    AFL table  304  may include a table of entries that map an IP destination address (DA) of a packet (e.g., received from network  140 ) with a next hop (e.g., device) to which the packet may be routed. In one example, AFL table  304  may include an IP DA field, a next hop field, and a variety of entries associated with the IP DA field and the next hop field. Further details of AFL table  304  are provided below in connection with, for example,  FIGS. 4A and 4B . 
         [0032]    Routing table  306  may include a table of entries that provide routing information for a packet received by access router  120  (e.g., from user device  110 ). In one example, routing table  306  may be configured by NMS  130  to forward a packet on specific tunnel (e.g., using a tunnel header) to a first feature peer (e.g., feature peer  150 - 1 ). In another example, routing table  306  may be used to automatically discover addresses and next hops of feature peers and to automatically populate AFL table  304 . 
         [0033]    As further shown in  FIG. 3A , NMS  130  may provide provisioning information  308  to ACL table  302 , AFL table  304 , and routing table  306 . Provisioning information  308  may include information that enables access router  120  to handle packets received from user device  110  and/or provided to user device  110 . In one example, provisioning information  308  may instruct ACL table  302  to map customer packets (e.g., received from an SA received from user device  110 ) to AFL table  304  using information obtained from routing table  306 . AFL table  304  and routing table  306  may include a mapping to a tunnel for a first feature peer  150  if the customer subscribes to a peer-to-peer based feature network forwarding service (e.g., provided by network  100 ). 
         [0034]    NMS  130  may provision feature peers  150  with feature information  310  and may provision a first feature peer (e.g., feature peer  150 - 1 ) with feature information  310  and subscriber information  312 . Feature information  310  may include feature software (e.g., software that enables feature peers  150  to provide features and/or services, such as content-related services; security-related services; flow, rate, and QoS-related services; accounting-related services; administrative-related services; etc.); a feature net representation (e.g., a graph of feature peers  150  through which a packet may be routed); registration information; authentication information; load balancing and backup feature peer information; etc. Subscriber information  312  may include information associated with subscribers to features and/or services (e.g., content-related services, security-related services, etc.) provided by network  100 . NMS  130  may periodically provide feature information  310  to feature peers  150  or may provide feature information  310  to feature peers  150  based on conditions (e.g., in response to a trigger) associated with network  140  and/or feature peers  150 . 
         [0035]    As further shown in  FIG. 3A , routing table  306  of access router  120  may retrieve network routing protocol information  313  from network  140 . Network information  313  may include IP IGP/BGP information, VPN MP-BGP information, Ethernet ARP information, etc. associated with network  140 . Routing table  306  may use network information  313  to automatically populate AFL table  304  with forwarding information. In this way, information about a change in network topology related to feature peers  150  (e.g., a routing metric, a routing preference, or a failure may be used to automatically update forwarding information). AN server  160  may provide mapping/balancing information  314  to feature peers  150 . Mapping/balancing information  314  may include information that provides topology mapping for feature peers  150  (e.g., to minimize cost and achieve optimal performance), and information that enables loads on feature peers  150  to be balanced so that one or more feature peers  150  do not become overloaded (e.g., with traffic). An alternative to communication with a logically centralized AN server  160  may include using pairs of feature servers to communicate load and active status amongst smaller sets of nodes to improve convergence time (e.g., using the procedure depicted in  FIG. 3B ). 
         [0036]    As shown in  FIG. 3B , feature peers  150  may communicate with each other to provide feature peer information  316  to other feature peers  150 . Feature peer information  316  may include identification information; load information; path information; active/inactive status information; session signaling (e.g., signaling message packets  318  communicated between other parties (e.g., a session initiation protocol (SIP) user agent and a SIP server) intercepted for processing by a feature peer, and/or signaling provided between feature peers  150  during provisioning of packet  318 ); policy information (e.g., information associated with policies, such as usage policies, bandwidth allocations, etc.); database information (e.g., information contained in databases of feature peers  150 , sizes of such databases, etc.); etc. associated with feature peers  150 ; and subscriber information (e.g., information associated with customers or subscribers to peer-to-peer based feature network forwarding). Feature peer information  316  may enable feature peers  150  to define a set of feature net logic (e.g., a set of feature peers  150 ) that may be dynamically determined and self correcting. In one exemplary implementation, feature peers  150  may communicate with each other using distributed hash tables (DHTs) to locate appropriate feature peers  150  based on a key (e.g., provided via feature peer information  316 ) that includes a feature peer ID, a subscriber ID range, feature information, a customer ID, IP source/destination addresses, etc. In another exemplary implementation, feature peers  150  may use P2P communication to provide event-driven (or periodic) updated subscriber and feature related information that need not be forwarded via a packet header. 
         [0037]    As further shown in  FIG. 3B , a packet  318  from a customer (e.g., user device  110 ) may be provided to access router  120  (e.g., to ACL table  302  of access router  120 ). Packet  318  may include an IP header (IPH)  320  and a payload (PL)  322 . IPH  320  may provide an address associated with user device  110 . PL  322  may include information associated with features and/or services (e.g., content-related services, security-related services, flow, rate, and QoS-related services, accounting-related services, administrative-related services, etc.) provided by feature peers  150 . ACL table  302  may receive packet  318 , may determine that packet  318  is associated with subscribed to services and/or features, and may direct packet  318  to AFL table  304 , as indicated by reference number  324 . 
         [0038]    AFL table  304  may be configured (e.g., via provisioning information  308 ) by NMS  130  to forward a packet on a specific tunnel  326  (e.g., using a tunnel header) to a first feature peer (e.g., feature peer  150 - 1 ) or may be automatically configured by routing table  306 . AFL table  304  may provide a tunnel header  328  (e.g., which defines tunnel  326  to feature peer  150 - 1 ) in packet  318 , and may forward packet  318 , (e.g., using tunnel header  328 ) along tunnel  326  to feature peer  150 - 1 . In one exemplary implementation, routing table  306  operating in conjunction with AFL table  304  may utilize mechanisms (e.g., anycast mechanisms, link aggregation groups (LAGs)) for providing resiliency and load balancing to feature peers  150 . Feature peer  150 - 1  may receive packet  318 . 
         [0039]    With reference to  FIG. 3C , feature peer  150 - 1  may determine (e.g., based on feature peer information  316 ) which of feature peers  150 - 2 ,  150 - 3 , and  150 - 4  can support a feature associated with packet  318  (e.g., a feature set forth in PL  322  of packet  318 ). Feature peer  150 - 1  may determine subscriber information associated with packet  318 , and may select a set of feature peers  150  (e.g., from feature peers  150  determined to support the feature associated with packet  318 ) for packet  318  to traverse. In one exemplary implementation, feature peer  150 - 1  may rank feature peers  150 , determined to support the feature associated with packet  318 , based on feature peer information  316 . For example, feature peer  150 - 1  may rank feature peers  150  with smaller loads higher than feature peers  150  with greater loads. Feature peer  150 - 1  may select the set of feature peers  150  (e.g., from the ranked feature peers  150  determined to support the feature associated with packet  318 ) based on the rankings Packet  318  may be provided to the other feature peers  150  in the set of feature peers  150 , may be returned to access router  120 , and/or may be forwarded on to its destination address (e.g., provided in network  140 ). 
         [0040]    For example, feature peer  150 - 1  may alter a tunnel header (e.g., tunnel header  328 ) of packet  318 . Tunnel header  328  may be altered to define a tunnel  332  to a next feature peer (e.g., feature peer  150 - 2 ) to which to provide packet  318 . Feature peer  150 - 1  may modify packet  318  by adding a feature header  334 - 1  to packet  318 , and may forward the modified packet  318  to feature peer  150 - 2  (e.g., via tunnel  332 ). Feature header  334 - 1  may include a feature net ID, the subscriber information associated with packet  318 , an address associated with access router  120 , etc. 
         [0041]    Feature peer  150 - 2  may receive the modified packet  318  from feature peer  150 - 1 , and may decapsulate packet  318  from tunnel  332 . Feature peer  150 - 2  may determine (e.g., based on feature peer information  316 ) which of the other feature peers  150  can support a feature associated with packet  318  (e.g., a feature set forth in PL  322  of packet  318 ). Feature peer  150 - 2  may determine subscriber information associated with packet  318 , and may select a set of feature peers  150  (e.g., from feature peers  150  determined to support the feature associated with packet  318 ) for packet  318  to traverse. Feature peer  150 - 2  may inspect feature header  334 - 1  and feature information  310  (e.g., provided by NMS  130  or by feature peer information  316 ) to determine feature processing options and a next feature peer (e.g., feature peer  150 - 3 ) to which to provide packet  318 . Feature peer  150 - 2  may alter a tunnel header (e.g., tunnel header  328 ) of packet  318 . Tunnel header  328  may be altered to define a tunnel  336  to the next feature peer (e.g., feature peer  150 - 3 ), and may forward the modified packet  318  to feature peer  150 - 3  (e.g., via tunnel  336 ). 
         [0042]    As further show in  FIG. 3C , feature peer  150 - 2  may modify feature header  334 - 1  based on feature information  310  and/or feature peer information  316  to create a modified feature header  334 - 2  and the modified customer packet  318 . In an exemplary implementation, feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) based on changing conditions and/or session signaling associated with other feature peers  150 . For example, a feature peer  150  defined by feature header  334 - 1  may experience load changes or may fail. Alternatively, another feature peer  150  (e.g., not defined by feature header  334 - 1 ) may better serve packet  318  (e.g., due to changing conditions) than a feature peer  150  initially defined by feature header  334 - 1 . In such situations, feature peer  150 - 2  may modify tunnel header  328  (e.g., to create feature header  334 - 2 ) so that a failed or overloaded feature peer  150  is not traversed by packet  318  or so that another feature peer  150  (e.g., not defined by tunnel header  328 ) is traversed by packet  318 . In other situations, session signaling may result in a change of session state (e.g., a voice or video over IP session being established or released) or conditions may change as a result of packet volume, type, or rate (e.g., the packet rate exceeds that provisioned by NMS  130 ). In these other situations, feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) so that different feature processing (e.g., a different QoS is provided for packets that exceed NMS  130  provisioned packet rate) may be performed by the next feature peer  150 - 3  on packet  318 . 
         [0043]    In another exemplary implementation, feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) based on session signaling associated with other feature peers  150 . For example, if a particular feature peer  150  (e.g., feature peer  150 - 2 ) defined by feature header  334 - 1  detects a change in session state from intercepted session signaling, feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) to reflect the change in session state. All feature peers  150  in the feature net graph may then be aware of this change in session state and may modify their feature processing accordingly. 
         [0044]    Feature peer  150 - 3  may receive the modified packet  318  from feature peer  150 - 2 , and may decapsulate packet  318  from tunnel  336 . Feature peer  150 - 3  may determine (e.g., based on feature peer information  316 ) which of the other feature peers  150  can support a feature associated with packet  318  (e.g., a feature set forth in PL  322  of packet  318 ). Feature peer  150 - 3  may determine subscriber information associated with packet  318 , and may select a set of feature peers  150  (e.g., from feature peers  150  determined to support the feature associated with packet  318 ) for packet  318  to traverse. Feature peer  150 - 3  may inspect feature header  334 - 2  and feature information  310  (e.g., provided by NMS  130  or by feature peer information  316 ) to determine feature processing options and a next feature peer (e.g., feature peer  150 - 4 ) to which to provide packet  318 . Feature peer  150 - 3  may alter a tunnel header (e.g., tunnel header  328 ) of packet  318 . Tunnel header  328  may be altered to define a tunnel  338  to the next feature peer (e.g., feature peer  150 - 4 ), and may forward the modified packet  318  to feature peer  150 - 4  (e.g., via tunnel  338 ). 
         [0045]    As further show in  FIG. 3C , feature peer  150 - 3  may modify feature header  334 - 2  based on feature information  310  and/or feature peer information  316  to create a modified feature header  334 - 3  and the modified customer packet  318 . In an exemplary implementation, feature peer  150 - 3  may modify feature header  334 - 2  (e.g., to create feature header  334 - 3 ) based on changing conditions associated with other feature peers  150 . For example, a feature peer  150  defined by feature header  334 - 2  may experience load changes or may fail. Alternatively, another feature peer  150  (e.g., not defined by feature header  334 - 2 ) may better serve packet  318  (e.g., due to changing conditions) than a feature peer  150  defined by feature header  334 - 2 . In such situations, feature peer  150 - 3  may modify tunnel header  328  (e.g., to create feature header  334 - 3 ) so that a failed or overloaded feature peer  150  is not traversed by packet  318  or so that another feature peer  150  (e.g., not defined by tunnel header  328 ) is traversed by packet  318 . In other situations, session signaling may result in a change of session state (e.g., a voice or video over IP session being established or released) or conditions may change as a result of packet volume, type, or rate (e.g., the packet rate exceeds that provisioned by NMS  130 ). In these other situations, feature peer  150 - 3  may modify feature header  334 - 2  (e.g., to create feature header  334 - 3 ) so that different feature processing (e.g., a different QoS is provided for packets that exceed NMS  130  provisioned packet rate) may be performed by the next feature peer  150 - 4  on packet  318 . 
         [0046]    In another exemplary implementation, feature peer  150 - 3  may modify feature header  334 - 2  (e.g., to create feature header  334 - 3 ) based on session signaling associated with other feature peers  150 . For example, if a particular feature peer  150  (e.g. feature peer  150 - 3 ) defined by feature header  334 - 2  detects a change in session state from intercepted session signaling, feature peer  150 - 3  may modify feature header  334 - 2  (e.g., to create feature header  334 - 3 ) to reflect the change in session state. All feature peers  150  in the feature net graph may then be aware of this change in session state and may modify their feature processing accordingly. In another example, feature peer  150 - 3  may determine that an order in which packet  318  is to traverse feature peers  150  (e.g., as defined by feature header  334 - 2 ) may be need to modified (e.g., based on changing conditions). Feature peer  150 - 3  may modify feature header  334 - 2  (e.g., to create feature header  334 - 3 ) to change the order in which packet  318  traverses feature peers  150  defined by feature header  334 - 2 . In effect, the changed feature header  334 - 2  may reference a different feature net that has feature peers  150  ordered in a different way. Alternatively, modification of feature header  334 - 2  may effectively reference a different feature net that has more or fewer feature peers  150  than that invoked for other packets. This means that each packet to/from a user device may receive different feature peer processing. 
         [0047]    Feature peer  150 - 4  may receive the modified packet  318  from feature peer  150 - 3 , and may decapsulate packet  318  from tunnel  338 . Feature peer  150 - 4  may inspect feature header  334 - 3  and feature information  310  (e.g., provided by NMS  130 ) to determine feature processing options. Feature peer  150 - 4  may determine that it is the last feature peer  150  in a feature graph (e.g., a path traversed by packet  318 ), and may determine that packet  318  is to be returned to its origination point (e.g., to access router  120 ,  FIG. 3A ). Feature peer  150 - 4  may use the address associated with access router  120  (e.g., as provided in feature header  334 - 1 ) to define a tunnel  340  to access router  120 . Feature peer  150 - 4  may alter a tunnel header (e.g., tunnel header  328 ) of packet  318 , and may remove feature header  334 - 3  from packet  318 . Tunnel header  328  may be altered to define tunnel  340  to access router  120 , and may forward packet  318  to access router  120  (e.g., via tunnel  340 ). 
         [0048]    Access router  120  (e.g., AFL table  304 ) may receive packet  318  from feature peer  150 - 4 , and may decapsulate packet  318  from tunnel  340 . AFL table  304  may use IPH  320  to determine a next hop for packet  318 , and may forward (e.g., via a tunnel  342 ) packet  318  to a destination address associated with network  140 , as indicated by reference number  344 . 
         [0049]    Although  FIGS. 3A-3C  depict a chain or loop feature graph (e.g., packet  318  travels via feature peers  150 - 1 ,  150 - 2 ,  150 - 3 , and  150 - 4 ) for routing packet  318 , in other exemplary implementations, different types of feature graphs may be used for routing packet  318  (e.g., a decision tree feature graph, a feature graph that traverses feature peers  150 - 1  and  150 - 4 , etc.). In one exemplary implementation, packet  318  may not be returned to access router  120  for forwarding on to the destination address associated with network  140 , but rather packet  318  may be forwarded (or may be dropped) by any of feature peers  150  (e.g., provided in the feature graph). Furthermore, although  FIGS. 3A-3C  depict packet  318  being provided by user device  110 , the implementations described herein may be applied to a packet provided by network  140  and destined for user device  110 . Alternatively, a copy of packet  318  may be created at one of feature peers  150  and may be processed separately. In another alternative, due to modification of a feature header via feature peers  150  in response to changing conditions and/or session signaling, packets to/from the same user device may traverse a different set of feature peers  150 , traverse feature peers  150  in a different order, and/or receive different processing by feature peers  150  in response to the modified feature header. 
         [0050]    Although  FIGS. 3A-3C  show exemplary components of network portion  300 , in other implementations, network portion  300  may contain fewer, different, differently arranged, or additional components than depicted in  FIGS. 3A-3C . In still other implementations, one or more components of network portion  300  may perform one or more other tasks described as being performed by one or more other components of network portion  300 . 
         [0051]      FIGS. 4A and 4B  illustrate diagrams of exemplary interactions among components of another exemplary portion  400  of network  100 . As illustrated, exemplary network portion  400  may include user device  110 , access router  120  (e.g., including ACL table  302  and AFL table  304 ), network  140 , and feature peers  150 . User device  110 , access router  120  (e.g., including ACL table  302  and AFL table  304 ), network  140 , and/or feature peers  150  may include the features described above in connection with, for example,  FIGS. 1-3C . ACL table  302  may include an IP source address (SA) field  402 , a tunnel header (TH) field  404 , and a variety of entries associated with IP SA field  402  and TH field  404 . AFL table  304  may include an IP destination address (DA) field  406 , a next hop (NH) field  408 , and a variety of entries associated with IP DA field  406  and NH field  408 . 
         [0052]    As shown in  FIG. 4A , user device  110  may provide packet  318  (e.g., including IPH  320  and PL  322 ) to ACL table  302  of access router  120 . In one exemplary implementation, IPH  320  may include an IP source address of “D,” and ACL table  302  may associate IP SA of “D” with a first tunnel header (TH. 1 ) associated with feature peer  150 - 1 . ACL table  302  may determine a tunnel  410  for packet  318  based on the IP SA (e.g., “D”) of IPH  320  (or based on other parameters). Access router  120  may add a first tunnel header (TH. 1 )  412  to packet  318 , and may forward packet  318  (e.g., based on first tunnel header  412 ) to feature peer  150 - 1  via tunnel  410 , as determined via the “TH. 1 ” IP DA entry in AFL table  304 . 
         [0053]    Feature peer  150 - 1  may receive packet  318  from tunnel  410 , and may perform feature processing of packet  318 . In one exemplary implementation, feature peer  150 - 1  may use distributed hash tables (DHTs)  414 ,  416 , and  418  to determine how to process packet  318 . In one example, a DHT function may not be performed for each packet, but may be performed in an event-driven manner when feature peer  150  net state changes (e.g., when a load crosses a threshold or when feature peer&#39;s  150  active/in active state changes). Event-driven DHT lookup results may then be locally cached for more efficient operation until a next event occurs. 
         [0054]    DHT  414  may include an IP SA field, a feature net (FN) field, and a variety of entries associated with the IP SA field and the FN field. DHT  416  may include fields associated with each feature peer (FP.x) in a column for each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k). DHT  418  may include an index of a specific feature peer that identifies one or more tunnel header (TH) fields, and to be used to forward a packet to the feature peers. If a feature peer is to replicate packets to multiple other feature peers, there may be a separate TH entry in DHT  418 . In one example, feature peer  150 - 1  may perform a lookup of DHT  414  based on the IP SA (e.g., “D”), or other parameters, associated with packet  318 , and may determine that the IP SA of “D” may be associated with a first feature network (FN. 1 ). Feature peer  150 - 1  may perform a lookup of DHT  416  based on the first feature network (FN. 1 ) descriptor, and may determine a next feature peer (e.g., feature peer  150 - 2  (FP. 2 )) associated with the first feature network (FN. 1 ). Feature peer  150 - 1  may use the determined next feature peer (e.g., FP. 2 ) as an index for DHT  418  to determine the associated tunnel header (e.g., TH. 2 , per DHT  418 ) to define a tunnel  420  to feature peer  150 - 2  and to modify packet  318 . For example, feature peer  150 - 1  may add a tunnel header  422  (e.g., TH. 2 ) and a feature header  424 - 1  (e.g., FH. 1 ) to packet  318 . Tunnel header  422  may define tunnel  420 . Feature header  424 - 1  may include the first feature network ID (e.g., FN. 1 ), an address associated with access router  120 , and subscriber information, and may be used by subsequent feature peers  150 . Feature peer  150 - 1  may then route packet  318  to feature peer  150 - 2  via tunnel  420 . 
         [0055]    Feature peer  150 - 2  may receive packet  318  from tunnel  420 , and may perform feature processing of packet  318 . In one exemplary implementation, feature peer  150 - 2  may use event-driven DHTs  426  and  428  to determine how to process packet  318 . DHT  426  may include fields associated with each feature peer (FP.x) in a column for each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k). DHT  428  may include an index of a specific feature peer that identifies one or more tunnel header (TH) fields to be used to forward a packet to the feature peers. If a feature peer is to replicate packets to multiple other feature peers, there may be a separate TH entry in DHT  428 . Feature peer  150 - 2  may perform a lookup of DHT  426  based on the first feature network (FN. 1 ) descriptor, and may determine a next feature peer (e.g., feature peer  150 - 3  (FP. 3 )) associated with the first feature network (FN. 1 ). Feature peer  150 - 2  may use the determined next feature peer (e.g., FP. 3 ) as an index for DHT  428  to determine the associated tunnel header (e.g., TH. 3 , per DHT  428 ) to define a tunnel  430  (as shown in  FIG. 4B ) to feature peer  150 - 3  and to modify packet  318 . For example, feature peer  150 - 2  may add a tunnel header  432  (e.g., TH. 3  as shown in  FIG. 4B ), defining tunnel  430 , to packet  318 , and may or may not modify one or more fields associated with feature header  424 - 1  (FH. 1 ). Feature peer  150 - 2  may then route packet  318  to feature peer  150 - 3  via tunnel  430 . 
         [0056]    As shown in  FIG. 4B , feature peer  150 - 2  may modify feature header  424 - 1  based on feature information  310  and/or feature peer information  316  to create a modified feature header  424 - 2  (e.g., FH. 2 ) and the modified customer packet  318 . In an exemplary implementation, feature peer  150 - 2  may modify feature header  424 - 1  (e.g., to create feature header  424 - 2 ) based on changing conditions (e.g., load conditions, availability, change in session state based on provisioned policy, etc.) associated with other feature peers  150 . In another exemplary implementation, feature peer  150 - 2  may modify feature header  424 - 1  (e.g., to create feature header  424 - 2 ) based on session signaling associated with other feature peers  150 . Feature header  424 - 2  may include the first feature network ID (e.g., FN. 1 ), an address associated with access router  120 , and subscriber information, and may be used by subsequent feature peers  150 . 
         [0057]    As further shown in  FIG. 4B , feature peer  150 - 3  may receive packet  318  from tunnel  430 , and may perform feature processing of packet  318 . In one exemplary implementation, feature peer  150 - 3  may use event-driven DHTs  434 ,  436 , and  438  to determine how to process packet  318 . DHT  434  may include an IP SA field, a FN field, and a variety of entries associated with the IP SA field and the FN field. DHT  436  may include fields associated with each feature peer (FP.x) in a column for each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k). DHT  438  may include an index of a specific feature peer that identifies one or more tunnel header (TH) fields to be used to forward a packet to the feature peers. If a feature peer is to replicate packets to multiple other feature peers, there may be a separate TH entry in DHT  438 . Feature peer  150 - 3  may perform a lookup of DHT  436  based on the first feature network (FN. 1 ) descriptor, and may determine a next feature peer (e.g., feature peer  150 - 4  (FP. 4 )) associated with the first feature network (FN. 1 ). Feature peer  150 - 3  may use the determined next feature peer (e.g., FP. 4 ) as an index for DHT  438  to determine the associated tunnel header (e.g., TH. 4 , per DHT  438 ) to define a tunnel  440  to feature peer  150 - 4  and to modify packet  318 . For example, feature peer  150 - 3  may add a tunnel header  442  (e.g., TH. 4 ), defining tunnel  440 , to packet  318 , and may or may not modify one or more fields associated with feature header  424 - 2  (FH. 2 ). Feature peer  150 - 3  may then route packet  318  to feature peer  150 - 4  via tunnel  440 . 
         [0058]    Feature peer  150 - 3  may modify feature header  424 - 2  based on feature information  310  and/or feature peer information  316  to create a modified feature header  424 - 3  (e.g., FH. 3 ) and the modified customer packet  318 . In an exemplary implementation, feature peer  150 - 3  may modify feature header  424 - 2  (e.g., to create feature header  424 - 3 ) based on changing conditions (e.g., load conditions, availability, etc.) associated with other feature peers  150 . In another exemplary implementation, feature peer  150 - 3  may modify feature header  424 - 2  (e.g., to create feature header  424 - 3 ) based on session signaling associated with other feature peers  150 . Feature header  424 - 3  may include the first feature network ID (e.g., FN. 1 ), an address associated with access router  120 , and subscriber information, and may be used by subsequent feature peers  150 . 
         [0059]    Feature peer  150 - 4  may receive packet  318  from tunnel  440 , and may perform feature processing of packet  318 . In one exemplary implementation, feature peer  150 - 4  may use event-driven DHTs  444  and  446  to determine how to process packet  318 . DHT  444  may include fields associated with each feature peer (FP.x) in a column for each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k). DHT  446  may include an index of a specific feature peer that identifies one or more tunnel header (TH) fields to be used to forward a packet to the feature peers. If a feature peer is to replicate packets to multiple other feature peers, there may be a separate TH entry in DHT  446 . Feature peer  150 - 4  may perform a lookup of DHT  444  based on the first feature network (FN. 1 ) descriptor, and may determine a next feature peer (e.g., “END”) associated with the first feature network (FN. 1 ). Feature peer  150 - 3  may use the address associated with access router  120  (e.g., from feature header  424 ) as an index for DHT  446  to determine a tunnel header (e.g., TH. 5 , per DHT  446 ) that defines a tunnel  448  to access router  120 . For example, feature peer  150 - 4  may add a tunnel header  450  (e.g., TH. 5 ), defining tunnel  448 , to packet  318 , and may remove feature header  424 - 3  (FH. 3 ) from packet  318 . Feature peer  150 - 4  may then route packet  318  to access router  120  (e.g., to AFL table  304  of access router  120 ) via tunnel  448 . 
         [0060]    As shown in  FIG. 4B , access router  120  (e.g., via AFL table  304 ) may identify packet  318  received from tunnel  448  as decapsulated (DE), and may utilize lookup information  452  to route packet  318  to its DA (e.g., based on IP DA field  406  and NH field  408 ). In one example, lookup information  452  may include a longest prefix match in network  140 . AFL table  304  may use lookup information  452  to determine a next hop (e.g., a destination address in network  140 ) for packet  318 , and may forward (e.g., via a tunnel  454 ) packet  318  to the destination address (DA) associated with network  140 , as indicated by reference number  456 . 
         [0061]    Although  FIGS. 4A and 4B  show exemplary components of network portion  400 , in other implementations, network portion  400  may contain fewer, different, differently arranged, or additional components than depicted in  FIGS. 4A and 4B . In still other implementations, one or more components of network portion  400  may perform one or more other tasks described as being performed by one or more other components of network portion  400 . For example, feature peers  150  may be used to distribute additional feature/subscriber information that may be omitted from feature header  424 - 1  of packet  318 . Furthermore, although not shown in  FIGS. 4A and 4B , a similar procedure may be used to implement a feature net for packets received from network  140  that are addressed to a specific user. 
         [0062]    In one exemplary implementation, information contained in event-driven DHTs  414 / 416  (e.g., provided in feature peer  150 - 1 ), event-driven DHT  426  (e.g., provided in feature peer  150 - 2 ), event-driven DHTs  434 / 436  (e.g., provided in feature peer  150 - 3 ), and event-driven DHT  444  (e.g., provided in feature peer  150 - 4 ) may be provided by and/or continuously updated by feature peer information  316  ( FIG. 3B ). Functions associated with feature peers  150  may change over time and in response to changing conditions and/or session signaling. Thus, continuously updated feature peer information  316  may enable implementations described herein to dynamically update traversal of feature peers  150  by packet  318 . Furthermore, in one exemplary implementation, information about each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k) may include partial ordering information (or no ordering information) such that traversal of feature peers  150  by packet  318  may occur in different orders or may change in response loads and/or failures associated with feature peers  150 . In one example, traversal of feature peers  150  by packet  318  may occur in parallel and may include interactions between parallel streams. In an exemplary implementation, a distributed control plane may be dynamically executed between feature peers  150  to determine how to implement and/or adapt each feature net (e.g., FN. 1 , FN. 2 , . . . , FN.k). 
         [0063]    In contrast to the star/flower arrangement and the service header-based routing arrangement, which require expensive changes to the software and/or hardware of the access router, implementations described herein do not require changes to the software/hardware of access router  120 . Furthermore, the feature header (e.g., feature headers  334 - 1 ,  334 - 2 ,  334 - 3 ,  424 - 1 ,  424 - 2 , and/or  424 - 3 ) described herein may include information distributed by DHT/P2P technology, possibly in an event-driven manner to optimize efficiency. Convergence time, adaptation to changes, and ability to rapidly respond to changes, associated with implementations described herein, may be improved over centralized arrangements, such as the star/flower arrangement and the service header-based routing arrangement. Implementations described herein may combine DHT/P2P and network-aware routing using application layer topology optimization, and may function across multiple feature peers owned by different service providers. 
         [0064]    Implementations described herein may be used to support a variety of services and/or features, such as content delivery network (CDN)-related features; caching, streaming server, and/or P2P native applications; encryption and/or decryption; changing wireless conditions (e.g., signal strength, location, privacy, bit rate, battery life, etc.); load and/or other information (e.g., local weather, traffic conditions, third party information, etc.); delivering service characteristics based on knowledge of user device  110 ; packet repair; VPN and/or Internet denial of service (DoS) detection and/or mitigation; sniffing packets and performing actions on packets; phishing detection; usage metering services; etc. 
         [0065]      FIGS. 5-8  are flow charts of an exemplary process  500  for modifying a peer-to-peer based feature network according to implementations described herein. In one implementation, process  500  may be performed by one of feature peers  150 . In another implementation, some or all of process  500  may be performed by another device or group of devices, including or excluding one of feature peers  150 . 
         [0066]    As shown in  FIG. 5 , process  500  may include communicating with other feature peers to obtain information associated with the other feature peers (block  510 ), and receiving a customer packet that includes a feature header (block  520 ). For example, in implementations described above in connection with  FIGS. 3A-3C , feature peers  150  may communicate with each other to provide feature peer information  316  to other feature peers  150 . Feature peer information  316  may include identification information; load information; path information; active/inactive status information; session signaling; policy information; database information; etc. associated with feature peers  150 ; and subscriber information (e.g., information associated with customers or subscribers to peer-to-peer based feature network forwarding). Feature peer  150 - 1  may modify packet  318  (e.g., received from a customer) by adding feature header  334 - 1  to packet  318 , and may forward the modified packet  318  to feature peer  150 - 2  (e.g., via tunnel  332 ). Feature header  334 - 1  may include a feature net ID, the subscriber information associated with packet  318 , an address associated with access router  120 , etc. Feature peer  150 - 2  may receive the modified packet  318  from feature peer  150 - 1 , and may decapsulate packet  318  from tunnel  332 . 
         [0067]    As further shown in  FIG. 5 , process  500  may include modifying the feature header, based on the information associated with the other feature peers, to create a modified customer packet (block  530 ), and determining, based on the feature peer information, which of the other feature peers can support a feature associated with the modified customer packet (block  540 ). For example, in implementations described above in connection with  FIG. 3C , feature peer  150 - 2  may modify feature header  334 - 1  based on feature information  310  and/or feature peer information  316  to create a modified feature header  334 - 2  and the modified customer packet  318 . Feature peer  150 - 2  may determine (e.g., based on feature peer information  316 ) which of the other feature peers  150  can support a feature associated with packet  318  (e.g., a feature set forth in PL  322  of packet  318 ). 
         [0068]    Returning to  FIG. 5 , process  500  may include selecting a set of other feature peers, from the determined other feature peers, for the modified customer packet to traverse (block  550 ), and forwarding, based on the modified feature header, the modified customer packet to one of the feature peers in the set of other feature peers (block  560 ). For example, in implementations described above in connection with  FIG. 3C , feature peer  150 - 2  may determine subscriber information associated with packet  318 , and may select a set of feature peers  150  (e.g., from feature peers  150  determined to support the feature associated with packet  318 ) for packet  318  to traverse. Feature peer  150 - 2  may inspect feature header  334 - 1  and feature information  310  (e.g., provided by NMS  130  or by feature peer information  316 ) to determine feature processing options and a next feature peer (e.g., feature peer  150 - 3 ) to which to provide packet  318 . Feature peer  150 - 2  may alter a tunnel header (e.g., tunnel header  328 ) of packet  318 . Tunnel header  328  may be altered to define a tunnel  336  to the next feature peer (e.g., feature peer  150 - 3 ), and may forward the modified packet  318  to feature peer  150 - 3  (e.g., via tunnel  336 ). 
         [0069]    Process block  510  may include the process blocks depicted in  FIG. 6 . As shown in  FIG. 6 , process block  510  may include receiving session signaling associated with the other feature peers (block  600 ), receiving policy information associated with the other feature peers (block  610 ), and receiving database information associated with the other feature peers (block  620 ). 
         [0070]    For example, in implementations described above in connection with  FIG. 3B , feature peers  150  may communicate with each other to provide feature peer information  316  to other feature peers  150 . Feature peer information  316  may include identification information; load information; path information; active/inactive status information; session signaling (e.g., signaling provided between feature peers  150  during provisioning of packet  318 ); policy information (e.g., information associated with policies, such as usage policies, bandwidth allocations, etc.); database information (e.g., information contained in databases of feature peers  150 , sizes of such databases, etc.); etc. associated with feature peers  150 ; and subscriber information (e.g., information associated with customers or subscribers to peer-to-peer based feature network forwarding). Feature peer information  316  may enable feature peers  150  to define a set of feature net logic (e.g., a set of feature peers  150 ) that may be dynamically determined and self correcting. 
         [0071]    Process block  530  may include the process blocks depicted in  FIG. 7 . As shown in  FIG. 7 , process block  530  may include modifying the feature header of the customer packet based on changing conditions associated with the other feature peers (block  700 ), and/or modifying the feature header of the customer packet based on session signaling associated with the other feature peers (block  710 ). For example, in implementations described above in connection with  FIG. 3C , feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) based on changing conditions (e.g., change in session state, etc.) associated with other feature peers  150 . In one example, feature peer  150 - 2  may modify feature header  334 - 1  (e.g., to create feature header  334 - 2 ) based on session signaling associated with other feature peers  150 . Modification of the feature header may cause a different feature net and hence packet  318  may traverse feature peers  150  in a different order or traverse a different set of feature peers  150 . 
         [0072]    Process block  550  may include the process blocks depicted in  FIG. 8 . As shown in  FIG. 8 , process block  550  may include ranking the determined other feature peers based on the information associated with the determined other feature peers (block  800 ), and selecting the set of other feature peers, for the customer packet to traverse, from the ranked, determined other feature peers and based on the ranking (block  810 ). For example, in implementations described above in connection with  FIG. 3C , feature peer  150 - 1  may rank feature peers  150 , determined to support the feature associated with packet  318 , based on feature peer information  316 . In one example, feature peer  150 - 1  may rank feature peers  150  with less loads higher than feature peers  150  with more loads. Feature peer  150 - 1  may select the set of feature peers  150  (e.g., from the ranked feature peers  150  determined to support the feature associated with packet  318 ) for packet  318  to traverse based on the rankings. 
         [0073]    Implementations described herein may include systems and/or methods that may modify a peer-to-peer based feature network based on changing conditions and/or session signaling. For example, in one implementation, a feature peer (e.g., a server that provides features and/or services, such as content-related services, security-related services, etc.) may communicate with other feature peers to obtain information associated with the other feature peers, which may or may not be associated with a received packet (e.g., from a user or customer) that includes a feature header. The feature peer may modify the feature header, based on the information associated with the other feature peers, to create a modified customer packet. The feature peer may determine, based on the feature peer information, which of the other feature peers can support a feature associated with the modified customer packet. The feature peer may select a set of the other feature peers, from the determined other feature peers, for the modified customer packet to traverse. The feature peer may forward, based on the modified feature header, the modified customer packet to one of the feature peers in the set of other feature peers. 
         [0074]    The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. 
         [0075]    For example, while series of blocks have been described with regard to  FIGS. 5-8 , the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel. 
         [0076]    It will be apparent that aspects, as described herein, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement the embodiments based on the description herein. 
         [0077]    Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. 
         [0078]    No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.