Patent Description:
BGP (Border Gateway Protocol) is protocol that manages the transmission of packets across the Internet through the exchange of routing and reachability information between edge network elements (NEs), such as routers, positioned within a communications system. BGP directs packets between autonomous systems (AS), or networks managed by a single enterprise or service provider. BGP offers network stability guaranteeing that network elements (NEs) can quickly adapt to send packets through another reconnection if a particular path fails. An NE implementing BGP (e.g., a BGP NE) performs routing decisions based on paths, rules, or network policies configured by a network administrator.

The BGP NE maintains a routing table containing routing information from both directly connected NEs connected to an external AS as well as NEs within the same AS, and continually updates the routing table as changes occur. The BGP NE sends updated routing information through all the NEs in the communications system every time a change occurs to the routing information. A technical document by <NPL>, relates to BGP for Internet Service Providers.

The dependent claims recite advantageous embodiments of the invention.

It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims.

<FIG> is a diagram illustrating a communications system <NUM> configured to implement controller Border Gateway Protocol (cBGP) according to various embodiments of the disclosure. The communications system <NUM> includes two autonomous systems, AS <NUM> and AS <NUM>. The AS <NUM> includes NEs <NUM> and <NUM>, and the AS <NUM> comprises NEs <NUM>-<NUM>. In <FIG>, the NEs <NUM>-<NUM> are interconnected by links <NUM>-<NUM>. Links <NUM> and <NUM> are inter-domain links connecting NEs within a different AS <NUM> and AS <NUM> (e.g., NE <NUM> to NEs <NUM> and <NUM>). Links <NUM>-<NUM> are intra-domain links connecting NEs <NUM>-<NUM> within a single AS <NUM>.

NEs <NUM>-<NUM> may be a physical device, such as a router, a bridge, a virtual machine, a network switch, or a logical device configured to perform switching and routing according to various routing protocols. As described herein, NEs <NUM>-<NUM> are configured to implement BGP.

Links <NUM>-<NUM> may be wired or wireless links or interfaces interconnecting each of the NEs <NUM>-<NUM> and configured to forward traffic according to various routing protocols, such as BGP. BGP is further defined in the Inter-Domain Routing Working Group (IDR WG) Request for Comments (RFC) <NUM>, entitled "<NPL> (hereinafter referred to as RFC <NUM>).

BGP sessions between NEs <NUM>-<NUM> in different ASs are referred as external BGP (eBGP) sessions or connections. For example, a BGP session between NE <NUM> and NE <NUM> or between NE <NUM> and NE <NUM> is an eBGP session. In contrast, BGP sessions between NEs of the same AS are referred to as internal BGP (iBGP) sessions or connections. For example, a BGP session between NE <NUM> and NE <NUM> and between NE <NUM> and NE <NUM> is an iBGP session. Two NEs <NUM>-<NUM> that have established an iBGP session are referred to as iBGP peers. Similarly, two NEs <NUM>-<NUM> that have established an eBGP session are referred to as eBGP peers.

In <FIG>, NE <NUM> is designated as a BGP Route Reflector (RR) for the communications system <NUM>, in which the NE <NUM> is directly or indirectly connected to the remaining NEs <NUM>-<NUM> and <NUM>-<NUM> of the communications system <NUM>. In an embodiment, the NE <NUM> implemented as the RR may be configured to act as a controller, or central entity, of the communications system <NUM>.

Within the communications system <NUM>, the NEs <NUM>-<NUM> are configured to communicate four different types of messages that are specified for BGP Version <NUM>, as described by RFC <NUM>: an OPEN message, an UPDATE message, a NOTIFICATION message, and a KEEPALIVE message. An OPEN message establishes a BGP session. Both sides of the BGP session negotiate session capabilities before establishing a BGP session using the OPEN message. In accordance with some embodiments, an OPEN message includes a version, AS number, hold timer, and some optional parameters. In particular, an OPEN message may optionally contain a capabilities type length value (TLV), indicating a capability of the NE <NUM>-<NUM> sending the OPEN message.

After a BGP session is established, the UPDATE and/or KEEPALIVE messages are selectively exchanged between session participants. UPDATE messages are central to BGP and contain all the necessary information that BGP uses to construct a loop-free forwarding path. The UPDATE message advertises any feasible routes, withdraws previously advertised routes, or can include both. The three basic blocks of an UPDATE message include Network Layer Reachability Information (NLRI), path attributes, and withdrawn (unfeasible) routes. For example, an UPDATE message includes a withdrawn routes length field (<NUM> octets), a withdrawn routes field (variable length), a total path attribute length field (<NUM> octets), a path attributes field (variable length), and a NLRI field (<NUM> octets).

The NLRI field is encoded as one or more <NUM>-tuples of the form <Length, Prefix>, where the Length parameter indicates the length in bits of the internet protocol (IP) address prefix and the Prefix parameter indicates an IP address prefix. For example, an NLRI field with the value <<NUM>, <NUM>. <NUM>> indicates network reachability information for the route <NUM>. <NUM>/<NUM>. The path attributes field comprises a set of parameters used to keep track of route-specific information such as ORIGIN, AS-PATH, NEXT-HOP, MULTI-EXIT-DISC, LOCAL-PREF, and so on.

Whenever an error is detected, a NOTIFICATION message is sent and the connection is closed. The NOTIFICATION message includes an error code indicating the specific type of error that is detected.

When an NE <NUM>-<NUM> implementing iBGP or eBGP generates or receives routing information, such as in an UPDATE message, the NE <NUM>-<NUM> forwards the routing information to neighboring NEs <NUM>-<NUM> that also implement BGP. For example, when NE <NUM> transmits an UPDATE message carrying routing information of a certain path toward a destination to NE <NUM>, NE <NUM> is first configured to update a local routing table based on the UPDATE message when applicable to the NE <NUM>. Subsequently, NE <NUM> forwards the UPDATE message based on the local routing table and policy to neighboring BGP peers. The neighboring BGP peers that receive the UPDATE message similarly process the UPDATE message to determine whether the local routing table needs to be updated based on the routing information carried in the UPDATE message and then forwards the UPDATE message based on the local routing table and policy to neighboring peers.

However, often times, NEs <NUM>-<NUM> (or BGP peers) receive routing information via BGP messages, without having any use or need for the routing information. Therefore, these NEs <NUM>-<NUM> that receive unwanted routing information merely discard the routing information or forward the routing information to other NEs <NUM>-<NUM>, which may also not have any use or need for the routing information.

For this reason, NEs <NUM>-<NUM> implementing iBGP or eBGP flood network resources with these messages carrying routing information, even though several of the NEs <NUM>-<NUM> in the communications system <NUM> simply ignore or discard the message. In this way, communication systems implementing BGP, either iBGP and/or eBGP, typical incur a large amount of unnecessary overhead.

Disclosed herein are embodiments directed to a modified, lightweight version of BGP, referred to herein as cBGP, in which NEs that have established a cBGP session (referred to herein as cBGP NE) may only be permitted to communicate a particular type of information. In an embodiment, an NE <NUM> establishes a cBGP session with NEs <NUM> and <NUM>. NEs <NUM> and <NUM> may be referred to herein as cBGP peers due to the cBGP session established between NE <NUM> and NE <NUM>. Similarly, NEs <NUM> and <NUM> may be referred to herein as cBGP peers due to the cBGP session established between NE <NUM> and NE <NUM>.

In this embodiment, NE <NUM> may only be permitted to communicate control messages to the NEs <NUM> and <NUM> through the cBGP session. For example, the control messages may include instructions that are sent to the NEs <NUM> and <NUM>. Similarly, NEs <NUM> and <NUM> are only permitted to transmit responses to the instructions or status information to the NE <NUM> through the cBGP session. In an embodiment, route information, such as the route information carried in an UPDATE message, is prohibited from being communicated between NE <NUM> and NEs <NUM> and <NUM> through the cBGP sessions.

For example, in <FIG>, NE <NUM> has established an eBGP session with NEs <NUM> and <NUM>, an iBGP session with NEs <NUM> and <NUM>, and a cBGP session with NEs <NUM> and <NUM>. In this case, when NE <NUM> receives routing information from one of the eBGP peers, such as NE <NUM>, NE <NUM> may forward the routing information to another eBGP peer (e.g., NE <NUM>), or an iBGP peer (e.g., one of NEs <NUM> or <NUM>). However, NE <NUM> is prohibited from forwarding the routing information to one of the cBGP peers (e. g, NEs <NUM> or <NUM>).

When NE <NUM> receives routing information from an iBGP peer as a client, such as NE <NUM>, NE <NUM> may forward the routing information to one of the eBGP peers (e.g., NEs <NUM> or <NUM>), the other iBGP peer (e.g., NE <NUM>), another iBGP client NE, or an iBGP non-client NE. However, NE <NUM> is prohibited from forwarding the routing information to one of the cBGP peers (e. g, NEs <NUM> or <NUM>).

When NE <NUM> receives routing information from an iBGP peer as a non-client, such as NE <NUM>, NE <NUM> may forward the routing information to one of the eBGP peers (e.g., NEs <NUM> or <NUM>), an eBGP client, the other iBGP peer (e.g., NE <NUM>), or an iBGP client. However, NE <NUM> is prohibited from forwarding the routing information to one of the cBGP peers (e. g, NEs <NUM> or <NUM>) or a non-client NE. In some cases, when NE <NUM> receives routing information from another iBGP peer (e.g., NEs <NUM> and <NUM>) or another eBGP peer (e.g., NEs <NUM> and <NUM>), the routing information may be permitted to be forwarded to another BGP controller.

Unlike iBGP sessions and eBGP sessions, the cBGP sessions disclosed herein limit the amount of information that can be communicated between cBGP peers. The embodiments disclosed herein are advantageous in that cBGP sessions significantly reduce the amount of data that is transmitted within the communications system <NUM>. In addition, the embodiments disclosed significantly reduce the amount of processing required to be performed by the cBGP peers within the communications system <NUM>.

<FIG> is a schematic diagram of an NE <NUM> suitable for implementing cBPG according to various embodiments of the disclosure. In an embodiment, the NE <NUM> may be implemented as any one of NEs <NUM>-<NUM>.

The NE <NUM> comprises ports <NUM>, transceiver units (Tx/Rx) <NUM>, a processor <NUM>, and a memory <NUM>. The processor <NUM> comprises a cBGP module <NUM>. Ports <NUM> are coupled to Tx/Rx <NUM>, which may be transmitters, receivers, or combinations thereof. The Tx/Rx <NUM> may transmit and receive data via the ports <NUM>. Processor <NUM> is configured to process data. Memory <NUM> is configured to store data and instructions for implementing embodiments described herein. The NE <NUM> may also comprise electrical-to-optical (EO) components and optical-to-electrical (OE) components coupled to the ports <NUM> and Tx/Rx <NUM> for receiving and transmitting electrical signals and optical signals.

The processor <NUM> may be implemented by hardware and software. The processor <NUM> may be implemented as one or more central processing unit (CPU) and/or graphics processing unit (GPU) chips, logic units, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor <NUM> is in communication with the ports <NUM>, Tx/Rx <NUM>, and memory <NUM>. The cBGP module <NUM> is implemented by the processor <NUM> to execute the instructions for implementing various embodiments discussed herein. For example, the cBGP module <NUM> is configured to permit transmission of a first type of message through a cBGP session and prohibit transmission of a second type of message through a cBGP session. The inclusion of the cBGP module <NUM> provides an improvement to the functionality of the NE <NUM>. The cBGP module <NUM> also effects a transformation of NE <NUM> to a different state. Alternatively, the cBGP module <NUM> is implemented as instructions stored in the memory <NUM>.

The memory <NUM> comprises one or more of disks, tape drives, or solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory <NUM> may be volatile and non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM).

In an embodiment, the memory <NUM> is configured to store a routing table <NUM> comprising routing information <NUM>. For example, routing information <NUM> includes information describing nodes or links along a path or tunnel to a destination. The routing table <NUM> includes routing information <NUM> for many different paths or tunnels. In an embodiment, the memory <NUM> is further configured to store instructions <NUM>, which are messages used to instruct another NE in a communications system <NUM>. In an embodiment, the instructions <NUM> are permitted to be communicated through a cBGP session. In an embodiment the memory <NUM> is further configured to store a peer group policy <NUM> and peer data <NUM>. A peer group policy <NUM> indicates a type of peer data <NUM> that can be shared between NEs of a peer group, as will be further described below with reference to <FIG> and <FIG>.

It is understood that by programming and/or loading executable instructions onto the NE <NUM>, at least one of the processor <NUM> and/or memory <NUM> are changed, transforming the NE <NUM> in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.

<FIG> is a message sequence diagram illustrating a method <NUM> of establishing and implementing a cBGP session in the communications system <NUM> according to various embodiments of the disclosure. Method <NUM> is implemented by NEs <NUM>-<NUM> in the communications system <NUM>, such as NE <NUM>, NE <NUM>, and NE <NUM>. In an embodiment, NE <NUM> may be implemented as a controller or the RR of the communications system <NUM>. Method <NUM> is performed after an iBGP session as already been established between NE <NUM> and <NUM>, and after a Transmission Control Protocol (TCP) three-way handshake has been completed between NE <NUM> an NE <NUM>.

Upon completion of the TCP three-way handshake, NEs <NUM> and <NUM> attempt to establish a cBGP session using OPEN messages <NUM> and <NUM>. At step <NUM>, NE <NUM> populates and transmits an OPEN message <NUM> to NE <NUM>. The OPEN message <NUM> includes information describing that NE <NUM> should be negotiated and accepted by NE <NUM> before establishing a cBGP session between NE <NUM> and NE <NUM>. An OPEN message <NUM> includes a version of BGP that NE <NUM> is capable of implementing, an AS number of NE <NUM>, a hold down timer indicating a proposed number of seconds between messages, a BGP identifier indicating an identifier of the NE <NUM>, and one or more optional parameters. In an embodiment, the OPEN message <NUM> indicates whether NE <NUM> is capable of establishing a cBGP session. For example, the OPEN message <NUM> may include an optional capabilities field that includes a code indicating whether NE <NUM> is capable of establishing a cBGP session. In an embodiment, the capabilities field also indicates whether or not NE <NUM> is implemented or acting as the controller. As NE <NUM> is not implemented as the controller in this example, the capabilities field may indicate that NE <NUM> is not the controller.

At step <NUM>, NE <NUM> populates and transmits an OPEN message <NUM> to NE <NUM>. The OPEN message <NUM> is similar to the OPEN message <NUM>, except that the OPEN message <NUM> includes information describing NE <NUM>. The OPEN message <NUM> includes a version of BGP that NE <NUM> is capable of implementing, an AS number of NE <NUM>, a hold down timer indicating a proposed number of seconds between messages, a BGP identifier indicating an identifier of the NE <NUM>, and one or more optional parameters. In an embodiment, the OPEN message <NUM> indicates whether NE <NUM> is capable of establishing a cBGP session. For example, the OPEN message <NUM> may include an optional capabilities field that includes a code indicating whether NE <NUM> is capable of establishing a cBGP session. In an embodiment, the capabilities field also indicates whether or not NE <NUM> is implemented or acting as the controller. As NE <NUM> is implemented as the controller in this example, the capabilities field may indicate that NE <NUM> is the controller.

At steps <NUM> and <NUM>, the NEs <NUM> and <NUM> determine whether or not to establish a cBGP session between NEs <NUM> and <NUM> based on the information contained in the OPEN messages <NUM> and <NUM>. In particular, at step <NUM>, NE <NUM> determines whether the information and capabilities sent in the OPEN message <NUM> from NE <NUM> matches, or is compatible with, the capabilities and features of NE <NUM>. Similarly, at step <NUM>, NE <NUM> determines whether the information and capabilities sent in the OPEN message <NUM> from NE <NUM> matches, or is compatible with, the capabilities and features of NE <NUM>.

In response to the features and capabilities of both NEs <NUM> and NE <NUM> being compatible, NEs <NUM> and <NUM> establish a cBGP session between NEs <NUM> and <NUM>. In contrast, when the features and capabilities of both NEs <NUM> and <NUM> are not compatible, a cBGP session cannot be established between NEs <NUM> and <NUM>.

After establishing a cBGP session between NEs <NUM> and <NUM>, certain types of information are permitted to be communicated through the cBGP session, while other types of information are prohibited from being communicated through the cBGP session. In an embodiment, control messages are permitted to be communicated through the cBGP session. For example, control messages such as instructions and/or status updates are permitted to be communicated through a cBGP session.

In <FIG>, at step <NUM>, NE <NUM> transmits instructions <NUM> to NE <NUM>. For example, the instructions <NUM> may be a UPDATE message with a Control Information Attribute containing an Assign Adjacency Segment Identifier (SID) to Link Instruction sub-TLV, which instructs NE <NUM> to assign an adjacency SID to a link. The adjacency SID and the link are represented in the sub-TLVs shown below with reference to <FIG> and <FIG>. An example of an instruction <NUM> indicating that the NE <NUM> should assign an adjacency SID to a link is represented in the sub-TLV referenced below in <FIG>.

In response to receiving the UPDATE message, NE <NUM> transmits a response or status <NUM> back to NE <NUM>, as step <NUM>. For example, the response or status <NUM> indicates the status or result of the execution of the instruction included in the UPDATE message. In one embodiment, the response or status <NUM> is another UPDATE message with a Control Information Attribute containing a Status TLV, which indicates whether the execution of the instruction is successful. An example of a response or status <NUM> indicating whether the instruction <NUM> was successfully performed is represented in the sub-TLV referenced below in <FIG>.

In an embodiment, only control messages that do not contain routing information are permitted to be transmitted through a cBGP session. Routing information refers to information describing a path to a destination in the communications system <NUM> or the network. For example, routing information may include labels, addresses, or identifiers of certain NEs along a path to a destination.

In one embodiment, NE <NUM> does not receive messages with routing information from NE <NUM> and does not send messages with routing information <NUM> to NE <NUM> because NEs <NUM> and <NUM> participate in a cBGP session. For example, NE <NUM>, acting as the RR and controller, does not send a message with routing information <NUM> to NE <NUM> after receiving the message from NE <NUM>, which has an iBGP session with NE <NUM>.

For example, in <FIG>, NE <NUM> has already established an iBGP session with NE <NUM>, through which messages containing routing information <NUM> are permitted to be transmitted. At step <NUM>, NE <NUM> transmits an UPDATE message containing routing information <NUM> to NE <NUM>, and NE <NUM> receives the UPDATE message. In BGP, NE <NUM> is configured to distribute this UPDATE message to connected BGP peers, such as NE <NUM>. However, since NE <NUM> has established a cBGP session with NE <NUM>, NE <NUM> is prohibited from forwarding the UPDATE message containing routing information <NUM> to NE <NUM>. That is, NE <NUM> does not send the UPDATE message containing the routing information <NUM> to NE <NUM>.

In a similar fashion, routing information <NUM> learned by NE <NUM> is prohibited from being distributed or forwarded to NE <NUM>, with which a cBGP session has been established. In some embodiments, when a NE <NUM> or <NUM> receives routing information <NUM>, NEs <NUM> and <NUM> are prohibited from forwarding or distributing the routing information <NUM> to any other cBGP peers.

In some embodiments, iBGP peers and eBGP peers are prohibited from transmitting UPDATE messages to NEs <NUM>, or any other NEs with which a cBGP session has been established. In the case that NE <NUM> receives an UPDATE message, NEs <NUM> is configured to discard, drop, or ignore the UPDATE message. Accordingly, the cBGP session established between NEs <NUM> and <NUM> prevent unnecessary traffic from being forwarded through the communications system <NUM> and clogging network resources.

<FIG> is a diagram illustrating a communications system <NUM> configured to implement cBGP according to various embodiments of the disclosure. Communications system <NUM> of <FIG> is similar to communications system <NUM> of <FIG>, except that the communications system <NUM> of <FIG> shows the different BGP session <NUM>-<NUM> established between NE <NUM> and NEs <NUM>-<NUM> and <NUM>-<NUM>. In addition, the communications system <NUM> of <FIG> shows that different types of BGP sessions may be established between a single pair of NEs.

Similar to the communications system <NUM> of <FIG>, in the communications system <NUM> of <FIG>, NE <NUM> is implemented as the controller and the RR of the communications system <NUM>. In this way, NE <NUM> has established different types of BGP sessions or connections with the other NEs <NUM>-<NUM> and <NUM>-<NUM> in the communications system <NUM>. In particular, NE <NUM>, positioned within AS <NUM>, has established separate eBGP sessions with both NEs <NUM> and <NUM>, both of which are positioned within AS <NUM>. As shown in <FIG>, NE <NUM> has established an eBGP session <NUM> with NE <NUM> and an eBGP session <NUM> with NE <NUM>.

NE <NUM> has also established separate iBGP sessions with NEs <NUM>, <NUM>, <NUM>, and <NUM>, all of which are positioned within the same AS <NUM>. As shown in <FIG>, NE <NUM> has established an iBGP session <NUM> with NE <NUM>, an iBGP session <NUM> with NE <NUM>, an iBGP session <NUM> with NE <NUM>, and an iBGP session <NUM> with NE <NUM>.

In some embodiments, NE <NUM> is configured to establish cBGP sessions with some of the NEs <NUM> and <NUM> with which other BGP session types have already been established. As shown by <FIG>, NE <NUM> has already established an eBGP session <NUM> with NE <NUM> and an iBGP session <NUM> with NE <NUM>. In an embodiment, NE <NUM> is configured to additionally establish a cBGP session with NEs <NUM> and <NUM>. In particular, NE <NUM> is configured to establish a cBGP session <NUM> with NE <NUM> and a cBGP session <NUM> with NE <NUM>.

NE <NUM> additionally establishes the cBGP sessions <NUM> and <NUM> in two different manners. In the first manner, NE <NUM> establishes the cBGP sessions <NUM> and <NUM> separately from the existing BGP sessions. For example, NE <NUM> establishes cBGP session <NUM> with NE <NUM> separately, for example, as a separate tunnel, from the existing eBGP session <NUM>. In this example, different types of messages are communicated between NEs <NUM> and <NUM> through the different types of BGP sessions (e.g., eBGP session <NUM> and cBGP session <NUM>). In an embodiment, a first type of message is permitted to be communicated through the cBGP session <NUM>, in which the first type of message is a control message excluding routing information <NUM>. In this embodiment, a second type of message including routing information <NUM> should be communicated through the eBGP session <NUM>.

For example, when NE <NUM> receives an UPDATE message from another BGP peer, NE <NUM> may first determine a type of message of the UPDATE message based on the format of the UPDATE message. In response to determining that the UPDATE message contains routing information <NUM>, NE <NUM> determines that the UPDATE message should be forwarded to NE <NUM> through the eBGP session <NUM>, not the cBPG session <NUM>. In this case, NE <NUM> transmits the UPDATE message to NE <NUM> through the eBGP session <NUM>.

In contrast, when NE <NUM> sends an instruction to the NE <NUM>, NE <NUM> first determines a type of message of the instruction. In response to determining that the instruction is a control message that does not contain routing information <NUM>, NE <NUM> determines that the instruction should be forwarded to NE <NUM> through the cBGP session <NUM>. In this case, NE <NUM> transmits the instruction to NE <NUM> through the cBGP session <NUM>.

Similar methodologies are utilized when NE <NUM> establishes a cBGP session <NUM> with an NE <NUM> separately from the existing iBGP session <NUM>. For example, NE <NUM> establishes a cBGP session <NUM> with NE <NUM> separately, for example, as a separate tunnel, from the existing iBGP session <NUM>. In this example, different types of messages are communicated between NEs <NUM> and <NUM> through the different types of BGP sessions (e.g., iBGP session <NUM> and cBGP session <NUM>). In an embodiment, a first type of message is permitted to be communicated through the cBGP session <NUM>, in which the first type of message is a control message excluding routing information <NUM>. In this embodiment, a message including routing information <NUM> should be communicated through the iBGP session <NUM>.

In a second manner of establishing a cBGP session, NE <NUM> establishes the cBGP sessions <NUM> and <NUM> by combining the cBGP sessions <NUM> and <NUM> with the existing eBGP session <NUM> and iBGP session <NUM>. For example, instead of creating a separate tunnel for the new cBGP session <NUM>, NE <NUM> creates a combined BGP session with NE <NUM> by adding the cBGP session <NUM> to the existing eBGP session <NUM>. In this example, different types of messages are permitted to be communicated between NEs <NUM> and <NUM> through the combined BGP session. In this embodiment, a first type of message is permitted to be communicated through the combined BGP session, in which the first type of message is a control message excluding routing information <NUM>. In this embodiment, a second type of message including routing information <NUM> is also permitted to be communicated through the combined BGP session.

Similar methodologies are utilized when NE <NUM> establishes a combined BGP session with an NE <NUM> with which an iBGP session <NUM> has already been established. For example, NE <NUM> establishes a combined BGP session with NE <NUM> by, for example, adding a cBGP session <NUM> to the existing iBGP session <NUM>. In this example, different types of messages are permitted to be communicated between NEs <NUM> and <NUM> through the combined BGP session.

Accordingly, the embodiments disclosed herein enable cBGP sessions to be established flexibly with other NEs, regardless of whether other types of BGP sessions have already been established with the other NEs. When establishing cBGP sessions using the first manner, a cBGP session is separately and independently established from the other existing BGP session. In this first manner, the cBGP NE is configured to filter messages based on the type of message to determine which BGP session through which to transmit the message. When establishing cBGP sessions using the second manner, the cBGP session is combined with the existing BGP session. In this second manner, all types of messages may be transmitted through the combined BGP session.

<FIG> is a diagram illustrating a capabilities TLV <NUM> sent by an NE in the communications system <NUM> of <FIG> or the communications system <NUM> of <FIG> according to various embodiments of the disclosure. In an embodiment, the capabilities TLV <NUM> includes information indicating whether an NE <NUM>-<NUM> is capable of establishing a cBGP session with another NE <NUM>-<NUM>. In an embodiment, the capabilities TLV <NUM> is included as an optional parameter in an OPEN message, similar to the OPEN messages <NUM> and <NUM> of <FIG>. In another embodiment, the capabilities TLV <NUM> is a new and separate message transmitted between NEs <NUM>-<NUM> in a communications system <NUM> to indicate a respective capability of the NE <NUM>-<NUM>.

In the embodiment shown in <FIG>, the capabilities TLV <NUM> includes a capability code <NUM>, a capability length <NUM>, and a capability value <NUM>. The capability code <NUM> is a one byte field carrying a code indicating whether the NE <NUM>-<NUM> sending the capabilities TLV <NUM> is capable of establishing a cBGP session with another NE <NUM>-<NUM>. In an embodiment, the code is a value presenting whether the NE <NUM>-<NUM> is capable of establishing a cBGP session with another NE <NUM>-<NUM> or whether the NE <NUM>-<NUM> is not capable of establishing a cBGP session with another NE <NUM>-<NUM>.

The capability length <NUM> is a one byte field indicating that the length of the capability value <NUM> is <NUM> bytes. The capability value <NUM> is a <NUM> byte field carrying various flags. In an embodiment, the capability value <NUM> carries a C flag <NUM> and an I flag <NUM>. In an embodiment, the C flag <NUM> is set to indicate whether the NE <NUM>-<NUM> sending the capabilities TLV <NUM> acts as a controller of the communications system <NUM>. For example, when the C flag <NUM> is set to <NUM>, the C flag <NUM> indicates that the NE <NUM>-<NUM> sending the capabilities TLV <NUM> acts as the controller of the communications system <NUM>. Similarly, when the C flag <NUM> is set to <NUM>, the C flag <NUM> indicates that the NE <NUM>-<NUM> sending the capabilities TLV <NUM> does not act as the controller of the communications system <NUM>.

In an embodiment, the I flag <NUM> is set to indicate whether the NE <NUM>-<NUM> sending the capabilities TLV <NUM> is configured to create a separate cBGP session or a combined BGP session, when applicable, as described above with reference to <FIG>. For example, when the I flag <NUM> is set to <NUM>, the NE <NUM>-<NUM> sending the capabilities TLV <NUM> is configured to create a cBGP session with another NE <NUM>-<NUM> that is separate and independent from any other existing BGP session. For example, the NE <NUM>-<NUM> sending the capabilities TLV <NUM> is configured to create a new cBGP session, by creating a separate tunnel or path, with the other NE <NUM>-<NUM>. Similarly, when the I flag <NUM> is set to <NUM>, the NE <NUM>-<NUM> sending the capabilities TLV <NUM> is configured to create a combined BGP session with another NE <NUM>-<NUM>.

<FIG> is a diagram illustrating a communications system <NUM> configured to implement a cBGP peer session within a peer group according to various embodiments of the disclosure. In <FIG>, the communications system <NUM> includes a controller <NUM> and two peer groups <NUM> and <NUM>. The peer groups <NUM> and <NUM> refer to a set or group of NEs <NUM>-<NUM> and NEs <NUM>-<NUM> in the communications system <NUM> that share a similar characteristic or policy.

In <FIG>, the peer group <NUM> includes NEs <NUM>, <NUM>, and <NUM>, while peer group <NUM> includes NEs <NUM>, <NUM>, and <NUM>. Within peer group <NUM>, NEs <NUM>-<NUM> are grouped together based on a shared characteristic or policy. A shared characteristic or policy may include, for example, a shared tenant identifier (ID), a similar geographic district, a similar zone, a similar group name, a method of encryption or decryption, etc. For example, NEs <NUM>-<NUM> are associated with the same tenant, and thus, the same tenant identifier, even though NEs <NUM>-<NUM> may be located in geographically distinct regions. For this reason, NEs <NUM>-<NUM> are grouped together into a single peer group <NUM>.

Similarly, within peer group <NUM>, NEs <NUM>-<NUM> are grouped together based on a shared characteristic or policy. For example, NEs <NUM>-<NUM> may be associated with the same company name, and thus, may belong in the same peer group <NUM>, even though NEs <NUM>-<NUM> are located in geographically distinct regions.

In an embodiment, NEs <NUM>-<NUM> and NEs <NUM>-<NUM> are similar to NEs <NUM>-<NUM> of the communications systems <NUM> and <NUM>. In another embodiment, the NEs <NUM>-<NUM> and <NUM>-<NUM> are implemented as customer premises equipment (CPE), which are terminals or devices located at a premise of a subscriber and connected to a telecommunication circuit of a carrier.

NEs <NUM>-<NUM> and <NUM>-<NUM> are each coupled to the controller <NUM> via links <NUM>-<NUM> and <NUM>-<NUM>, respectively. Links <NUM>-<NUM> and <NUM>-<NUM> may be similar to links <NUM>-<NUM>, in that links <NUM>-<NUM> and <NUM>-<NUM> may be wired or wireless links or interfaces interconnecting each of the NEs <NUM>-<NUM> and <NUM>-<NUM> to the controller <NUM>. Links <NUM>-<NUM> and <NUM>-<NUM> are configured to forward traffic according to various routing protocols, such as B GP (e.g., iBGP, eBGP, and cBGP).

In an embodiment, the controller <NUM> is similar to NE <NUM>, in that the controller may act as the RR of the communications system <NUM>. In another embodiment, the controller <NUM> may be a separate server or site external to the ASs included in the communications system <NUM>.

In some embodiments, the controller <NUM>, NEs <NUM>-<NUM>, and <NUM>-<NUM> are configured to selectively communicate certain types of information by establishing cBGP sessions between members of the peer groups <NUM> and <NUM> and the controller <NUM>. In an embodiment, the controller <NUM> establishes cBGP session with NEs <NUM>-<NUM>. The controller <NUM> separately establishes a cBGP session with NEs <NUM>-<NUM>.

After the cBGP session has been established between the controller <NUM> and members of the peer groups <NUM> and <NUM>, the controller <NUM> determines whether to forward or distribute information received from other member NEs <NUM>-<NUM> and <NUM>-<NUM> within a peer group <NUM> and <NUM>. In this embodiment, certain types of information may be permitted to be forwarded or distributed to NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>.

For example, information that may be shared within member NEs <NUM>-<NUM> and <NUM>-<NUM> of a peer group <NUM> and <NUM> include private addresses of NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>, port addresses for ports of particular NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>, security related information for NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>, information describing Ethernet virtual private networks (EVPNs) for NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>, information describing intelligent virtual private networks (IVPNs) for NEs <NUM>-<NUM> and <NUM>-<NUM> within the same peer group <NUM> and <NUM>, etc. For example, when the communications system <NUM> is a software defined wide area network (SD-WAN), information that may be shared within member NEs <NUM>-<NUM> and <NUM>-<NUM> of a peer group <NUM> and <NUM> includes end node wide area network (WAN) auto discovery information, such as the SD-WAN node private address, WAN ports or addressees registered with an SD-WAN controller, etc. In this example, controller facilitated Internet Protocol Security (IPsec) associated information establishment among WAN ports are also shared within member NEs <NUM>-<NUM> and <NUM>-<NUM> of a peer group <NUM> and <NUM>. In one embodiment, routing information <NUM> may also be shared between member NEs <NUM>-<NUM> and <NUM>-<NUM> of the same peer group <NUM> and <NUM>.

In an embodiment, a network administrator or operator preconfigures the controller <NUM> to include identifiers, labels, or addresses of each of the NEs <NUM>-<NUM> and <NUM>-<NUM> within a particular peer group <NUM> and <NUM>. In another embodiment, the controller <NUM> determines member NEs <NUM>-<NUM> and <NUM>-<NUM> of the peer group <NUM> and <NUM> intelligently based on characteristics or properties associated with the NEs <NUM>-<NUM> and <NUM>-<NUM>. For example, the controller <NUM> may obtain the tenant identifiers for each NE <NUM>-<NUM> and then create the peer group <NUM> based on the matching tenant identifiers for NEs <NUM>-<NUM>.

In an embodiment, the controller <NUM> distributes information based on peer group policies <NUM> defined by the network administrator or operator specifying the types of information that may be shared within member NEs <NUM>-<NUM> and <NUM>-<NUM> of the peer group <NUM> or <NUM>. In another embodiment, the controller <NUM> may be configured to intelligently determine peer group policies <NUM> defining the types of information that may be securely shared between member NEs <NUM>-<NUM> and <NUM>-<NUM> of a peer group <NUM> or <NUM>.

<FIG> is a message sequence diagram illustrating a method <NUM> of implementing cBGP in the communications system <NUM> of <FIG> according to various embodiments of the disclosure. Method <NUM> is implemented by NEs in the communications system <NUM>, such as the controller <NUM> and NEs <NUM>, <NUM>, <NUM>, and <NUM>. Method <NUM> is performed after the controller <NUM> has established a cBGP session with NEs <NUM>, <NUM>, <NUM>, and <NUM> and after the peer groups <NUM> and <NUM> are established. As described above, the peer group <NUM> includes NEs <NUM> and <NUM>, while the peer group <NUM> includes NEs <NUM> and <NUM>.

The controller <NUM> may obtain peer data 780A and 780B, either by generating the peer data 780A and 780B or receiving the peer data 780A and 780B from another BGP peer/NE. For example, the peer data 780A includes an address of the NE <NUM> from the peer group <NUM> (see <FIG>), and the peer data 780B may include port information regarding NE <NUM> from peer group <NUM> (see <FIG>).

Prior to transmitting the peer data 780A-B to other member NEs of the respective peer groups <NUM> and <NUM>, the controller <NUM> determines whether the peer data 780A-B comprises a type of data that is permitted to be distributed or forwarded to other member NEs of the respective peer groups <NUM> and <NUM> based on a peer group policy <NUM> defined for each of the peer groups <NUM> and <NUM>. In an embodiment, the peer group policies <NUM> indicate the type of data that may be shared between a respective peer group <NUM> and <NUM>. In this embodiment, the controller <NUM> compares the peer data 780A-B with the respective peer group policy <NUM> for each peer group <NUM> and <NUM> to determine whether the peer data 780A-B is permitted to be shared.

When the peer group policy <NUM> for the peer group <NUM> indicates that address information is permitted to be shared with other NEs in the peer group <NUM>, at step <NUM>, the controller <NUM> transmits the peer data 780A to NE <NUM> of peer group <NUM>. Notably, the controller <NUM> did not forward the peer data 780A to NEs <NUM> or <NUM>, which are members of a different peer group <NUM>. Similarly, when peer group policy <NUM> for the peer group <NUM> indicates that port information is permitted to be shared with other NEs in the peer group <NUM>, at step <NUM>, the controller <NUM> transmits the peer data 780B to NE <NUM> of peer group <NUM>. Notably, the controller <NUM> did not forward the peer data 780B to NEs <NUM> or <NUM>, which are members of a different peer group <NUM>. In an embodiment, the NEs within the peer groups <NUM> and <NUM> also locally store the peer group policies <NUM> that are used to determine whether to share the peer data 780A-B.

<FIG> are diagrams illustrating an UPDATE message <NUM> encoded based on BGP <NUM> according to various embodiments of the disclosure. The UPDATE message <NUM> may be encoded similar to the UPDATE message described in the Network Working Group (NWG) Request for Comments (RFC) <NUM> document, entitled "<NPL>. As shown by <FIG>, the UPDATE message <NUM> includes a header <NUM> and various attributes <NUM>.

In an embodiment, the UPDATE message <NUM> may be transmitted by NE <NUM>, for example, at step <NUM> of <FIG>, or transmitted by the NE <NUM>, for example, at step <NUM>. With references to <FIG>, the term "node" may be used interchangeably with "NE.

The header <NUM> includes a marker <NUM>, a length <NUM>, and a type <NUM>. The marker <NUM> is a <NUM>-octet field included for compatibility and may be set to all ones. The length <NUM> is a <NUM>-octet unsigned integer indicating the total length of the UPDATE message <NUM>, including the header <NUM>, in octets. The type <NUM> is a <NUM>-octet unsigned integer indicating a type code of the UPDATE message <NUM> carrying the attributes <NUM>, and in particular, the control information <NUM>. In an embodiment, the type code is <NUM>, which is the existing type code of the existing UPDATE message. When the UPDATE message is transmitted over a cBGP session, it contains control information <NUM>. In another embodiment, the type code is a new number other than <NUM>. This new number (i.e., new type code) indicates that the message is a UPDATE message containing control information <NUM>.

The attributes <NUM> include details used to advertise feasible routes that share common path attributes to a peer, or to withdraw multiple unfeasible routes from service. As shown by <FIG>, the attributes <NUM> include at least one of a withdrawn routes length <NUM>, withdrawn routes <NUM>, total path attribute length <NUM>, path attributes <NUM>, NLRIs <NUM>, or control information <NUM>. The withdrawn routes length <NUM> is a <NUM>-octet unsigned integer indicating the total length of the withdrawn routes <NUM> in octets. The withdrawn routes <NUM> is a variable-length field that contains a list of IP address prefixes for the routes that are being withdrawn from the service. Each IP address prefix is encoded as a single <NUM>-tuple of the form <length, prefix>.

<FIG> shows the <NUM>-tuple form used to signal each IP address prefix in the withdrawn routes <NUM>. The <NUM>-tuple includes a length <NUM><NUM>-octet field indicating the length in bits of the IP address prefix <NUM> field. The IP address prefix <NUM> field carries the IP address prefix.

The total path attribute length <NUM> is a <NUM>-octet unsigned integer indicating the total length of the path attributes <NUM> in octets. The path attributes <NUM> is a variable length sequence of path attributes present in every UPDATE message <NUM>, except for an UPDATE message that carries only withdrawn routes. Each path attribute <NUM> is reflected as a triple including an attribute type, length, and value. The NLRIs <NUM> is a variable length field containing a list of IP address prefixes. The reachability information in NLRIs <NUM> is encoded as one or more <NUM>-tuples of the form <length, prefix>.

<FIG> shows the <NUM>-tuple form used to signal each IP address prefix in the NLRIs <NUM>. The <NUM>-tuple includes a length <NUM><NUM>-octet field indicating the length in bits of the IP address prefix <NUM> field. The IP address prefix <NUM> field carries the IP address prefix.

According to some embodiments, the attributes <NUM> includes the control information <NUM>. In an embodiment, the instructions <NUM> and the response or status <NUM> described above with reference to <FIG> is carried in the control information <NUM> of the UPDATE message <NUM>. In this embodiment, NEs or nodes that have established cBGP sessions with one another are only permitted to transmit UPDATE messages <NUM> carrying instructions <NUM> and/or the response or status <NUM> in the control information <NUM>.

<FIG> is a diagram illustrating the control information <NUM> included in the update message <NUM> according to various embodiments of the disclosure. The control information attribute <NUM> includes various fields, such as attribute flags <NUM>, attribute type <NUM>, length <NUM>, identifier <NUM>, and one or more sub-TLVs <NUM>. The attribute flags <NUM> include <NUM> bits, in which each one is a flag representing information regarding the control information <NUM>. In an embodiment, bit <NUM> is an optional bit indicating whether the control information <NUM> is optional or well-known. For example, bit <NUM> is set to <NUM> if the control information <NUM> is optional or set to <NUM> if the control information <NUM> is well-known. Bit <NUM> may be a transitive bit indicating whether the control information <NUM> is transitive or non-transitive. For example, bit <NUM> is set to <NUM> if the control information <NUM> is transitive or set to <NUM> if the control information <NUM> is non-transitive. Bit <NUM> may be a partial bit indicating whether the control information <NUM> is partial or complete. For example, bit <NUM> is set to <NUM> if the control information <NUM> is partial or set to <NUM> if the control information <NUM> is complete. Bit <NUM> is an extended length bit indicating whether the length <NUM> field of the control information <NUM> is <NUM> or <NUM> octets. For example, bit <NUM> is set to <NUM> if the length <NUM> of control information <NUM> is <NUM> octet or set to <NUM> if the length <NUM> of the control information <NUM> is <NUM> octets. In an embodiment, for the control information <NUM>, bit <NUM> is set to <NUM> since the control information <NUM> is optional, and bit <NUM> is set to <NUM> since the control information <NUM> is non-transitive.

The attribute type <NUM> includes a code or value indicating that the attribute is the control information <NUM>. The length <NUM> is an <NUM> bit or <NUM> bit value indicating the number of bytes in the control information <NUM>. The identifier <NUM> is a <NUM> bit field identifying a set of instructions in the control information <NUM>. The sub-TLVs <NUM> include one or more sub-TLVs <NUM> carrying information, instructions <NUM>, or status <NUM>, as will be further described in the examples below.

<FIG> are diagrams illustrating examples of sub-TLVs 915A-E included in the control information attribute <NUM> according to various embodiments of the disclosure. The sub-TLVs 915A-E shown in <FIG> carry information regarding nodes/NEs, links, or interfaces upon with the instructions <NUM> are to be performed.

<FIG> shows a node sub-TLV 915A indicating a node/NE receiving the instructions <NUM>. The node sub-TLV 915A includes various fields, such as, the node type <NUM>, length <NUM>, and node IP address <NUM>. The node type <NUM> carries a value indicating that the sub-TLV 915A is the node sub-TLV 915A. The length <NUM> indicates either <NUM> bytes or <NUM> bytes, based on whether the node IP address <NUM> caries an IPv4 address or an IPv6 address. When the node IP address <NUM> carries an IPv4 address, the length <NUM> indicates <NUM> bytes. When the node IP address <NUM> carries an IPv6 address, the length <NUM> indicates <NUM> bytes. The node IP address <NUM> caries the IP address (either IPv4 address or IPv6 address) of the node/NE receiving the instructions <NUM>.

<FIG> shows a link sub-TLV 915B indicating a link to which the instructions <NUM> are applied. The link sub-TLV 915B includes various fields, such as, the link type <NUM>, the length <NUM>, link local IP address <NUM>, and link remote IP address <NUM>. The link type <NUM> carries a value indicating that the sub-TLV 915B is the link sub-TLV 915B. The length <NUM> indicates either <NUM> bytes or <NUM> bytes, depending on whether the IP addresses included in the link local IP address <NUM> and the link remote IP address <NUM> are IPv4 addresses (<NUM> bytes) or IPv6 address (<NUM> bytes). The link local IP address <NUM> carries the local IP address of the link as either an IPv4 address or an IPv6 address. The link remote IP address <NUM> carries the remote IP address of the link as either an IPv4 address or an IPv6 address.

<FIG> are IP prefix sub-TLVs 915C and 915D indicating a prefix to which the instructions <NUM> are applied. In particular, <FIG> shows an IPv4 prefix sub-TLV 915C, carrying an IPv4 prefix, and <FIG> shows an IPv6 prefix sub-TLV 915D carrying an IPv6 prefix.

As shown by <FIG>, the IPv4 prefix sub-TLV 915C includes various fields, such as the IPv4 prefix type <NUM>, length <NUM>, prefix length <NUM>, and IPv4 prefix <NUM>. The IPv4 prefix type <NUM> carries a value indicating that the sub-TLV 915C is the IPv4 prefix sub-TLV 915C. The length <NUM> carries the length of the IPv4 prefix sub-TLV 915C excluding the type field <NUM> and length <NUM> field, which may be a variable length. The prefix length <NUM> carries a length of the IPv4 prefix <NUM>, and the IPv4 prefix <NUM> carries the IPv4 prefix.

As shown by <FIG>, the IPv6 prefix sub-TLV 915D includes various fields, such as the IPv6 prefix type <NUM>, length <NUM>, prefix length <NUM>, and IPv6 prefix <NUM>. The IPv6 prefix type <NUM> carries a value indicating that the sub-TLV 915D is the IPv6 prefix sub-TLV 915D. The length <NUM> carries the length of the IPv6 prefix sub-TLV 915D excluding the type field <NUM> and length <NUM> field, which may be a variable length. The prefix length <NUM> carries a length of the IPv6 prefix <NUM>, and the IPv6 prefix <NUM> carries the IPv6 prefix.

<FIG> shows an adjacency segment identifier (SID) sub-TLV 915E indicating an adjacency SID to which the instructions <NUM> are to be applied. The adjacency SID sub-TLV 915E includes various fields, such as, the adjacency SID type <NUM>, length <NUM>, flags <NUM>, weight <NUM>, reserved bits, and an SID, label, or index <NUM>. The adjacency SID type <NUM> includes a value indicating that the sub-TLV 915E is the adjacency SID sub-TLV 915E. The length <NUM> carries a length of the adjacency SID sub-TLV 915E excluding the type field <NUM> and length <NUM> field. The flags <NUM> carry various bits or flags, such as a backup flag, a value index flag, a local/global flag, a group flag, or a persistent flag. The weight <NUM> is used for load balancing purposes. The SID, label, or index <NUM> carries a <NUM> octet index defining an offset in the SID/label space, a <NUM> octet local label, or an SID. Additional details regarding the SID sub-TLV 915E is further described in the <NPL>.

<FIG> show sub-TLVs 915A-E carrying information regarding nodes/NEs, links, or interfaces upon with the instructions <NUM> are to be performed. <FIG> only shows a few examples of such sub-TLVs <NUM> that can be carried in the control information <NUM> of the UPDATE message <NUM>. It should be appreciated that other sub-TLVs <NUM> carrying other types of information may otherwise be included in the control information <NUM> of the UPDATE message <NUM>.

<FIG> are diagrams illustrating sub-TLVs 915F-G including instructions <NUM> carried in the control information <NUM> according to various embodiments of the disclosure. The instructions <NUM> are instructions that are to be executed on a node/NE, link, prefix, or segment, as identified by, for example, one or more of the sub-TLVs 915A-E. In an embodiment, the sub-TLVs 915F-G including instructions <NUM> are permitted to be communicated during a cBGP session.

<FIG> shows an assign adjacency SID to link sub-TLV 915F according to various embodiments of the disclosure. The assign adjacency SID to link sub-TLV 915F includes an instruction <NUM> for a node/NE receiving the UPDATE message <NUM> to assign an adjacency SID to a link. The assign adjacency SID to link sub-TLV 915F includes various fields, such as, an assign adjacency SID link type <NUM>, a length field <NUM>, the adjacency SID sub-TLV 915E, and the link sub-TLV 915B. The assign adjacency SID link type <NUM> carries a value indicating that the sub-TLV 915F is the assign adjacency SID to link sub-TLV 915F. The length <NUM> carries a length of the assign adjacency SID to link sub-TLV 915F excluding the type field <NUM> and length <NUM> field. As described above, the adjacency SID sub-TLV 915E carries an SID, label, or index <NUM>, and the link sub-TLV 915B carries the link local IP address <NUM> and the link remote IP address <NUM>. This information is used by the node/NE receiving the assign adjacency SID to link sub-TLV 915F to assign an adjacency SID, identified in the assign adjacency SID to link sub-TLV 915F, to a link, which is also identified in the assign adjacency SID to link sub-TLV 915F.

<FIG> shows flow redirect sub-TLV <NUM> according to various embodiments of the disclosure. The flow redirect sub-TLV <NUM> includes an instruction <NUM> for a node receiving the UPDATE message <NUM> to redirect a data flow. The flow redirect sub-TLV <NUM> includes various fields, such as, a flow redirect type <NUM>, a length field <NUM>, an indirection ID <NUM>, and a flow specification <NUM>. The flow redirect type <NUM> carries a value indicating that the sub-TLV <NUM> is the flow redirect sub-TLV <NUM>. The length <NUM> carries a length of the flow redirect sub-TLV <NUM> excluding the type field <NUM> and length <NUM> field. The indirection ID <NUM> identifies a tunnel by which traffic should be redirected. In one embodiment, the indirection ID <NUM> is <NUM> bits. The flow specification <NUM> describes the traffic that should be redirected through the tunnel identified by the indirection ID <NUM>. In one embodiment, the flow specification <NUM> is a link sub-TLV 915B, which indicates that the flow is the traffic from the link given by the link sub-TLV. In another embodiment, the flow specification <NUM> is an IPv4 prefix sub-TLV 915C, which describes a traffic flow. This information is used by the node/NE receiving the flow redirect sub-TLV <NUM> to redirect the traffic described by the flow specification <NUM> to the tunnel identified in the indirection ID <NUM>.

<FIG> is a diagram illustrating a status sub-TLV <NUM> including a response or status <NUM> carried in the control information <NUM> according to various embodiments of the disclosure. The status sub-TLV <NUM> is populated in a new UPDATE message <NUM> carrying information indicating whether the node receiving the first UPDATE message <NUM> successfully performed the instruction <NUM> carried in the first UPDATE message <NUM>. The status sub-TLV <NUM> includes various fields, such as the status type <NUM>, the length <NUM>, reserved bits, status brief (SB) <NUM>, error code <NUM>, and a reason if failure occurs <NUM>. The status type <NUM> carries a value indicating that the sub-TLV <NUM> is the status sub-TLV <NUM>. The length <NUM> carries a length of the status sub-TLV <NUM> excluding the type field <NUM> and length <NUM> field. The SB <NUM> includes a value indicating whether the instructions <NUM> were successfully performed. For example, SB <NUM> may be set to <NUM> if the instructions <NUM> were successfully performed, <NUM> if the instructions <NUM> were not successfully performed or failed, and <NUM> if the instructions <NUM> were only partially performed. The error code <NUM> may carry an error code or value when the instruction <NUM> was unable to be successfully performed identifying a pre-determined reason as to why the instruction <NUM> instruction <NUM> was unable to be successfully performed. The reason if failure occurs <NUM> is an optional field that may carry additional information describing reasons why the instruction <NUM> was unable to be successfully performed.

In an embodiment, during a cBPG session, when a node/NE receives a first UPDATE message <NUM> containing control information <NUM>, in which the control information <NUM> carries an instruction <NUM>, the node/NE may first attempt to perform the instruction <NUM>. For example, the control information <NUM> may include the assign adjacency SID to link sub-TLV 915F. The node/NE may attempt to assign an adjacency SID, identified in the assign adjacency SID to link sub-TLV 915F, to a link, which is also identified in the assign adjacency SID to link sub-TLV 915F. The node may then populate a new (or second) UPDATE message <NUM> with control information <NUM> including a status sub-TLV <NUM> indicating whether the adjacency was properly assigned and the identifier <NUM> which is from the control information <NUM> in the first UPDATE message <NUM>. In this manner, the cBGP session permits UPDATE messages <NUM> carrying control information <NUM> to be communicated amongst NEs or nodes that have established a cBGP session. In one embodiment, only UPDATE messages <NUM> carrying the control information <NUM>, and no other attributes <NUM>, are permitted to communicated amongst NEs or nodes that have established a cBGP session. In another embodiment, only UPDATE messages <NUM> carrying the control information <NUM> are permitted to communicated amongst NEs or nodes that have established a cBGP session, regardless of whether the UPDATE message <NUM> includes other attributes <NUM>.

<FIG> is a flowchart illustrating a method <NUM> of establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. Method <NUM> is implemented by a controller, such as NE <NUM>, NE <NUM>, or <NUM> of the communications systems <NUM>, <NUM>, or <NUM>. Method <NUM> may be implemented after the controller has established a TCP three-way handshake with another NE, such as NE <NUM>.

At step <NUM>, the controller establishes a cBGP peer session with NE <NUM>. For example, NE <NUM> establishes a cBGP peer session with NE <NUM> by sending an OPEN message indicating that NE <NUM> is capable of establishing a cBGP peer session. NE <NUM> then receives an OPEN message from NE <NUM> indicating that NE <NUM> is capable of establishing a cBGP peer session. As described with reference to <FIG>, when both NE <NUM> and NE <NUM> are capable of establishing a cBGP peer session, the cBPG peer session is established between NE <NUM> and NE <NUM>. In an embodiment, a first type of message is permitted to be communicated through the cBGP peer session. For example, the first type of message includes control messages excluding routing information <NUM>, such as instructions, responses to the instructions, and status messages. In this embodiment, messages containing routing information <NUM> are prohibited from being communicated through the cBGP session.

At step <NUM>, NE <NUM> transmits a message to NE <NUM> through the cBGP peer session. For example, Tx/Rx <NUM> of NE <NUM> transmits a message to NE <NUM> through the cBGP peer session. For example, the message is an instruction regarding an interface of NE <NUM> and does not contain routing information <NUM>.

At step <NUM>, NE <NUM> determines whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information <NUM>. For example, the cBGP module <NUM> is executed by the processor <NUM> to determine whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information <NUM>.

At step <NUM>, NE <NUM> transmits the message to the NE through the cBGP session if the message is permitted to be communicated through the cBGP session. For example, Tx/Rx <NUM> of NE <NUM> transmits the message to NE <NUM> if the message is permitted to be communicated through the cBGP session (i.e., if the message does not contain routing information <NUM>).

At step <NUM>, NE <NUM> receives a response message from the NE through the cBGP session. For example, Tx/Rx <NUM> of NE <NUM> receives a response message from NE <NUM> through the cBGP peer session. For example, the response message indicates whether or not NE <NUM> has successfully assigned the segment identifier (SID) to the interface identified in the message sent at step <NUM>.

<FIG> is a flowchart illustrating another method <NUM> of establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. Method 140C is implemented by an NE in the communications system <NUM> that is not the controller, such as NEs <NUM>-<NUM> or <NUM>-<NUM>. Method <NUM> may be implemented after the NE, such as NE <NUM>, has established a TCP three-way handshake with the controller, such as NE <NUM>.

At step <NUM>, the NE <NUM> establishes a cBGP peer session with NE <NUM>. For example, NE <NUM> establishes a cBGP peer session with NE <NUM> by sending an OPEN message indicating that NE <NUM> is capable of establishing a cBGP peer session. NE <NUM> then receives an OPEN message from NE <NUM> indicating that NE <NUM> is capable of establishing a cBGP peer session. As described with reference to <FIG>, when both NE <NUM> and NE <NUM> are capable of establishing a cBGP peer session, the cBPG peer session is established between NE <NUM> and NE <NUM>. In an embodiment, a first type of message is permitted to be communicated through the cBGP peer session. For example, the first type of message includes control messages excluding routing information <NUM>, such as instructions, responses to the instructions, and status messages. In this embodiment, messages containing routing information <NUM> are prohibited from being communicated through the cBGP session.

At step <NUM>, NE <NUM> receives a message from NE <NUM> through the cBGP peer session. For example, Tx/Rx <NUM> of NE <NUM> receives a message from NE <NUM> through the cBGP peer session. For example, the message of the first type is an instruction regarding an interface of NE <NUM> and does not contain routing information <NUM>.

At step <NUM>, NE <NUM> transmits a response message to NE <NUM> through the cBGP peer session. For example, Tx/Rx <NUM> of NE <NUM> transmits a response message to NE <NUM> through the cBGP peer session. For example, the response message indicates whether or not NE <NUM> has successfully assigned the segment identifier (SID) to the interface identified in the message sent at step <NUM>.

<FIG> is a diagram illustrating an apparatus <NUM> for establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. The apparatus <NUM> comprises a means for establishing <NUM>, a means for transmitting <NUM>, a means for determining <NUM>, and a means for receiving <NUM>.

In an embodiment in which the apparatus <NUM> is implemented as a controller, the means for establishing <NUM> comprises a means for establishing a cBGP peer session with another NE in the communications system, such as communications system <NUM> or <NUM>. For example, NE <NUM> establishes a cBGP peer session with NE <NUM> by sending an OPEN message indicating that NE <NUM> is capable of establishing a cBGP peer session and receiving an OPEN message from NE <NUM> indicating that NE <NUM> is capable of establishing a cBGP peer session. As described with reference to <FIG>, when both NE <NUM> and NE <NUM> are capable of establishing a cBGP peer session, the cBPG peer session is established between NE <NUM> and NE <NUM>. In an embodiment, the means for receiving <NUM> comprises a means for receiving a message for communication through the cBGP session to an NE <NUM>. In this embodiment, the means for determining <NUM> comprises a means for determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information <NUM>. In this embodiment, the means for transmitting <NUM> comprises a means for transmitting the message to the other NE in the communications system through the cBGP session. In this embodiment, the means for receiving <NUM> comprises a means for receiving a response message from the other NE in the communications system through the cBGP session.

In an embodiment in which the apparatus <NUM> is implemented as an NE in the network excluding the controller, the means for establishing <NUM> comprises establishing a cBPG peer session with the controller of the communications system. For example, NE <NUM> establishes a cBGP peer session with NE <NUM> by sending an OPEN message indicating that NE <NUM> is capable of establishing a cBGP peer session and receiving an OPEN message from NE <NUM> indicating that NE <NUM> is capable of establishing a cBGP peer session. As described with reference to <FIG>, when both NE <NUM> and NE <NUM> are capable of establishing a cBGP peer session, the cBPG peer session is established between NE <NUM> and NE <NUM>. The means for receiving <NUM> comprises receiving a message from the controller through the cBGP session. The means for determining <NUM> comprises a means for determining whether the message is permitted to be communicated through the cBGP session. The means for transmitting <NUM> comprises transmitting a response message to the controller through the cBGP session.

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented. A first type of message is permitted to be communicated through the combined BGP session, in which the first type of message is a control message excluding routing information <NUM>. In this embodiment, a second type of message including routing information <NUM> is also permitted to be communicated through the combined BGP session.

Claim 1:
A method performed by a controller (<NUM>, <NUM>, <NUM>) configured to implement Border Gateway Protocol, BGP, in a communications system (<NUM>, <NUM>, <NUM>), comprising:
(<NUM>) establishing a controller BGP, cBGP, session with a network element, NE (<NUM>);
(<NUM>) receiving a message for communication through the cBGP session to the NE (<NUM>);
(<NUM>) determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information (<NUM>);
(<NUM>) transmitting the message to the NE (<NUM>) through the cBGP session if the message is permitted to be communicated through the cBGP session; and
(<NUM>) receiving a response message of a first type from the NE (<NUM>) through the cBGP session;
the method being characterized in that
the first type of message is permitted to be communicated through the cBGP session and a second type of message is prohibited from being communicated through the cBGP session, wherein the first type of message is a message carrying instructions, whereas the second type of message is a message carrying the routing information (<NUM>); and wherein
the controller (<NUM>, <NUM>, <NUM>) and the NE (<NUM>) are included in a common autonomous system, AS, and the method further comprises: establishing an interior BGP, iBGP, session with the NE (<NUM>), wherein the iBGP session is separate and distinct from the cBGP session; and determining whether a second message received from the NE (<NUM>) includes the routing information (<NUM>) based on a format of the second message; or
the controller (<NUM>, <NUM>, <NUM>) is included in a first autonomous system, AS, whereas the NE (<NUM>) is included in a second AS different from the first AS, and the method further comprises: establishing an exterior BGP, eBGP, session with the NE (<NUM>), wherein the eBGP session is separate and distinct from the cBGP session; and determining whether the second message received from the NE (<NUM>) includes the routing information (<NUM>) based on the format of the second message.