Patent application number | Description | Published |
20080232247 | Network traffic demotion - A method and apparatus for demoting network traffic are disclosed. In one embodiment, a method includes transmitting traffic associated with a session over a first path, and maintaining state information identifying the first path as a forwarding path for the session. Traffic associated with the session is rerouted from the first path to a second path following a network failure and the rerouted traffic is marked so that at least a portion of the rerouted traffic can be dropped at any point in the network if rerouting causes network congestion. | 09-25-2008 |
20080298265 | Convergence measurement in computer network - A system and method for measuring convergence performance in a network are disclosed. In one embodiment, the method includes receiving a plurality of probes at a network device, temporarily storing data from at least a portion of the received probes and deleting at least a portion of the temporarily stored data at regular intervals, and receiving a packet indicating a convergence event and storing data from probes received over a predetermined period. | 12-04-2008 |
20080320166 | AUTOMATIC PRIORITIZATION OF BGP NEXT-HOP IN IGP CONVERGENCE - In one embodiment, an inter-domain routing protocol stores an inter-domain routing protocol route having an associated next-hop address. A routing table is searched for an for an intra-domain routing protocol route that may be used to reach the next-hop address of the inter-domain routing protocol route. Such route is marked as an important route for convergence. Later, in response to a change in the network requiring a routing table update, the intra-domain routing protocol route marked as an important route for convergence is processed by an intra domain routing protocol before any other intra-domain routing protocol routes are processed that are not marked as important routes for convergence. | 12-25-2008 |
20090010153 | Fast remote failure notification - A method and system for failure notification at a remote node in communication with a local node are disclosed. The local node is configured for faster failure detection than the remote node. In one embodiment, the method includes establishing a failure monitoring session between the local node and the remote node, receiving at the remote node, a failure notification from the local node, the failure notification sent using a protocol of the failure monitoring session, and rerouting traffic at the remote node in response to the failure notification. | 01-08-2009 |
20090073996 | INTERIOR GATEWAY PROTOCOL SUMMARIZATION PRESERVING INTERNET PROTOCOL REACHABILITY INFORMATION - In one example embodiment, a system and method is illustrated that includes receiving connectivity data for at least one network device, the connectivity data describing a connection to the at least one network device within an area. The system and method further includes processing the connectivity data to obtain a routing update for distribution to another network device outside the area. Additionally, the system and method includes a routing summary in the routing update, the routing summary including an address prefix. Further, the system and method includes reachability information in the routing update, the reachability information including an address for the at least one network device. | 03-19-2009 |
20090122805 | Instrumenting packet flows - Disclosed are, inter alia, methods, apparatus, computer-readable media, mechanisms, and means for instrumenting real-time customer packet traffic. These measured delays can be used to determine whether or not the performance of a packet switching device and/or network meets desired levels, especially for complying with a Service Level Agreement. | 05-14-2009 |
20090141721 | Deterministic Multiprotocol Label Switching (MPLS) Labels - Disclosed are, inter alia, methods, apparatus, computer-readable media, mechanisms, and means for deterministically determining MPLS labels as functions of addresses of Forwarding Equivalence Classes (FECs), and using these determined labels in the forwarding of packets. By each packet switching device in a network deterministically determining the same MPLS label to use for each FEC, each packet switching device knows what label will be used by the other packet switching devices, without running Label Distribution Protocol (LDP) or another label publishing protocol. Additionally, this knowledge extends to all packet switching devices in a network, not merely neighboring packet switching devices, which allows a packet switching device to specify a stack of labels to define a desired path through the network for explicit path routing and/or fast rerouting of traffic without having to previously establish a tunnel or path using Resource Reservation Protocol (RSVP), for example. | 06-04-2009 |
20090147674 | LOOP PREVENTION TECHNIQUES USING ENCAPSULATION MANIPULATION OF IP/MPLS FIELD - In one embodiment, an edge device communicates with a neighboring routing domain. A failure that prevents communication between the edge device and the neighboring routing is detected. When the edge device thereafter receives a data packet that is directed to the neighboring routing domain, it determines if the received data packet was rerouted to the edge device from another edge device coupled to the neighboring routing domain. If the received data packet was not rerouted to the edge device from another edge device coupled to the neighboring routing domain, the edge device reroutes the received data packet to another edge device for forwarding to the neighboring routing domain. However, if the received data packet was rerouted to the edge device from another edge device coupled to the neighboring routing domain, the edge device prevents the received data packet from being rerouted a second time to prevent loops. | 06-11-2009 |
20090193105 | Local placement of large flows to assist load-balancing - In one embodiment, an apparatus generally comprises one or more input interfaces for receiving a plurality of flows, a plurality of output interfaces, and a processor operable to identify large flows and select one of the output interfaces for each of the large flows to load-balance the large flows over the output interfaces. The apparatus further includes memory for storing a list of the large flows, a pinning mechanism for pinning the large flows to the selected interfaces, and a load-balance mechanism for selecting one of the output interfaces for each of the remaining flows. A method for local placement of large flows to assist in load-balancing is also disclosed. | 07-30-2009 |
20090201803 | Multicast fast reroute for network topologies - In one embodiment, a method includes receiving a multicast join message at a node having a plurality of interfaces, identifying the interface at which the join message was received, and selecting one or more of the interfaces to transmit the join message based on whether the join message was received on a ring interface. If the join message was received on one of the ring interfaces, the join message is transmitted on another of the interfaces. If the join message was not received on one of the ring interfaces, the join message is transmitted on both of the ring interfaces. The method further includes receiving multicast data and transmitting the multicast data on the interface at which the join message was received. | 08-13-2009 |
20090201811 | Load Balancing Manipulation of Packet Flows Within a Transport Conduit - Disclosed are, inter alia, methods, apparatus, computer-readable media, mechanisms, and means for load balancing manipulation of packet flows within a transport conduit (e.g., a tunnel, pseudo wire, etc.), typically using a load balancing value which is independent of standard routing-based parameters (e.g., source address, destination address, source port, destination port, protocol type, etc.). A load balancing value is included in encapsulated packets transported across a network using a transport conduit. This load balancing value can be used to load balance the individual flows/microflows within the transport conduit. | 08-13-2009 |
20090225671 | Monitoring Quality of a Packet Flow in Packet-Based Communication Networks - A communication system includes multiple routers interconnected by a packet-based communication network. Each of the routers includes a monitoring application that monitors quality of one or more packet flows during each of multiple successive monitoring periods. For each of the packet flows, the monitoring application determines quality metrics based on information obtained from transport headers of packets. | 09-10-2009 |
20090232031 | RECEIVER-BASED CONSTRUCTION OF POINT-TO-MULTIPOINT TREES USING PATH COMPUTATION ELEMENTS IN A COMPUTER NETWORK - In one embodiment, a trigger to add a leaf node to a multicast group of a computer network is detected, and the leaf node may determine a root node of the multicast group to request a path between a tunnel tree and the leaf node of the multicast group. In response to the multicast group having an existing tree, a reply is received from the root node with a computed path to add the leaf node to the tree at a selected node of the tree. The leaf node may then be added to the multicast group tunnel tree over the computed path at the selected node. | 09-17-2009 |
20090245259 | FAST REROUTE (FRR) PROTECTION AT THE EDGE OF A RFC 2547 NETWORK - In one embodiment, an edge device in a first routing domain is configured to communicate with a second routing domain via a data link. The edge device receives a data packet containing a destination address that is reachable via the second routing domain and an indication that the data packet is a protected packet that was previously rerouted from another edge device in the first routing domain via a Multi-Protocol Label Switching (MPLS) Fast Reroute (FRR) backup path. The edge device determines if communication with the second routing domain is still available via the data link, and if so, removes the indication that the data packet is a protected packet and forwards the data packet to the second routing domain, and, if not, drops the data packet to prevent the data packet from being rerouted a second time in the first routing domain on another MPLS FRR backup path. | 10-01-2009 |
20090296579 | EFFICIENT CONVERGENCE OF GROUPED VPN PREFIXES - In one embodiment, one or more virtual private network (VPN) prefixes may be grouped at a network node into sets having shared network border node next-hop options, where each border node has a defined index value associated therewith. Also, a list of VPN labels associated with each VPN prefix may be maintained by the network node, where each VPN label is associated with a border node of a particular set by a corresponding index value. Further, the network node may determine a particular border node for traffic to be forwarded, along with the defined index value. The network node may then apply the index value to select an associated VPN label, and may affix the selected VPN label to the traffic for forwarding. | 12-03-2009 |
20100080222 | AUTOMATIC RD REWRITE TECHNIQUE TO ACHIEVE FAST CONVERGENCE IN INTER-AS NETWORKS - A virtual private network (VPN) is formed with a pair of autonomous systems (ASes) connected by each having at least two autonomous system border routers (ASBRs) connected to the corresponding ASBRs at the other AS, referred to as an Option B VPN-IPv4 network. Route reflectors (RRs) only reflect the best Border Gateway Protocol (BGP) paths, providing no backup BGP paths for fast convergence. Advantageously, an automatic route distinguisher (RD) rewrite component at the ASBRs creates unique prefixes and advertises the original RD as transitive attribute in an update message to external AS peers. Each RD gets mapped to another unique prefix at the ASBR and also that two ASBRs will create different unique prefixes. Thus, the route reflector sees different prefixes and reflects all of them. The ingress provider edge (PE) router can import the prefixes and correctly obtain the alternate paths for fast convergence. | 04-01-2010 |
20100118732 | LOOP PREVENTION TECHNIQUE FOR MPLS USING SERVICE LABELS - In one embodiment, a loss of communication is detected between a first edge device of a computer network and a neighboring routing domain. A data packet is received at the first edge device, where the received data packet contains a destination address that is reachable via the neighboring routing domain. A determination is made whether a service label is located in a Multi-Protocol Label Switching (MPLS) label stack included in the received data packet. A service label in the MPLS label stack indicates that the received data packet was previously rerouted in accordance with fast reroute (FRR) operations. In response to a determination that the received data packet does not include a service label in the MPLS label stack, the received data packet is rerouted to a second edge device of the computer network for forwarding to the neighboring routing domain. | 05-13-2010 |
20100150020 | BACKUP ROUTE GENERATION IN BORDER GATEWAY PROTOCOL - A method is provided for generating a backup route. Here, a route and a route distinguisher type associated with the route are received and a backup route is generated based on attributes of the route. A particular backup route distinguisher type that is associated with the route distinguisher type is assigned to the backup route. The backup route with the backup route distinguisher type are then advertised. Another method is provided that identifies the backup route. When the route and its route distinguisher type are received from the advertisement, an identification is made as to whether the route distinguisher type is assigned to a backup route. The route may then be designated as a backup route based on the identification. | 06-17-2010 |
20100215047 | SUBSETS OF THE FORWARD INFORMATION BASE (FIB) DISTRIBUTED AMONG LINE CARDS IN A SWITCHING DEVICE - Disclosed are, inter alia, methods, apparatus, computer-storage media, mechanisms, and means associated with subsets of the Forward Information Base (FIB) distributed among line cards in a switching device; especially wherein one or more of the line cards does not contain the complete FIB, and this line card forwards packets, for which it does not have the forwarding information, to another line card which has the forwarding information for the packet. | 08-26-2010 |
20100309919 | LABEL DISTRIBUTION PROTOCOL LABEL FILTERING - In one embodiment, a device of a particular non-backbone routing domain in a computer network determines whether each of one or more routes is reachable within the particular non-backbone domain. The device may then generate a filtered set of label mappings having only those of the one or more routes reachable within the particular non-backbone domain. Accordingly, the device may advertise label mappings only of the filtered set to one or more neighboring devices. | 12-09-2010 |
20110075680 | Forwarding of Packets Based on a Filtered Forwarding Information Base - A filtered Forwarding Information Base (FIB) (the “complete local FIB”) is used to determine how to forward packets, typically on line cards. The complete local FIB is generated by filtering (i.e., dropping or removing) extraneous entries in the standard global FIB of a router. This smaller FIB is then installed within the memory of a forwarding engine, possibly implemented as a single application-specific integrated circuit (ASIC), for use in determining how to forward packets, with the router forwarding packets accordingly. | 03-31-2011 |
20110080911 | Forwarding of Packets to a Same Location Having a Same Internet Protocol (IP) Address Embedded in a Different Advertised Route - Routes advertised in a network may include an Internet Protocol (IP) address and one or more values to distinguish the route from other route(s) including the same IP address. Routes in a same context (e.g., within a same Virtual Private Network or for an entire network) with a same IP address are considered to refer to a same destination. When these routes are associated with different paths through a network, these different paths can be used to forward traffic for packets associated with routes including a same IP address (in a same context), particularly in response to a network problem. | 04-07-2011 |
20110228785 | AUTOMATIC ROUTE TAGGING OF BGP NEXT-HOP ROUTES IN IGP - In one embodiment, a router in a routing domain exchanges routing information with one or more other routers located external to the routing domain using an exterior gateway protocol (EGP). The router exchanges routing information with one or more other routers located internal to the routing domain using an interior gateway protocol (IGP). The router detects a route to be advertised by the IGP is also used as a next-hop attribute of a route advertised by the EGP. In response, the router tags the route advertised by the IGP as an important route for convergence to indicate that the tagged route is to be processed before other routes that have not been tagged during convergence processing. The tagged route is advertised within the routing domain using the IGP. | 09-22-2011 |
20110268130 | Coordinated Updating of Forwarding Information Bases in a Multistage Packet Switching Device - Disclosed are, inter alia, methods, apparatus, computer-storage media, mechanisms, and means associated with the coordinated updating of forwarding information bases (FIBs) in a multistage packet switching device, which performs at least lookup operations on multiple different FIBs in determining how to forward a packet. One embodiment uses lookup operations on two different FIBs, with these being an ingress FIB on an ingress line card and an egress FIB on an egress line card. In response to a change in the forwarding information for a stream of packets, the egress FIBs are first updated to include both the old and new forwarding information. After all egress FIBs have been updated, the ingress FIBs are updated to use the new forwarding information. This update procedure is designed to eliminate loss or duplication of packets induced during the updating of these FIBs to use the new forwarding information. | 11-03-2011 |
20110280123 | Multicast label distribution protocol node protection - In one embodiment, a method includes receiving at a router, a multicast label distribution protocol message comprising local node information for a protected node and one or more leaf nodes downstream of the protected node in a primary label switched path, creating one or more backup label switched paths to the one or more leaf nodes, detecting a failure at the protected node, and forwarding at the router, traffic for the one or more leaf nodes to the one or more backup label switched paths. An apparatus for multicast label distribution protocol node protection is also disclosed. | 11-17-2011 |
20120002673 | Distributing Packets to Line Cards of a Packet Switching Device Based on Bridge Indication Values Received Therewith - A packet switching device maintains mappings of bridge identification values to line cards for each of multiple virtual bridges. When a packet is received that includes a bridge identification value, corresponding line card(s) are identified, with each being forwarded the packet. Each of these identified line cards, in response to receipt of the packet from the line card, determines whether to forward or drop the packet based on its maintained bridge table. In this manner, the original receiving line card does not need to maintain forwarding information based on destination addresses of received packets (e.g., does not need to maintain a bridge table for each virtual bridge), but rather forwards a packet to other line cards associated with the virtual bridge corresponding to the bridge identification value received in a packet. | 01-05-2012 |
20120027016 | Service Request Packet Including an Exterior Network Protocol Attribute - Packets are encapsulated and sent from a service node to one or more application nodes for applying one or more Layer-4 to Layer-7 services to the packets. Before which for a packet, the service node performs a lookup operation based on a destination address of the packet in a routing data structure derived from a exterior network protocol, such as, but not limited to Border Gateway Protocol (BGP). This lookup operation results in the identification of a next hop packet switching device to which the packet would be sent from the service node. The service node includes this identification of the next hop address in the request packet sent to the application node(s). After the service(s) are applied to the packet, an application node will send the services-applied packet to this next hop address. In this manner, application nodes do not need to run an exterior network protocol. Although, they typically will run an Interior Gateway Protocol for identifying how to forward packets to the next hop address. | 02-02-2012 |
20120036279 | DISTRIBUTED CONNECTIVITY VERIFICATION PROTOCOL REDUNDANCY - In one embodiment, a connectivity verification protocol (CVP) session for a particular virtual interface (VI) may operate on a particular group of two or more line cards (LCs) on a network device. The group of LCs may then transmit CVP session packets, at a reduced rate that is sufficient to maintain the CVP session based on a negotiated CVP full rate, onto the particular VI through ingress path processing on the network device. Ingress path processing, in particular, takes transmitted CVP session packets and egresses them onto an appropriate LC of the network device currently responsible for the VI egress. Also, in response to receiving CVP session packets for the VI on an LC of the network device currently responsible for the VI ingress, the receiving LC may forward the received CVP session packets to the particular corresponding group of LCs, which may then process the received CVP session packets. | 02-09-2012 |
20120063314 | UNIVERSAL LOAD-BALANCING TUNNEL ENCAPSULATION - In one embodiment, packets received at head-end nodes in a computer network may have a payload and protocol ID of an original protocol of the packet. To allow load balancing across the network, the head-end node may convert the protocol ID to indicate a UDP packet, and may insert a UDP shim header into the packet having a load balance ID, at least one port ID of a destination tail-end node of the packet, and an indication of the original protocol ID. The head-end node may transmit the converted UDP packet toward the tail-end node as part of a load-balanced UDP flow based on the load balance ID. Tail-end nodes may receive UDP packets, and determine whether they are converted UDP packets. If so, the original protocol of the packet may be determined, the UDP header may be removed, and the packet may be processed according to the original protocol. | 03-15-2012 |
20120099420 | EFFICIENT CONVERGENCE OF GROUPED VPN PREFIXES - In one embodiment, a list of border node next hop options is maintained in a memory. The list of border node next hop options includes one or more of border nodes that may be utilized to reach one or more prefixes. An index value is associated with each border node of the list of border node next hop options. A list of labels is also maintained in the memory. The index value of each border node is associated with a corresponding label for a path to reach that border node. When a change to the one or more border nodes is detected, the list of border node next hop options is updated to remove a border node. However, a label for the path to reach the border node is maintained in the list of labels for at least a period of time. | 04-26-2012 |
20120170486 | HIDING A SERVICE NODE IN A NETWORK FROM A NETWORK ROUTING TOPOLOGY - Hiding a service node in a network from a network topology is provided. In one embodiment, for example, an apparatus for hiding a service node in a network from a network topology, the apparatus comprising: a network interface; a processor; and one or more stored sequences of instructions which, when executed by the processor, cause the processor to perform: discovering a service node in a data network in accordance with a link-state protocol wherein the service node provides a network topology dependent service other than packet forwarding; establishing a link-state adjacency with the service node and one or more packet forwarding nodes in accordance with the link-state protocol; receiving a link-state advertisement; in response to identifying the link-state advertisement as an originating link-state advertisement sent from the service node, suppressing flooding of the received link-state advertisement to the one or more packet forwarding nodes. | 07-05-2012 |
20120198064 | USING CONTEXT LABELS TO SCALE MAC TABLES ON COMPUTER NETWORK EDGE DEVICES - In one embodiment, an access component of a local network edge device receives traffic, and generates a frame for the traffic that includes a remote context label that identifies an access component of the remote network edge device to which the traffic is to be forwarded upon arrival at the remote network edge device, and a virtual circuit label corresponding to a particular virtual service of the traffic. The local network edge device forwards the frame towards the remote network edge device. In another embodiment, the frame may be received at a core component of the remote network edge device, an in response to the remote context label identifying an access component of the remote network edge device, forwarded to the access component, which determines the particular virtual service, and forwards the traffic from the frame out the access component towards an endpoint for the traffic. | 08-02-2012 |
20120213222 | Single-homing and Active-Active Multi-homing in a Virtual Private LAN Service - In one embodiment, single-homing and active-active multi-homing is provided in a Virtual Private LAN Service (VPLS). A customer edge node actively communicates frames of a same Virtual Private Network (VPN) instance with two or more VPLS nodes of a VPLS network. The VPLS nodes are configured to appropriately forward frames throughout the VPLS network: without looping of a frame sent by the same external node back to the same external node, without flooding multiple copies of a frame to the same external node, and while performing learning of addresses in forwarding tables of said VPLS nodes such that said forwarding tables of said VPLS nodes converge despite frames of the same LAN service being received by said at least two of said VPLS nodes from the same external node. | 08-23-2012 |
20120213225 | Packet Switching Label Assignment Across Multiple Packet Switching Forwarding Groups - In one embodiment, a packet switching device assigns a same particular packet switching label to each particular route of a plurality of particular routes having the same one or more best paths, wherein the plurality of particular routes includes routes from at least two different forwarding groups. A forwarding group is defined as a specific route, one or more routes associated with a same customer edge router, or one or more routes associated with a single virtual routing and forwarding domain (VRF). The packet switching device advertises to other packet switching device(s) to add this same particular label to packets having one of the plurality of particular routes, which they do. The packet switching device then packet switches packets based on the particular label received in a label field in a header of these packets. | 08-23-2012 |
20120221624 | Client Diversity Policy Sharing with the Transport Layer - Diversity constraints with respect to connections or links in a client layer are conveyed to a server layer where those links or connections are served by paths in the server layer. A network device in the server layer stores data associated paths in the server layer with identifiers for connections in the client layer. The network device in the server layer receives from a network device in the client layer a request to set up a path in the server layer for a connection in the client layer. The network device in the server layer receives information describing the diversity requirements associated with connections in the client layer. The server layer network device computes a route in the server layer for the connection specified in the request based on the diversity requirements. | 08-30-2012 |
20120230335 | TRAFFIC DISTRIBUTION ACROSS A PLURALITY OF ATTACHMENT CIRCUITS OF A MULTIHOMED SITE - In one embodiment, an edge device of a core network may receive a plurality of packets from a peripheral network having a plurality of active connections to the core network, where each packet has a destination address and a source address. The edge device may compute a hash on the destination address or the source address of each packet, and determine whether the computed hash corresponds to the edge device. In response to the computed hash not corresponding to the edge device, the edge device may drop the packet, and in response to the computed hash corresponding to the edge device, the edge device may process the packet to forward the packet, where the dropping and processing load balances the plurality of packets over the active connections and prevents formation of loops in the core network. | 09-13-2012 |
20120275338 | Selectively Populating Forwarding Information Bases in a Packet Switch - In one embodiment, forwarding information bases (FIBs) are selectively populated in a packet switch. A packet switching device determines, based on one or more protocol signaling messages, a subset, which is less than all, on which FIBs a lookup operation may be performed for identifying forwarding information for a received particular packet. The packet switching device populates each of these FIBs, but not all of the FIBs of the packet switching device, with forwarding information corresponding to the particular forwarding value. Thus, FIB resources are consumed for only those FIBs which could actually be used, and not all of the FIBs, for forwarding packets in the data plane of the packet switching device, whether these packets are received on a primary or backup path. | 11-01-2012 |
20120287935 | INTERIOR GATEWAY PROTOCOL SUMMARIZATION PRESERVING INTERNET PROTOCOL REACHABILITY INFORMATION - In one example embodiment, a system and method is illustrated that includes receiving connectivity data for at least one network device, the connectivity data describing a connection to the at least one network device within an area. The system and method further includes processing the connectivity data to obtain a routing update for distribution to another network device outside the area. Additionally, the system and method includes a routing summary in the routing update, the routing summary including an address prefix. Further, the system and method includes reachability information in the routing update, the reachability information including an address for the at least one network device. | 11-15-2012 |
20130088974 | Avoiding Micro-loops in a Ring Topology of a Network - In one embodiment, micro-loops are avoided in ring topologies of packet switching devices by changing the order of propagation of link state information concerning failed communications between a particular packet switching device and a neighbor packet switching device. In one embodiment, the particular packet switching device communicates link state information of a high cost of the particular communications (e.g., in the direction from particular to neighbor packet switching devices) such that this link state information will propagate towards the particular packet switching device from at least from the furthest packet switching device in the ring topology that is currently configured to forward packets having a destination address of the neighbor packet switching device through the particular packet switching device. | 04-11-2013 |
20130089097 | Forwarding IPv6 Packets based on Shorter Addresses Derived from Their IPv6 Destination Addresses - In one embodiment, a packet switching device is configured to convert an Internet Protocol Version 6 (IPv6) destination address, of a received particular IPv6 packet, to a second, shorter destination address. This second destination address is then used to determine forwarding information for the received IPv6 packet, which is forwarded accordingly. In one embodiment, this second address is a 32-bit address, and in particular, an Internet Protocol Version 4 (IPv4) address. Thus, one embodiment can use the IPv4 forwarding infrastructure of a packet switching device for determining how to forward IPv6 packets. In a network according to one embodiment, packets are encapsulated in an IPv6 packet using an IPv6 destination address (that can be converted to an IPv4 address) of an egress edge packet switching device. Thus, core packet switching devices can forward IPv6 packets using IPv4 lookup operations. | 04-11-2013 |
20130223228 | Resilient Forwarding of Packets with a Per-Customer Edge (per-CE) Label - In one embodiment, a packet switching device is configured to perform a lookup operation, based on a particular per-CE label (per-Customer Edge label) included in a particular packet, in a forwarding data structure for identifying forwarding information for the particular packet. When a corresponding outbound path is unavailable, a per-VRF (per-Virtual Routing and Forwarding) lookup operation in a VRF data structure, identified based on the particular per-CE label, based on a destination address of a packet encapsulated within the received packet. A corresponding packet is forwarded based on the results of the VRF lookup operation. In one embodiment, a set of more than one egress line card is identified based on this lookup operation, and packets of different routes are load balanced among egress line cards in this identified set of egress line cards. | 08-29-2013 |
20130232193 | Control-Plane Interface Between Layers in a Multilayer Network - In one embodiment, information is exchanged between independent control planes of different layers in a multilayer network, such as, but not limited to, between a packet switching client-layer network and an optical server-layer network. This exchanged information includes signaling regarding a server-layer communications service, having server-layer characteristics, within the server-layer network for use in communicatively coupling at least two devices of the client-layer network. In one embodiment, the client-layer network specifies at least one of these server-layer characteristics that the server-layer communications service provided by the server-layer network must have. In one embodiment, the server-layer network signal to the client-layer network at least one of these server-layer characteristics of the existing server-layer communications service. In one embodiment, this signaling between the client-layer network and the server-layer network includes sending extended Resource Reservation Protocol (RSVP) messages. | 09-05-2013 |
20130254359 | ADDRESS RESOLUTION SUPPRESSION FOR DATA CENTER INTERCONNECT - An example method is provided that includes determining whether an address resolution protocol reply from a local machine has been received at an edge node; updating a local cache based on the reply from the local machine; and sending the reply to a plurality of edge nodes through a data plane of a data center interconnect. In more specific implementations, the method can include determining whether an address resolution protocol request has been received from the local machine. The method could also include updating a local machine cache based on the request. In certain implementations, the method can include determining whether the request is targeting the local machine; and dropping the request if the request is targeting the local machine. The method could also include sending the request through the data center interconnect if the request is not targeting the local machine. | 09-26-2013 |
20130265881 | ROUTE CONVERGENCE MONITORING AND DIAGNOSTICS - In one embodiment, a method includes assigning an identifier to a route computation at a network device, grouping route updates for the route computation, marking at least one route update for each group of route updates with the identifier, tracking flow of marked route updates at a plurality of routing components within the network device, and storing tracking data at the network device for use in convergence monitoring. An apparatus and logic are also disclosed herein. | 10-10-2013 |
20130265894 | NETWORK AVAILABILITY ANALYTICS - In one embodiment, a method includes receiving at a network device, route convergence measurements and traffic demand measurements from a plurality of routers, and computing network availability based on the measurements at the network device. The route convergence measurements are associated with route computations at the routers and the traffic demand measurements include portions of a demand matrix associated with the routers. An apparatus and logic are also disclosed herein. | 10-10-2013 |
20130265905 | DISTRIBUTED DEMAND MATRIX COMPUTATIONS - In one embodiment, a method includes receiving a packet at a first network device, logging the packet into a demand corresponding to a cell of a demand matrix, and storing the demand in a demand database at the first network device. The demand database includes a plurality of demands computed for a specified time period and corresponding to cells of the demand matrix associated with traffic entering a network at the first network device. Demands corresponding to cells of the demand matrix associated with traffic entering the network at a second network device are computed and stored at the second network device. An apparatus and logic are also disclosed herein. | 10-10-2013 |
20130336107 | DYNAMICALLY TRIGGERED TRAFFIC ENGINEERING ROUTING ADVERTISEMENTS IN STATEFUL PATH COMPUTATION ELEMENT ENVIRONMENTS - In one embodiment, a device (e.g., a path computation element, PCE) monitors a tunnel set-up failure rate within a computer network, and determines whether to adjust an accuracy of routing information based on the tunnel set-up failure rate. For instance, the tunnel set-up failure rate being above a first threshold indicates a need for greater accuracy. In response to the tunnel set-up failure rate being above the first threshold, the device may then instruct one or more routers to shorten their routing update interval in the computer network. | 12-19-2013 |
20130336116 | CONGESTION-BASED NOTIFICATION DURING FAST REROUTE OPERATIONS IN STATEFUL PATH COMPUTATION ELEMENT ENVIRONMENTS - In one embodiment, once activation of use of a backup tunnel is detected for a primary tunnel, then a level of congestion of the path of the backup tunnel may be determined. In response to the level being greater than a threshold, a head-end node of the primary tunnel is triggered to reroute the primary tunnel (e.g., requesting to a path computation element). Conversely, in response to the level not being greater than the threshold, the backup tunnel is allowed to remain activated. | 12-19-2013 |
20130336126 | TIME-BASED SCHEDULING FOR TUNNELS COMPUTED BY A STATEFUL PATH COMPUTATION ELEMENT - In one embodiment, a path computation element (PCE) in a computer network receives one or more path computation requests (PCReqs), and records a time of each PCReq and the corresponding requested bandwidth. Based on this information, the PCE may determine a traffic profile of the computer network, and may augment a traffic engineering database (TED) with requested bandwidth according to time based on the traffic profile. As such, prior to a particular time, the PCE may determine placement of tunnels within the traffic profile for the particular time. | 12-19-2013 |
20140098675 | MPLS SEGMENT-ROUTING - MPLS segment routing is disclosed. In one embodiment, a first core router generates a first data structure that maps first portcodes to respective identities of first neighbor routers or respective first links, wherein the first portcodes identify respective first ports of the first core router, and wherein the first ports are coupled to the first neighbor routers, respectively, via the first links, respectively. The first core router generates and transmits a first link-state packet, wherein the first link-state packet comprises an identity of the first core router and the first data structure. | 04-10-2014 |
20140101335 | Identifying, Translating and Filtering Shared Risk Groups in Communications Networks - A method, apparatus, and computer-readable storage medium for processing shared risk group (SRG) information in communications networks are disclosed. The method includes receiving network information comprising SRG information from a second domain at a first domain, obtaining at least one SRG identifier by processing the SRG information, and processing the at least one SRG identifier, the processing using processing criteria. The apparatus includes a network interface adapted to receive network information comprising shared risk group information, a processor coupled to the network interface and configured to execute one or more processes, and a memory coupled to the processor and adapted to obtain at least one SRG identifier by processing the SRG information and to process the at least one SRG identifier using processing criteria. The computer-readable storage medium is configured to store program instructions that when executed are configured to cause the processor to perform the method. | 04-10-2014 |
20140126355 | IDENTIFYING, TRANSLATING AND FILTERING SHARED RISK GROUPS IN COMMUNICATIONS NETWORKS - A method, apparatus, and computer-readable storage medium are disclosed for processing shared risk group (SRG) information in communications networks. The method includes obtaining at least one SRG identifier by processing SRG information included in network information received at a first network layer from a second network layer, and processing the at least one SRG identifier using one or more operations configured to ensure that the SRG identifier is unique among a plurality of SRG identifiers. The apparatus includes a network interface adapted to receive network information comprising SRG information, a processor coupled to the network interface, and a memory coupled to the processor and adapted to obtain at least one SRG identifier by processing the SRG information and to process the at least one SRG identifier. The computer-readable storage medium is configured to store program instructions that when executed are configured to cause a processor to perform the method. | 05-08-2014 |
20140169370 | Segment Routing Techniques - An apparatus and method is disclosed for segment routing (SR). In one embodiment, the method includes a node creating a segment stack that identifies one segment calculated using a first algorithm and a second segment calculated using a second, different algorithm. The node then attaches this header to a packet and sends it to another node. | 06-19-2014 |
20140192630 | GRACEFUL HANDLING OF CRITICAL TRAFFIC BLACKHOLING FAULTS - In one embodiment, a network device may detect a data plane critical fault condition, while a corresponding control plane is not experiencing a critical fault condition. In response to a network device based critical fault condition, the network device may activate and advertise an increased and expensive usable metric for each network interface of the network device. On the other hand, in response to an interface based critical fault condition, the network device may activate and advertise an increased and expensive usable metric for one or more particular network interfaces of the interface based critical fault, and signals, over the control plane to a corresponding network device at an opposing end of each particular network interface of the interface based critical fault, a request to activate and advertise an increased and expensive usable metric at the opposing end of each particular network interface. | 07-10-2014 |
20140211794 | Signaling Using a Time-to-Live (TTL) Field of a Packet - In one embodiment, a Time-to-Live (TTL) field of a packet is used to signal information (other than normal other than a life span of the packet or distance information relative to the network node). The packet is sent through a network, which typically includes traversing one or more intermediate nodes resulting in a modification of its TTL field (e.g., each node reduces the TTL value). After receiving the packet, a network node interprets the current value of the TTL field to identify the particular information encoded in the TTL field. Typically the current value of the TTL field is compared to a range of possible values to accommodate different TTL reductions due to different paths through a network. Signaling using the TTL value may be advantageous in networks that perform Equal-Cost-Multi-Path (ECMP) routing as the TTL value does not effect this routing. | 07-31-2014 |
20140233946 | Replacing an Existing Network Communications Path with a New Path Using Some Exclusive Physical Resources of the Existing Path - In one embodiment, a replacement network communications path is determined using dedicated resources of an existing path. One or more network elements in a network determines a new communications path between a first network node and a second network node in the network while an existing communications path is currently configured in the network to carry traffic between the first and second network nodes. The existing communications path includes one or more exclusive physical resources dedicated to the existing communications path. The new communications path includes at least one of said exclusive physical resources dedicated to the existing communications path. One embodiment includes: subsequent to said determining the new communications path, removing the existing communications path from service, and then instantiating the new communications path, with the new communications path including said at least one of said exclusive physical resources. | 08-21-2014 |
20140258486 | Server-Layer Shared Link Risk Group Analysis to Identify Potential Client-Layer Network Connectivity Loss - In one embodiment, a particular device within a client-layer network maintains client-layer topology information including server-layer Shared Risk Link Group (SRLG) information of server-layer devices and links in a server-layer network associated with client-layer links and client-layer nodes in the client-layer network. A determination is made to discover if there is an alternative client-layer path to an established client-layer path between a first packet switching device and a second packet switching device if all server-layer resources of any particular server-layer SRLG of a plurality of total server-layer SRLGs associated with the established client-layer path become unavailable. In one embodiment, the plurality of total server-layer SRLGs includes: an SRLG of a same optical node, an SRLG of a same optical fiber, an SRLG of co-located plurality of optical nodes, and/or an SRLG of co-located plurality of optical fibers. | 09-11-2014 |
20140269266 | METHOD AND SYSTEM FOR PATH MONITORING USING SEGMENT ROUTING - A method and system are disclosed for use of segment routing in monitoring of a network path. In one embodiment, the method includes selecting a plurality of segment identifiers and assembling the segment identifiers into a segment identifier stack, where the segment identifier stack encodes a test path within the network for attempted routing of a test message. The method may further include inserting the segment identifier stack into a header associated with the test message, and forwarding the test message according to an entry in a forwarding table corresponding to the segment identifier at the top of the segment identifier stack. Interior gateway protocol advertisements may be used to communicate segment identifiers for creating or updating of the data structure or the forwarding table. In an embodiment, the system includes one or more network interfaces and a processor configured to perform the steps of the method. | 09-18-2014 |
20140270771 | Network Server Layer Providing Disjoint Channels in Response to Client-Layer Disjoint Path Requests - In one embodiment, a network server layer provides disjoint channels in response to client-layer disjoint path requests. For example, the network layer can be an optical network, and the client layer may be a packet switching layer (e.g., label switching, Internet Protocol). In one embodiment, a server-layer node receives a client-layer disjoint path request to provide a server-layer channel through a server-layer network. The client-layer disjoint path request includes an identifier corresponding to an existing client-layer path that traverses a current channel through the server-layer network that does not include the server-layer node. The server-layer network determines a particular channel through the server-layer network that is disjoint to the current channel based on route information of the current channel, and then signaling is performed within the server-layer network to establish the particular channel. | 09-18-2014 |
20140341222 | SEGMENT ROUTING MAPPING SERVER FOR LDP/SR INTEROPERABILITY - An apparatus and method for enabling interoperability of segment routing (SR) enabled nodes and LDP enabled nodes in a network domain. In one embodiment, the method may include mapping a first node identifier (ID) to a first segment ID in memory, wherein the first node ID uniquely identifies a first node within a network domain, and wherein the first node is not SR enabled. A message is generated and subsequently transmitted directly or indirectly to another node within the network domain, wherein the message comprises the first node ID mapped to the first segment ID, and wherein the other node is SR enabled. | 11-20-2014 |
20150043570 | DISCOVERY OF CONNECTIVITY AND COMPATIBILITY IN A COMMUNICATION NETWORK - In one embodiment, a method includes receiving at a node in a first network, information identifying a spare interface between a first network device in the first network and a second network device in a second network, and using the spare interface to create a path in the first network if the spare interface is compatible. The spare interface information includes connectivity and compatibility information. | 02-12-2015 |
20150085860 | DISTRIBUTED CONNECTIVITY VERIFICATION PROTOCOL REDUNDANCY - In one embodiment, a connectivity verification protocol (CVP) session for a particular virtual interface (VI) may operate on a particular group of two or more line cards (LCs) on a network device. The group of LCs may then transmit CVP session packets, at a reduced rate that is sufficient to maintain the CVP session based on a negotiated CVP full rate, onto the particular VI through ingress path processing on the network device. Ingress path processing, in particular, takes transmitted CVP session packets and egresses them onto an appropriate LC of the network device currently responsible for the VI egress. Also, in response to receiving CVP session packets for the VI on an LC of the network device currently responsible for the VI ingress, the receiving LC may forward the received CVP session packets to the particular corresponding group of LCs, which may then process the received CVP session packets. | 03-26-2015 |