Patent Application
20050094566
This invention is related to the field of networking, and more particularly, to protocols and algorithms for routing in networks.
In communications networks such as the Internet, information is transmitted in the form of packets. A packet comprises a unit of digital information that is individually routed hop-by-hop on from a source to a destination. The routing of a packet entails that each node, or router, along a path traversed by the packet examines header information in the packet to compare this header against a local database; upon consulting the local database, the router forwards the packet to an appropriate next hop. This local database is typically called the Forwarding Information Base or FIB. The FIB is typically structured as a table, but may be instantiated in alternative formats. Entries in the FIB determine the next hop for the packet, i.e., the next router, or node, to which the respective packets are forwarded in order to reach the appropriate destination. The Forwarding information Bases are usually derived from global or network-wide information from a collective database. Each protocol names the collective databases to denote the type of information. Such databases are referred to generically herein as Network Information Bases (NIBs).
In implementations of the Internet Protocol (IP), the FIB is typically derived from a collective database, i.e., a NIB, referred to as a Routing Information Database or RIB. A RIB resident on a router amalgamates the routing information available to that router; one or more algorithms are typically used to map the entries, e.g., routes, in the RIB to those in the FIB, which, in turn, is used for forwarding packets to their next hop. The IP RIB may be constructed by use of two techniques, which may be used in conjunction: (a) static configuration and (b) dynamic routing protocols. Dynamic IP routing protocols may be further subdivided into two groups based on the part of the Internet in which they operate: exterior gateway protocols, or EGPs, are responsible for the dissemination of routing data between autonomous administrative domains, and interior gateway protocols, or IGPs, are responsible for dissemination of routing data within a single autonomous domain. Furthermore, two types of IGPs are in widespread use today: those that use a distance-vector type of algorithm and those that use the link-state method.
Route Selection Policies and EGPs
Routers typically support route selection policies which enable the identification of a best route amongst alternative paths to a destination. Routing selection policies may be pre-defined by a protocol, or may be otherwise distributed through a network, either statically or dynamically. An example of an EGP protocol which predefines route selection policies is exemplified by the Border Gateway Protocol version 4 (BGP-4), which allows route selection policy based on destination address and the BGP Path information. Routers also typically support route distribution policies, which govern the determination of which routes are sent to particular peers. Route distribution policies may be pre-defined by a protocol, statically configured, or dynamically learned. Dynamically learned policies can, in turn, be forwarded to a router within the same routing protocol, or, alternatively, forwarded via a separate protocol. As illustrative examples, BGP-4 allows for the inclusion of outbound route filter policies within BGP packets; the Rout Policy Server Language sends route distribution policy in a separate protocol. Some BGP-4 peers add or subtract BGP communities from e-BGP-4 path attributes, to mitigate policy processing on recipient peers. The addition of the BGP-4 Communities is sometimes called coloring of “dyeing” BGP-4 routes.
Link State Protocols
Link state routing protocols are typically based on a set of features uniquely tuned for each protocol. These features include:
The sub-protocols for neighbor acquisition typically include indications for whether a link is up or down, and the creation of peer adjacencies. Extensions to the link state protocols are also available which allow for improved scaling. These extensions include:
Examples of common link state protocols include OSPF and IS-IS. OSPF and IS-IS support two levels of hierarchy within the area of the network. Extensions to IS-IS in M-ISIS allow multiple Routing Information Bases (REIBs) with multiple level topologies be passed in the IS-IS protocol. Both the OSPF and ISIS protocols use a “hello” packet to signal that a peer is up on a link. A 2-way hello sequence between two peers involves the 1st peer sending a hello and the 2nd peer responding to the hello. A 3-way hello sequence between two peers involves the 1st peer sending a hello, the 2nd peer responding with a hello, and the 3rd peer responding with a third hello. Some hello sequences in other protocols (e.g., PLP) utilize a “heard-you” flag to indicate that the 2nd hello is in response to the first. Peer adjacency databases are generated per level per RIB, as are Shortest Path First (SPF) calculations; OSPF and ISIS utilize modified Dijkstra algorithms to compute shortest paths.
Path Vector Protocols
A prominent example of a path vector protocol is the Border Gateway Protocol, BGP v4. In this protocol, reachability information is passed from BGP-specific routers. Such reachability information may be inserted from Internal Gateway Protocols (IGPs), examples of which include OSPF, ISIS, RIP, IGRP or E-IGRP, an Exterior Gateway Protocol (EGP), which, in this case, is BGP, or static routes. BGP policy operates on the information contained in the route (for e.g., reachable prefix, AS Path, Path Attributes, NextHop router), the peer the route was received from, and the interface with which the route was associated. The Policy processing returns a metric that is associated with the route. Two routes first compare the two policy values to select the best route to be used. If the policy values are the same, the BGP protocol breaks ties between the two routes by comparison of the following:
Additionally, some implementations extend the BGP-4 specification to include the use the “time” of route creation for tie-breaking. The prior art evinces a need for routing techniques which combine features of link state and path vector protocols. There is also a need for such new techniques to be interoperable with existing internet infrastructure. These and other objectives are addressed by the invention described herein.
This invention includes packet formats for routing protocols which combine link state and path vector routing techniques. Such protocols are referred to as Link State Path Vector (LSPV) protocols. Embodiments of the invention include extensions to protocols such as the Border Gateway Protocol (BGP) and Intermediate Standard to Intermediate Standard (IS-IS). Embodiments of the invention include packet formats for LSPV protocols which align the bytes of the one or more LSPV protocols with bytes in formats for protocols in the prior art. These and other embodiments of the invention are described in further detail herein.
Introduction: Link State Path Vector Protocols
The concept of Link State Path Vector protocols is further described in U.S. utility application 10/648,758. LSPVs may include extensions to existing link state or path vector protocols. Embodiments of the invention include templates common to all LSPVs. Such embodiments include common formats for packet headers and PDUs, which may be overlayed over existing protocol formats. One such overlay format is illustrated in
Table 1 below describes the individual fields in the LSPV header overlay 100.
In embodiments of the invention, LSPV protocols may include one or more of the following types of messages, or Packet Data Units (PDUs):
These PDUs are elaborated upon further herein.
BGP LSPV
One extension of an existing path vector protocol to an LSPV, in accordance with embodiments of the invention, is an extension of BGP, referred to herein as BGP LSPV. In embodiments of the invention, BGP LSPV is a Link-State Path Vector protocol (LSPV) which utilizes a link-state algorithm to calculate the BGP peer topology over virtual links. The BGP Path Vector allows multiple paths for a BGP route weighted by a vector. The Path Vector portion of BGP utilizes routing policies to determine the vector of weights associated with each routes. In embodiments of the invention, the Link State Path Vector combines these two calculations for each route.
In embodiments, BGP LSPV peers are connected via a virtual link topology, which may or may not comprise full mesh topologies. BGP LSPV peers can be layered into multiple levels of Peer interconnection within a policy domain; a policy domain may comprise a single Autonomous System (AS) or multiple ASs, as further described in U.S. application Ser. No. 10/648,141, which is hereby incorporated by reference in its entirety. In embodiments of the invention, BGP LSPV peers can communicate as I-BGP peers with n-levels, or as I-BGP and E-BGP peers at n-levels within an Autonomous System Confederations, or as I-BGP and E-BGP at n-levels within a policy domain.
In embodiments of the invention, BGP LSPV establishes peer sessions with BGP-4 peers via TCP connections, or with other BGP LSPV peers via TCP connections, GRE Tunnels or Multicast groups within an Autonomous System (AS). In embodiments of the invention, these peers exchange one or more of the following types of packets:
In embodiments of the invention, each of the packets has a fixed header and a variable amount of additional information following the PDU header. The variable information is formatted in Type-Length-Value (TLV) fields. Each TLV field may be in turn broken down into a variable length sub-TLV field. Each sub-TLV field may in turn be broken down into other sub-fields.
The Hello packets are used to establish a connection between BGP peers. The Link State Packet transmits data between two peers. The CSNP and PSNP are used to indicate which link state packets need to be resent to peers. The CSNP and PSNP allow flooding to resend any missed packets and to age out by flooding any over long packet. The Policy packets allow for BGP policy to be sent to a peer out of band from the normal Link State Packets. The BGP-v4 compatibility packet allows passage of the BGP LSPV packets.
Overlay of the Hello Header for All LSPV Protocols
Embodiments of the invention include overlays for Hello messages in LSPV protocols.
Table 2 describes the individual fields of the overlay format for Hello messages in LSPV 200 in accordance with embodiments of the invention.
Variable Header Fields for Hello PDUs
In embodiments of the invention, the Hello PDU includes variable fields, which may, in turn, be used to transmit BGP parameters. In some embodiments, these parameters may include one or more of the following:
Standard Variable Fields:
In embodiments of the invention, these optional variable fields may be expanded upon as follows:
Embodiments of the invention may utilizes the following default format:
Embodiments of the invention include overlays for Link State messages in LSPV protocols. Table 3 lists field types in headers for link state messages in accordance with embodiments of the invention.
In embodiments of the invention, Link State messages may further include one or more variable fields, examples of which are provided below:
Fixed header
Link State
In embodiments of the invention, Link State messages may also include one or more of the following optional headers:
In embodiments of the invention, these optional variable fields may be expanded upon as follows:
Embodiments of the invention support the communication of Complete Sequence Number Packets in LSPVs. In embodiments, the complete sequence number (CSN) packet indicate the life time, checksum and authentication of LSPs already sent. The CSN provides a range of information handled by this PDU.
An example format for CSN PDUs, in accordance with embodiments of the invention, is presented in Table 4.
In some embodiments, the LSP-ID format is as follows:
This format of the LSP allows IS-IS and BGP v4 to run on the same connection as BGP-LSPV. Other suitable LSP ID formats shall be apparent to those skilled in the art.
In embodiments of the invention, CSN packets may include one or more variable fields. An example format for such variable fields is provided in Table 5.
Partial Sequence Number PDU
Embodiments of the invention allow Partial Sequence Number (PSN) messages to be communicated in LSPVs. An example of a format for such PSNs in accordance with embodiments of the invention is presented in Table 6.
In embodiments of the invention, PSNs may include variable fields, such as those presented in Table 7 below.
Variable fields may also include one or more of the following:
Embodiments of the invention support the communication of policy filters in LSPVs, which contain a complete sequence number PDU listing the IDs of all LSP sent by the given node. A header format used for such policy filters in accordance with embodiments of the invention is presented in Table 8.
In embodiments of the invention, the Policy Filter PDUs may include variable fields, which may include one or more of the following:
In embodiments of the invention, BGP-LSPV can co-exist with a BGP-4 peer on the same packets. The BGP4 header includes 16 bytes of marker. The BGP-LSPV fixed header overlays the marker field of the BGP-4 packets. Currently the BGPv4 specification indicates that the marker bytes is all I s. In embodiments of the invention, the BGP-LSPV header allows for this marker field to be stuffed within it. In some such embodiments, , the intra-domain routing protocol Discriminator is set as 0×85 as an architectural constant for BGP-LSPV. 0×85 was used by IDRP, an ISO Version of BGP.
In embodiments of the invention, the header portion of the BGP-LSPV packets are the same format as the IS-IS packets with a 6 octet ID field and additional variable length fields at the end. The header portion of the BGP-LSPV packets can also overlay the maker field of the BGP-4 packets. These overlays provide BGP-LSPV with the ability to co-exist with either the BGP-4 or BGP-LSPV protocol on a link. The discriminating factor is the intra-domain routing protocol discriminator 0×85 that indicates this is a BGP-LSPV protocol.
In embodiments of the invention, the BGP-4 packets may initiate the connection with the following exchange:
Hello/Open [BGP LSPV hello/BGP v4 Hello]→
←—Hello/Open [BGP LSPV/BGP v4]
←BGP4/Keepalive [BGP LSPV/BGPv4]
In the event of a failure, in embodiments of the invention the BGP-4 may take down the connection with:
BGP4/Notify→
A PDU format for such headers, in accordance with embodiments of the invention, is presented in Table 9
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This application claims priority to U.S. Provisional Application No. 60/511,281, filed Oct. 14, 2003, entitled “PACKET FORMATS FOR ADVANCED ROUTING PROTOCOLS” and U.S. Provisional Application No. 60/511,404, filed Oct. 14, 2003, entitled “OVERLAYING LSPV PACKETS ON ISIS, OSPF, AND BGP-4 PACKET HEADERS” each of which are hereby incorporated by reference in their entirety. This application is related to U.S. Utility Application No. 10/648,141, filed Aug. 25, 2003, entitled “ESTABLISHMENT AND ENFORCEMENT OF POLICIES IN PACKET-SWITCH NETWORKS”, U.S. Utility Application No. 10/648,146, filed Aug. 25, 2003, entitled “NESTED COMPONENTS FOR NETWORK PROTOCOLS,” and U.S. Utility Application No. 10/648,758, filed Aug. 25, 2003, entitled “SYSTEMS AND METHODS FOR ROUTING EMPLOYING LINK STATE AND PATH VECTOR TECHNIQUES,” each of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60511281 | Oct 2003 | US | |
| 60511404 | Oct 2003 | US |
